There was a significant disagreement between the reviewers on this paper. All of the reviewers thought that the search phase to repair the original decompilation was an intriguing contribution. The main difference of opinion was on the difficulty of the examples presented in this paper, and of C decompilation in general. To this end, I note that the main competitor that is compared to (retdec) is based on a recent PhD thesis (J. Křoustek: Retargetable Analysis of Machine Code. Ph.D. Thesis, FIT BUT, Brno, CZ, 2015, pp. 190 --- I would suggest to the authors of this submission that it would be kind to cite the thesis in addition to the URL), and the supplemental material shows a pretty convincing case where this method breaks down. I also note that several of the papers that the authors cite show results of 80-98% (so less than perfect) on the subtask of identifying function boundaries in stripped C executable --- so just figuring out **where** to decompile, and not actually producing code. This also seems like clear evidence that for C code (unlike Java bytecode, which is much easier) decompilation is still a difficult open issue.