On Friday, 16 January 2026 08:05:59 Pacific Standard Time David Brown via Std-
Proposals wrote:
> As I understand it, the Itanium has an extra "valid" bit for each
> register - the idea is that reading a register with that bit cleared
> will give a trap or exception, helping you find "variable used before
> initialisation" bugs. Theoretically, such a system could also be used
> to track indeterminate bits. But I don't expect that to be a practical
> usage on real processors, and the possibility of such tracking should
> not be an argument against unspecified bits.

By the nature of padding bits, they can only exist in the trailing portion of
a higher-alignment datum where the leading portion *is* valid. Assuming types
are never mis-aligned, this implies there's no way for a padding bit to exist
in a page different from the last datum bit.

This implies the compiler is allowed to load the padding bits into a register
and that can never fault, provided the object was valid in the first place.
That's true for any architecture I know of, including Itanium.

On Itanium, the NaT bit (Not a Thing) can only come from an explicitly
speculative memory read that wasn't actually executed. But it applies to the
entire value, not to specific padding bits. Therefore, the requirement that
padding bits be in valid memory implies that the compiler is only allowed to
emit speculative loads where it is executing speculatively and will either
discard the result or will resolve the speculation (chk.s instruction).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.