Just looking at the Fortran 2018 spec, section 11.4, “STOP and ERROR
STOP statements”. Paragraph 2 says:

When an image is terminated by a STOP or ERROR STOP statement,
its stop code, if any, is made available in a processor-dependent
manner. If the stop-code is an integer, it is recommended that the
value be used as the process exit status, if the processor
supports that concept. If the stop-code in a STOP statement is of
type character or does not appear, or if an end-program-stmt is
executed, it is recommended that the value zero be supplied as the
process exit status, if the processor supports that concept. If
the stop-code in an ERROR STOP statement is of type character or
does not appear, it is recommended that a processor-dependent
nonzero value be supplied as the process exit status, if the
processor supports that concept.

But on VMS, the usual success status code is 1, with other odd values
indicating varying degrees of success, while even values (including
zero) indicate warnings or errors. So how does that work?

On 2/25/2024 7:16 PM, Lawrence D'Oliveiro wrote:
> Just looking at the Fortran 2018 spec, section 11.4, “STOP and ERROR
> STOP statements”. Paragraph 2 says:
>
> When an image is terminated by a STOP or ERROR STOP statement,
> its stop code, if any, is made available in a processor-dependent
> manner. If the stop-code is an integer, it is recommended that the
> value be used as the process exit status, if the processor
> supports that concept. If the stop-code in a STOP statement is of
> type character or does not appear, or if an end-program-stmt is
> executed, it is recommended that the value zero be supplied as the
> process exit status, if the processor supports that concept. If
> the stop-code in an ERROR STOP statement is of type character or
> does not appear, it is recommended that a processor-dependent
> nonzero value be supplied as the process exit status, if the
> processor supports that concept.
>
> But on VMS, the usual success status code is 1, with other odd values
> indicating varying degrees of success, while even values (including
> zero) indicate warnings or errors. So how does that work?

1) "recommended" is a pretty vague term.

2) VMS Fortran is not Fortran 2018 - it is Fortran 95.

3) Fortran 95 spec says:

<quote>
8.4 STOP statement
R840 stop-stmt is STOP [ stop-code ]
R841 stop-code is scalar-char-constant
or digit [ digit [ digit [ digit [ digit ] ] ] ]
Constraint: scalar-char-constant shall be of type default character.
Execution of a STOP statement causes termination of execution of the
program. At the time of
termination, the stop code, if any, is available in a
processor-dependent manner. Leading zero
digits in the stop code are not significant.
</quote>

4) Reality is pretty simple:

$ type Z1.for
program z1
end
$ for Z1
$ link Z1
$ run Z1
$ sh symb $status
$STATUS == "%X00000001"
$ type Z2.for
program z2
stop
end
$ for Z2
$ link Z2
$ run Z2
$ sh symb $status
$STATUS == "%X00000001"
$ type Z3.for
program z3
stop 44
end
$ for Z3
$ link Z3
$ run Z3
44
$ sh symb $status
$STATUS == "%X00000001"
$ type Z4.for
program z4
stop 'Bingo'
end
$ for Z4
$ link Z4
$ run Z4
Bingo
$ sh symb $status
$STATUS == "%X00000001"
$ type Z5.for
program z5
call sys$exit(%val(44))
end
$ for Z5
$ link Z5
$ run Z5
%SYSTEM-F-ABORT, abort
$ sh symb $status
$STATUS == "%X0000002C"

Arne

