https://gcc.gnu.org/g:b52a90e7a03fef3c237a78c91dcad37237338d1b

commit r16-4313-gb52a90e7a03fef3c237a78c91dcad37237338d1b
Author: Sam James <[email protected]>
Date:   Thu Oct 9 03:40:58 2025 +0100

    doc: type-punning through a union is a GNU extension for C++
    
    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:
            PR c++/117219
    
            * doc/invoke.texi (-fstrict-aliasing): Explain that type-punning
            through a union in C++ is supported as a GNU extension.

Diff:
---
 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 41ce025350e7..c0d1442f7b19 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15049,10 +15049,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;

Reply via email to