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