Hi Alex,
> On Feb 3, 2026, Rainer Orth <[email protected]> wrote:
>
>> Hi Alex,
>>> Document and silence a few more "Invalid sum" test failures that I've
>>> hit on sparc-leon3-elf. One of the tests also affects other targets,
>>> according to the PR, while the other two also fail on sparc64-elf.
>>>
>>> Tested on sparc-leon3-elf with gcc-15, and on sparc64-elf with trunk.
>>> Ok to install?
>>>
>>>
>>> for gcc/testsuite/ChangeLog
>>>
>>> PR tree-optimization/119293
>>> * gcc.dg/vect/vect-33.c: XFAIL on sparc*-*-*.
>>> * gcc.dg/vect/vect-86.c: Likewise.
>>> * gcc.dg/vect/vect-epilogues.c: XFAIL on sparc-leon3-elf,
>>> s390x-*-* and powerpc64le-*-*.
>
>> I don't it's right to just xfail them without further analysis.
>
> My initial analysis suggested that these were variations of the problem
> I'd analyzed more deeply in the named PR.
>
> Here are more details.
>
> vect-33.c: The loop over 16 chars is vectorized with a prologue for
> alignment, a vectorized loop that stores 8 chars per iteration, and an
> epilogue. After fre5, the loop body undergoes threading wherein the
> block that succeeds the prologue is known not to iterate further, and
> it's resolving that conditional and removing the corresponding edge that
> misaligns the counts.
>
> vect-86.c: Nested loops over unknown-n ints in two arrays. a[j] is set
> to i+n in the inner loop for 0<=j<n, and b[i] is written in the outer
> loop for 0<=i<n. The inner loop is vectorized to write pairs of
> elements, with an epilogue for a potentially odd n. After fre5, we
> thread the outer loop latch in two paths, managing to eliminate the
> redundant test for n==1. Both removed edges mess with the counts of
> their successors, though one of them also involves propagation of
> probabilities and might be something more elaborate, but I hadn't
> noticed that in my cursory analysis.
>
> vect-epilogues.c: Nested loops wherein the inner loop sets unknown-W
> elements of DST by averaging corresponding elements in SRC1 and SRC2,
> all pointers to unsigned char, and the outer loop offsets all pointers
> by each one's unknown stride, for H times. We do not vectorize this
> testcase on sparc-elf. After fre5, we thread the W==0 condition that
> bypasses the inner loop into the subsequent loop iteration, and the
> elimination of the condition messes with counts and probabilities, and
> enables bb merging and a quite useless partial outer loop, that later
> passes eliminate, but the effects of the misalignments between counts
> and probabilities in the return block remain all the way to the end.
>
>> Besides, there are open PRs for all three of them:
>
>> vect-33.c PR tree-optimization/115184
>
> This could most certainly duped onto PR119293, it's just another
> occurrence of the same problem.
>
>> vect-86.c PR tree-optimization/123199
>
> The above also covers the remaining failure in vect-epilogue.
>
> This *probably* could also be duped onto the same PR, but there's a
> twist WRT probability estimations that I don't see in vect-33.c or
> vect-121.c, which might justify keeping a separate PR. But from my
> partial understanding of the problem, ISTM that there's also some
> significant likelihood that fixing the updates will fix these as well.
>
>> vect-epilogues.c PR testsuite/92310
>
> This one seems to be about the failure to vectorize the epilogue, which
> we don't seem to hit any more. Do you?
You're right, I don't. I should have looked closer at the actually
failure.
>> since they FAIL on sparc*-sun-solaris2.11 as well.
>
> I suppose generalizing sparc-leon3-elf to sparc-*-* for all 32-bit sparc
> for the latest XFAIL would make sense.
>
>
> Anyhow, I'd be happy to add my analysis to PR119293, in case we agree to
> dupe the others, or to file the analyses in the separate reports if
> we're keeping them. My personal preference would be to consolidate and
> aggregate the information in a single place (so, the former), but I
> wouldn't mind doing otherwise, or mentioning PRs that remain open in the
> commit message for cross-referencing.
It would certainly help to have the dupes marked appropriately.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
