https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113287
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |tnfchris at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comparing the arguments of the __mulbitint3 call between -O3 -msse4 and -O3
-msse4 -fno-tree-vectorize shows that the arguments to that call are computed
right even when vectorizing, (_BitInt(9020)) 5 << 1128, 5 and seems there is
some bug in the vectorization of the loop trying to check if the result of the
__mulbitint3 fits into signed int (which it doesn't).
That is done by checking if the least significant limb
(unsigned long) ((signed long) res[0] >> 31) > 1UL (that is not the case, the
least significant limb is actually 0), then comparing the next 140 array
elements against
(unsigned long) ((signed long) res[0] >> 31) (one of them is different) and
finally
if none is different, compare (long) (res[141] << 60) >> 60 against it too.
So, I believe this is a bug in the vectorizer part Tamar is changing right now.
