This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]