On 10/8/25 20:43, 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;
LGTM. Thanks!
-Sandra