https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Biener <rgue...@gcc.gnu.org>: https://gcc.gnu.org/g:13dfb01e5c30c3bd09333ac79d6ff96a617fea67 commit r14-2951-g13dfb01e5c30c3bd09333ac79d6ff96a617fea67 Author: Richard Biener <rguent...@suse.de> Date: Thu Aug 3 13:11:12 2023 +0200 tree-optimization/110702 - avoid zero-based memory references in IVOPTs Sometimes IVOPTs chooses a weird induction variable which downstream leads to issues. Most of the times we can fend those off during costing by rejecting the candidate but it looks like the address description costing synthesizes is different from what we end up generating so the following fixes things up at code generation time. Specifically we avoid the create_mem_ref_raw fallback which uses a literal zero address base with the actual base in index2. For the case in question we have the address type = unsigned long offset = 0 elements = { [0] = &e * -3, [1] = (sizetype) a.9_30 * 232, [2] = ivtmp.28_44 * 4 } from which we code generate the problematical _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4]; which references the object at address zero. The patch below recognizes the fallback after the fact and transforms the TARGET_MEM_REF memory reference into a LEA for which this form isn't problematic: _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4]; _3 = *_24; hereby avoiding the correctness issue. We'd later conclude the program terminates at the null pointer dereference and make the function pure, miscompling the main function of the testcase. PR tree-optimization/110702 * tree-ssa-loop-ivopts.cc (rewrite_use_address): When we created a NULL pointer based access rewrite that to a LEA. * gcc.dg/torture/pr110702.c: New testcase.
