[cfe-dev] C++11 and enhacned devirtualization

[Hal Finkel]

----- Original Message -----
> From: "Piotr Padlewski" <prazek at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Rafael Espíndola" <rafael.espindola at gmail.com>, "David Blaikie" <dblaikie at gmail.com>, "Richard Smith"
> <richard at metafoo.co.uk>, "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Thursday, July 16, 2015 12:30:14 PM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> 
> Because standard say, that when You put new object into previous
> object (f.e. by placement new) the lifetime of an object has ended,
> and using previous pointer to it leads to UB.
> 
> 
> see c++11 standard, 3.8 Object lifetime
> 

Ah, right. Thanks!

 -Hal

> 
> On Thu, Jul 16, 2015 at 10:26 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> ----- Original Message -----
> > From: "Piotr Padlewski" < prazek at google.com >
> > To: "Hal Finkel" < hfinkel at anl.gov >
> > Cc: "Rafael Espíndola" < rafael.espindola at gmail.com >, "David
> > Blaikie" < dblaikie at gmail.com >, "Richard Smith"
> > < richard at metafoo.co.uk >, " cfe-dev at cs.uiuc.edu Developers" <
> > cfe-dev at cs.uiuc.edu >
> > Sent: Thursday, July 16, 2015 12:19:40 PM
> > Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> > 
> > 
> > It can, but it will be UB, so we don't have to worry about it.
> 
> Why is it UB? Or when it the placement new changing the vtable not
> UB?
> 
> -Hal
> 
> > 
> > 
> > On Thu, Jul 16, 2015 at 10:16 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Rafael Espíndola" < rafael.espindola at gmail.com >
> > > To: "Piotr Padlewski" < prazek at google.com >
> > > Cc: "David Blaikie" < dblaikie at gmail.com >, "Hal Finkel" <
> > > hfinkel at anl.gov >, "Richard Smith" < richard at metafoo.co.uk >,
> > > " cfe-dev at cs.uiuc.edu Developers" < cfe-dev at cs.uiuc.edu >
> > > Sent: Thursday, July 16, 2015 12:14:29 PM
> > > Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> > > 
> > > On 16 July 2015 at 10:02, Piotr Padlewski < prazek at google.com >
> 
> 
> > > wrote:
> > > > The proposal of our solution will be published next week. Brief
> > > > introduction:
> > > > 
> > > > "Basic idea is to mark vtable loads with !invariant , and also
> > > > put
> > > > assume()
> > > > after calling constructor to show how vtable will look like.
> > > > Function
> > > > @llvm.invariant.barrier that breaks the invariant will be
> > > > needed
> > > > to
> > > > cope
> > > > with placement new and other cases where the vptr is
> > > > legitimately
> > > > permitted
> > > > to change."
> > > 
> > > 
> > > Nice, this should also avoid loading the vtable pointer multiple
> > > times in
> > > 
> > > struct C {
> > > virtual void foo();
> > > };
> > > void g();
> > > void f(C *x) {
> > > x->foo();
> > > g();
> > 
> > Not if g() might placement-new something else on top of x. The
> > problem is that if we need to make conservative assumptions about
> > whether or not g() might contain a '@llvm.invariant.barrier', we
> > must assume it might.
> > 
> > -Hal
> > 
> > > x->foo();
> > > }
> > > 
> > > Cheers,
> > > Rafael
> > 
> > 
> > > 
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > 
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory