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