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

[Mark Mitchell]

Gabriel Dos Reis wrote:

>> 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.
> After the placement new, the object previously pointed
> to by 'p' ceases to exist.

I'm not entirely happy even with that.  I think that if mem is declared
as type int [2], rather than as type char[8], this is weird.  But, I'm
happier with the idea that you can blow away the entire object than
blowing away *part* of it as done previously, and I'm happier about the
fact that this is dynamically allocated storage, not a declared variable
with lifetime given by a lexical block.

I guess the way to justify the interpretation you have given above is to
say that the placement new is approximately as-if you wrote:

  delete p;
  f = new float;

and the memory allocator happened to give you back the same address you
had before.  You're just bundling those operations into a single construct.

I can live with that, in part because if you apply that interpretation
to an automatic variable or a variable with static storage you get
undefined behavior at the point of the delete.  In other words, this
provides a framework that justifies why you can do this with
dynamically-allocated storage, but not with other storage (unless, of
course, it is declared as a character type or array thereof).

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713