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

2013-11-18 Thread 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

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

2013-11-15 Thread 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

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

2013-11-08 Thread 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

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

2013-11-08 Thread 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

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

2013-11-07 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019 --- Comment #3 from Jeffrey A. Law law at redhat dot com --- OK, making a conditional no-return call into an unconditional no-return call would have the same problem. Ugh. The problem I see where is we're going to have to run some kind of

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

2013-11-07 Thread 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

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

2013-11-07 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019 --- Comment #5 from Jeffrey A. Law law at redhat dot com --- 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. I did find that combine.c already has some bits to

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

2013-11-06 Thread 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

2013-11-06 Thread 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

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

2013-11-06 Thread 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