https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #4) > The change makes loop iteration estimates more realistics, but does not > introduce any new code that actually changes the IL, so it seems this makes > existing problem more visible. I will try to debug what happens. Yeah, I didn't see any debug info handling in that commit, so wouldn't surprise me if it was something latent before, or something where ch now needs to do a better job. All I can see from the dumps is that before ch2 the debug stmt placements were reasonable both for b and j, b 0 at the very start and after SSA_NAME def stmts which update it to a new value for the var (e.g. after PHI at the start of loop body, or after increasing the IV). Before r14-162 ch2 used to do weird stuff with them - duplicating # DEBUG b => 0 # DEBUG b => 0 at the start, after ++j: # DEBUG j => j_9 # DEBUG j => j_9 after ++b: # DEBUG b => b_7 # DEBUG b => b_7 and (the perhaps only reasonable change adding # DEBUG j => 0 after the b PHI, though not really necessary as it has unconditional goto to the header with PHI after which it is set to something else). But, newly ch2 in addition to the useless duplicate of b => 0, j => j_9 and b => b_7 removes the most important debug stmts ( # DEBUG j => j_2 and # DEBUG b => b_1 after the PHIs) and adds wrong-debug debug stmts elsewhere - the # DEBUG j => 0 and # DEBUG b => 0 in random incorrect places.