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

[Tony Kelman <tony.kelman@juliacomputing.com>]

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

The first time I ran with --sanity-checks it made the problem much
more obvious. Maybe the first reduction was assumed to pass without it
or something?

> 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?

Ah. I should have mentioned that I needed to use delta's -in_place
option to get delta to work. Does creduce have an equivalent or do I
have to manually do the backups and restoration on any build or test
failure?

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

With some iterations of delta, manually removing unused functions, and
speculatively removing different arguments or calls I was able to get
a copy of SLPVectorizer.cpp down to 102 lines (though still
#include'ing 5 of the llvm headers) that gives the known-good result
with the good switch and segfaults with the bad, but it might also be
so small or full of UB that it isn't meaningful to determine what's
getting miscompiled. I'm not sure at this point.

Maybe if creduce had something like an in-place option to automate
this type of situation where there's an external build system that has
an absolute path to the file hard-coded, I would have gotten more
mileage out of it here.