https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |110838
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue is we are vectorizing
b = 32872 >> a;
as a HImode shift with
b = 32872 >> MIN (a, 15)
that's wrong since it never yields the desired zero. With a shift value
of 16 invoking undefined behavior for HImode but the expression originally
promoted to int and thus fine to be shifted by even 18 this means we cannot
vectorize this without introducing undefined behavior in GIMPLE?
This was introduced by the fix for PR110838 (and followup fixes).
I wonder if it would make most sense to allow shifts by the width of
the promoted left operand which would also help interoperability of
GIMPLE with Fortran here? I'm not sure what the reasoning is to
disallow that specific shift amount (any hardware that would not compute
the result to zero or -1? Esp. for logical right shifts this seems like
an odd restriction). I'd hate to have another shift operator with
special defined behavior for this single case but I see no other way
to fix this short of complicating the lowering to
a >= 16 ? 0 : 32872 >> MIN (a, 15) (the MIN is still required to
avoid requiring masking).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838
[Bug 110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
