Fortran Exit Codes

[Lawrence D'Oliveiro]

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?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro
Just looking at the Fortran 2018 spec, section 11.4, “STOP and ERROR
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

[Arne Vajhøj]

Post by Arne Vajhøj
$ 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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
2) VMS Fortran is not Fortran 2018 - it is Fortran 95.

Really?? Why?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Lawrence D'Oliveiro]

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?

[David Wade]

Post by Lawrence D'Oliveiro

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

[Arne Vajhøj]

Post by David Wade
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Scott Dorsey]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Single Stage to Orbit]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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.

[bill]

Post by Single Stage to Orbit

Post by Scott Dorsey

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Stephen Hoffman]

Post by Lawrence D'Oliveiro
Just looking at the Fortran 2018 spec, section 11.4, “STOP and ERROR
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.

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
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.