https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- So what goes wrong is the single-element interleaving code-gen for the pointer copy. We have t.c:18:21: note: Detected single element interleaving picture_7(D)->p[i_18].p_pixels step 16 but for the store: t.c:18:21: missed: not consecutive access res_8(D)->p[i_18].p_pixels = _1; t.c:18:21: note: using strided accesses ... t.c:18:21: note: ==> examining statement: _1 = picture_7(D)->p[i_18].p_pixels; t.c:18:21: note: vect_model_load_cost: aligned. t.c:18:21: note: vect_model_load_cost: inside_cost = 24, prologue_cost = 0 . and in group get-load-store type we handle it as (V1DI) if (!STMT_VINFO_STRIDED_P (first_stmt_info) && (can_overrun_p || !would_overrun_p) && compare_step_with_zero (vinfo, stmt_info) > 0) { /* First cope with the degenerate case of a single-element vector. */ if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U)) *memory_access_type = VMAT_CONTIGUOUS; looks like this needs to be conditional on gap == 0? Adding that fixes the testcase. This was added by g:6737facbb3c53a1f0158b05e4116c161ed9bc319 Richard? It looks like the !STMT_VINFO_STRIDED_P check might have supposed to prevent this? In vectorizable_load we're also doing if (memory_access_type == VMAT_GATHER_SCATTER || (!slp && memory_access_type == VMAT_CONTIGUOUS)) grouped_load = false; but vect_transform_grouped_load doesn't like this case, possibly because there's nothing to "permute" (eliding that alone doesn't fix the code-gen issue).