http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #19 from bin.cheng <amker.cheng at gmail dot com> --- > > >not about an iv use appearing in memory reference while not marked as > >address_p, and can be fixed by revise the existing check condition, is > >it true? > > No, even expressing an address this way is broken as for example dependence > analysis via scev can get confused about the actual base object. Agree, only I think it's not scev's responsibility since scev only cares base value initialized for the analyzing loop, rather than the BASE object. > > IIRC previously we already avoided the mem-use case and I had to generalize > it > to also avoid addresses. Not all. For the reported case, use and cand like: use 3 generic in statement vect_p.70_247 = PHI <vect_p.70_248(17), vect_p.73_246(6)> at position type vector(8) unsigned char * base batmp.71_245 + 1 step 8 base object (void *) batmp.71_245 is a biv related candidates candidate 15 depends on 3 var_before ivtmp.154 var_after ivtmp.154 incremented before exit test type unsigned int base (unsigned int) pDst_39(D) - (unsigned int) &p1 step (unsigned int) (pretmp.21_118 + 1) The check: if (address_p || (use->iv->base_object && cand->iv->base_object && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object)) && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object)))) { /* Do not try to express address of an object with computation based on address of a different object. This may cause problems in rtl level alias analysis (that does not expect this to be happening, as this is illegal in C), and would be unlikely to be useful anyway. */ if (use->iv->base_object && cand->iv->base_object && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0)) return infinite_cost; } still evaluates to false because: use->iv->base_object != NULL && cand->iv->base_object == NULL >