On 2/25/2024 7:37 PM, Arne Vajhøj wrote:
> 4) Reality is pretty simple:
>
> $ type Z1.for
>       program z1
>       end
> $ for Z1
> $ link Z1
> $ run Z1
> $ sh symb $status
>   $STATUS == "%X00000001"
> $ type Z2.for
>       program z2
>       stop
>       end
> $ for Z2
> $ link Z2
> $ run Z2
> $ sh symb $status
>   $STATUS == "%X00000001"
> $ type Z3.for
>       program z3
>       stop 44
>       end
> $ for Z3
> $ link Z3
> $ run Z3
> 44
> $ sh symb $status
>   $STATUS == "%X00000001"
> $ type Z4.for
>       program z4
>       stop 'Bingo'
>       end
> $ for Z4
> $ link Z4
> $ run Z4
> Bingo
> $ sh symb $status
>   $STATUS == "%X00000001"
> $ type Z5.for
>       program z5
>       call sys$exit(%val(44))
>       end
> $ for Z5
> $ link Z5
> $ run Z5
> %SYSTEM-F-ABORT, abort
> $ sh symb $status
>   $STATUS == "%X0000002C"

One more:

$ type Z6.for
program z6
call lib$stop(%val(44))
end
$ for Z6
$ link Z6
$ set noon
$ run Z6
%SYSTEM-F-ABORT, abort
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
z6 Z6 Z6 2 0000000000000048
0000000000020048
0 FFFFFFFF80340964
FFFFFFFF80340964
%TRACE-I-END, end of TRACE stack dump
$ sh symb $status
$STATUS == "%X1000002C"

Arne

On Sun, 25 Feb 2024 19:37:55 -0500, Arne Vajhøj wrote:

> 2) VMS Fortran is not Fortran 2018 - it is Fortran 95.

Really?? Why?

On 2/25/2024 8:35 PM, Lawrence D'Oliveiro wrote:
> On Sun, 25 Feb 2024 19:37:55 -0500, Arne Vajhøj wrote:
>> 2) VMS Fortran is not Fortran 2018 - it is Fortran 95.
>
> Really?? Why?

HP/HPE did not invest much in VMS, so no new Fortran from them.

VSI is currently busy getting existing VMS functionality working
as-is on VMS x86-64, so no new Fortran from them *yet*.

When porting is complete, then I am sure VSI will start
looking at upgrading compilers and adding new compilers.

But I have no idea whether they will prioritize a
new Fortran compiler or they will focus on something
else (Go, Graal-everything, .NET, Julia, OOify
VMS Pascal, OOify VMS Basic etc.etc.).

The strategy of:
* keeping existing compiler at 95 level
with all the VMS specific extensions
* in parallel add a port of standard flang
which supports 2018
has been mentioned a couple of times here.

I don't know if that is what VSI will do, but it sounds
like a relative easy path. They have LLVM and clang running,
so adding a standard flang frontend should not be that difficult.
At least easier than lifting existing Fortran compiler
to 2018 level. But then I am not a compiler guy.

Arne

In article <urgpt4$26bol$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 25 Feb 2024 19:37:55 -0500, Arne Vajhøj wrote:
>
>> 2) VMS Fortran is not Fortran 2018 - it is Fortran 95.
>
>Really?? Why?

Because engineers should never, ever be allowed to use pointers. Fortran 95
is already going too far.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Sun, 25 Feb 2024 20:48:06 -0500, Arne Vajhøj wrote:

> I don't know if that is what VSI will do, but it sounds like a relative
> easy path. They have LLVM and clang running,
> so adding a standard flang frontend should not be that difficult.

Looking around, I came across this
<https://www.linaro.org/blog/comparing-llvm-flang-with-other-fortran-compilers/>,
from just a few months ago. Seems there is “Classic Flang” and “LLVM
Flang”: the latter is an all-new compiler, but its performance is not
there yet.

Also looks like Gfortran is roughly as good as “Classic Flang”, if not
better than it in some places.

Which Flang will VSI be using?

On Mon, 2024-02-26 at 01:54 +0000, Scott Dorsey wrote:
> > > 2) VMS Fortran is not Fortran 2018 - it is Fortran 95.
> >
> > Really?? Why?
>
> Because engineers should never, ever be allowed to use pointers. 
> Fortran 95 is already going too far.

I second this.
--
Tactical Nuclear Kittens

