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

Re: [creduce-dev] reduction using dynamic information

On 2016-07-13 16:56, John Regehr wrote:

- The scheme we've been talking about so far is about cutting out
computations that satisfy the inputs necessary for seeing a compiler
bug.  But compiler bugs also have an output side, which is necessary
to observe that the bug happened.  In Csmith there's the checksum code
for example.  By printing the values of variables in buggy and
not-buggy executions, C-Reduce can search for the first program point
where some variable takes on the wrong value.  In this case the
generated code becomes:

{ int tmp = expr1;
  static int _creduce_checked = 0;
  if (!_creduce_checked) {
     if (tmp != reference_value) abort();
     _creduce_checked = 1;
  }
  x = foo(tmp, expr2);}

Thus, we can also shorten the output side of compiler bugs.  It
remains to be seen if C-Reduce will tend to just remove this code,
instead of removing the code that follows it.  There may be a way to
convince it to do the right thing, such as requiring that an
interesting program contains an abort() call.
Yes, I think we can implement this. My concern is that searching only the first program point where a wrong value is taken might not always lead to optimal output. For example, we may get a smaller reduced program by keeping the second failing point. In other words, we could lose other search paths if we only focus on the first failing point.
On the other hand, this early-abort strategy could serve as a trade-off between reduction speed and reduction rate. More importantly, we will never know if we don't give it a shot :) 

- Yang