There's background in
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593>. Neither
Richi nor me could find the union-assignment "gcc extension" at
a glance, probably because it's not an *extension* but an
implementation-defined behavior, and actually duly documented as
such. However, to cross-reference that section together with
the clarifying type-punning blurb in the -fstrict-aliasing
documentation seems would be an improvement, and apparently
there's enough confusion about casting, pointers and unions to
call for an extra example, covering the offending code in the
PR.
So far the RFA. The RFC is whether (to reject this patch and
call for another) to allow the cast-through-pointer-to-union in
the example and the PR as a variant of the blessed
implementation-defined type-punning using unions. IMHO not, but
the offending code is from a canonical strtod implementation
imported into newlib, and enough people are confused already, so
better ask explicitly before what I fear will be the second
-fstrict-aliasing storm of bug-reports and flames.
Tested by "make info-gcc dvi-gcc" and inspecting output.
Ok to commit? I'll suggest 4.3-branch too, though the
"miscompilation" doesn't show up there.
(Yes, I also have a fix for newlib.)
gcc:
* doc/invoke.texi (Optimize Options) <fstrict-aliasing>: Add
anchor for the type-punning blurb. Cross-reference "Structures
unions enumerations and bit-fields implementation". Provide a
cast-through-pointer example. Make final sentence self-contained.
* doc/implement-c.texi (Structures unions enumerations and
bit-fields implementation): Cross-reference the type-punning blurb
in the -fstrict-aliasing documentation.
Index: implement-c.texi
===================================================================
--- implement-c.texi (revision 137051)
+++ implement-c.texi (working copy)
@@ -433,8 +433,8 @@ used to determine if a function has not
different type (C90 6.3.2.3).}
The relevant bytes of the representation of the object are treated as
-an object of the type used for the access. This may be a trap
-representation.
+an object of the type used for the access. @xref{Type-punning}. This
+may be a trap representation.
@item
@cite{Whether a ``plain'' @code{int} bit-field is treated as a
Index: invoke.texi
===================================================================
--- invoke.texi (revision 137051)
+++ invoke.texi (working copy)
@@ -6146,7 +6146,7 @@ example, an @code{unsigned int} can alia
@code{void*} or a @code{double}. A character type may alias any other
type.
-Pay special attention to code like this:
[EMAIL PROTECTED] special attention to code like this:
@smallexample
union a_union @{
int i;
@@ -6163,7 +6163,8 @@ The practice of reading from a different
recently written to (called ``type-punning'') is common. Even with
@option{-fstrict-aliasing}, type-punning is allowed, provided the memory
is accessed through the union type. So, the code above will work as
-expected. However, this code might not:
+expected. @xref{Structures unions enumerations and bit-fields
+implementation}. However, this code might not:
@smallexample
int f() @{
a_union t;
@@ -6174,7 +6175,18 @@ int f() @{
@}
@end smallexample
-Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
+Similarly, access by taking the address, casting the resulting pointer
+and dereferencing the result might not work, even if the cast uses a
+union type, e.g.:
[EMAIL PROTECTED]
+int f() @{
+ double d = 3.0;
+ return ((union a_union *) &d)->i;
[EMAIL PROTECTED]
[EMAIL PROTECTED] smallexample
+
+The @option{-fstrict-aliasing} option is enabled at levels
[EMAIL PROTECTED], @option{-O3}, @option{-Os}.
@item -fstrict-overflow
@opindex fstrict-overflow
brgds, H-P