On 26/02/2024 03:45, Lawrence D'Oliveiro wrote:
> On Sun, 25 Feb 2024 20:48:06 -0500, Arne Vajhøj wrote:
>
>> I don't know if that is what VSI will do, but it sounds like a relative
>> easy path. They have LLVM and clang running,
>> so adding a standard flang frontend should not be that difficult.
>
> Looking around, I came across this
> <https://www.linaro.org/blog/comparing-llvm-flang-with-other-fortran-compilers/>,
> from just a few months ago. Seems there is “Classic Flang” and “LLVM
> Flang”: the latter is an all-new compiler, but its performance is not
> there yet.
>
> Also looks like Gfortran is roughly as good as “Classic Flang”, if not
> better than it in some places.
>
> Which Flang will VSI be using?

Historically VMS Fortran was famous for its extensions and perhaps also
non-standard behaviour. Does Flang includes support for the extensions?

Dave

On 2/26/2024 4:29 AM, Single Stage to Orbit wrote:
> On Mon, 2024-02-26 at 01:54 +0000, Scott Dorsey wrote:
>>>> 2) VMS Fortran is not Fortran 2018 - it is Fortran 95.
>>>
>>> Really?? Why?
>>
>> Because engineers should never, ever be allowed to use pointers.
>> Fortran 95 is already going too far.
>
> I second this.

And as an old time Fortran programmer I will gladly make it three.

bill

On 2/26/2024 5:49 AM, David Wade wrote:
> Historically VMS Fortran was famous for its extensions and perhaps also
> non-standard behaviour. Does Flang includes support for the extensions?

Many VMS extensions got standardized in later Fortran versions,
but several did not, so relevant question.

Flang apparently does not support it.

https://flang.llvm.org/docs/FlangCommandLineReference.html

GFortran on the other hand support some of it.

https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

Arne

On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:

> GFortran on the other hand support some of it.
>
> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

That’s another thing that would have been available for free, if the VMS
port had been based on Linux.

On 2024-02-26 00:16:04 +0000, Lawrence D'Oliveiro said:

> Just looking at the Fortran 2018 spec, section 11.4, “STOP and ERROR
> STOP statements”. Paragraph 2 says:
>
> When an image is terminated by a STOP or ERROR STOP statement,
> its stop code, if any, is made available in a processor-dependent
> manner. If the stop-code is an integer, it is recommended that the
> value be used as the process exit status, if the processor
> supports that concept. If the stop-code in a STOP statement is of
> type character or does not appear, or if an end-program-stmt is
> executed, it is recommended that the value zero be supplied as the
> process exit status, if the processor supports that concept. If
> the stop-code in an ERROR STOP statement is of type character or
> does not appear, it is recommended that a processor-dependent
> nonzero value be supplied as the process exit status, if the
> processor supports that concept.
>
> But on VMS, the usual success status code is 1, with other odd values
> indicating varying degrees of success, while even values (including
> zero) indicate warnings or errors. So how does that work?

C and its run-time will return OpenVMS status values, or will return
traditional UNIX status values, depending on the switches and the
context. By default, C uses the OpenVMS conventions here.

Page 19 and following describes how this works in C on OpenVMS:
https://docs.vmssoftware.com/docs/vsi-c-run-time-library-reference-manual-for-openvms-systems.pdf

Here, Fortran will undoubtedly use the OpenVMS status norms, because
that's what the operating system supports. If there's enough pushback
to VSI, there'll probably be a alter-the-return-values mechanism added.
If that mechanism is not already present in some build.

More generally on OpenVMS, any value with 1 in the low three bits—in
the so-called severity field—is successful. Two of the severity values
defined STS$K_SUCCESS and STS$K_INFO are odd, as well.

Page 244 has general details:
https://docs.vmssoftware.com/docs/vsi-openvms-programming-concepts-manual-volume-i.pdf

The following has the C condition value / return value / error value
details:
https://docs.vmssoftware.com/vsi-c-user-s-guide-for-openvms-systems/#RET_STATUS_SEC

