This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
- From: Richard Guenther <rguenther at suse dot de>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Michael Matz <matz at suse dot de>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Richard Guenther <richard dot guenther at gmail dot com>, Paolo Bonzini <bonzini at gnu dot org>, gcc-patches at gcc dot gnu dot org, Diego Novillo <dnovillo at google dot com>
- Date: Wed, 14 Apr 2010 23:09:29 +0200 (CEST)
- Subject: Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
- References: <alpine.LNX.2.00.1001221549140.7863@zhemvz.fhfr.qr> <Pine.LNX.4.64.1002031407130.18785@wotan.suse.de> <4B697B53.6020301@codesourcery.com> <Pine.LNX.4.64.1002031446140.18785@wotan.suse.de> <206fcf961002030658h2eeb851ay620be9e114f8b050@mail.gmail.com> <Pine.LNX.4.64.1002031559520.18785@wotan.suse.de> <206fcf961002030732v507ab7e9r2818ff5a28399605@mail.gmail.com> <Pine.LNX.4.64.1002031640440.18785@wotan.suse.de> <206fcf961002030823k4c10784cwc386a571f253f3c@mail.gmail.com> <Pine.LNX.4.64.1002031725290.18785@wotan.suse.de> <206fcf961002030851u220d8cd0w759ab0a86e21b78@mail.gmail.com> <Pine.LNX.4.64.1002031753010.18785@wotan.suse.de> <4B69CB11.6090703@codesourcery.com> <4BC618DA.2030104@redhat.com> <alpine.LNX.2.00.1004142220050.5522@zhemvz.fhfr.qr> <4BC62AC7.10208@redhat.com>
On Wed, 14 Apr 2010, Jason Merrill wrote:
> On 04/14/2010 04:29 PM, Richard Guenther wrote:
> > On Wed, 14 Apr 2010, Jason Merrill wrote:
>
> > > Note "or is copied as an array of character type". Since struct
> > > assignment is
> > > defined as memberwise assignment and union assignment is defined as
> > > assignment
> > > of the value representation (which is an array of unsigned char), such an
> > > assignment should transfer the effective type of a subobject that
> > > completely
> > > overlaps either a union or an array of character type.
>
> > Correct. I don't remember off-hand if the code as written in
> > libstdc++ and/or produced by the C++ frontend is recognizable
> > as such.
>
> The problematic code in std/functional looked like
>
> union _Any_data
> {
> // member functions
> _Nocopy_types _M_unused;
> char _M_pod_data[sizeof(_Nocopy_types)];
> };
>
> void swap(function& __x)
> {
> _Any_data __old_functor = _M_functor;
> _M_functor = __x._M_functor;
> __x._M_functor = __old_functor;
> // ....
> }
>
> Here we are doing an assignment of a union, which is defined as a copy of the
> value representation, which means copying it as an array of unsigned char. So
> it should be equivalent to memcpy as far as TBAA is concerned.
Yep.
> > At least if we have an aggregate union assignment
> > we do not use alias-set zero for it, but we only special
> > case component-refs into union objects. So, either we want
> > to treat union assignment uniformly in the middle-end and
> > have to adjust get_alias_set or the C/C++ langhooks need
> > adjustment here. Note that I am not sure we're not pessimizing
> > much code that way.
>
> Using alias set zero seems excessive; what we want is to use the existing
> memcpy semantics when copying a union or character array.
Well, memcpy semantics _is_ using alias-set zero. Note that
the problematic issue with the _Any_data union is that its
alias-set is different from zero and contains subsets for
all its members - but we do _not_ access the union with any
of its member types. So the only alias-set that would conflict
with a non-member alias-set is alias-set zero.
Richard.