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

[Gabriel Dos Reis <dosreis at gmail dot com>]

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