From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16226 invoked by alias); 18 Nov 2011 06:42:13 -0000 Received: (qmail 16214 invoked by uid 22791); 18 Nov 2011 06:42:12 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BG X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Nov 2011 06:41:59 +0000 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/51197] [4.7 Regression] Backtrace information less useful Date: Fri, 18 Nov 2011 07:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg01860.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 --- Comment #3 from Janne Blomqvist 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.