This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
- From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 31 Aug 2015 21:12:46 +0000
- Subject: [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation
- Auto-submitted: auto-generated
- References: <bug-53379-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #22 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Joost VandeVondele from comment #21)
> Since it is mostly a 'taste' issue when to emit a backtrace or not, I think
> it makes sense to just make it an option flag, either never or always emit a
> backtrace. The flag '-fbacktrace' already exists and it could imply generate
> a backtrace on every 'error termination', run time error, or deadly signals.
>
> I would find that very useful.
I strongly second that. Backtraces are useful for those informed, and can be
turned off (or ignored) by the non expert. So, I think every error termination
should print a backtrace.
That is: any case where we call abort(), or call exit() with non-zero status.
Except, possibly, user-specified non-zero status (like "STOP 42").
PS: Regarding the argument that many runtime errors already indicate the source
file and line number for the error, wellâ a backtrace has much more indication
since it indicates the entire code path for the error.