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, Jakub Jelinek wrote:
> On Mon, Oct 24, 2016 at 11:13:04AM +0300, 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.
>
> And I'm afraid just conservatively assuming any method call could change
> the object on which it has been called on into something different would
> pretty much kill most of the devirtualization.
> CCing Honza.
But we already assume any function call may - so if the C++ standard
allows this we have to assume any method call may do so as well.
See my destructor example on how the C++ FE also mishandles this case.
IMHO this is worth a DR and a clarification on whether this is allowed.
Richard.