[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [creduce-dev] A reduction attempt that creduce handled poorly, where delta was able to make progress

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 and SLPVectorizer2.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.


2017-01-27 8:53 GMT+02:00 Tony Kelman <tony.kelman@juliacomputing.com>:
... 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