[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 6 Mar 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> The second UB is on
> #2  ao_ref_init_from_vn_reference (ref=<optimized out>, set=1, base_set=1,
> type=<optimized out>, ops=...) at ../../gcc/tree-ssa-sccvn.cc:1224
> 1224                offset += op->off << LOG2_BITS_PER_UNIT;
> where op->off is negative.
> Isn't this just an unnecessary optimization?  I mean can't we just do
>                     offset += op->off * BITS_PER_UNIT;
> BITS_PER_UNIT is a constant 8 on all targets we support...

It's a habit from dealing with offset_int (but this is poly_int64)
where the multiply is possibly a lot more costly than a shift.

So yeah, a multiply is fine I guess.