This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/60517] warning/error for taking address of member of a temporary object


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...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]