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? > 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. -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity. Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
