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
On Wed, Feb 3, 2010 at 6:52 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 2 Feb 2010, Gabriel Dos Reis wrote:
>
>> > Just to be crystal clear: if that storage was anonymous, ?do you agree that
>> > we can construct arbitrary types into it? ?I.e. is the following valid in
>> > C++? :
>> >
>> > struct X { int mem[2]; } *p, *q;
>> > float *f;
>> > p = new X; q = new X;
>> > f = new (&p->mem[0]) float;
>>
>> this assumes that the storage is properly aligned, etc.
>
> Right, let's assume this.
>
>> After the placement new, the object previously pointed
>> to by 'p' ceases to exist.
>>
>> > *f = 1.0;
>>
>> OK.
>>
>> > *q = *p;
>>
>> The reads invokes undefined behaviour: if there is any
>> object at all pointed to by 'p' it never was initialized.
>
> Would it make a difference to you, if I had these two inits in front of
> the placement new?:
>
> p->mem[0] = 0; p->mem[1] = 0;
No, it would make no difference: I do not see any object of type
X pointed to by 'p'.
>
>> > (incidentally it's interesting to think about what type the access '*p'
>> > has)
>>
>> '*p' is lvalue of type 'X'.
>
> Although a part of it (the space in mem[0] at least) is a float? ?And type
> 'X' doesn't contain a float? ?That's surprising to say the least :)
The fact that '*p' is an lvalue of type 'X' only follows from static analysis
of the source code, and the C++ standard definition.
-- Gaby