VEX/priv/guest_x86_helpers.c: Helper functions for
crc32 computation
VEX/pub/libvex_guest_x86.h: Helper function decls
VEX/priv/guest_x86_toIR.c: The crc32 instruction decoder
none/tests/x86/crc32.c: New testcase
none/tests/x86/crc32.stdout.exp: Ditto (expected output)
none/tests/x86/crc32.vgtest: Ditto (testcase config)
none/tests/x86/Makefile.am: Plug the test in
tests/check_ppc64_auxv_cap: replace LD_SHOW_AUXV-grep shell script with C program using getauxval()
glibc 2.42 removed sysdeps/powerpc/dl-procinfo.h, which contained
the PowerPC-specific _dl_procinfo() hook that printed human-readable
capability strings in LD_SHOW_AUXV output. After the change,
LD_SHOW_AUXV emits raw hex for AT_HWCAP / AT_HWCAP2 instead of
capability names like 'altivec' or 'vsx'.
tests/check_ppc64_auxv_cap was a shell script that grep'd
LD_SHOW_AUXV output for capability words, used as a .vgtest 'prereq:'
across many PowerPC tests under none/tests/ppc{32,64}/ and
memcheck/tests/ppc{32,64}/. On glibc 2.42 it always returns
non-zero, so vg_regtest.in silently skips every test that depends
on it (rc 256, "skipping, prereq failed"). Effectively the entire
PowerPC instruction-level regression suite was disabled.
Replace the shell script with a small C program using getauxval(),
which reads AT_HWCAP / AT_HWCAP2 directly and is unaffected by the
glibc change. Calling convention and exit codes match the original
script exactly, so none of the .vgtest files need modification:
check_ppc64_auxv_cap <capability>
exit 0 - capability is present
exit 1 - capability is absent, unknown, or usage error
tests/Makefile.am: move check_ppc64_auxv_cap from dist_noinst_SCRIPTS
to check_PROGRAMS so automake builds the binary from the C source.
For portability, configure.ac is extended with AC_CHECK_FUNCS([getauxval])
to detect whether the platform provides getauxval(). On glibc Linux it
is always present (since 2.16, 2012). On other platforms (FreeBSD,
Solaris, macOS) the function may be absent; on those, the program is
compiled with a stub main() that returns 1 for every query. None of
those platforms currently use Valgrind's PowerPC port, but the build
must still succeed there.
Mark Wielaard [Thu, 18 Jun 2026 12:34:19 +0000 (14:34 +0200)]
Check compiler support -mcpu=power9 or power10 for isa 3.0 and isa 3.1
For the HAS_ISA_3_00 and HAS_ISA_3_1 conditionals we want the compiler
to support -mcpu=power9 (isa 3.0) and -mcpu=power10 (isa 3.1) because
we will pass that flag when building test cases.
The old script did not complain about missing header files belonging to
a newly added testcase. I could not figure out how to improve the old
script to handle this so I rewrote it and added a few more checks. See
the commentary in the script.
The makefile parser is more robust and can process the generated
makefiles instead of reading Makefile.am files. Which eliminates any
worries about handling include directives and ifdeffery.
Abhay Kandpal [Tue, 16 Jun 2026 13:16:54 +0000 (08:16 -0500)]
configure.ac: Fix AC_HWCAP_CONTAINS_FLAG for glibc 2.42 on PowerPC
glibc 2.42 removed sysdeps/powerpc/dl-procinfo.h which contained
the _dl_procinfo() hook responsible for printing human-readable
capability strings in LD_SHOW_AUXV output on PowerPC. As a result,
LD_SHOW_AUXV now prints raw hex values (e.g. 0xdc0065c2) instead
of capability names (e.g. altivec vsx ppc64 ppc32).
The AC_HWCAP_CONTAINS_FLAG macro was using LD_SHOW_AUXV text output
and grep to detect hardware capabilities at configure time. This
broke on glibc 2.42 causing HWCAP_HAS_ALTIVEC and other flags to
be unset, resulting in testVMX.c failing to compile on PowerPC BE
systems due to missing -maltivec flag.
Beyond the immediate glibc-2.42 breakage, the configure-time HWCAP
checks were conceptually wrong: they answer "does the build host
have these capabilities right now?" when the right build-time
question is "can the compiler/assembler emit these instructions?".
Runtime hardware capability is a runtime concern and is already
handled by coregrind/m_machine.c's signal-based probes in
VG_(machine_get_hwcaps)(). Mark suggested removing the HWCAP
clauses entirely and relying on the existing assembler/compiler
checks alone.
This patch:
- Removes AC_HWCAP_CONTAINS_FLAG and all 10 of its invocations.
- Drops the '-a x$HWCAP_HAS_* = xyes' clause from 8 AM_CONDITIONALs:
HAS_ISA_2_07, HAS_ALTIVEC, HAS_VSX, HAS_DFP, BUILD_DFP_TESTS,
SUPPORTS_HTM, HAS_ISA_3_00, HAS_ISA_3_1.
- Forces HAS_ISA_2_05 unconditionally true. ISA 2.05 is POWER6
(2007); no supported PowerPC system today lacks it. The
conditional can't be deleted because tests/Makefile.am still
references it.
- Replaces HAS_ISA_2_06's HWCAP clause with the existing VSX
assembler check, since VSX was introduced in ISA 2.06 and any
assembler that accepts VSX accepts ISA 2.06. The AM_CONDITIONAL
is relocated to after the VSX assembler probe so the variable
ac_compiler_supports_vsx is defined when it is read.
- HWCAP_HAS_MMA was defined but never consumed in configure.ac,
so removing the macro call is a clean removal.
Mark Wielaard [Sat, 13 Jun 2026 22:01:49 +0000 (00:01 +0200)]
Fix compile issue in VEX/priv/guest_amd64_helpers.c with GCC8
GCC 8.5.0 doesn't like a direct variable declaration after a case
statement.
priv/guest_amd64_helpers.c: In function 'amd64g_dirtyhelper_CPUID_avx2':
priv/guest_amd64_helpers.c:3653:10: error: a label can only be part of a
statement and a declaration is not a statement
Create a block for the case statement to declare the variable.
Martin Cermak [Fri, 12 Jun 2026 15:07:52 +0000 (17:07 +0200)]
Update the LTP version in valgrind testsuite to v20260529
Update the LTP version in valgrind testsuite to v20260529.
All patches from auxprogs/ltp-patches were accepted by LTP
upstream and included in the release, so these can now be
dropped locally.
Mark Wielaard [Mon, 8 Jun 2026 13:09:04 +0000 (15:09 +0200)]
Add PMULDQ SSE4.1 support for x86
Add handling of PMULDQ to VEX/priv/guest_x86_toIR.c based on the
guest_amd64_toIR.c implementation (inline math_PMULDQ_128).
Move test_PMULDQ from none/tests/amd64/sse4-64.c to
none/tests/sse4-common.h and add the same test to
none/tests/x86/sse4-x86.c with new PMULDQ output in stdout.exp.
Mark Wielaard [Wed, 27 May 2026 18:03:47 +0000 (20:03 +0200)]
Add x86 ROUNDPS and ROUNDPD
This completes the ROUNDPS, ROUNDSS, ROUNDPD and ROUNDSD SSE4.1
support for x86. x86 already supported SSE 4.1 ROUNDSS and ROUNDSD
instructions.
Add ROUNDPS and ROUNDPD support in VEX/priv/guest_x86_toIR.c based on
the amd64 implementation. Move the testcases from sse4-64.c to
sse4-common.h and make them use XMMREG_DST instead of xmm11 (which
isn't available on x86).
Add testcase output for test_ROUNDPD_w_immediate_rounding,
test_ROUNDPS_w_immediate_rounding, test_ROUNDPD_w_mxcsr_rounding and
test_ROUNDPS_w_mxcsr_rounding to sse4-x86.stdout.exp.
Florian Krohm [Sun, 7 Jun 2026 15:21:12 +0000 (15:21 +0000)]
Remove essentially empty .stderr.exp files in none/tests/...
Where "essentially empty" means "containing two empty lines only".
That not-so-interesting output can nicely be suppressed by adding
"vgopts: -q" to the respective .vgtest file.
Two exceptions:
(1) vgtest files already containing vgopts are not modified.
(2) If there is more than one .stderr.exp file all .stderr.exp
files are retained.
Moved sel16x4_0/1/2/3 to VEX/priv/guest_generic_helpers.h.
Moved amd64g_calculate_sse_phminposuw from guest_amd64_helpers.c
to guest_generic_helpers.h and renamed to
g_calculate_sse_phminposuw so both x86 and amd64 can use it.
Add test function to sse4-common.h and update
none/tests/x86/sse4-x86.c to test the instruction.
Paul Floyd [Wed, 3 Jun 2026 19:39:00 +0000 (21:39 +0200)]
Warning cleanup: one more -Wmisleading-indentation for minilzo-inl.c
I think that I will give up here. The ones in minilzo-inl.c were
easy to fix. The others are all deep in macros and caused by
macros putting everything on one line. I don't think that it's worth
the effort to use pragmas or per-file compiler options or to convert
the macros to static inline functions. I'm only seeing them with
GCC 8.5 on ppc64le.
Paul Floyd [Wed, 3 Jun 2026 06:06:49 +0000 (08:06 +0200)]
Regtest warnings: fixes for GCC 16.1 C++20 volatile deprecation
We now get warnings for things like using operator++ on a volatile.
Simply removing the volatile keyword seems to solve the problem.
In two of the cases the value is now returned in order to prevent the
compiler from optimising away the variable (which was probably the
original intent).
Paul Floyd [Sun, 31 May 2026 05:53:50 +0000 (07:53 +0200)]
Massif doc: mention that Darwin x86 uses unsigned long for size_t.
This is somewhat academic, macOS 10.15 dropped x86 in 2019,
Valgrind does not support macOS 10.14 x86 since it uses AVX.
The last version of macOS x86 that we do have support for is
macOS 10.13 which was released in 2017 and ended support in
2020.
Paul Floyd [Fri, 29 May 2026 19:16:32 +0000 (21:16 +0200)]
Darwin version macros: remove DARWIN_10_6 and DARWIN_10_7
A while back I bumped up the configure.ac oldest supported OSX to
version 10.8 (that's the oldest with an xcode supporting C11,
I suppose that we could use MacPorts gcc or clang but I don't
want to turn back now).
There were a good number of uses of conditional DARWIN_10_6
and DARWIN_10_7 in the code that this change purges.
Paul Floyd [Fri, 29 May 2026 06:31:39 +0000 (08:31 +0200)]
Warning cleanup: make sure that either macros are defined or use #ifdef rather than #if
A comment in https://bugs.kde.org/show_bug.cgi?id=519604 about correctly checking
for DARWIN_VERS led me to doing some builds with -Wundef. We still get quite a few
warnings from mips and LZO. I'll repeat the exercise on illumos Darwin and Linux amd64.
Florian Krohm [Fri, 22 May 2026 20:08:50 +0000 (22:08 +0200)]
Remove VEX/test
The snippets there are not suitable for testsuite integration.
Some compile with warnings or not at all (x87fxam.c, x87tst.c),
fpucw.c has no meaningful output. The remaining ones test x87
FPU state save / restore by dumping the state as hex bytes. That
would result in several .exp files because FPU state contains
instruction and data addresses.
Mark Wielaard [Fri, 22 May 2026 05:39:56 +0000 (07:39 +0200)]
Use helper functions to print double +/- inf/nan for sse4 testcase
Different libc printf implementations can have different ways to print
plus/minus nan/inf values. Add a print_double wrapper that checks
whether the double value is a nan, inf and whether it has a positive
or negative signbit. Similarly add a print_float wrapper. This way
we don't need any alternative .exps or filters.
Mark Wielaard [Thu, 5 Mar 2026 17:49:32 +0000 (18:49 +0100)]
Add PACKUSDW SSE4.1 support for x86
Add handling of PACKUSDW to VEX/priv/guest_x86_toIR.c based on the
guest_amd64_toIR.c implementation. Handle Iop_QNarrowBin32Sto16Ux8
using h_generic_calc_QNarrowBin32Sto16Ux8 in VEX/priv/host_x86_isel.c.
Move test_PACKUSDW from none/tests/amd64/sse4-64.c to
none/tests/sse4-common.h and add the same test to
none/tests/x86/sse4-x86.c with new PACKUSDW output in stdout.exp.
Support pextrd instruction in guest_x86_toIR.c and
host_x86_isel.c. Add test function to sse4-common.h
and update none/tests/x86/sse4-x86.c to test the
instruction.
Florian Krohm [Sat, 16 May 2026 20:31:17 +0000 (20:31 +0000)]
New test none/tests/x86/fb_test_i386.c
This is essentially VEX/test/test-i386* with various fixes.
The md5sum code in fb_test_i386.c was copied verbatim from
none/tests/amd64/fb_test_amd64.c.
Extracts system register shift and mask macros to a new VEX public
header libvex_guest_arm64_sysregs.h
These macros are used in both VEX dirty helpers and coregrind
VG_(machine_get_hwcaps).
Mostly this is just refactoring the code. It should be more robust
in the face of changes concerning future ARM CPU features. The
id_aa64pfr0_el1 dirty helper has changed a bit - the code was wrong
but the output was right (for what we currently support).
Paul Floyd [Sun, 10 May 2026 13:10:58 +0000 (15:10 +0200)]
arm64: change configure dotprod test to a run test
We were testing for dotprod with AC_COMPILE_IFELSE. That's wrong, it just
checks that the compiler accepts -march=armv8.2-a+dotprod and that the
assembler handles dotprod opcodes. Changed it to AC_RUN_IFELSE which
additionally checks that the binary runs. Valgrind should be checking
for this in VG_(machine_get_hwcaps), storing it in VexArchInfo and
checking it in guest_arm64_toIR.c (it looks like we check it but don't
store 'dp' in vai.hwcaps and in general VEX doesnt check whether it
should try to decode these extensions).
This fixes the last part of the issues - CPUs with and without
crypto support. Rather than just fix building tests this splits
the crypto part out of fp_and_simd.c into a new file, v8crypro.c
Paul Floyd [Sun, 10 May 2026 07:34:19 +0000 (09:34 +0200)]
arm64: add a configure check for crypto support
This is related to https://bugs.kde.org/show_bug.cgi?id=391311
In the patch for that bugzilla item there is a build time fix.
Without the crypto tests the test will fail.
If there are no issues with this configure test I'll split off a new
test v8crypto from fp_and_simd.
This is point 6 on the list.
1. Cache the DZP bit from mrs dczid_el0 in a new field arm64_data_zero_prohibited of VexArchInfo
2. Use the cached values from VexArchInfo for mrs dczid_el0 rather than a dirty helper
3. Add a check to dc zva that the above DZP wasn't set. If it is then print a message
and stop with a Ijk_SigILL.
Paul Floyd [Fri, 8 May 2026 10:47:41 +0000 (12:47 +0200)]
Regtest: make x86 and amd64 inf and nan production cross platform, part 2
This is for FreeBSD and probably Darwin as well.
Now that we have the same nan generation on all platforms we only need two
expecteds for these tests, one where printf of a negative nan outputs
-nan and the other where it outputs nan.
So, add an expected for FreeSD x86. Rationalise the amd64 expecteds.
There were 2 for FreeBSD only differentiated by the mkPosNan codegen.
Now just the one is needed. While I'm at it make the expected name
more consistent, exp-freebsd rather than exp.freebsd.
Paul Floyd [Fri, 8 May 2026 07:05:42 +0000 (09:05 +0200)]
Regtest: make x86 and amd64 inf and nan production cross platform
We were using 1.0/0.0 to produce a positive inf and 0.0/0.0 to
produce a postive nan. GCC and clang handle the nan case
differently. GCC generates the division which counterintuitively
results in a negative nan. clang does constant folding and
directly generates a positive nan.
This change uses __builtin_inf and __builtin_nan instead. These
were added back with GCC 3.3 so there should be no backwards
compatibility issues.
Add these and adapt the ROUNDSS and ROUNDSD testcases so they work on
both amd64 and x86. Move get_mxcsr, set_mxcsr, get_sse_roundingmode
and set_sse_roundingmode from sse4-64.c to sse4-common.h (and add x86
variants). Move ROUNDSD and ROUNDSS test function and make them use
XMMREG_DST instead of xmm11 (which isn't available on x86).
Add testcase output for test_ROUNDSD_w_immediate_rounding(),
test_ROUNDSS_w_immediate_rounding(), test_ROUNDSD_w_mxcsr_rounding()
and test_ROUNDSS_w_mxcsr_rounding() to sse4-x86.stdout.exp.
Paul Floyd [Sun, 3 May 2026 06:39:07 +0000 (08:39 +0200)]
Darwin persona syscall: use the SYS_persona macro to detect at build time
It looks like I broke OSX 10.10 build when I added the persona wrapper.
Rather than hard code the version for persona this should work on
all platforms. In the longer term I'd like to do the same as Linux
and FreeBSD and not use a VERS macro for Darwin syscalls.
Mark Wielaard [Sat, 2 May 2026 20:59:23 +0000 (22:59 +0200)]
Change XMMREG_DST in sse4-common.h back to xmm11 for amd64
XMMREG_DST for amd64 (x86_64) was accidentially set to xmm7 instead of
using xmm11 in commit a1904db1dd0ee8c046a3fd89c822463cd496d78e.
Add SSE4.1 PBLENDVB, BLENDVPS and BLENDVPD
Change it back to xmm11 to make sure a register that isn't available
in 32bit mode is tested. No changes to any of the test results because
of this.
Paul Floyd [Fri, 1 May 2026 09:16:17 +0000 (11:16 +0200)]
Darwin fixup_macho_loadcmds: make build more flexible
Part of work for https://bugs.kde.org/show_bug.cgi?id=519604
The value of maxprot for the __UNIXSTACK load command changed
from 7 to 3 during the macOS 10.14 lifecycle. Our code used
the SDK value to decide which to check for. MacPorts buildbot
targets all macOS 10.14 versions which does not work with our
assumption that latest 10.14 SDK => maxprot 3. In order to make
this more flexible we now allow maxprot 3 or 7 on macOS 10.14.
This is just for fixup_macho_commands that just gets used
once for each tool during builds.