On 24 Jan 2026 00:07, Thiago Macieira via Std-Proposals wrote:
> On Friday, 23 January 2026 10:02:24 Pacific Standard Time Sebastian Wittmeier
>
>> The language in general may not insert (anymore) any code changing the
>> padding bits and bytes, if there was no write of t. This could have been
>> possible up till now under the as-if rule, as the padding bits may have
>> changed at any time.
>
> I'm not sure. Others have argued that padding bits cannot change out of the
> blue, without a write operation. I think we do want to firm up the language
> here, though. One of two options:
>
> * padding bits must remain the same, whether they were indeterminate or not
> * padding bits must remain the same only if they were cleared
>
> The test is something like this:
>
> memcpy(buf, &type_with_padding, sizeof(type_with_padding));
> // lots of code, but type_with_padding isn't modified
> memcmp(buf, &type_with_padding, sizeof(type_with_padding)) == 0
>
> And from reading the code generated by GCC[1] for the above for long double, I
> think it would have the surprise "padding bits changed without write"
> behaviour: it performs FSTP once at %rsp+64 (&v), and once at %rsp+16 then
> copies to %rsp+32 (buf) (the third FSTP operation is the call to f()). Since
> the two variables came from distinct FSTP operations, the padding bits would
> be different. Clang and the old ICC only have two FSTP, so the origins of &v
> and buf are the same, copied via all-bits-copying instructions.
>
> [1] https://gcc.godbolt.org/z/Wxdxbjao5

Interesting, thanks for the code sample.

However, I do not find where the standard permits padding bits (or, more
generally, the object representation) to change out of thin air, without
a modifying operation on the object. I tend to think this might be a
compiler bug.