------- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-24 18:04 ------- (In reply to comment #8) > What else could it be than a pointer? It might be possible to mark it somehow > so that the middle end knows to consider the referent uninitialized. > > Incidentally, perhaps we should mark the this parameter as __restrict... > > It does seem reasonable for the front end to detect uses of a member in a > previous mem-initializer, though that wouldn't handle uses in the body.
I think there is no reasonable way to get reliable uninitialized variable warnings for incoming pointed-to memory. The only way we can warn here is by inlining the constructor into the caller to see either a static variable or the memory allocation. But this all boils down to the middle-end not doing uninitialized variable warnings for memory at all. I'd close this one as WONTFIX or mark it as dup of a "do uninitialized variable warnings for memory". Note that for unrelated reasons we had the idea of introducing a way to tell the middle-end that previous content of memory becomes undefined, sort-of adding an assignment from an undefined value like A = <error-mark>; for the reason to preserve aggregate lifetime information after BIND expression lowering. The above might also be used carefully in constructors to mark pieces that the constructor is supposed to initialize as having undefined content. Well - if the language standard allows this. Of course using <error-mark> is just a random (and probably bad) idea. Introducing a SSA name default definition for A (even though not of register type) might be another trick. The frontend could also use the above at the end of destructors to help dead code elimination. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
