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

[Richard Smith]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120912/a520b0c5/attachment.html>