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