https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124166
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |arm
Status|UNCONFIRMED |NEW
Component|other |testsuite
Last reconfirmed| |2026-02-19
Ever confirmed|0 |1
Keywords| |testsuite-fail
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think check_effective_target_arm_vect_no_misalign isn't appropriate for
vect_no_align, it is for !vect_hw_misalign. But I'm honestly not sure what
vect_no_align, aka "does not support a vector alignment mechanism", should
mean. It _might_ be something that only powerpc has, vect-realign loads,
though the large list of targets maybe suggests sth different ...
It for sure does not mean a target cannot do peeling or versioning for
alignment. For the testcases in question we rely on aligning global
variables and handling one misaligned access:
for (i = 0; i < N; i++)
{
next_a = a[i+1];
curr_a = x > c[i] ? curr_a : next_a;
}
so here indeed I'd expect only targets that can handle misaligned
vector accesses or a scheme like re-aligning loads to handle the loop.
But of course with outer loop vectorization both a[] and c[] are simply
scalar loads and not subject to any such restriction, instead x_in/x_out
are, and those variables can be both aligned.
So IMO the condition is simply bogus and the XFAIL can be removed?
