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 22:29:32 +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>
On Wed, 14 Apr 2010, Jason Merrill wrote:
> What's the status of these issues, now that 4.5 has branched?
I am developing the required infrastructure to support a proper
fix on the mem-ref2 branch.
> On 02/03/2010 02:14 PM, Mark Mitchell wrote:
> > This all depends on the fact that mem is an array of characters. An
> > array of characters is always (in my model) understood to be a blob of
> > bytes in which you can create and destroy other objects. The fact that
> > it's a non-static data member of X is not important. My feeling is that
> > an array of characters is implicitly a union of the array of characters
> > and whatever type is created via placement new.
>
> I agree with this.
>
> In an earlier message in the thread Richard quoted the C standard:
>
> 6.5/6 'If a value is copied into an object having no
> declared type using memcpy or memmove, or is copied as an
> array of character type, then the effective type of the
> modified object for that access and for subsequent accesses that
> do not modify the values is the effective type of the object
> from which the value is copied, if it has one'.
>
> 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. 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.
Richard.