Andrew Pinski <[email protected]> writes:
> On Wed, Oct 8, 2025, 7:44 PM Sam James <[email protected]> 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
>
> It also came up to a question to me on
> https://github.com/llvm/llvm-project/issues/162419#issuecomment-3381876892 . I
> didnt get around to answering it yet. And you beat me to adding the
> documentation. Please update the llvm issue pointing
> to this doc change too.
Heh. Done, thanks.
>
> 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;
> --
> 2.51.0
