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

2012-12-14 Thread 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

 1 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

2012-12-14 Thread 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).


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

2012-12-13 Thread 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

1 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

2012-06-06 Thread 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

2012-03-16 Thread 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

2012-03-16 Thread 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

2012-03-16 Thread 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

2012-03-15 Thread 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.)