https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 > > Richard Sandiford <rsandifo at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords|wrong-code |internal-improvement > Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot > gnu.org > Status|NEW |ASSIGNED > > --- Comment #7 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc > index c0550acf6b2..06cd6e42355 100644 > --- a/gcc/tree-vect-stmts.cc > +++ b/gcc/tree-vect-stmts.cc > @@ -9908,7 +9908,8 @@ vectorizable_store (vec_info *vinfo, > = fold_build2 (MEM_REF, vectype, dataref_ptr, > dataref_offset ? dataref_offset > : build_int_cst (ref_type, 0)); > - if (alignment_support_scheme == dr_aligned) > + if (alignment_support_scheme == dr_aligned > + && align >= TYPE_ALIGN_UNIT (vectype)) > ; > else > TREE_TYPE (data_ref) > > seems to fix it. (Loads will need similar treatment.) > > The justification is that preferred_vector_alignment requests element > alignment > for SVE, even though the vector mode itself has 128-bit alignment. In that > context, dr_aligned means that element alignment has been reached. Hmm, indeed. We support "alignment" different from mode/type alignment. But we're also using 'dr_aligned' to indicate there cannot be a fault when accessing the vector which would be not sufficient either in this case. So I think there's a deeper issue with this misunderstanding of what 'dr_alignment' meands. > It looks like a long-standing issue, so I suppose it should wait for GCC 16. Not sure - this is definitely wrong-code.
