[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Andrew Pinski from comment #5)
> r9-3927 changed the type from int to HOST_WIDE_INT which is always at least
> 64bit ...
> 
> I also wonder if we could use wi::widest_int here.

That's prohibitively expensive (storage-wise).  Note propagating a failure
upwards should in theory be possible (but it's going to "hurt" - welcome C++
exceptions?)

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

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

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

--- Comment #5 from Andrew Pinski  ---
r9-3927 changed the type from int to HOST_WIDE_INT which is always at least
64bit ...

I also wonder if we could use wi::widest_int here.

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I commented in the dup:

This code hasn't been fixed to avoid overflows and generally expects to operate
with infinite precision integers ... (you know, 32/64bits will be enough -
really!).

Fixing requires overhauling all of the API and data structures in dependence
analysis and finding a suitable representation for "infinite precision
integers".
Note that most of the APIs do not have a well-defined failure mode so bailing
out isn't easy either.

Using GMP is very likely prohibitly expensive not only due to its lack of
optimizing the small-precision case.  OTOH we are using it from niter analysis
already.  Evaluating ISL ints (isl/val.h when configured to not use GMP) might
be worth, as well as maybe looking at including (patched?) mini-gmp (not sure
if that plays well with linking against real gmp, but eventually mpfr plays
well enough with mini-gmp and doesn't get too slow).

Note the HWIs are less likely a problem than the ints currently used for
lambda vectors/matrices.

Note that simply silencing UBSAN by using unsigned arithmetic will simply
silence it, not avoiding wrong-code issues that might be latent there.

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
*** Bug 85158 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
I tried a -fsanitize=undefined build of today's gcc trunk with -O3
and the runtime errors I found are:

$ grep error: mk.out
../../trunk/gcc/tree-data-ref.c:3640:26: runtime error: signed integer
overflow: 9223372036854775807 - -1 cannot be represented in type 'long int [3]'
../../trunk/gcc/tree-data-ref.c:3642:52: runtime error: signed integer
overflow: -9223372036854775808 - 1 cannot be represented in type 'long int [3]'
$

[Bug tree-optimization/82494] UBSAN in gcc/tree-data-ref.c:3427:16: runtime error: signed integer overflow: 131072 * -131072 cannot be represented in type 'int'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-09
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think there's a dup somewhere.  We've discussed that

typedef int *lambda_vector;

is simply too optimistic.  The machinery assumes this is an arbitrary precision
integer ;)  A optimistic "fix" would be to make it int64_t, probably catching
most (if not all) practical cases (all overflows are possibly wrong-code!).

A real fix would involve either using gmp (ugh) or making a lot of routines
failable that are not right now plus using overflow-detecting math (and fail).