On Fri, Jan 23, 2026, 15:32 Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

On Fri, Jan 23, 2026 at 12:56 AM Jan Schultke <janschultke@googlemail.com> wrote:

Good point. IIUC, the x87 `fstpt` instruction (used by GCC's codegen) writes only 10 bytes, not 16 bytes.

And Clang's codegen explicitly writes only 10 bytes, not 16 bytes, using integer `movw`.

Now, at constexpr time, GCC does act as if it's zeroing the padding bits: https://godbolt.org/z/o6Gcen1P5

And EDG 6.8's __builtin_bit_cast seems to be doing the same thing, zeroing the padding bits: https://gcc.godbolt.org/z/GEMYbhdx8

It's worth noting that both GCC and Clang are correct because this is a case of undefined behavior during constant evaluation. https://eel.is/c++draft/bit.cast#4.2 states that the behavior is undefined when you get a padding bit from the source into a non-padding bit within the destination.

...Unless the destination is `unsigned char`, which it is in my example above. In that case, (4.1) applies, and the value of the unsigned char is indeterminate instead.

Yes, of course.

 

The one-liner repro for the divergence is:

constexpr auto x = __builtin_bit_cast(__int128, 0.0L); // GCC OK, Clang error

Whereas Clang rejects the bit_cast entirely. IIUC, Clang is using logic similar to Jan's to insist that this std::bit_cast has UB so it shouldn't compile at constexpr time.

Clang rejects that code, but simply on the basis that constant evaluation hits something that's UB. Clang is already allowed to do that.

Ah, we're both wrong. This example has nothing to do with UB. Clang is acting on [expr.const]/21, which says that if a result (like the result of that bit_cast, which becomes the result of `g()`) has any indeterminate value bits, then it's not a constant expression; and therefore we can't use the result of `g()` to initialize `constexpr Dest a`.

[bit.cast] explicitly points out the UB in its effects, so I don't think this applies. The UB already happens inside the function.

What I'm suggesting is that the call to std::bit_cast should be ill-formed because it's unconditionally UB, and thus indicative of a programmer error, even if never evaluated.

Yes, I know you're suggesting that; but that isn't the right thing to do.

What you should do is what Thiago et al. have been saying: simply propose the following patch to [bit.cast].

I think both options are viable.

Returns: An object of type To. Implicitly creates objects nested within the result ([intro.object]). Each bit of the value representation of the result is equal to the corresponding bit in the object value representation of `from`. Padding bits of the result are unspecified. For the result and each object created within it, if there is no value of the object's type corresponding to the value representation produced, the behavior is undefined. If there are multiple such values, which value is produced is unspecified. A bit in the value representation of the result is zero if it corresponds to a padding bit of `from`; otherwise, its value is indeterminate if it does not correspond to a bit in the value representation of `from` or corresponds to a bit for which the smallest enclosing object is not within its lifetime or has an indeterminate value ([basic.indet]) . A bit in the value representation of the result ; otherwise, it is erroneous if it corresponds to a bit for which the smallest enclosing object has an erroneous value. For each bit b in the value representation of the result that is indeterminate or erroneous, let u be the smallest object containing that bit enclosing b:

(4.1) If u is of unsigned ordinary character type or `std::byte` type, u has an indeterminate value if any of the bits in its value representation are indeterminate, or otherwise has an erroneous value.
(4.2) Otherwise, if b is indeterminate, the behavior is undefined.
(4.3) Otherwise, the behavior is erroneous, and the result is as specified above.

The result does not otherwise contain any indeterminate or erroneous values.

That not only makes the code have well-defined behavior, but also makes similar code (e.g. with `array<int,4>` in place of `array<unsigned char,16>`) have well-defined behavior too.

This wording change does require GCC and Clang to make a change to their runtime codegen, as Thiago pointed out, but that's fine. Any user program that works in C++26 will continue to work exactly the same after this wording patch, since the only thing this patch does is to change the values you get when you use bit_cast to inspect an object's padding bits (which aren't under your control anyway).

[...]

GCC accepts that code, which it's allowed to do. It's simply undefined behavior at compile time.

No it's not. It currently (in C++26) produces an indeterminate value, which is not a constant expression, which must be rejected as the initializer for a constexpr variable.

I think I do see what you're saying about unconditional UB, though, in the case where `Dest` is not an array<unsigned char,16> but rather array<int,16> and some of the bits of the incoming object are indeterminate or erroneous. Is it possible to have indeterminate or erroneous bits at constexpr time (except in this weird case, the result of `std::bit_cast` of padding bits, which the patch above eliminates)? If so, then I agree it would be good to also add either this patch to [bit.cast]:

(4.1) If u is of unsigned ordinary character type or `std::byte` type, u has an indeterminate value if any of the bits in its value representation are indeterminate, or otherwise has an erroneous value.
(4.2) Otherwise, if b is indeterminate, the behavior is undefined and the result of `bit_cast` is not a constant expression ([expr.const]).
(4.3) Otherwise, the behavior is erroneous, and the result is as specified above.

or — probably cleaner — this patch to [expr.const]/9.8 instead:

(9.8) an operation that would have undefined or erroneous behavior as specified in [intro] through [cpp];
(9.x) an operation that would have undefined or erroneous behavior as specified in [bit.cast];

We can't make the former patch say "and the call to `bit_cast` is ill-formed" because in general the compiler can't tell whether at runtime the input bits will have indeterminate values (or be outside their lifetimes). But if it's all happening at constexpr time then the compiler can know and reject the expression.

We can apply what I suggest in my draft though because I only propose to diagnose the degenerate form, where casting always results in UB regardless of input, and whether this happens is known.