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

classic Classic list List threaded Threaded
5 messages Options
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: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,

Index: runtime/stop.c
===================================================================
--- runtime/stop.c      (revision 277638)
+++ runtime/stop.c      (working copy)
@@ -123,7 +123,7 @@ stop_numeric (int code, bool quiet)
       report_exception ();
       st_printf ("STOP %d\n", code);
     }
-  exit (code);
+  exit (EXIT_FAILURE);
 }


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

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

Jakub Jelinek
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?

        Jakub

Reply | Threaded
Open this post in threaded view
|

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

Tobias Burnus-3
In reply to this post by Steve Kargl
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.)

SIGABRT sounds wrong for STOP as:

"Execution of a STOP statement initiates normal termination of
execution.  Execution of an ERROR STOP statement initiates error
termination of execution."

Otherwise, the standard states: "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."

Cheers,

Tobias

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

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

--
Steve