Re: [boost] aligned_storage in unions

Subject: Re: [boost] aligned_storage in unions
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-09-22 17:38:40

On 09/22/10 15:28, Frank Mori Hess wrote:
> On Wednesday 22 September 2010, Larry Evans wrote:
>> On 09/22/10 14:04, Frank Mori Hess wrote:
> 
>>> I don't see how that gets around the anti-aliasing rules.  The compiler
>>> is allowed to assume incompatible pointers won't _ever_ alias.  So just
>>> because your program does things in a certain order doesn't mean the
>>> compiler isn't allowed to use the anti-aliasing assumptions to reorder
>>> things in a nasty way.  Couldn't it look at the destruction of the old
>>> object and the construction of the new object as two completely
>>> independent actions it is free to reorder or interleave?
> 
>> I hadn't thought of the compiler reordering the calls.
>> Just to be clear, the compiler, using the anti-aliasing rules,
>> could reorder:
> 
>>   316	        destroy();
>>   317	        assign_copy(from);
> 
>> to:
> 
>>   317	        assign_copy(from);
>>   316	        destroy();
> 
>> ?  Or maybe just do everything in destroy before the lhs->~Lhs() call,
>> then execute assign_copy(from) and then do lhs->~Lhs().  Hmm...
>> OK, I think I got it, but am surprised.
> 
> I think so, in principle.  I only have a vague idea of what optimizing 
> compilers actually do under the hood though, which is why I tend to be very 
> conservative about obeying the strict aliasing rules (they've bitten me 
> before).
> 

A more concrete example is attached.

IOW, the strict aliasing rules would allow the compiler to move:

  p20->~str();

after the:

  str<10>* p10=new(buf) str<10>;

because p20 and p10 are assumed not pointing to the same
location.

Note: I did compile with:

  -O3 -Wstrict-aliasing

as Mathias suggested; however, the compiler didn't issue any
warnings.  I'm wondering why?

-Larry