http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #8 from Joost VandeVondele
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #7 from Janne Blomqvist 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 co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #4 from Jos de Kloe 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #3 from Tobias Burnus 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 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #2 from Jos de Kloe 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
