When running the testsuite on i686-pc-linux-gnu using 3.4.x or mainline with either -fpic or -fPIC, I get an execution failure in g++.dg/eh/omit-frame- pointer2.C as shown here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00085.html http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00084.html When running the testcase under 3.3.x it passes so this is a regression as of 3.4.x.
I can confirm the segfault, but I'm not sure if this is a gcc bug.
*** Bug 20581 has been marked as a duplicate of this bug. ***
From PR 20581: "The following is a slightly modified version of g++.dg/eh/omit-frame-pointer2.C. It fails with -O -fomit-frame-pointer -mno-accumulate-outgoing-args -fpic (you need all flags). Basic problem is that there are 24 bytes on the stack at the point of the call to f2, which throws, but the code following the landing pad only pops 12 of them, so the return from f1 does not pick up the right address. The unwinder could in principle adjust SP to compensate, but it doesn't; there seems to be sufficient info in the tables to do this, but no such code in the unwinder. I am unsure just how this is supposed to work. // Reduced from PR c++/5246, PR c++/2447 // { dg-options "-O -fomit-frame-pointer" } // { dg-options "-O -fomit-frame-pointer -mno-accumulate-outgoing-args" { target i?86-*-* } } // { dg-do run } void *sp; void step (int) { sp = __builtin_alloca (0); } void f2 (void) { step (2); throw int(); } void f1 (void) { try { step (1); f2 (); step (-1); } catch (int) { step (3); } } int main () { f1 (); return 0; } "
RTH, any thoughts as to how this is supposed to work?
See http://gcc.gnu.org/ml/gcc/2005-03/msg01081.html This fails because exception handling and -fdefer-pop don't work well together. The easy solution is to disable the defer pop optimization when we have function calls that can throw.
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02530.html>.
Subject: Bug 19225 CVSROOT: /cvs/gcc Module name: gcc Changes by: dalej@gcc.gnu.org 2005-03-30 20:21:39 Modified files: gcc : ChangeLog calls.c Log message: 2005-03-30 Dale Johannesen <dalej@apple.com> PR middle-end/19225 * calls.c (expand_call): Flush pending deferrals before throwing call. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8037&r2=2.8038 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.384&r2=1.385
Fixed (4.1 only)
(Bugs should not be marked as FIXED, nor the target milestone moved, so long as they are still open against 3.4 or later, unless it has been decided that they will not be fixed there, so I've reopened this one.) Dale, is there any reason that you do not think it's appropriate to apply this patch to the release branches? If not, please apply. Thanks, -- Mark
Subject: Bug 19225 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: dalej@gcc.gnu.org 2005-04-06 01:11:42 Modified files: gcc : ChangeLog calls.c Log message: 2005-04-05 Dale Johannesen <dalej@apple.com> PR middle-end/19225 * calls.c (expand_call): Flush pending deferrals before throwing call. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.133&r2=2.7592.2.134 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.378.8.1&r2=1.378.8.2
Subject: Bug 19225 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: dalej@gcc.gnu.org 2005-04-06 21:01:53 Modified files: gcc : ChangeLog calls.c Log message: 2005-04-06 Dale Johannesen <dalej@apple.com> PR middle-end/19225 * calls.c (expand_call): Flush pending deferrals before throwing call. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.834&r2=2.2326.2.835 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.315.2.7&r2=1.315.2.8
Also fixed in 4.0 and 3.4 branches. Closing.