[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-09-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-09-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Sep 15 09:21:09 2018
New Revision: 264342

URL: https://gcc.gnu.org/viewcvs?rev=264342=gcc=rev
Log:
PR middle-end/86864
* cfgexpand.c (expand_gimple_basic_block): Be prepared for a BARRIER
before and after a JUMP_TABLE_DATA.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20180915-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-09-14 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-08-21 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-08-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
The issue looks like that

(jump_insn 19 18 20 3 (parallel [
(set (pc)
(reg:DI 94))
(use (label_ref 21))
]) -1
 (nil)
 -> 21)
(barrier 20 19 21)

doesn't have the jump at the end.  Whoever inserted that barrier insn did it
wrong.  But I'm not too much of an expert here either.

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-08-06 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It's strange because the CFG looks fine in optimized dump:

g (int b, int c, int d)
{
  long int a.0_1;

   [local count: 1073741825]:
  if (b_5(D) > 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 1073741825]:
  switch (b_5(D))  [75.00%], case 29:  [25.00%], case 32:
 [25.00%], case 40:  [25.00%], case 42:  [25.00%], case 48:
 [25.00%]>

   [count: 0]:
:
  __builtin_unreachable ();

   [local count: 1073312327]:
  # c_2 = PHI <1(2), 2(3)>
:
  if (d_6(D) != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719119259]:
  a.0_1 = a;
  if (a.0_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 713752697]:
  f ();

   [local count: 1073312326]:
  if (c_2 == 1)
goto ; [20.24%]
  else
goto ; [79.76%]

   [local count: 217238415]:
  f (); [tail call]

   [local count: 1073312326]:
  return;

I'm adding Jakub and Richi, they are more familiar with GIMPLE representation.

[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-08-06 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-06
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, mine.