[Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

Tobias Burnus-5
At some point, 'call abort()' was changed to 'stop'; this works fine as
long as exit status is != 0. At least on my Linux system, this works
until 255. (Which matches POSIX, which requires 8 bits.) For "stop 256",
I get an exit status == 0.

I am not sure whether other systems break earlier, but I assume most
support 0 to 255. Currently, gcc/testsuite/*fortran* has those maximal
'stop' counts:

127
127
144
174
192
240
1516 ! <-- this was patched.

In libgomp, the current record are 222 and 242. Hence, when adding
extensive test cases, one needs to watch out!

Cheers,

Tobias


committed.diff (517 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

Steve Kargl
On Thu, Oct 31, 2019 at 05:46:38PM +0100, Jakub Jelinek wrote:

> On Thu, Oct 31, 2019 at 09:42:07AM -0700, Steve Kargl wrote:
> > On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> > > At some point, 'call abort()' was changed to 'stop'; this works fine as
> > > long as exit status is != 0. At least on my Linux system, this works
> > > until 255. (Which matches POSIX, which requires 8 bits.) For "stop 256",
> > > I get an exit status == 0.
> > >
> > > I am not sure whether other systems break earlier, but I assume most
> > > support 0 to 255. Currently, gcc/testsuite/*fortran* has those maximal
> > > 'stop' counts:
> >
> > FreeBSD's manpage for exit(3) (and _Exit()) states
> >
> >      Both functions make the low-order eight bits of the status
> >      argument available to a parent process which has called a
> >      wait(2)-family function.
> >
> > I suspect the other BSDs also follow posix.  I wonder if gfortran
> > should either apply a mask to the stop code or simply map nonzero
> > values to one of EXIT_FAILURE, SIGQUIT, or SIGABRT.  Perhaps,
>
> I think being able to supply the exact code to shell is useful,
> perhaps we should just use
>   exit (code > 255 ? 255 : code);
> or similar?
>

I'm fine with this option.  I'll work up a patch
later with the above, and add some documentation
to the gfortran manual.

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: [Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

Janne Blomqvist-3
In reply to this post by Tobias Burnus-5
On Thu, Oct 31, 2019 at 7:03 PM Steve Kargl
<[hidden email]> wrote:

>
> On Thu, Oct 31, 2019 at 05:51:38PM +0100, Tobias Burnus wrote:
> > On 10/31/19 5:42 PM, Steve Kargl wrote:
> > > I suspect the other BSDs also follow posix. I wonder if gfortran
> > > should either apply a mask to the stop code or simply map nonzero
> > > values to one of EXIT_FAILURE, SIGQUIT, or SIGABRT. Perhaps,
> > >
> > > -  exit (code);
> > > +  exit (EXIT_FAILURE);
> >
> >
> > Or "exit (code > 255 ? EXIT_FAILURE : code);". I think EXIT_FAILURE is 1
> > on most systems. I recall that windows interpreted exit(3) as abort,
> > which can also be surprising. (But is fine for our testsuite purpose.)
>
> As I replied to Jakub, I'm fine with the ternary expression.
>
> I did a brief scan of signal.h, and there is a SIGSTOP.
> Depending on whether a user installed a signal handler,
> SIGSTOP might lead to a zombie process so I did not
> mention it as a possibility.

I'd personally prefer the current behavior. I.e. just let the
underlying OS/libc handle it as it sees fit. No need to invent our own
semantics here. Tobias quoted the relevant part of the standard, which
the current implementation fulfills just fine.

--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

Re: [Patch,committed] Ensure that gfortran.dg/achar_2.f90 can fail

Janne Blomqvist-3
On Thu, Oct 31, 2019 at 10:04 PM Steve Kargl
<[hidden email]> wrote:

>
> On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
> >
> > I'd personally prefer the current behavior. I.e. just let the
> > underlying OS/libc handle it as it sees fit. No need to invent our own
> > semantics here. Tobias quoted the relevant part of the standard, which
> > the current implementation fulfills just fine.
> >
>
> I'm fine with that.  I suppose someone should
> document how gfortran communicates an exit
> status to an invoking shell handle; especially
> when the stop codes exceeds 255.

In principle yes, but how to do it without bogging down into minutiae
of how different targets allow retrieving the process exit status?

For POSIX, we can say that the 8 lowest order bits are used.  Except
if using the POSIX 2008 waitid() function which allows the parent
process to retrieve the full 32 bits. And Windows apparently use
32-bit unsigned integers. And then all the weird targets that a
handful of people around the world for some reason care about, etc.

More info at wikipedia: https://en.wikipedia.org/wiki/Exit_status

Perhaps some note that positive integers in the range [0,255] are
somewhat portable?

--
Janne Blomqvist