http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-11-18 06:41:15 UTC --- (In reply to comment #2) > Well, thanks for pointing out I was not precise enough. > While "reducing" the problem, I forgot that the difference > lies in where the line > > > > Floating point exception (core dumped) > > ends up. Try redirecting stderr, you'll see that in the first > case (bash on linux) this line does *not* go to stderr, > while in the second case (4.6) it does. When running programs > in a shell with output redirected, the information will end up > in different places. > > So it would be nice to actually write the SIG* information also > to stderr. In 4.7 that's out of libgfortran's control, and I'd argue that fixing it would make other issues worse. So in 4.7 the signal handler basically does 1) Print the backtrace. 2) Reset the handler for the signal to the default. 3) Raise the same signal. This has the benefit that except for the printing of the backtrace, the handling of the signal is identical to how it works with -fno-backtrace. E.g. we get the correct process return value, and the decision whether to generate a core dump or not is done by the OS in an identical fashion. If you check 4.6, you get different process return codes for 1) default (-fno-backtrace), 2) -fbacktrace 3) -fbacktrace -fdump-core. In the latter two cases the exit codes have nothing to do with the fatal signal which was delivered. So to get back to the stdout/stderr issue, in 4.7 the last line of the output is not printed by libgfortran but rather by the OS (libc?) default signal handler for that signal (just like happens with -fno-backtrace). So libgfortran has no say in where it goes. Of course, in 4.7 libgfortran could print a similar line as in 4.6, but that would lead to duplicated output in the common case where stdout and stderr go to the same place.
