[Bug target/63534] New: [5 Regression] Bootstrap failure on x86_64/i686-linux
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Oct 14 12:31:00 GMT 2014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Bug ID: 63534
Summary: [5 Regression] Bootstrap failure on x86_64/i686-linux
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: ian at gcc dot gnu.org, kyukhin at gcc dot gnu.org, law at gcc dot gnu.org,
vmakarov at gcc dot gnu.org
r216154 broke bootstrap on x86_64-linux and i686-linux for me, pretty much
everything in libgo ICEs, including as simple testcases as:
void foo (void) {}
with -m32 -fsplit-stack -fpic (with or without -O?).
Seems the pro_and_epilogue pass adds insn like:
(insn 14 13 15 3 (set (reg:SI 3 bx)
(reg:SI 83)) g2.i:3 90 {*movsi_internal}
(nil))
before a call to __morestack added during the prologue expansion, which of
course isn't right, this is after reload and using a pseudo is not allowed.
Also, looking at a simple testcase like:
void foo (void) { bar (); bar (); }
I see wrong-code for -m32 -O2 -fpic -p:
there is
call *mcount@GOT(%ebx)
before set_got is invoked, so if e.g. the routine is called from executable,
where %ebx can contain pretty much anything, it will crash, or if it is called
from a different shared library, it will access unrelated pointer in that other
shared library's got rather than current library's got.
And lastly, I'm seeing on the same testcase significant code quality regression
with just -m32 -O2 -fpic:
.cfi_startproc
- pushl %ebx
+ pushl %esi
.cfi_def_cfa_offset 8
- .cfi_offset 3, -8
- call __x86.get_pc_thunk.bx
- addl $_GLOBAL_OFFSET_TABLE_, %ebx
- subl $8, %esp
+ .cfi_offset 6, -8
+ pushl %ebx
+ .cfi_def_cfa_offset 12
+ .cfi_offset 3, -12
+ call __x86.get_pc_thunk.si
+ addl $_GLOBAL_OFFSET_TABLE_, %esi
+ subl $4, %esp
.cfi_def_cfa_offset 16
+ movl %esi, %ebx
call bar@PLT
call bar@PLT
- addl $8, %esp
- .cfi_def_cfa_offset 8
+ addl $4, %esp
+ .cfi_def_cfa_offset 12
popl %ebx
.cfi_restore 3
+ .cfi_def_cfa_offset 8
+ popl %esi
+ .cfi_restore 6
.cfi_def_cfa_offset 4
ret
.cfi_endproc
Here, the register allocator makes a bad decision (load the got into %esi
rather than %ebx, both are call saved registers, but we need it in %ebx), and
nothing after LRA fixes it up (postreload, etc.).
Can the problematic commit be reverted and all these issues analyzed and fixed
before it is reapplied?
More information about the Gcc-bugs
mailing list