[Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace

[Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace

[kloedej at knmi dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

             Bug #: 52594
           Summary: no traceback expected for explicit fortran stop
                    command combined with -fbacktrace
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kloedej@knmi.nl


I noticed that a full traceback is generated when gfortran executables exit
after an explicit stop command in the code.
Although useful in some cases, I would like to request an additional
commandline switch to block this behaviour.

My reasons:
-I am developing a collection of fortran software and am running routinely a
large number of unittests on them. A significant number of these unit tests
provoke the tool to stop with non-zero exit status (usually by inserting faulty
data that should trigger some safety checks in the software).
-I would like to easily discriminate real programming errors that can be
detected by gfortran (i.e. segmentation fault, illegal instruction, bus error
or floating-point exception, etc., as mentioned on the manpage), from these
explicit stop commands.
-the current situation where both types of conditions generate a full traceback
makes it hard to interpret the results because the interesting tracebacks get
lost in the large number of unwanted tracebacks from explicit stops.

Maybe you could consider implementing an option like: -fno-traceback-on-stop to
remedy this?

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-15 18:57:49 UTC ---
Using the current GCC 4.6 (4.6.4 20120310), I get by default no backtrace. Only
with -fbacktrace, I indeed get a backtrace when using STOP 1 but not one for
STOP 0.

Solution: Use -fno-backtrace (which is the default in 4.6).


With GCC 4.7 (and 4.8) -fbacktrace is now enabled default. However, you no
longer get a backtrace for STOP 1 or ERROR STOP 1.

Thus, I think GCC 4.7 and 4.8 do what you want. (GCC 4.7.0 will be released in
the next days, 4.8 is the current developer version.)

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[kloedej at knmi dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

--- Comment #2 from Jos de Kloe <kloedej at knmi dot nl> 2012-03-16 08:28:11 UTC ---
Thanks for your answer.
Using stop 0 or stop 1 would indeed be a way around, but the awkward thing is
that I do have some requirements to produce different values for the exit
status for different error conditions. So using stop 1 everywhere is no
solution for me.

Anyway, this bug is just a feature request, so it is up to you developers to
decide if you want to implement this or not.

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-16 11:13:17 UTC ---
(In reply to comment #2)
> Thanks for your answer.
> Using stop 0 or stop 1 would indeed be a way around

I am lost.

With GCC 4.6 and an explicit -fbacktrace, I *do* get a backtrace for any
nonzero integer/exit status in STOP/ERROR STOP. (And none for zero.)

In GCC 4.7 and 4.8 (which have -fbacktrace already implicitly), I *do* *not*
get a backtrace for STOP/ERROR STOP, independent whether the integer is nonzero
or not.

> Anyway, this bug is just a feature request, so it is up to you developers to
> decide if you want to implement this or not.

I still believe that GCC 4.7 and 4.8 handle it - by default - as you would
like.

(Cf. http://gcc.gnu.org/wiki/GFortranBinaries ; if you are under Linux, your
distribution will likely have some 4.7 packages available - either in some
special branch or in their development version, cf. also
http://gcc.gnu.org/wiki/GFortranDistros)

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[kloedej at knmi dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

--- Comment #4 from Jos de Kloe <kloedej at knmi dot nl> 2012-03-16 11:36:48 UTC ---
> I am lost.

The way around that I mentioned was for gcc 4.7+ (so I cannot test this right
away, but will upgrade as soon as it is feasible for me).

Anyway, thanks for your thoughts.

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jb at gcc dot gnu.org
         Resolution|                            |WONTFIX

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-06-06 07:48:30 UTC ---
Based on the discussion here, 4.7+ already does what the reporter wants. 

For 4.6 and older releases, as it isn't a regression we shouldn't change the
behavior. Hence, closing as wontfix.

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch

--- Comment #6 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-14 07:59:30 UTC ---
I was just about to file a bugreport that STOP 1 should yield a backtrace if
compiled with -fbacktrace.... that would really be useful to debug code that
just calls 'STOP 1' on some error condition (of course happening only with
10000 MPI tasks, so no gdb as far as I can manage). I would be happy to have
-fbacktrace=STOP as a way to specify more explicitly when an error should
happen (generalizable to -fbacktrace=STOP,ALLOCATE,... ?)

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-14 08:44:44 UTC ---
(In reply to comment #6)
> I was just about to file a bugreport that STOP 1 should yield a backtrace if
> compiled with -fbacktrace.... that would really be useful to debug code that
> just calls 'STOP 1' on some error condition (of course happening only with
> 10000 MPI tasks, so no gdb as far as I can manage). I would be happy to have
> -fbacktrace=STOP as a way to specify more explicitly when an error should
> happen (generalizable to -fbacktrace=STOP,ALLOCATE,... ?)

FWIW, you can get a backtrace by calling the ABORT intrinsic instead.

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594

--- Comment #8 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-14 08:47:14 UTC ---
(In reply to comment #7)

> FWIW, you can get a backtrace by calling the ABORT intrinsic instead.

thanks... I'm using that now. 

However, that requires changing a lot of places in the code unfortunately (and
abort is an extension, so we can't put it in the code 1-to-1).