[gcc r17-2729] testsuite/aarch64: use a relative tolerance in vect-vaddv.c

https://gcc.gnu.org/g:f44527143df24430447d68e4b0e461685827f0f6

commit r17-2729-gf44527143df24430447d68e4b0e461685827f0f6
Author: Kyrylo Tkachov <[email protected]>
Date:   Sun Jul 26 05:18:55 2026 -0700

    testsuite/aarch64: use a relative tolerance in vect-vaddv.c
    
    The test builds a reference sum by adding the elements in order and
    compares it against the vaddv reduction with an absolute tolerance of
    1e-6.  vaddvq_f32 expands to two faddp, i.e. a pairwise sum, so the two
    sides associate differently and agree only to within a few ULP.  At the
    magnitudes in input_float32[] one float32 ULP is 6.1e-5 to 2.4e-4, tens
    to hundreds of times larger than the tolerance, so the comparison only
    ever passed when both sides happened to round the same way.
    
    The test compiles with -ffast-math, and since r17-2478-g3adb33259541
    ("Improve BB vectorization of reductions", PR tree-optimization/126028)
    the reference chain is reassociated too, which changes the rounding and
    the test aborts in test_vaddvf32_float32x4_t.  That commit removed the
    forced-even-lane trim in vect_slp_check_for_roots and added the
    non-matching-lane split retry in vect_build_slp_instance, so the four
    input_float32[] lanes are now discovered as a group once the out_l[0]
    lane is split off.  Both association orders are legal here and both land
    within 1 ULP of the exact sum.
    
    This is the third time the test has broken this way.  PR testsuite/101506
    added the asm barrier on the reference accumulator for the same reason.
    
    Compare relatively instead.  Every reference value in the test is
    non-zero, so a plain relative test is safe, and at 1e-6 relative the
    float32 checks still have about a factor of ten of margin over the
    worst-case three-ULP reassociation error for this data.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.target/aarch64/vect-vaddv.c (EQUALF, EQUALD): Compare
            relative to the reference value.
    
    Signed-off-by: Kyrylo Tkachov <[email protected]>

Diff:
---
 gcc/testsuite/gcc.target/aarch64/vect-vaddv.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/vect-vaddv.c b/gcc/testsuite/gcc.target/aarch64/vect-vaddv.c
index 3a12ae9706af..47c1f77a5bc3 100644
--- a/gcc/testsuite/gcc.target/aarch64/vect-vaddv.c
+++ b/gcc/testsuite/gcc.target/aarch64/vect-vaddv.c
@@ -41,8 +41,11 @@ double input_float64[] = {0.1, -0.1, 0.4, 10.3,
 			  7.9, -870.0, 10.4, 310.11,
 			  0.0, -865.0, -2213.0, -1.5};
 
-#define EQUALF(a, b) (fabsf (a - b) < DELTA)
-#define EQUALD(a, b) (fabs (a - b) < DELTA)
+/* The reference sum and the vaddv reduction associate the addends
+   differently, so they agree only to within a few ULP.  Compare with a
+   relative tolerance: every reference value here is non-zero.  */
+#define EQUALF(a, b) (fabsf (a - b) <= DELTA * fabsf (b))
+#define EQUALD(a, b) (fabs (a - b) <= DELTA * fabs (b))
 #define EQUALL(a, b) (a == b)
 
 #define TEST(SUFFIX, Q, TYPE, LANES, FLOAT)				\