[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:193fccaa5c3525e979a989835c47c76d2c49d10c

commit r13-4834-g193fccaa5c3525e979a989835c47c76d2c49d10c
Author: Andrew Pinski 
Date:   Wed Nov 2 15:56:31 2022 +

Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector
types

Even though this PR was reported with an ubsan issue, the problem is
tree_nonzero_bits is being called with an expression which is a vector
type.
This fixes three patterns I noticed which does that.
And adds a testcase for one of the patterns.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions

gcc/ChangeLog:

PR tree-optimization/105532
* match.pd (~(X >> Y) -> ~X >> Y): Check if it is an integral
type before calling tree_nonzero_bits.
(popcount(X) + popcount(Y)): Likewise.
(popcount(X)): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/vector-shift-1.c: New test.

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords||patch

--- Comment #7 from Richard Biener  ---
Patch posted & approved.

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

--- Comment #6 from Andrew Pinski  ---
Patch submitted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604914.html

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> The bug is either in tree_nonzero_bits and should not be doing:
>   return wi::shwi (-1, TYPE_PRECISION (TREE_TYPE (t)));

Just FYI, TYPE_PRECISION for vectors is a log2 of the number of elements, see
TYPE_VECTOR_SUBPARTS. Which is why you get 0 here since we have 1 element.

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

--- Comment #4 from Andrew Pinski  ---
Created attachment 53820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53820=edit
Patch which is under test

This is patch 1 of 2. The 2nd patch adds the assert to catch this earlier on.

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
I am going to take care of this at least for GCC 13.

There is another invalid use here too:
/* Common POPCOUNT/PARITY simplifications.  */
/* popcount(X) is (X>>C2)&1 when C1 == 1<

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|UBSAN: gcc/hwint.h:293:61:  |[11/12/13 Regression]
   |runtime error: shift|UBSAN: gcc/hwint.h:293:61:
   |exponent 64 is too large|runtime error: shift
   |for 64-bit type 'long   |exponent 64 is too large
   |unsigned int'   |for 64-bit type 'long
   ||unsigned int'
   Target Milestone|--- |11.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2022-11-02
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96688

--- Comment #2 from Andrew Pinski  ---
Confirmed.
The bug is either in tree_nonzero_bits and should not be doing:
  return wi::shwi (-1, TYPE_PRECISION (TREE_TYPE (t)));

For vector types or is in match.pd where it should not be calling
tree_nonzero_bits for vector types.
/* ~(X >> Y) -> ~X >> Y if ~X can be simplified.  */
(simplify
 (bit_not (rshift:s @0 @1))
  (if (!TYPE_UNSIGNED (TREE_TYPE (@0)))
   (rshift (bit_not! @0) @1)
   /* For logical right shifts, this is possible only if @0 doesn't
  have MSB set and the logical right shift is changed into
  arithmetic shift.  */
   (if (!wi::neg_p (tree_nonzero_bits (@0)))
(with { tree stype = signed_type_for (TREE_TYPE (@0)); }
 (convert (rshift (bit_not! (convert:stype @0)) @1))

I almost want to say we should put an gcc_assert in tree_nonzero_bits for when
it gets called with vector or complex types (maybe even real types).

The match.pd pattern was added with r11-6663-g8f8762a2e8659c .