Missing barrier in outof_cfglayout

Jeff Law law@redhat.com
Mon May 11 16:58:00 GMT 2015

On 05/11/2015 10:19 AM, Georg-Johann Lay wrote:
> When pass outof_cfglayout is adding barriers, it appears that it misses
> some situations and then runs into "ICE: missing barrier" in the
> remainder (or, with checking disabled, into some other assertion).
[ ... ]

> The last else is entered for an UNconditional jump with e_fall = 0 so
> that after the unconditional jump_insn no barrier is emit.
> Now I am unsure about the right condition when to add the missing
> barrier; the following change works, but presumably the condition is
> only 99% correct ;-)
But why is there a JUMP_INSN here to start with?   Prior to cfglayout I 
believe simple unconditional jumps shouldn't exist in the INSN chain. 
Instead they are inserted as we leave cfglayout based on the state of 
the CFG.

> The respective BB has just that unconditional jump_insn; it is generated
> by CSE1 as it optimized a switch statement and was originally some
> conditional jump (-fno-jump-tables) or computed jump (with -fjump-tables):
This is where I'd focus my efforts.  Instead of modifying the JUMP_INSN 
directly, we're supposed to be going through the various CFG routines.

Most likely it's this code:
      /* If this SET is now setting PC to a label, we know it used to
          be a conditional or computed branch.  */
       else if (dest == pc_rtx && GET_CODE (src) == LABEL_REF
                && !LABEL_REF_NONLOCAL_P (src))

              new_rtx = emit_jump_insn_before (gen_jump (XEXP (src, 0)), 
               JUMP_LABEL (new_rtx) = XEXP (src, 0);
               LABEL_NUSES (XEXP (src, 0))++;

And it almost certainly should be calling into the cfgrtl.c routines 


More information about the Gcc mailing list