On Thu, Jan 22, 2026 at 11:53 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 22 January 2026 08:35:58 Pacific Standard Time Arthur O'Dwyer
> via Std-Proposals wrote:
> > There are no ABI issues and no backward-compatibility issues. It would
> not
> > totally surprise me if vendors are actually already doing this today,
> > because doing anything else (at constexpr time, anyway) would be harder.
>
> They aren't. https://gcc.godbolt.org/z/EjGb89sez (ignore the MSVC and ICC
> panes)
>
> They use the x87 to store the long double to memory, which means 6 of the
> 16
> bytes are unmodified from what was there.
>

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
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.

–Arthur