https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128133
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > (In reply to Richard Biener from comment #1) > > Confirmed. So this is exposing "wrong" padding handling where we basically > > assume that loads from memory materialize "correct" padding as if extended, > > like we do for bool (the only previously handled case). For bitfields > > we defer to ifcvt to expose BIT_FIELD_REFs. > > > > The appropriate fix for now is to reject non-mode precision types that > > we can backport and add proper support later. > > At least with the exception of bool which we handle correctly. > > For _BitInt on the store side, it depends whether the code actually extends > or just keeps undefined bits in the padding bits. If it extends, then it is > ok for any target, if it can store there random bits, then it is only ok on > non-extend _BitInt targets (x86, aarch64, powerpc*). > Loads can be ok on the extend _BitInt targets (arm, riscv, s390x). I think we reject any actual operations in bit precision that would change padding values (oops, we allow BIT_XOR_EXPR ...). So the case in question would be loading an unsigned and truncating where I think the truncation would be lost, thus the bits are "undefined"? Currently we reject the src[i] = dst[i] case at the conversion: t.c:6:21: note: ==> examining statement: _6 = (unsigned _BitInt(17)) _4; t.c:6:21: note: vect_is_simple_use: operand *_3, type of def: internal t.c:6:21: missed: type conversion to bit-precision unsupported t.c:6:21: missed: bit-precision arithmetic not supported. t.c:6:21: note: vect_is_simple_use: operand *_3, type of def: internal t.c:6:21: missed: type conversion to/from bit-precision unsupported. my question in the other PR was whether we have to extend according to the ABI (according to sign, forced zero/sign) upon such case? Then we have to be careful when we implement the above (the obvious solution being a simple AND with a mask, thus always zero-extend). The ABI for signed bools is probably nowhere defined, but we're not gating against those and we've traditionally relied on patterns there (mostly because of data vs. mask). That said, the question is whether we want to enforce and rely on vector registers having extended _BitInts according to the ABI or if we want to use something that's better suited for actual operations. I'd have to look at how _BitInt operations are lowered to decide on that.
