[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

[rdapp at gcc dot gnu.org]

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?