http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- The issue is that predcom treats e[c + 3][d] and e[c + 4][d] as having distance '2', but that's in a dimension that is not evolving. Later we adjust the evolving dimension index with an adjusted value which obviously breaks as it gets out-of-bounds. That will later confuse data-ref analysis as well, so the "fix" using signed arithmetic doesn't fix the underlying issue. I'm not sure why the issue with tree_could_trap_p exists, tree_could_trap_p is very conservative and we can arrange for constant offsets to appear in a single MEM_REF. Trying a patch doing that.
