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

Kostya Serebryany kcc at google.com
Wed Sep 12 22:18:31 PDT 2012


Yes, this is http://code.google.com/p/address-sanitizer/issues/detail?id=83 and
we hope to get to it in Oct.

--kcc

On Thu, Sep 13, 2012 at 4:27 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Sep 12, 2012 at 4:50 PM, 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:
>>
>>>
>>> On Sep 12, 2012, at 16:27 , David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>> > On Wed, Sep 12, 2012 at 4:10 PM, Jordan Rose <jordan_rose at apple.com>
>>> wrote:
>>> >> The thing that keeps me from removing it is that it IS more
>>> convenient and it CAN be made safe. The first way is to use C++11 to forbid
>>> the use of this function on rvalues; that looks like this:
>>> >>
>>> >>  template<class T> const T *getAs() const && = delete;
>>> >>  template<class T> const T *getAs() const & {
>>> >>    return dyn_cast<T>(this);
>>> >>  }
>>> >
>>> > Indeed, my thoughts precisely. [I wonder at what point it'll be worth
>>> > moving default development to C++11 and just keeping some bots around
>>> > for C++98 back compat testing.]
>>> >
>>> >> This could be hidden behind a compatibility macro:
>>> >>
>>> >>  template<class T> const T *getAs() const LLVM_RVALUE_DELETE;
>>> >>  template<class T> const T *getAs() const LLVM_LVALUE {
>>> >>    return dyn_cast<T>(this);
>>> >>  }
>>> >
>>> > What do you envision those macros being defined to in C++98? Wouldn't
>>> > you end up with errors relating to redeclaration of class members if
>>> > they expanded to nothing in C++98 builds.
>>>
>>> I guess I should have tried it first. I forgot you can't redeclare class
>>> members. :-(
>>
>>
>> #define LLVM_LVALUE
>> #define LLVM_RVALUE_DELETE volatile LLVM_DELETED_FUNCTION
>>
>> Still quite ugly, though.
>>
>>
>>> >> 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).
>>
>
> This is an important (and planned) feature. The goal is to get ASan to
> catch the bugs, and then Clang to emit the lifetime markers. We want them
> because Nadav is implementing exactly the optimization that GCC benefits
> from for Clang+LLVM.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120913/0b642fa0/attachment.html>


More information about the cfe-dev mailing list