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.