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

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

[schwab@linux-m68k.org]

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

            Bug ID: 59019
           Summary: [4.9 regression] ICE in advance_target_bb, at
                    sched-rgn.c:3561
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
                CC: law at gcc dot gnu.org
            Target: ia64-*-*

Broken by r204414.

$ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/20050629-1.c -O2 -S -w
../gcc/testsuite/gcc.dg/20050629-1.c: In function ‘finalize_ssa_v_may_def_ops’:
../gcc/testsuite/gcc.dg/20050629-1.c:238:2: internal compiler error: in
advance_target_bb, at sched-rgn.c:3561
  }
  ^
0x400000000095d1cf advance_target_bb
        ../../gcc/sched-rgn.c:3560
0x40000000010da62f commit_schedule
        ../../gcc/haifa-sched.c:5628
0x40000000010f348f schedule_block(basic_block_def**, void*)
        ../../gcc/haifa-sched.c:6424
0x400000000096c60f schedule_region
        ../../gcc/sched-rgn.c:3057
0x400000000096c60f schedule_insns
        ../../gcc/sched-rgn.c:3393
0x400000000096cf1f schedule_insns
        ../../gcc/sched-rgn.c:3378
0x400000000096cf1f rest_of_handle_sched
        ../../gcc/sched-rgn.c:3586
0x400000000096cf1f execute
        ../../gcc/sched-rgn.c:3650
>From gcc-bugs-return-433705-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 06 10:48:59 2013
Return-Path: <gcc-bugs-return-433705-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23236 invoked by alias); 6 Nov 2013 10:48:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20322 invoked by uid 48); 6 Nov 2013 10:46:57 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59014] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
Date: Wed, 06 Nov 2013 10:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59014-4-X9u9f38gdc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59014-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59014-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00482.txt.bz2
Content-length: 348

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY014

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I'd say this is .vrp1.  In .mergephi2, we have

  <bb 4>:
  a.1_11 = a.1_5;
  d = a.1_11;
  return 0;

but in .vrp1:

  <bb 4>:
  a.1_13 = 0;
  a.1_11 = 0;
  d = 0;
  return 0;

And yeah, the bug goes away with -fno-tree-vrp.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

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

[law at redhat dot com]

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.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> 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).

Yet the comment I added should have made it clear that I didn't invent this,
look at the CALL_INSN case just above.  For example, turning a conditional
no-return call into an unconditional one will have the same effect.

> 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. 

Yes, that's a generic issue with passes making things unconditional, the CFG
must be updated.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The problem I see where is we're going to have to run some kind of cleanup
> pass after each RTL pass that might make these transformations (cse, gcse,
> cprop, combine and I'm sure others).  That seems quite heavyweight and bad
> from a compile-time standpoint.
> 
> But I don't really see a way out.  I guess I'm hoping you have other
> suggestions for how we can fix this.

Maybe declare trap_if instructions unconditionally control-flow altering?  They
are probably quite rare in practice, so perhaps this wouldn't really pessimize.

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Always considering trap-if as ending a BB appears to be a bit of a rathole. 
> Every time I squash one issue, another raises its head.

A little unexpected I'd say, what kind of issues does that introduce?

> I did find that combine.c already has some bits to recognize when it does
> something that may muck up the CFG and tries to compensate, it just doesn't
> hadle the situation around trap-if.
> 
> I'm going to see if I can proof of concept a fix in that code.  Of course
> this is a pass specific fix, but as I look deeper, more memories keep coming
> back -- we've had special code in cse.c to deal with similar situations, so
> maybe adding another case for combine isn't that bad after all.

See existing examples in split_all_insns and lra.

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

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu.org

--- Comment #7 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #5)
> Always considering trap-if as ending a BB appears to be a bit of a rathole. 
> Every time I squash one issue, another raises its head.

Heh, I'm surprised that trap-if is not already a control flow insn.
Clearly it can alter control flow. Likewise for a conditional no-return
call.

Anyway, there are lots of places in the compiler where a transformation
results in a CFG cleanup of some sort.  Before this trap-if case, my
favorite was in lower-subreg.c, where splitting a trapping load into
multiple trapping loads -- fun!

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

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
This has gone latent.  Regardless it's relatively easy to fix things up in
combine -- which does similar kinds of things when it's able to collapse a
conditional jump to an unconditional jump and the like.  I'm testing that now
(with a hack that exposes this bug again to ensure the combine.c bits get
exercised).

Basically we just have to remove the now dead insns from the block, zap the
outgoing edges and emit the barrier.

Steven, the reason conditional traps are not considered control flow altering
is that in the event of a trap, then stop execution.  If the condition is
false, they carry-on.  I can see both sides the "they should be considered
control flow altering" -- I'm not passionate enough about either to make a big
deal of it.

Eric, in the chaos of the last few days, I didn't save any of the spots that I
had to change to make conditional traps control flow altering.  I went through
3 or 4 places that needed fixing, then decide to look at working within the
current scheme by fixing up combine...

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

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Trunk no longer exhibits this problem and probably wont, at least not due to
the isolation of erroneous paths optimization due to changes in that code.

There's still on issue here, but it's latent.