This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] libstdc++/77686 use may_alias for std::function storage
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Sep 2016 13:14:06 +0200
- Subject: Re: [PATCH] libstdc++/77686 use may_alias for std::function storage
- Authentication-results: sourceware.org; auth=none
- References: <20160928105732.GA7817@redhat.com>
On Wed, Sep 28, 2016 at 12:57 PM, Jonathan Wakely <firstname.lastname@example.org> wrote:
> std::function::swap does swap(_M_functor, x._M_functor) which
> exchanges the underlying bytes of the two _Any_data PODs using that
> type's implicit assignment operator. However, unlike using placement
> new to construct an object in the storage, simply memcpying the bytes
> doesn't change the effective type of the storage, so alias analysis
> decides it can't point to whatever we've tried to store in there.
To clarify -- the implicit assingment operator for PODs (including unions)
simply expands to an aggregate assignment which is subject to TBAA
rules and thus in this case instantiates an effective type of _Any_data.
Using memcpy would have worked as memcpy _does_ transfer
the effective type of the storage. It wasn't points-to deciding things
here but TBAA given automatic storage X with effective type T
read via an lvalue of type _Any_data.
> This attribute tells the middle-end to assume anything those bytes
> could contain any type of object, which is exactly what we want.
It tells the middle-end that accessing storage via a _pointer_ to such
marked type may access storage with a dynamic type that is not
compatible with the type.
Btw, I think the patch is correct.
> PR libstdc++/77686
> * include/std/functional (_Any_data): Add may_alias attribute.
> Tested powerpc64le-linux, committing to trunk and gcc-6-branch.
> std::any doesn't have the same problem, because I defined an _Op_xfer
> operation that uses placement new to copy the object into the
> destination, so the dynamic type is changed correctly. I haven't
> checked whether optional and variant might have similar problems in
> any implicit copy/move operations working on POD storage.