http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #2) > (In reply to Marc Glisse from comment #1) > > I see in the dump: > > > > # .MEM_4 = VDEF <.MEM_8> > > D.2272 ={v} {CLOBBER}; > > # VUSE <.MEM_4> > > _5 = MEM[(doubleD.39 *)&D.2272]; > > > > which looks like something we could warn about in the middle-end. > > Could you elaborate? My middle-end foo is not as good as it used to be. _5 = MEM[(doubleD.39 *)&D.2272]; says we are reading something inside variable D.2272. And right in the previous instruction: D.2272 ={v} {CLOBBER}; we clobbered the content of that variable, so what we are reading is nonsense. These clobbers are specifically added to indicate when variables die (like your temporary). And we don't need to rely on the clobber being exactly the previous instruction. The state of the memory (VUSE) when we execute the last instruction was defined (VDEF) by the clobber instruction, typically walk_aliased_vdefs would help you find the last instructions that touched something related to the variable (get_ref_base_and_extent to get the variable maybe?), the visitor would always stop, recording if the instruction was a clobber, and you would check if all branches (or one branch for a -Wmaybe- type of warning?) stopped on a clobber. Some passes may record enough information to make the walk unnecessary, but I am not sure. And you may want to record objects you have already warned about, to avoid flooding if a dead variable is used a lot. Now that I am describing it, there may already be code that does the same thing for use-after-free or other cases? Anyway, a hard part would be deciding in which pass to warn. And turning this vague description (assuming it makes at least a bit of sense) into something that actually works. And finding a right compromise between false positives and false negatives. The usual...