Hi Abhay,
On Fri, Oct 23, 2026 at 12:02:40AM +0530, Abhay Kandpal wrote:
> I compared the current candidate with the old release 3.27 and did
> not observe any new failures.
Great.
> But I observed a missing expected file.
>
> "none/tests/ppc32/xlc_dbl_u32" fails on P8 BE in 3.28.0.RC1 because
> xlc_dbl_u32.stderr.exp was removed in 3.28.0 (it was also dropped
> from EXTRA_DIST in none/tests/ppc32/Makefile.am). The file looked
> empty but contained two blank lines, which the test still writes to
> stderr, so vg_regtest now reports a stderr failure. The test program
> itself passes: it prints "pass" under Valgrind, the same as with
> 3.27.1. Restoring the file, or removing the two blank lines from
> the test's stderr, would fix it. It only shows on P8 BE because
> that's the only one of our machines where this 32-bit test runs.
Well spotted. commit 8ecbba5d1ba1 ("Remove essentially empty
.stderr.exp files in none/tests/...") removed
none/tests/ppc32/xlc_dbl_u32.exp but didn't add "vgopts: -q" to
none/tests/ppc32/xlc_dbl_u32.vgtest
I added that now. But as you note below the 32bit ppc tests don't run
on most current power cpus.
> Test Result for power machines.
>
> P10 LE
> == 788 tests, 9 stderr failures, 0 stdout failures, 0 stderrB failures, 0
> stdoutB failures, 0 post failures ==
> helgrind/tests/getaddrinfo (stderr)
> memcheck/tests/fwrite (stderr)
> memcheck/tests/linux/sys-copy_file_range (stderr)
> memcheck/tests/linux/sys-preadv_pwritev (stderr)
> memcheck/tests/sendmsg (stderr)
> memcheck/tests/writev1 (stderr)
> none/tests/track_bad (stderr)
> none/tests/track_new (stderr)
> none/tests/use_after_close (stderr)
>
> P9 LE
> == 780 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0
> stdoutB failures, 0 post failures ==
> helgrind/tests/getaddrinfo (stderr)
>
> P8 LE
> == 774 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0
> stdoutB failures, 0 post failures ==
> memcheck/tests/linux/rfcomm (stderr)
Yes, these all look like existing/known failures. We might want to
see if we can figure out why some of the backtraces look bad on the
P10 LE failutes. But that isn't a regression.
> Regarding the BE failures: none of the ones below are regressions; they also
> fail with 3.27.1.
>
> * ppc32 tests on P9/P10 BE: all of them stop with "VEX: ISA 3.0 not supported
> in 32-bit mode".
> * none/tests/ppc64/test_copy_paste on P10 BE: reports dst_buffer not equal to
> src_buffer under Valgrind. It passes on P10 LE.
> * none/tests/ppc64/test_isa_3_1_* on P10 BE: output mismatches across many
> ISA 3.1 instructions,
> including prefixed loads and stores (plbz, pld, plq, plxv, pstfd, ...), VSX
> loads (lxvp, lxvkq, ...),
> MMA GER (pmxvbf16ger2*), vcmpsq/vcmpuq and dcffixqq/dctfixqq. These tests
> pass on P10 LE.
> * drd/tests/pth_detached3 on P8 BE: fails consistently, with 3.27.1 as well.
> * drd/tests/tls_threads: flaky on our machines (it passes when rerun).
> * none/tests/ppc64/test_darn_inst, test_isa_3_0_altivec, test_isa_3_0_other
> on P9/P10 BE: fail with 3.27.1 as well.
Thanks for analyzing these and noting they aren't regressions. Big
endian support isn't really tested much. There is one debian ppc64[be]
buildbot that shows similar results as you posted:
https://builder.sourceware.org/buildbot/#/builders/valgrind-debian-ppc64
Cheers,
Mark
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
