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

Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
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 .

Reply via email to