https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90946
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aoliva at gcc dot gnu.org Summary|gcc generates wrong debug |gcc generates wrong debug |information at -O3 |information at -O2 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- There isn't really much we can do - l_756 is memory for quite a bit of the compilation and there the dead-store removal "issue" with debug info pops up and we elide the last *l = 105487; store without leaving debug footprint. Then at some point we are able to rewrite l_756 to a register and only after that we elide even the first "store" leaving the only debug footprint but with the outdated value. So there's something that pops up in my mind we could do - mark everything that was memory at some point and avoid generating debug stmts for it. That's of course quite a big hammer.... There's missed optimization that could have made the optimized value <optimized out>, namely a pass ordering issue between DSE and DCE during early opts where we have after CSE <bb 2> : # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT l_756 = 40369; # DEBUG i => 0 # DEBUG BEGIN_STMT l = &l_756; # DEBUG BEGIN_STMT goto <bb 4>; [INV] ... <bb 12> : # DEBUG BEGIN_STMT l.8_17 = (long int) &l; o_37 = (int) l.8_17; # DEBUG o => o_37 l_756 ={v} {CLOBBER}; l ={v} {CLOBBER}; return; where you can see that 'l' is dead and thus we could have written l_756 into SSA much earlier (or eliminated all stores to it). It shows us not "quickly" eliminating zero-use SSA defs can lead to such delayed optimizations. into-SSA already could see it, doing <bb 12> : # DEBUG BEGIN_STMT l.8_17 = (long int) &l; - o = (int) l.8_17; - l_756 = {CLOBBER}; - l = {CLOBBER}; + o_37 = (int) l.8_17; + # DEBUG o => o_37 + l_756 ={v} {CLOBBER}; + l ={v} {CLOBBER}; return; of course it's a bit premature there and tailored to this particular testcase.