Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Apr 19, 2018 at 11:19:31AM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König <tk@tkoenig.net> wrote:
> > > > the recent patch to make the gfortran and libgomp testsuites more
> > > > standard conforming, by replacing CALL ABORT() with STOP N, led
> > > > to numerous testsuite failures on nvptx because stop_numeric
> > > > was not implemented in minimal.c.
> > > > 
> > > > I have committed the patch below in r259072 as obvious after Tom
> > > > de Vries had confirmed that it solves the problem.
> > > 
> > > ... for some meaning of "solves the problem"; see below.  ;-) Which you
> > > couldn't know, of course.  (So, definitely thanks anyway, for promptly
> > > addressing the issue raised!)
> > 
> > My preference would be just to revert the call abort to stop n changes
> > in target regions.
> 
> That seems backwards to me -- having "exit" (as well as Fortran language
> "stop" and "error stop") inside offloaded regions do the right thing is
> something we wanted to do anyway, eventually.

I'm looking for a GCC8 fix, and for that it seems like the simplest
and safest solution.

> > Mapping exit to abort is weird
> 
> Sure, that's why PR85463 is still open, and has some (initial)
> comments/ideas regarding that.
> 
> > and making exit terminate whole process even
> > when called from offloaded regions might be too expensive.
> 
> In what way "too expensive"?

If you need to add code to handle that case to every target region entry
just in case something does stop, the slow down might be too high and
unacceptable.  Depends on how it is implemented.

	Jakub