On 7/09/2011, at 3:13 AM, Steven Bosscher wrote: > On Tue, Sep 6, 2011 at 11:14 AM, Tom de Vries <[email protected]> wrote: >> Hi, >> >> During testing the approved-for-commit middle-end patch for bug 43864 on >> ARM, I >> ran into a gcc.dg/torture/pr46068.c ICE. >> >> The following assert in haifa-sched.c:check_cfg triggered: >> ... >> else if (any_condjump_p (head)) >> gcc_assert (/* Usual case. */ >> (EDGE_COUNT (bb->succs) > 1 >> && !BARRIER_P (NEXT_INSN (head))) >> /* Or jump to the next instruction. */ >> || (EDGE_COUNT (bb->succs) == 1 >> && (BB_HEAD (EDGE_I (bb->succs, 0)->dest) >> == JUMP_LABEL (head)))); >> ... >> Bootstrapped and reg-tested on x86_64 and build and reg-tested on arm. >> >> OK for trunk? > > No. If the conditional return is not taken, you should not fall into a > barrier. It looks like the CFG somehow got corrupted, and if that's > indeed the case then your patch just papers over the problem. That > follows after the barrier?
Initially, I thought so too, that is why I wrote the above assert in the first
place. However, __builtin_unreachable() adds a whole new spin on where a
BARRIER can occur; after all, this built-in expands directly to BARRIER.
Before Tom's optimization the fall-through path of conditional jump was
followed by an unconditional jump to a label directly followed by a barrier.
Tom's patch removed the middle-man in the face of unconditional jump so that
the barrier now follows a conditional jump. This is very odd, but, given the
initial test case, is a valid case.
For reference, the test case in question:
/* { dg-do compile } */
void
foo ()
{
asm goto (""::::l1);
__builtin_unreachable ();
l1:;
}
void
bar ()
{
foo ();
foo ();
}
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
smime.p7s
Description: S/MIME cryptographic signature