And if you think that "just swap in the Linux kernel" idea you've been
floating won't hit this status difference and myriad other details,
you're headed for a surprise.

--
Pure Personal Opinion | HoffmanLabs LLC

On Mon, 26 Feb 2024 17:11:06 -0500, Stephen Hoffman wrote:

> And if you think that "just swap in the Linux kernel" idea you've been
> floating won't hit this status difference and myriad other details,
> you're headed for a surprise.

We already know how to handle things like that.

On 2/26/2024 4:35 PM, Lawrence D'Oliveiro wrote:
> On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:
>> GFortran on the other hand support some of it.
>>
>> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
>
> That’s another thing that would have been available for free, if the VMS
> port had been based on Linux.

They got a lot more for free by reusing the existing frontend.

Arne

On Mon, 26 Feb 2024 19:17:42 -0500, Arne Vajhøj wrote:

> On 2/26/2024 4:35 PM, Lawrence D'Oliveiro wrote:
>
>> On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:
>>
>>> GFortran on the other hand support some of it.
>>>
>>> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
>>
>> That’s another thing that would have been available for free, if the
>> VMS port had been based on Linux.
>
> They got a lot more for free by reusing the existing frontend.

But not the traditional VMS extensions?

On 2/26/2024 7:53 PM, Lawrence D'Oliveiro wrote:
> On Mon, 26 Feb 2024 19:17:42 -0500, Arne Vajhøj wrote:
>> On 2/26/2024 4:35 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:
>>>> GFortran on the other hand support some of it.
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
>>>
>>> That’s another thing that would have been available for free, if the
>>> VMS port had been based on Linux.
>>
>> They got a lot more for free by reusing the existing frontend.
>
> But not the traditional VMS extensions?

They got those.

Same frontend => same dialect supported.

Arne

On Mon, 26 Feb 2024 20:03:40 -0500, Arne Vajhøj wrote:

> On 2/26/2024 7:53 PM, Lawrence D'Oliveiro wrote:
>>
>> On Mon, 26 Feb 2024 19:17:42 -0500, Arne Vajhøj wrote:
>>>
>>> On 2/26/2024 4:35 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:
>>>>>
>>>>> GFortran on the other hand support some of it.
>>>>>
>>>>> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
>>>>
>>>> That’s another thing that would have been available for free, if the
>>>> VMS port had been based on Linux.
>>>
>>> They got a lot more for free by reusing the existing frontend.
>>
>> But not the traditional VMS extensions?
>
> They got those.
>
> Same frontend => same dialect supported.

I thought you said Flang “apparently does not support” VMS extensions.

On 2/26/2024 8:06 PM, Lawrence D'Oliveiro wrote:
> On Mon, 26 Feb 2024 20:03:40 -0500, Arne Vajhøj wrote:
>
>> On 2/26/2024 7:53 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Mon, 26 Feb 2024 19:17:42 -0500, Arne Vajhøj wrote:
>>>>
>>>> On 2/26/2024 4:35 PM, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> On Mon, 26 Feb 2024 16:00:25 -0500, Arne Vajhøj wrote:
>>>>>>
>>>>>> GFortran on the other hand support some of it.
>>>>>>
>>>>>> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
>>>>>
>>>>> That’s another thing that would have been available for free, if the
>>>>> VMS port had been based on Linux.
>>>>
>>>> They got a lot more for free by reusing the existing frontend.
>>>
>>> But not the traditional VMS extensions?
>>
>> They got those.
>>
>> Same frontend => same dialect supported.
>
> I thought you said Flang “apparently does not support” VMS extensions.

Correct.

But we are talking about VMS Fortran on x86-64 and not flang right?

VMS Fortran on x86-64 use the traditional frontend and support all
VMS extensions.

Flang does not support VMS extensions and does not currently run
on VMS (but could run on VMS some day).

Arne