https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-03-08
Ever confirmed|0 |1
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #9)
> I suspect the problem lies somewhere here:
>
> _11 = .VEC_EXTRACT (mask__83.22_110, 0);
> _23 = MEM[(short int *)&t + 20B];
> _24 = _23 & _132;
> _25 = _24 != 0;
> _121 = (<signed-boolean:1>) _25;
> _157 = _11 ^ _121;
>
> For
> _121 = (<signed-boolean:1>) _25;
> we seem to be negating a 1 to a -1. Once the -1 is xor'ed with 1 the result
> is -2 instead of the expected 0. It's not the negation itself but rather
> the whole sequence leading to it.
No you got it wrong.
_121 will either be -1 or 0. _11 should be -1 or 0 too.
So the question is what was the VEC_EXTRACT doing the right thing? Is it 0/-1
or 0/1?
> _25 = _24 != 0; // 1
> _127 = (<signed-boolean:1>) _25; // 1
> _157 = _127 ^ _278; // 1
> When _24 is 3, _25 is 1, and _127 should be 1 ? Just like cast to 1 bit.
No, _127 will be -1. BUT _278 should be 0/-1 and not 0/1.
`signed-boolean:1` can only have 0 or -1. Anything else is undefined.
So this is why I ask about the _278 above.
> 135 │ 102de: 8f35 xor a4,a4,a3 //
> a4 = -2, a3 = 1
a3 should have been -1.
a3 comes from:
130 │ 102cc: 5c10b0d7 vmerge.vim v1,v1,1,v0 // v1.b =
{1}
131 │ 102d0: 421026d7 vmv.x.s a3,v1 // a3
= 1
Which I assume is expanded from the VEC_EXTRACT above? If so there is a missing
sign extend going on when we are extracting from a `vector(8)
<signed-boolean:1>` to `<signed-boolean:1>`.
