[clang++] Is accessing an inactive member of a packed structure union undefined behavior?

[safocl]

template <typename Type>
struct __attribute__((packed)) packed_t { Type v; };

union {
      packed_t<float> f;
      packed_t<int> i;
} u = {{1.0f}};

auto a = u.i.v;

does this code have undefined behavior?

In a standard-layout union with an active member of struct type T1, it is permitted to read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated.

If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.

https://eel.is/c++draft/class.mem#general-30
https://eel.is/c++draft/class.prop#10
https://eel.is/c++draft/class.union#general-2
https://eel.is/c++draft/basic.lval#11.sentence-2

But packed structures don't exist in the C++ standard and are represented by a byte array (as I understand it). So, if the sizes of these types are the same, there shouldn't be any undefined behavior. It's also unclear how the program will behave if the sizes are different.
Does the common initial sequence rule apply here within structures for accessing their data members?

[AaronBallman]

Formally speaking, it's UB; we define the extension for packing members that but only describes the layout of the object, not the accessing behavior, so it falls back to the usual standard rules for accessing inactive members of a union, which is UB in C++ and fine in C.

However, GCC documents that you can access the inactive member of a union, even with strict aliasing enabled: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict-aliasing

The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.

Clang does not have similar documentation, but given the pervasive nature of type punning through inactive unions, I think we may want to make the same claim. Then you wouldn't even need the packing trick, so long as the access is through the union, it would be well-defined in C++ as well as C. CC @nikic @rjmccall @efriedma-quic @erichkeane for additional opinions on whether that's a reasonable idea or not.

[nikic]

As far as I know, we already use omnipotent char for union accesses, so I believe that is consistent with current optimization behavior. I wouldn't mind making that a documented guarantee.

[AaronBallman]

As far as I know, we already use omnipotent char for union accesses, so I believe that is consistent with current optimization behavior. I wouldn't mind making that a documented guarantee.

I'll write up a quick RFC to document this, thanks for the quick feedback!

[AaronBallman]

As far as I know, we already use omnipotent char for union accesses, so I believe that is consistent with current optimization behavior. I wouldn't mind making that a documented guarantee.

I'll write up a quick RFC to document this, thanks for the quick feedback!

https://discourse.llvm.org/t/ub-when-type-punning-through-unions/88527

[safocl]

and fine in C.

this is unspecified behavior in C
(ISO/IEC 9899:TC2 Committee Draft — May 6, 2005 WG14/N1124)

Annex J
(informative)
Portability issues

J.1 Unspecified behavior

1 The following are unspecified:
[...]
— The value of a union member other than the last one stored into (6.2.6.1).

In essence, this is still not something defined in C in terms of behavior - since unpredictable results are possible - it's just that for some reason it's included in the unspecified section, and not in the undefined.

1 The following are unspecified:
[...]
— The value of padding bytes when storing values in structures or unions (6.2.6.1).

union {
  float32 f;
  int64    i;
} u;
u.f = 42.f;
auto a = i; // What is the value of variable a?

[safocl]

However, GCC documents that you can access the inactive member of a union, even with strict aliasing enabled:

but this only for C, not for C++:
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html

A member of a union object is accessed using a member of a 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. See Type-punning. This may be a trap representation.

[AaronBallman]

and fine in C.

this is unspecified behavior in C (ISO/IEC 9899:TC2 Committee Draft — May 6, 2005 WG14/N1124)

Annex J
(informative)
Portability issues
J.1 Unspecified behavior
1 The following are unspecified:
[...]
— The value of a union member other than the last one stored into (6.2.6.1).

In essence, this is still not something defined in C in terms of behavior - since unpredictable results are possible - it's just that for some reason it's included in the unspecified section, and not in the undefined.

It is well-defined in C, but can result in a trap representation, hence it's unspecified. See DR 283.

[AaronBallman]

However, GCC documents that you can access the inactive member of a union, even with strict aliasing enabled:

but this only for C, not for C++: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html

A member of a union object is accessed using a member of a 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. See Type-punning. This may be a trap representation.

I believe it applies to C++ as well, at least the docs around -fstrict-aliasing make no mention of it being language-specific. But I'm not 100% sure, @pinskia do you happen to know?

[safocl]

-fstrict-aliasing

(type-punning with -fstrict-aliasing compiler option)
but this is the default behavior for C++, but not for C. -- for this reason I believe that this option is only applicable within the C, and also the fact that the documentation only mentions the C standard -- indicates type-punning only for C.