Test-Case Reduction for C Compiler Bugs

John Regehr, Yang Chen, Pascal Cuoq, Eric Eide, Chucky Ellison, Xuejun Yang

  • Read: 15 Nov 2025
  • Published: 11 June 2012

ACM SIGPLAN Notices, Volume 47, Issue 6, Pages 335 - 346

https://dl.acm.org/doi/10.1145/2345156.2254104


Q&A (link)

What are the motivations for this work?

  • See Abstract, Introduction.
  • The motivation is to perform automatic reduction on C compiler bug reports.
  • The existing approach to automated test-case reduction, delta debugging, is not ideal for reducing C programs because it typically yields test cases that are too large or even invalid.
  • The authors encountered 2 major problems while using the SOTA reducers:
    1. The tools get stuck at local minima that are too large.
    2. The test cases generated often contain undefined behaviors (e.g. uninitialized local variable in C code).

What is the proposed solution?

  • See Abstract, Seciton 4, 5, 6.
  • Use a novel framework in which a generic fixpoint computation invokes modular transformations that perform reduction operations.
  • Introducted a generalized delta debugger, which combines a search algorithm, a transformation operator, a validity-checking function, and a fitness function (check if the program is human-friendly).
  • For test-case validity (whether the C code contains any UB), the authors don’t have a general solution. Their approach is to use either CSmith which already guarantees validity of generated programs or semantics-checking C interpreter like KCC and Frama-C.
  • Three reducers were implemented, 2 of which are based on CSmith:
    1. Altering the randomization of CSmith to generate programs that produce the same output.
    2. Fast-Reducer, uses AST of CSmith. Ideas like dead-code elimination, path divergence exploition, effect inline (try replacing all func calls with inline) are used to help reduction.
    3. Modular Reducer. Named C-Reducer, it invokes a collection of pluggable transformations until a global fixpoint is reached.

What is the work’s evaluation of the proposed solution?

  • See Section 7.

What is your analysis of the identified problem, idea and evaluation?

  • The work is limited to handling UB for C code. Generalizing the technique to other programming languages might be a useful follow-up.

What are the contributions?

  • See Introduction.
  • C-Reducer, a test-case modular reducer for compiler test reduction that output more than 25 times smaller than that produced by a line-based delta debugger, on average.

What are future directions for this research?

  • See Section 6, 9.
  • According to the authors, their furture work is gonna be related to automatic production of additional elements of a compiler bug report.
  • In my point of view, the algorithm of C-Reduction is clearly not optimal in terms of efficiency. It is basically:
    1. An outer while loop checking if fixpoint is reached
    2. An inner for loop iterating through all the pre-defined transformations.
  • I believe that the algorithm can be better designed to eliminate certain transformations during the process of search, which should improve the performance.

What questions are you left with?

NONE

What is your take-away message from this paper?

NONE

Written on