https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122976
--- Comment #2 from Jacek Sieka <arnetheduck at gmail dot com> --- > -fno-lto We use no-lto for all cryptography (it's incompatible with certain constant-time requirements) so the fact that some TUs were being compiled with no-lto was not a result of trying to minimize the issue - rather it's a general property of the build system. It was only by chance that we found that flipping the LTO flag makes a difference, however .. > Does the issue still reproduce when compiling select other TUs with -fno-lto? .. it's tricky. The observability of the bug depends on (the equivalent of) calling `free` with an invalid pointer. Depending on what code we remove when minimizing, the pointer we pass to free gets overwritten with different values - in the particular example posted here, the pointer gets overwritten by some random constant in a different translation unit which happens to be "incorrect enough" to make `free` complain. Remove a few lines of code and a "something else" overwrites the variable passed to free. When that "something else" is "zero", `free` works so the program doesn't crash but we can still see valgrind complaining. Remove a bit more, and `valgrind` stops complaining but it's quite possible that the value is getting overwritten with zeroes that randomly happened to sit in memory). Something similar happens when changing some TUs to no-lto - the values involved are different, so there's a risk of false positives. I've gotten as far as being able to set -flto on 3-4 more TUs and then I can still observe the bug with valgrind, but it's hard to minimize further.
