https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025
--- Comment #19 from graham.stott at btinternet dot com --- JeffThere's trival error in gcc/config/mips/mti-linux.h which causes loads of warnings everytime it's includedThere's a missing space between a string and MACRO about line 28Graham -------- Original message -------- From: law at redhat dot com <gcc-bugzi...@gcc.gnu.org> Date: 03/04/2019 06:00 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added---------------------------------------------------------------------------- Priority|P3 |P2 Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |law at redhat dot com--- Comment #16 from Jeffrey A. Law <law at redhat dot com> ---In response to c#10 and c#11. I suspect you're not able to trigger thefailures because of something in auto-host.h. If I first configure & installbinutils for the target (mips-mti-linux-gnu), then configure gcc for the sametarget I can trigger the failures per the instructions in this BZ.What I'm unable to figure out is my own comment WRT FRAME_RELATED_P from lastyear. I don't see any evidence this is at all related to FRAME_RELATED_P insnsin delay slots.AFAICT we've done shrink wrapping on this case. ISTM there's multiple paths tothe epilogue, some save r16/r17 and adjust the stack pointer, others do not(according to my reading of the dwarf2cfi pass RTL dump). Thus triggering theCFI failure due to the inconsistency (not to mention bogus code).So of course the next thing to do is look at the prologue/epilogue dump andeverything looks fine there. Things also look fine at the .barriers dump. Then reorg comes along and mucks things up horribly.The bug here is in reorg and its legacy of trying to compensate for the lack ofa CFG. In particular it has a function skip_consecutive_labels. The idea (ofcourse) is to have jumps target the last label if there's several in a row. The code looks something like this: for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn)) if (LABEL_P (insn)) label = insn;THe loop termination condition allows the code to look through notes and otherrandom crud.Now imagine if we have(code_label 1)(barrier)(code_label 2)(more code)The BARRIER after a CODE_LABEL can occur due to __builtin_unreachable.If a jump targets code_label 1, it will be redirected to code_label 2. That'sfine from a runtime standpoint, but runs afoul of the CFI bits. Why?Consider if the jump which targeted label 1 did not have a prologue (we'reshrink wrapping) and "more code" section is a shrink wrapped epilogue.The original paths to code_label 2 will have one CFI state while the new pathsto code_label 1 will have a different CFI state and we trip the check.I'm spinning a fix overnight.
