This is the mail archive of the
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.firstname.lastname@example.org> <Pine.LNX.email@example.com> <4B697B53.firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <4B69CB11.firstname.lastname@example.org> <4BC618DA.email@example.com> <alpine.LNX.firstname.lastname@example.org> <4BC62AC7.email@example.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.
> > 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.