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: Gabriel Dos Reis <dosreis at gmail dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: Mark Mitchell <mark at codesourcery dot com>, 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: Tue, 2 Feb 2010 02:24:00 -0600
- Subject: Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
- References: <alpine.LNX.2.00.1001221549140.7863@zhemvz.fhfr.qr> <4B5ABF96.1030804@gnu.org> <84fc9c001001230409xa74cab6iea45fa74da008bf@mail.gmail.com> <4B5AF989.6080002@gnu.org> <84fc9c001001230537lb8f5e9co42869f1965cc17cb@mail.gmail.com> <4B5C8C89.80108@codesourcery.com> <alpine.LNX.2.00.1001242151460.7863@zhemvz.fhfr.qr>
- Reply-to: gdr at integrable-solutions dot net
On Sun, Jan 24, 2010 at 3:18 PM, Richard Guenther <rguenther@suse.de> wrote:
> On Sun, 24 Jan 2010, Mark Mitchell wrote:
>
>> Richard Guenther wrote:
>>
>> > The type of the first argument of memcpy doesn't mean anything, so no.
>>
>> I don't claim to be up on the current state of the standards with
>> respect to these issues. ?The last time I tried to understand all the
>> issues, it appeared that the committees had simply punted; they didn't
>> seem to want to think about what these things meant.
>>
>> But, what evidence do we have that:
>>
>> + ? __builtin_memcpy (&i, p, 4);
>> + ? if (*(float *)&i != 1.0)
>>
>> is in fact legal and intended to change the dynamic type of the storage?
>> ?(In terms of the standard, that has to be "memcpy", not
>> "__builtin_memcpy", but we can understand those to be the same in this
>> context.)
>
> The evidence is 3.8/4 - 'A program may end the lifetime of any object
> by reusing the storage which the object occupies ...'.
I read "ending the lifetime" of an object very differently from changing
the dynamic type of an object. I would be very surprised to see any
evidence in the C++ standard to support the construct shown above.
> ?Re-using
> the storage involves constructing a new object in place.
That is correct. But, that does not necessarily imply that
the above construct is blessed.
> ?For POD
> types a copy using memcpy should be a standard conforming way
> (I'm of course always using middle-end view here and do not see
> a reason to not allow this).
I believe the standard explicitly blesses using a roundtrip memcpy().
I do not see any mention of changing declared object's dynamic type
with memcpy().
>
> I failed to find any explicit reference to the effect of memcpy
> on dynamic types in the C++ standard.
I believe in that case, we have "undefined behaviour" :-)
>?The C standard however
> has in 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'. ?The C standard
> restricts itself to speak about anonymous memory only here
> which effectively would make the testcase undefined in C
> (at least that's my reading).
yeah, I think that means objects allocated from free store.
However, C++ uses "object" in a more restricted form than C.
-- Gaby