On Wed, Sep 12, 2012 at 4:55 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Sep 12, 2012, at 16:50 , Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br></div><blockquote type="cite">
<div class="im">On Wed, Sep 12, 2012 at 4:32 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br></div><div class="im"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>>> 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.</div>

<div><div>
>><br>
>> Any chance of either of these happening on trunk?<br></div></div></blockquote><div> </div><div>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).</div>

</div>
</div></blockquote><br></div><div>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.</div></div></blockquote><div><br></div>
<div>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.</div></div>