Bug 490509 - GCC register allocation wrongly using ebp
Summary: GCC register allocation wrongly using ebp
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 490512
TreeView+ depends on / blocked
 
Reported: 2009-03-16 18:49 UTC by Glauber Costa
Modified: 2009-04-02 09:20 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-02 09:20:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Preprocessed gcc output (495.42 KB, application/octet-stream)
2009-03-16 18:49 UTC, Glauber Costa
no flags Details
Patch that fixes the bug (402 bytes, patch)
2009-03-16 20:10 UTC, Alexandre Oliva
no flags Details | Diff

Description Glauber Costa 2009-03-16 18:49:03 UTC
Created attachment 335390 [details]
Preprocessed gcc output

Description of problem:


Version-Release number of selected component (if applicable):

gcc version 4.4.0 20090313 (Red Hat 4.4.0-0.26) (GCC) 


How reproducible:
Always

Steps to Reproduce:
1. Compile qemu on an i386 host (./configure --target-list=i386-softmmu; make)
2. Run
3. See a segfault
  
Actual results:
QEMU segfaults.

Expected results:
QEMU runs. Sorry for not having a smaller test case for this

Additional info:
This works with older versions of gcc, including 4.3. I'm attaching to this BZ a copy of the preprocessed version of the culprit file (op_helper.c)

If you look closely, you'll see:

register struct CPUX86State *env asm("ebp");

Meaning gcc should not touch it, since it is a global var (or touch it and save it later). The generated object code has something like this:

    b1a3:       09 e8                   or     %ebp,%eax
    b1a5:       89 d5                   mov    %edx,%ebp

which seems invalid to me.

Comment 1 Alexandre Oliva 2009-03-16 20:10:17 UTC
Created attachment 335419 [details]
Patch that fixes the bug

Here's a patch that seems to fix the problem.  Still requires further testing.

Comment 2 Jakub Jelinek 2009-03-17 10:14:22 UTC
When tested, are you going to submit it to gcc-patches together with a testcase (if a small testcase is distillable)?  Thanks.

Comment 3 Alexandre Oliva 2009-03-17 18:48:59 UTC
Yup.  I'm not sure about a testcase, though.  Register allocation testcases are too fragile, even for glaring errors like this.

Comment 4 Alexandre Oliva 2009-03-19 01:23:11 UTC
Patch proposed upstream:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00891.html

Comment 5 Jakub Jelinek 2009-04-02 09:20:39 UTC
This should be fixed in 4.4.0-0.29 and above.


Note You need to log in before you can comment on or make changes to this bug.