https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #22 from Robin Dapp <rdapp at gcc dot gnu.org> --- > Is that not happening? What value does _164 actually end up being? > > In other words, if the XOR is happening in GPRs, it doesn't matter whether > the register holds 1 or -1 (or 3) for a true boolean. The upper bits are > don't-care, just like for an 8-bit value stored in a 64-bit register > (ignoring PROMOTE_MODE for now). 1 ^ -1 gives -2, which correctly has a > clear low bit. But it sounds like more than the low bit of the XOR is being > used somehow. Thanks. Yes, indeed the low bit is unset. The problem manifests when we vec_init a bitmask vector with this value by comparing it against 0. Comparing the full value (-2) against 0 _does_ care about the other set bits so it sounds like we should rather be explicitly checking the last bit to ensure symmetry in vec_extract and vec_init. Maybe with an explicit "& 0x1". I'm going to prepare a patch. Regarding the inconsistent LHS types for BIT_FIELD_REF and VEC_EXTRACT: While it doesn't appear to be an issue, shouldn't we be using the same type for both paths?
