Bug 139929

Summary: Invalid code generated for __builtin_setjmp with -fomit-frame-pointer
Product: [Fedora] Fedora Reporter: Tom Hughes <tom>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-22 10:48:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test case none

Description Tom Hughes 2004-11-18 20:10:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
When -fomit-frame-pointer is used with
__builtin_setjmp/__builtin_longjmp incorrect code is sometimes
produces that causes the stack pointer to be positioned wrongly after
a jump is taken.

Version-Release number of selected component (if applicable):
gcc-3.4.2-6.fc3

How reproducible:
Always

Steps to Reproduce:
Compile the attached code with the following command:

  cc -Wall -O -g -fomit-frame-pointer -o setjmp setjmp.c

Run the code and notice that the address of the local variables
changes after the longjmp is taken. It then crashes.
    

Additional info:

Comment 1 Tom Hughes 2004-11-18 20:10:41 UTC
Created attachment 106985 [details]
Test case

This is the test case for the bug.

Comment 2 Tom Hughes 2004-11-18 20:11:25 UTC
One other thing - I've tried this with clean 3.4.2 and 3.4.3 builds
from the gcc.gnu.org source and neither of those fails in this way.

Comment 3 Jakub Jelinek 2004-11-18 20:45:03 UTC
Well, I can certainly reproduce it with stock 3.4 branch (both mid October
and         .ident  "GCC: (GNU) 3.4.4 20041118 (prerelease)").
The important options for reproduction are -O -fomit-frame-pointer -m32 -march=i386
Maybe your self built gcc 3.4.[23] defaulted to -mtune=i686 or something else.


Comment 4 Tom Hughes 2004-11-18 20:58:14 UTC
Must have done - all I did was run configure with no arguments. I just
tried 3.4.3 with -mtune=i386 and that fails. Will you punt this
upstream or should I report this on the gcc tracker?

Comment 5 Jakub Jelinek 2004-11-18 21:00:30 UTC
I believe http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01562.html
should fix it, just need to verify that.


Comment 6 Jakub Jelinek 2004-11-22 10:48:46 UTC
Should be fixed in gcc-3.4.3-4 in rawhide.