Jason Merrill <[email protected]> writes: > On 10/9/25 3:43 AM, Sam James wrote: >> We didn't explicitly say that type-punning through a union is undefined >> behavior in C++. Mention that, and that we support it as a GNU extension. >> This was reported on LLVM's Discourse (forums) [0]. >> [0] >> https://discourse.llvm.org/t/ub-when-type-punning-through-unions/88527/6 >> gcc/ChangeLog: >> * doc/invoke.texi (-fstrict-aliasing): Explain that >> type-punning >> through a union in C++ is supported as a GNU extension. >> --- >> OK? >> gcc/doc/invoke.texi | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index 089328b2e7f1..b438ece40689 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -15048,10 +15048,11 @@ int f() @{ >> @end smallexample >> The practice of reading from a different union member than the one most >> 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 works as >> -expected. @xref{Structures unions enumerations and bit-fields >> -implementation}. However, this code might not: >> +@option{-fstrict-aliasing}, type-punning is allowed in C, provided the >> memory >> +is accessed through the union type. In ISO C++, type-punning through a >> union >> +type is undefined behavior, but GCC supports it as an extension. So, the >> code >> +above works as expected. @xref{Structures unions enumerations and >> +bit-fields implementation}. However, this code might not: >> @smallexample >> int f() @{ >> union a_union t; > > I wonder if we want to mention briefly that reading from the "common > initial sequence" of another union member is allowed in C++ under > [class.mem.general]p30? > > But perhaps that's beside the point since this passage is dealing with > members of different scalar types.
I'll look at handling that when refreshing it for bit_cast. Thanks. > > Jason
