[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 --- Comment #10 from Aldy Hernandez --- Author: aldyh Date: Wed Sep 13 17:28:54 2017 New Revision: 252573 URL: https://gcc.gnu.org/viewcvs?rev=252573&root=gcc&view=rev Log: PR81747, ICE in operator[] PR rtl-optimization/81747 * cse.c (cse_extended_basic_block): Don't attempt to record equivalences for degenerate conditional branches that branch to their fall-through. Modified: branches/range-gen2/gcc/ChangeLog branches/range-gen2/gcc/cse.c
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Alan Modra --- Fixed
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 --- Comment #8 from Alan Modra --- Author: amodra Date: Fri Aug 25 12:21:00 2017 New Revision: 251349 URL: https://gcc.gnu.org/viewcvs?rev=251349&root=gcc&view=rev Log: PR81747, ICE in operator[] PR rtl-optimization/81747 * cse.c (cse_extended_basic_block): Don't attempt to record equivalences for degenerate conditional branches that branch to their fall-through. Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 --- Comment #7 from Alan Modra --- Yeah, I have more or less the same patch about to be bootstrapped.
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747
--- Comment #6 from Segher Boessenkool ---
Yeah, I found out it is _not_ the one the backtrace (or GDB) points at.
I have a patch:
===
diff --git a/gcc/cse.c b/gcc/cse.c
index 6a968d1..34650d2 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -6642,6 +6642,7 @@ cse_extended_basic_block (struct cse_basic_block_data
*ebb
if (path_entry < path_size - 1
&& JUMP_P (insn)
&& single_set (insn)
+ && EDGE_COUNT (bb->succs) == 2
&& any_condjump_p (insn))
{
basic_block next_bb = ebb_data->path[path_entry + 1].bb;
===
Do you want to handle it? More your timezone than mine ;-)
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 --- Comment #5 from Alan Modra --- Segher, the confusion is due to looking at the wrong BRANCH_EDGE occurrence in cse.c
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 --- Comment #4 from Segher Boessenkool --- Yeah, but the condition in which BRANCH_EDGE is called starts with if (EDGE_COUNT (previous_bb_in_path->succs) == 2 so I'm confused now.
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3 from Alan Modra ---
The ICE occurs on this line in cse.c
bool taken = (next_bb == BRANCH_EDGE (bb)->dest);
looking at the definition of BRANCH_EDGE,
EDGE_SUCC ((bb), 0)->flags & EDGE_FALLTHRU is true
but
p *bb->succs
$4 = {m_vecpfx = {m_alloc = 4, m_using_auto_storage = 0, m_num = 1}, m_vecdata
= {0x76a32658}}
So only one successor, and attempting to access EDGE_SUCC(bb,1) is what
triggers the ICE.
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Segher Boessenkool changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Target|powerpc-*-linux-gnu*, |powerpc*-*-linux-gnu*, |powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu* --- Comment #2 from Segher Boessenkool --- This ICEs on any powerpc, not just 32-bit or with isel, etc. The ICE is gone if you make the function return a value, so it is ICE-on-invalid (at least since C99).
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 CC||amodra at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r244465 (one needs to apply patch from r244489).
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
