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.