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.