How we use binary search to find compiler bugs
bernsteinbear.com
How we use binary search to find compiler bugs
1–10 of 17 posts
Re: How we use binary search to find compiler bugs
#2Is this a fuzzing?
Re: How we use binary search to find compiler bugs
#3Is this a fuzzing?
Oh, good point, I should probably mention fuzzing in similar work. Since we're not modifying the input data or input program, I might not count it as fuzzing. ¯\_(ツ)_/¯
Re: How we use binary search to find compiler bugs
#4cvise is another tool for test case reduction, similar to creduce mentioned in the article:
Re: How we use binary search to find compiler bugs
#5cvise is another tool for test case reduction, similar to creduce mentioned in the article: https://github.com/marxin/cvise
Cool! Thanks for sharing.
Re: How we use binary search to find compiler bugs
#6https://dlang.org/blog/2020/04/13/dustmite-the-general-purpo...
Dustmite (say thank you to cybershadow) is the D community's beloved test case reduction tool
Re: How we use binary search to find compiler bugs
#7An even more fine-grained binary search technique for isolating compiler bugs is optimization fuel:
http://blog.ezyang.com/2011/06/debugging-compilers-with-opti...
Re: How we use binary search to find compiler bugs
#8I have wondered how to extend this to combinations of elements.
What if the bad outcome only happens when two or more elements are enabled?
Is there a generalization of binary search for powersets?
Can this be done efficiently?
Re: How we use binary search to find compiler bugs
#9JReduce (https://dl.acm.org/doi/abs/10.1145/3453483.3454091) uses similar technique but with semantics for debugging such problems with Java decompiler and bytecodes.
The problem is we don't know if compiling with these functions follows the monotonicity of binary searching: what if a problem is caused by a special combination of two functions? You have to arrange these two functions in the right order in order to find the problem.
Re: How we use binary search to find compiler bugs
#10Binary search is also helpful in code that doesn’t reliably produce useful stack traces (side eyes Promise.then). Comment out half of the potentially implicated code. If you get the same error, you very likely haven’t found a stack frame. If you get a different error or no error at all, keep halving until you either isolate the thing or know where to look.