An int. test should not allow this scenario: if the mutated file fails to compile, ninja will fail cause the int. test to exit with non-zero and creduce to reject this mutation.
I may be missing a step, but creduce usually creates a mutation of the source file in a temporary directory, how this file gets into the build?
The test needs to make the LLVM build use the current mutated SLPVectorizer.cpp from the /tmp/creduce... temporary directory the int. test runs in. This is hard to parallel as all sources, objects, executables paths are all hardcoded in the ninja build.
Even with one CPU, you need to keep the original SLPVectorizer.cpp, copy it over with the current mutated, run the test and if it fails restore the copy.
Anyhow, I doubt this process will reduce at all since the reduced SLPVectorizer.cpp needs to provide enough functionality to build LLVM, so creduce can't really reduce it. I'd go another way: add another C++ file, SLPVectorizer2.cpp, intiailly empty to the project. Compile SLPVectorizer.cpp always with the "good" switch andSLPVectorizer2.cpp without the switch, it being the "bad" file. Initially all the code is compiled with the good switch and the build is OK.
Start moving functions from SLPVectorizer.cpp to SLPVectorizer2.cpp until the problem happens.
The last function moved is the miscompiled one. Then compare the function assembler between the good and the bad versions and you'll have the miscompile.
... and now I realize what was happening. It was cutting the file down
from about 4000 lines to ~3500 or so, and constantly failing to
compile from then on because it was missing all the includes