On Tue, Feb 03, 2026 at 03:21:27PM +0000, Pengfei Li wrote:
> What I was not sure about is whether, when abi_limb_prec > limb_prec,
> the top 64 bits of padding in c are guaranteed to have already been
> zero- or sign-extended, or they could contain undefined bits.
That depends on bitint_extended. On !bitint_extended, those bits can
contain padding bits in theory but for tree_constant_output_def emitted
constants actually are sign/zero extended based on the type (but it doesn't
really matter, even the PHI result can contain random bits in those padding
bits). For bitint_extended, they need to be extended.
Just try
_BitInt(257) a = -1;
_BitInt(257) b = 0;
unsigned _BitInt(257) c = -1;
unsigned _BitInt(257) d = 0;
On aarch64, b and d are 384 bits of zeros, a is 384 bits of ones and c is
257 bits of ones and 255 bits of zeros. On aarch64 that just happens
because of the implementation, but say on arm 32-bit or riscv those are
mandated to look like that (and for loongarch some padding bits are required
to be extended and others don't).
Jakub
