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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)