[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