[Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561

["law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-07
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |law at redhat dot com
     Ever confirmed|0                           |1

--- Comment #1 from Jeffrey A. Law <law at redhat dot com> ---
This is a latent bug that the path isolation code happens to expose.

The fundamental problem is prior to combine we have the following RTL:

(insn 25 3 6 2 (set (reg/v:SI 340 [ new_i ])
        (const_int 0 [0])) j.c:225 -1
     (nil))
(insn 6 25 24 2 (set (reg:BI 343)
        (eq:BI (reg/v:SI 340 [ new_i ])
            (const_int -1 [0xffffffffffffffff]))) j.c:225 309 {*cmpsi_normal}
     (expr_list:REG_DEAD (reg/v:SI 340 [ new_i ])
        (nil)))
(insn 24 6 15 2 (trap_if (eq (reg:BI 343)
            (const_int 0 [0]))
        (const_int 0 [0])) -1
     (expr_list:REG_DEAD (reg:BI 343)
        (nil)))
(insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1
     (expr_list:REG_UNUSED (reg/i:SI 8 r8)
        (nil)))


At this stage insn 24 is not considered a control flow altering insn -- it's a
conditional trap.



Combine does its thing and we end with:

(insn 24 6 15 2 (trap_if (const_int 1 [0x1])
        (const_int 0 [0])) 363 {*trap}
     (nil))
(insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1
     (expr_list:REG_UNUSED (reg/i:SI 8 r8)
        (nil)))

Now insn 24 is an unconditional trap and is considered a control flow altering
insn (see Eric's change for PR29841).  Since we have a control flow altering
insn in the middle of a block, we trip the checking failure.

This seems like a pretty fundamental problem.   I can't think of any other case
where we allow optimizations to turn an insn which does not alter flow control
into a flow control altering insn (obviously we allow the opposite and it's
good).

This means that every pass which might potentially turn a conditional trap into
an unconditional trap would have to run DCE afterwards or otherwise cleanup the
code after the trap to avoid this problem.  Not good.

Or we would have to force each optimizer which might potentially turn a
conditional trap into an unconditional trap run find_many_sub_basic_blocks. 
Also not good.

Or we could hack the ia64 port in some horrid way to avoid this problem.  Even
worse.

I'm open to suggestions.