[cfe-dev] GCC's "Temporaries May Vanish Before You Expect"

[Jordan Rose]

On Sep 12, 2012, at 16:59 , Richard Smith <richard at metafoo.co.uk> wrote:

> On Wed, Sep 12, 2012 at 4:55 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> On Sep 12, 2012, at 16:50 , Richard Smith <richard at metafoo.co.uk> wrote:
> 
>> On Wed, Sep 12, 2012 at 4:32 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>  
>> >> The second way is if -fcatch-undefined-behavior could be augmented to handle this case. I have no idea how to do this, though -- perhaps it requires something ASan-ish to poison the temporary memory once its lifetime ends.
>> >>
>> >> Any chance of either of these happening on trunk?
>>  
>> We'd want to wait until the end of the storage duration rather than the end of the lifetime of the object, but yes, we could do that (for instance, we could emit llvm lifetime intrinsics for all local variables, and teach ASan to poison memory based on them).
> 
> Well, I'm not entirely sure what you mean by this, but AFAICT the issue is that GCC thinks the storage duration ends sooner than we think it does.
> 
> The issue is that GCC is more aggressive about reusing storage than we are. We're not miscomputing the storage duration somewhere, we just don't bother to model it in the IR at all.

I see. That makes sense. I think what I meant to say was that we don't have to start modeling the storage duration if we just invalidate the object at the end of its lifetime, which we already do correctly. I'm not as worried about this happening for local variables as I am for temporaries, but of course, yes, the same thing could happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120912/f160defc/attachment.html>