Hi Abhay, On Sun, Apr 19, 2026 at 12:25:02AM +0530, Abhay Kandpal via Valgrind-developers wrote: > I did testing again for valgrind-3.27.0.RC2.tar.bz2 on all setup like P10 LE, > P9 LE/BE, P8 LE. > > I found the results are mostly the same or slightly improved like for P9 BE, > below cases are fixed in RC2. > none/tests/fdleak_ipv4 (stderr) > none/tests/fdleak_ipv4_xml (stderr) > none/tests/fdleak_ipv4_xml (stdout) > > Versions used are the same as during RC1 testing which I already shared in my > previous mail.
Great. Thanks. > Technical Analysis: > ------------------- > > Valgrind's configure script detects AltiVec by parsing LD_SHOW_AUXV output: > > if env LD_SHOW_AUXV=1 true | grep ^AT_HWCAP | grep -q -w altivec > then > HWCAP_HAS_ALTIVEC='yes' > fi > > > With glibc 2.41, LD_SHOW_AUXV prints human-readable capability names: > > AT_HWCAP: true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec > ppc64 ppc32 > > > With glibc 2.42, it only prints raw hex values: > > AT_HWCAP: 0xdc0065c2 > > > > The hex value 0xdc0065c2 does have the AltiVec bit set (bit 28 = 0x10000000), > confirming > that the hardware supports AltiVec. > > > On BE systems, VGCONF_ARCH_SEC='ppc32' causes the ppc32 test suite to be > built. Without HWCAP_HAS_ALTIVEC='yes', > the -maltivec flag is omitted, and testVMX.c fails to compile. > > LE systems are unaffected because VGCONF_ARCH_SEC is empty and ppc32 tests > are not built. Wow, interesting failure. And nice analysis. > Workaround applied: I manually set HWCAP_HAS_ALTIVEC='yes' in the > configure script on P10/P8 BE systems to unblock testing. After > that, make and make regtest completed successfully. Results were > same as RC1. Thanks. Given there is a workaround, this is only with make regtest and on a secondary arch which isn't super popular I think we won't try to fix this before the release. > I still need to investigate whether this change in glibc 2.42 is intentional. Yes, this is slightly surprising change in behaviour for glibc LD_SHOW_AUXV=1 I don't see anything in NEWS that would explain the change. > Currently, Valgrind's configure.ac handles only the string format, not hex. > Do we need to handle this in configure.ac? To be honest I think these AC_HWCAP_CONTAINS_FLAG usage in configure are testing the wrong thing. They look whether the hardware supports some feature, but then use it to provide a flag to gcc for building something for that feature. So instead of a runtime check we should add a compiler flag check (and then do the runtime check before running the test). > Otherwise valgrind 3.27.0 RC2 is good to go. Thanks, I'll prep the final release now. Cheers, Mark _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
