Re: Valgrind-3.27.0.RC2 is available for testing
Abhay Kandpal via Valgrind-developers <valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Sun, 19 Apr 2026 00:25:02 +0530
| Newsgroups | gmane.comp.debugging.valgrind.devel,gmane.comp.debugging.valgrind |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7845603627807259430==
Content-Type: multipart/alternative;
boundary="------------lp0auyveLLk8bRcCKXc9uW8Y"
Content-Language: en-GB
This is a multi-part message in MIME format.
--------------lp0auyveLLk8bRcCKXc9uW8Y
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Mark,
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.
Here, I want to bring attention about error during "make regtest" which I encountered during testing in P10/P8 BE machines.
Current version in the systems for P10/P8 (BE):
GCC: GCC 15.2.0 (Debian) , Glibc: 2.42-14
During "make regtest" I got below error:
gcc -DALTIVEC -DGCC_COMPILER -m32 -MT testVMX-testVMX.o -c -o testVMX-testVMX.o testVMX.c
In file included from testVMX.c:249:
/usr/lib/gcc/powerpc64-linux-gnu/15/include/altivec.h:34:2: error:
#error Use the "-maltivec" flag to enable PowerPC AltiVec support
Root cause: The "-maltivec" flag is not being added because configure fails to detect AltiVec.
Background / How This Was Encountered:
-------------------------------------
After RC1 testing, I needed to install the libc6-dbg (glibc debuginfo) package on P10 BE and P8 BE to resolve Valgrind failures caused by missing debug symbols.
Installing libc6-dbg via apt silently upgraded the base libc6 package from version 2.41-12 to 2.42-14 as a dependency.
When RC2 was released and I ran configure fresh, make and then "make regtest" failure appeared.
P9 BE was not affected because I never installed libc6-dbg on that system, so it remains on glibc 2.41.
Confirmed glibc versions:
- P9 BE: glibc 2.41-12 (working)
- P10 BE: glibc 2.42-14 (failing)
- P8 BE: glibc 2.42-14 (failing)
- P10 LE: glibc 2.42 (working - LE does not build ppc32 tests)
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.
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.
I still need to investigate whether this change in glibc 2.42 is intentional.
Currently, Valgrind's configure.ac handles only the string format, not hex. Do we need to handle this in configure.ac?
Otherwise valgrind 3.27.0 RC2 is good to go.
Regards
Abhay Kandpal
On 18/04/26 06:35, Mark Wielaard wrote:
> An RC2 tarball for 3.27.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2
> (md5sum = 64b955764abeb80fd3e0b6287e596750)
> (sha1sum = a52b15d2f75619762fb1c5007e7c2c26d7e3711e)
> https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2.asc
> Public keys can be found athttps://www.klomp.org/mark/gnupg-pub.txt
>
> Please give it a try in configurations that are important for you and
> report any problems you have, either on this mailing list, or
> (preferably) via our bug tracker at
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
>
> The final 3.27.0 release is scheduled for Mon Apr 20.
>
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
--------------lp0auyveLLk8bRcCKXc9uW8Y
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre>Hi Mark,
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.
Here, I want to bring attention about error during "make regtest" which I encountered during testing in P10/P8 BE machines.
Current version in the systems for P10/P8 (BE):
<pre>GCC: GCC 15.2.0 (Debian) , Glibc: 2.42-14
During "make regtest" I got below error:
</pre></pre>
<table cellpadding="2" cellspacing="2" border="1" width="716"
height="81">
<tbody>
<tr>
<td valign="top">
<pre> gcc -DALTIVEC -DGCC_COMPILER -m32 -MT testVMX-testVMX.o -c -o testVMX-testVMX.o testVMX.c
In file included from testVMX.c:249:
/usr/lib/gcc/powerpc64-linux-gnu/15/include/altivec.h:34:2: error:
#error Use the "-maltivec" flag to enable PowerPC AltiVec support</pre>
</td>
</tr>
</tbody>
</table>
<pre><pre>Root cause: The "-maltivec" flag is not being added because configure fails to detect AltiVec.
Background / How This Was Encountered:
-------------------------------------
After RC1 testing, I needed to install the libc6-dbg (glibc debuginfo) package on P10 BE and P8 BE to resolve Valgrind failures caused by missing debug symbols.
Installing libc6-dbg via apt silently upgraded the base libc6 package from version 2.41-12 to 2.42-14 as a dependency.
When RC2 was released and I ran configure fresh, make and then "make regtest" failure appeared.
P9 BE was not affected because I never installed libc6-dbg on that system, so it remains on glibc 2.41.<pre>Confirmed glibc versions:
- P9 BE: glibc 2.41-12 (working)
- P10 BE: glibc 2.42-14 (failing)
- P8 BE: glibc 2.42-14 (failing)
- P10 LE: glibc 2.42 (working - LE does not build ppc32 tests)
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.
<span><span>Workaround applied: I manually set HWCAP_HAS_ALTIVEC='yes' in the configure script </span></span><span>on P10/P8 BE systems to unblock testing.
After that, make and make regtest completed </span><span>successfully. Results were same as RC1.</span>
I still need to investigate whether this change in glibc 2.42 is intentional.
Currently, Valgrind's configure.ac handles only the string format, not hex. Do we need to handle this in configure.ac?
Otherwise valgrind 3.27.0 RC2 is good to go.
Regards
Abhay Kandpal</pre>
</pre></pre>
<pre class="moz-cite-prefix">On 18/04/26 06:35, Mark Wielaard wrote:
</pre>
<blockquote type="cite"
cite="mid:20260418010512.GE14133-ccHWXNLP7XmvZOhXRs0CNB2eb7JE58TQ@public.gmane.org">
<pre wrap="" class="moz-quote-pre"><pre>An RC2 tarball for 3.27.0 is now available at
<a class="moz-txt-link-freetext" href="https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2">https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2</a>
</pre>(md5sum = 64b955764abeb80fd3e0b6287e596750)
(sha1sum = a52b15d2f75619762fb1c5007e7c2c26d7e3711e)
<a class="moz-txt-link-freetext" href="https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2.asc">https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.bz2.asc</a>
Public keys can be found at <a class="moz-txt-link-freetext" href="https://www.klomp.org/mark/gnupg-pub.txt">https://www.klomp.org/mark/gnupg-pub.txt</a>
Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
<a class="moz-txt-link-freetext" href="https://bugs.kde.org/enter_bug.cgi?product=valgrind">https://bugs.kde.org/enter_bug.cgi?product=valgrind</a>
The final 3.27.0 release is scheduled for Mon Apr 20.
_______________________________________________
Valgrind-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org">Valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/valgrind-developers">https://lists.sourceforge.net/lists/listinfo/valgrind-developers</a>
</pre>
</blockquote>
</body>
</html>
--------------lp0auyveLLk8bRcCKXc9uW8Y--
--===============7845603627807259430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7845603627807259430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
--===============7845603627807259430==--