Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example

[Andrew Haley <aph at redhat dot com>]

Richard Guenther wrote:
> On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <aph@redhat.com> wrote:
>> Hans-Peter Nilsson wrote:
>>>> Date: Tue, 24 Jun 2008 10:36:15 +0100
>>>> From: Andrew Haley <aph@redhat.com>
>>>> 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.