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?