[Bug tree-optimization/111458] [11 Regression] ICE in in dfs_enumerate_from, at cfganal.c:1560

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458

--- Comment #4 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #3)

> This issue is still latent in the forward threader.  The backward threader
> calls this function from back_threader_profitability::profitable_path_p,
> so before doing any CFG changes.  In GCC 12 and later the remaining forward
> threader instances are all from DOM(?).

Yes.  Remaining uses of the forward threader are all from DOM.

I'd like to remove the forward threader in the next release, but it requires
being absolutely sure ranger catches everything the scoped tables do,
especially the floating point stuff.

[Bug tree-optimization/111458] [11 Regression] ICE in in dfs_enumerate_from, at cfganal.c:1560

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-09-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
The issue is that the loop structure is broken and thus asking for
determine_bb_domination_status and then

1594  nblocks = dfs_enumerate_from (loop->latch, 1,
dbds_continue_enumeration_p,
1595bblocks, loop->num_nodes, bb);

doesn't work.  We are likely threading if (1 != 0) branches in weird ways.
The problem likely gone away by doing threading in a separate pass in GCC 12.

Calling determine_bb_domination_status after we have done any transforms
definitely looks dangerous - this should be done _before_ any CFG changes.
This issue is still latent in the forward threader.  The backward threader
calls this function from back_threader_profitability::profitable_path_p,
so before doing any CFG changes.  In GCC 12 and later the remaining forward
threader instances are all from DOM(?).

Reduced testcase for the GCC 11 branch:

func_1() {
  for (;;)
if (func_2())
  safe_lshift_func_uint16_t_u_u();
}
func_2(p_3, p_4) {
  char l_870;
  p_4 = -2;
  for (; p_4; p_4 = p_4 + 1) {
int l_888_0 = 5;
l_870 = 0;
for (; l_870 <= 0; l_870 += 1) {
  p_3 = 0;
  for (; p_3 >= 0; p_3 -= 1)
if (l_888_0)
  break;
  if (l_888_0)
break;
  l_888_0 &= 0;
}
  }
  return p_3;
}

[Bug tree-optimization/111458] [11 Regression] ICE in in dfs_enumerate_from, at cfganal.c:1560

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 11.4.0
   Keywords||ice-on-valid-code
  Known to work||10.1.0, 12.0
Summary|ICE in in   |[11 Regression] ICE in in
   |dfs_enumerate_from, at  |dfs_enumerate_from, at
   |cfganal.c:1560  |cfganal.c:1560
   Target Milestone|--- |11.5

--- Comment #2 from Andrew Pinski  ---
Someone will need to check to see if this went latent in GCC 12.
THere has been many changes in GCC 12 dealing with VRP and jump threading that
this might have been fixed ...