On 24/10/16 10:18 +0200, Richard Biener wrote:
> On Mon, 24 Oct 2016, Ville Voutilainen wrote:
>
> > On 24 October 2016 at 10:41, Richard Biener <rguenther@suse.de> wrote:
> > >> Seems that testcase is devirtualization related.
> > >> With -O3 -fno-devirtualize we return 3 (but still no calls).
> > >> With asm ("" : "+g" (p)); before return p; in launder we don't
> > devirtualize
> > >> it any more and return 3 in the end. Is the testcase only valid
> > >> with std::launder and not valid otherwise (I hope so, otherwise we are
> > in
> > >> big trouble with devirtualization)?
> > >
> > > I believe the testcase shows a bug in devirtualization. (stpuid
> > > godbolt.org having no way to textually extract the source easily)
> > >
> > > Please file a GCC bugreport. GCC shouldn't miscompile this even
> > > without std::launder.
> >
> >
> > Note that A::f() can be in a different translation unit, so we still
> > need the optimization
> > barrier in some cases, even if in this particular case as written we
> > wouldn't.
>
> Well, if it is valid to construct a new object in place of *this in
> a virtual function call on this then GCC has an issue regardless of
> std::launder. So, for
>
> {
> A a;
> A::f ();
> }
>
> where does the _FE_ get the knowledge what destructor to call? IIRC
> we "devirtualize" destructor calls in this case as well.
>
> struct B {
> virtual ~B();
> };
> struct A : B {
> virtual ~A();
> void foo ();
> };
>
> int foo ()
> {
> A a;
> a.foo();
> }
>
>
> foo ends up calling A::~A() with GCC 6.
>
> How do I launder a here?
This example has undefined behaviour even if you add std::launder. The
original example doesn't.
The difference is 3.8 [basic.life] paragraph 9, which says that if the
program ends the lifetime of the automatic object 'a' then it must
ensure that another object of the same type occupies the same storage
when the implicit destructor runs. So the original example is OK
because it ends the lifetime of the original object by creating a B at
the same location, but then creates another A there, so the implicit
destructor call to A::~A() is valid, because there is an A at that
location.