This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: C++17 std::launder and aliasing
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?
Richard.