https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 16 Sep 2026, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127382 > > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > The state of the padding bits is an ABI requirement. So, with the exception > of > cases where one can't observe that it needs to be honored. So, global > variables (where another TU could access those bits), addressable vars, > function arguments/return values (unless compiler can prove it is not > observable), by extension union members which can be accessed through type > punning, VIEW_CONVERT_EXPRs, memcpy, ... > RTL extends through e.g. EXTEND_BITINT macro on bitint_ext_undef before > operations, and through e.g. REDUCE_BIT_FIELD after operations, though > obviously scalars only, we don't have generic vectors of _BitInt (unlike > clang). So, for vectorized code the vectorizer has to ensure it. Of course, > it could do it ignoring the ABI details by always extending on both loads and > stores. That means when we store to _BitInt we can put garbage in the padding as we are properly extending at loads? That is, memory is not part of the ABI and an application does not have to adhere to padding details for its memory representation?
