And sadly that was one that I broke trying to refactor together all our C++ autoconf tests. Silver lining, I added a test for it so if I break it again we should notice earlier.
"some community effort" is a huge understatement. Let me rephrase that for you: "Possibly the largest ever single contribution to Valgrind".
Initial work on this was started by an engineer at Intel. She was based in St Petersburg so that work stalled in 2022. Here is the bugzilla item https://bugs.kde.org/show_bug.cgi?id=383010. The other big issue is that we don't have enough people working on Valgrind that are experts with the virtual CPU. There are a couple of guys working on s390 and a little bit of work is being done reusing amd64 sse4 support on x86. I dabble a little bit on arm64,
If there are any AVX512 experts that would like to help with this it would be most welcome.
I didn't intend to make a statement about the programming effort required. I wanted to contrast it with corporate politics at CPU vendors, from which it is largely decoupled. Given the size of the task, it needs corporate funding, just not from x86 vendors. For example, we're fairly strongly incentivized to make valgrind support for any potential future x86-64-v4 transition because our development community really expects valgrind support as part of the core toolchain.
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.
See my other reply for contents. Changed since RC0:
Copyright notices, Linux fsconfig syscall fix, s390 instruction selection bug, macOS build failure from distribution tarballs, a few more opcodes handled on x86.
We still use KDE's bugzilla. One of the reasons that Vagrind was initially developed was to help with KDE back when many developers didn't really understand how to use new and delete.
These days sourceware.org hosts the Valgrind git repo, buildbot CI and web site. We could also use their bugzilla. There isn't much point migrating as long as KDE can put up with us.
There was someone at Intel working on AVX512 support in Valgrind. She is/was based in St Petersburg. Intel shuttered their Russian operations when Putin invaded Ukraine and that project stalled.
If anyone has the time and knowledge to help with AVX512 support then it would be most welcome. Fair warning, even with the initial work already done this is still a huge project.
The problem is that there are many many people that are falling over themselves to believe bogus claims about false positives.
Outside of Valgrind bugzilla bug reports these claims almost never stand up to close scrutiny. Not that the people making the claims ever perform any scrutiny. It's usually "my application doesn't crash so it must be a false positive" or "I'm sure that I initialised that variable" or "it's not really a leak, the OS will reclaim the memory".
I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.
Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.
reply