This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] check_cfg assert fix
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Tom de Vries <vries at codesourcery dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim at codesourcery dot com>
- Date: Tue, 6 Sep 2011 17:13:59 +0200
- Subject: Re: [PATCH] check_cfg assert fix
- References: <4E65E463.6070004@codesourcery.com>
On Tue, Sep 6, 2011 at 11:14 AM, Tom de Vries <vries@codesourcery.com> 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))));
> ...
>
> It triggered on this rtl, a conditional return followed by a barrier:
> ...
> (jump_insn 44 43 93 7 (set (pc)
> ? ? ? ?(if_then_else (ne (reg:CC 24 cc)
> ? ? ? ? ? ? ? ?(const_int 0 [0]))
> ? ? ? ? ? ?(return)
> ? ? ? ? ? ?(pc))) gcc/testsuite/gcc.dg/builtin-unreachable-4.c:13 249
> {*cond_return}
> ? ? (expr_list:REG_DEAD (reg:CC 24 cc)
> ? ? ? ?(expr_list:REG_BR_PROB (const_int 9996 [0x270c])
> ? ? ? ? ? ?(nil)))
> ?-> return)
>
> (barrier 93 44 92)
> ...
>
> Although this insn sequence is non-optimal (the conditional return can be
> optimized to an unconditional one, given that it's followed by a barrier), it's
> not incorrect. The patch fixes this ICE by removing the check for the
> 'EDGE_COUNT (bb->succs) == 1' case.
>
> 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?
Ciao!
Steven