Re: Valgrind-3.27.0.RC2 is available for testing

Hi Abhay,

On Sun, Apr 19, 2026 at 12:25:02AM +0530, Abhay Kandpal via Valgrind-develo=
pers 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 i=
n my previous mail.

Great. Thanks.

> Technical Analysis:
> -------------------
> =

> =A0Valgrind's configure script detects AltiVec by parsing LD_SHOW_AUXV ou=
tput:
> =

>     if env LD_SHOW_AUXV=3D1 true | grep ^AT_HWCAP | grep -q -w altivec
>     then
>         HWCAP_HAS_ALTIVEC=3D'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 alti=
vec 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 =3D 0x1000=
0000), confirming
> that the hardware supports AltiVec.
> =

> =

> On BE systems, VGCONF_ARCH_SEC=3D'ppc32' causes the ppc32 test suite to b=
e built. Without HWCAP_HAS_ALTIVEC=3D'yes',
> the -maltivec flag is omitted, and testVMX.c fails to compile.
> =

> LE systems are unaffected because VGCONF_ARCH_SEC is empty and ppc32 test=
s are not built.

Wow, interesting failure. And nice analysis.

> Workaround applied: I manually set HWCAP_HAS_ALTIVEC=3D'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 intentio=
nal.

Yes, this is slightly surprising change in behaviour for glibc
LD_SHOW_AUXV=3D1 I don't see anything in NEWS that would explain the
change.

> Currently, Valgrind's configure.ac handles only the string format, not he=
x. 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