https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #5) > A clobber implies that the content is lost, so it is useless to store > something there right before the clobber (I assume that's why the store is > removed, I didn't check), but I don't believe it implies that the memory > location is reclaimed (does it?), so it would be fine to store a pointer in > some struct, kill what that pointer points to, re-create something there, > use that, etc. Without the return statement, it is normal to remove x=4 > (because of the clobber), but I don't see anything to warn about, while we > could warn with a return statement and no clobber, so the 2 things seem > quite different. OK, that makes sense. Thanks for the explanation. What about checking that the return value, if it is a VUSE, is not assigned to a local? That is, this would be valid, assuming y is not local, MEM[(struct foo *)&D.2281] = &x; MEM[(struct foo *)&D.2281] = &y; return D.2281; but this would not be: MEM[(struct foo *)&D.2281] = &x; return D.2281; It doesn't matter, whether x is clobbered or has a value and also it doesn't matter what is executed between the assignment and the return as long as it doesn't change the value of MEM[(struct foo *)&D.2281]. It could be a matter of following the chain of VUSE->VDEF, which I think we already do for Wuninitialized.
