[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2024-08-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 Andrew Pinski changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #10

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2021-04-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 Martin Sebor changed: What|Removed |Added Last reconfirmed|2014-10-03 00:00:00 |2021-4-16 Known to fail|

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #7) > IIRC we don't, and the file contains a comment saying that it would be > expensive. Actually, properly limiting the maximal depth of the walk (as is > done in

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #7 from Marc Glisse --- (In reply to Manuel López-Ibáñez from comment #6) > What about [...] That's roughly what I describe in comment #2, amended by comment #3. > It could be a matter of following the chain of VUSE->VDEF, > which I

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #6 from Manuel López-Ibáñez --- (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,

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #5 from Marc Glisse --- (In reply to Manuel López-Ibáñez from comment #4) > At some moment (in dcce1), gcc decides that x = 4 is not needed. For the > same reason, it could realize that MEM[(struct foo *)&D.2281] = &x must > produce a

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #2) > make_foo: > > MEM[(struct foo *)&D.2281] = &x; > x ={v} {CLOBBER}; > return D.2281; > > That doesn't seem so easy to warn about. We could walk from re

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #3 from Marc Glisse --- (In reply to Marc Glisse from comment #2) > make_foo: > > MEM[(struct foo *)&D.2281] = &x; > x ={v} {CLOBBER}; > return D.2281; > > That doesn't seem so easy to warn about. We could walk from return to

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-03 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 --- Comment #2 from Marc Glisse --- make_foo: MEM[(struct foo *)&D.2281] = &x; x ={v} {CLOBBER}; return D.2281; That doesn't seem so easy to warn about. We could walk from return to find some of the latest non-clobbered dominating writes

[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

2014-10-02 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|