optimization/902: x86 optimization bug with sibling call and -fomit-frame-pointer
Fergus Henderson
fjh@cs.mu.oz.au
Mon Nov 27 03:16:00 GMT 2000
>Number: 902
>Category: optimization
>Synopsis: x86 optimization bug with sibling call and -fomit-frame-pointer
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Mon Nov 27 03:16:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 2.97 20001124 (experimental)
>Organization:
Comp Sci, University of Melbourne
>Environment:
System: Linux hg 2.2.13 #1 Mon Nov 8 20:35:50 GMT 1999 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: configure --prefix=/usr/local/gcc-snapshot : (reconfigured) configure : (reconfigured) configure --prefix=/usr/local/gcc-snapshot
>Description:
On x86, `gcc -O2 -fomit-frame-pointer' generates incorrect code for
the following example. The generated code crashes with a segmentation
fault when returning from empty(). It looks like sibling call
optimization has generated incorrect code for foo().
>How-To-Repeat:
$ cat bug.c
extern void * malloc (unsigned size);
static void empty(void)
{
}
static void foo (int a, int * b, int c, int * d)
{
malloc(20);
empty();
}
int main ()
{
int x;
int y;
foo(0, &x, 0, &y);
return 0;
}
$ gcc -O2 -fomit-frame-pointer bug.c
$ ./a.out
Segmentation fault
>Fix:
A work-around is to just not use `-fomit-frame-pointer'.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the Gcc-bugs
mailing list