https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92534
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- Hmm, the fix for PR91790 was indeed incorrect. But the whole realignment code is somewhat "old"... Ideally we'd move the vect_setup_realigment code down to after we computed the dataref_ptr here: /* 1. Create the vector or array pointer update chain. */ if (j == 0) { ... else if (first_stmt_info_for_drptr && first_stmt_info != first_stmt_info_for_drptr) { dataref_ptr = vect_create_data_ref_ptr (first_stmt_info_for_drptr, aggr_type, at_loop, offset, &dummy, gsi, &ptr_incr, simd_lane_access_p, byte_offset, bump); /* Adjust the pointer by the difference to first_stmt. */ data_reference_p ptrdr = STMT_VINFO_DATA_REF (first_stmt_info_for_drptr); tree diff = fold_convert (sizetype, size_binop (MINUS_EXPR, DR_INIT (first_dr_info->dr), DR_INIT (ptrdr))); dataref_ptr = bump_vector_ptr (dataref_ptr, ptr_incr, gsi, stmt_info, diff); and feed it the dataref_ptr directly. Probably first refactor vect_setup_realignment into two pieces, one for the !compute_in_loop and one for the compute_in_loop case. Guess I'll revert the fix for PR91790 for now. Note the issue in that PR is that first_stmt_info_for_drptr provides the DR that needs to be used to compute the address expression but then needs to be adjusted as above. This is because only that DRs SSA names are sure to be defined at the location we need the address.