https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025
Jeffrey 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 the
failures because of something in auto-host.h. If I first configure & install
binutils for the target (mips-mti-linux-gnu), then configure gcc for the same
target 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 last
year. I don't see any evidence this is at all related to FRAME_RELATED_P insns
in delay slots.
AFAICT we've done shrink wrapping on this case. ISTM there's multiple paths to
the 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 the
CFI 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 and
everything 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 of
a CFG. In particular it has a function skip_consecutive_labels. The idea (of
course) 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 other
random 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's
fine 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're
shrink 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 paths
to code_label 1 will have a different CFI state and we trip the check.
I'm spinning a fix overnight.
