* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
@ 2012-03-15 18:59 ` burnus at gcc dot gnu.org
2012-03-16 8:45 ` kloedej at knmi dot nl
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-15 18:59 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
2012-03-15 18:59 ` [Bug fortran/52594] " burnus at gcc dot gnu.org
@ 2012-03-16 8:45 ` kloedej at knmi dot nl
2012-03-16 11:37 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: kloedej at knmi dot nl @ 2012-03-16 8:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
2012-03-15 18:59 ` [Bug fortran/52594] " burnus at gcc dot gnu.org
2012-03-16 8:45 ` kloedej at knmi dot nl
@ 2012-03-16 11:37 ` burnus at gcc dot gnu.org
2012-03-16 11:49 ` kloedej at knmi dot nl
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-16 11:37 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
` (2 preceding siblings ...)
2012-03-16 11:37 ` burnus at gcc dot gnu.org
@ 2012-03-16 11:49 ` kloedej at knmi dot nl
2012-06-06 7:48 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: kloedej at knmi dot nl @ 2012-03-16 11:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
` (3 preceding siblings ...)
2012-03-16 11:49 ` kloedej at knmi dot nl
@ 2012-06-06 7:48 ` jb at gcc dot gnu.org
2012-12-14 7:59 ` Joost.VandeVondele at mat dot ethz.ch
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-06-06 7:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
` (4 preceding siblings ...)
2012-06-06 7:48 ` jb at gcc dot gnu.org
@ 2012-12-14 7:59 ` Joost.VandeVondele at mat dot ethz.ch
2012-12-14 8:44 ` jb at gcc dot gnu.org
2012-12-14 8:47 ` Joost.VandeVondele at mat dot ethz.ch
7 siblings, 0 replies; 9+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2012-12-14 7:59 UTC (permalink / raw)
To: gcc-bugs
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,... ?)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
` (5 preceding siblings ...)
2012-12-14 7:59 ` Joost.VandeVondele at mat dot ethz.ch
@ 2012-12-14 8:44 ` jb at gcc dot gnu.org
2012-12-14 8:47 ` Joost.VandeVondele at mat dot ethz.ch
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-14 8:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
2012-03-15 18:47 [Bug fortran/52594] New: no traceback expected for explicit fortran stop command combined with -fbacktrace kloedej at knmi dot nl
` (6 preceding siblings ...)
2012-12-14 8:44 ` jb at gcc dot gnu.org
@ 2012-12-14 8:47 ` Joost.VandeVondele at mat dot ethz.ch
7 siblings, 0 replies; 9+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2012-12-14 8:47 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread