https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915
--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
This is an example of a known limitation in SLSR. The explanation is in
analyze_increments:
/* FORNOW: If we need to add an initializer, give up if a cast from
the candidate's type to its stride's type can lose precision.
This could eventually be handled better by expressly retaining the
result of a cast to a wider type in the stride. Example:
short int _1;
_2 = (int) _1;
_3 = _2 * 10;
_4 = x + _3; ADD: x + (10 * _1) : int
_5 = _2 * 15;
_6 = x + _3; ADD: x + (15 * _1) : int
Right now replacing _6 would cause insertion of an initializer
of the form "short int T = _1 * 5;" followed by a cast to
int, which could overflow incorrectly. Had we recorded _2 or
(int)_1 as the stride, this wouldn't happen. However, doing
this breaks other opportunities, so this will require some
care. */
In this case, we have "int" rather than "short int," and "int *" rather than
"int". Assuming a 64-bit machine, casting from a 64-bit wrapping type to a
32-bit non-wrapping type isn't legal.
I need to look at the stride-selection logic again. The various cast-sensitive
bits of this are tricky to get right.
