[Bug target/81325] -fcompare-debug failure on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |aoliva at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe this is a bug in find_many_sub_basic_blocks.  When looking at say:
int i;
int bar (void);

void
foo (int x)
{
 l1:
  i += 2;
  if (bar ())
    goto l1;
  int a = x + 5;
  int b = x + 10;
 l2:
  i += 2;
  if (bar ())
    goto l2;
}
where before cddce1 we have at -O2 -g:
...
    goto <bb 5>; [INV] [count: INV]
...
  <bb 5> [0.00%] [count: INV]:
  a_13 = x_12(D) + 5;
  # DEBUG a => a_13
  b_14 = x_12(D) + 10;
  # DEBUG b => b_14

  <bb 6> [0.00%] [count: INV]:
l2:
and cddce1 decides to remove the unused a_13 and b_14, we just kill the
forwarder block bb 5 and the debug stmts are dropped on the floor (which is
unfortunate and on this testcase actually it wouldn't be impossible to move the
debug stmts to the following block if the underlying vars are not mentioned in
that loop and there are no debug stmts for that either, but we don't go that
far).
CCing Alex, because this is a nice example where debug stmts as well as
frontier stmts are dropped on the floor.
Anyway, I believe at least for now find_many_sub_basic_blocks should just throw
away sequences of debug stmts in between an instruction that must end a basic
block and instruction that must start a basic block.