Richard Guenther wrote:
> On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Hans-Peter Nilsson wrote:
>>>> Date: Tue, 24 Jun 2008 10:36:15 +0100
>>>> From: Andrew Haley <[EMAIL PROTECTED]>
>>>> I thought cast-through-pointer-to-union didn't work and was already
>>>> disallowed; we've been around all this already.
>>> We also bless assignments through unions, and this could be
>>> argued as assigning through a union, albeit casted.
>>>
>>>> This patch of yours
>>>> already documents uncontroversial behaviour.
>>> That's what I hope, but the existence of that code together in
>>> an *else* clause of #ifdef YES_ALIAS by a well-known author
>>> makes it de-facto controversial IMHO. Note also that another
>>> maintainer thought the code to be valid; see the PR.
>> So I see. I'm pretty sure that the compiler's alias analysis won't
>> think it's valid, but I haven't checked.
>
> Right. It happily "mis-"optimizes it. And on a second thought I
> agree the construct is invalid.
>
>> Do we actually document anywhere that a C++-style type pun along the lines
>> of
>>
>> reinterpret_cast<T&>(x)
>>
>> will not work? I'm guessing it probably won't, and that the union trick
>> is the only thing we do support.
>
> This is not a "pun", it only re-interprets the pointer _value_,
Which pointer? x is not of pointer type, and neither is T.
> not what it points to.
The C++ standard calls this a type pun, so -- with all due respect -- I'm
going to believe it! The question is whether this will fall foul of gcc's
aliasing in the same way that a pointer cast does, and I think it will,
Anyway, I just checked, and we do warn, but only at -O2:
#include <iostream>
int
main(char argc, char **argv)
{
double d = 99;
long m = reinterpret_cast<long&>(d);
p.cc:7: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Not a problem, then.
Andrew.
