On Sun, Jul 9, 2017 at 12:12 AM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: >> Most of the case is "return" or "jmp" inside a ptrlist >> loop. > Yes, I saw that when running your previous version on the testsuite. One interesting idea is just use sparse context balance check to check the sparse code itself. It should work wonderfully with the ptrlist ref count. Because the loop will always terminate inside a function. We will never have the false alarm like the kernel has, which cause by some lock_acquire helper function. I have been doing it by hand so far. If I know I need to go through that many attempt to fix it, I might use the context check earlier. > Yes, the recursive kill_instruction I talked about. > I have already been bitten by it several time (not especially > about ptrlist thing, but other stuff too), it's quite dangerous. I dig a bit deeper. In this case, the outer loop is holding position 12, and the delete is happen on 11, one entry before. There for delete entry 11 will cause the list->list[] to slide forward impact position 12. The situation I am worry about does happen in real life. > 1) it would be a big code change > 2) change in simplification have non-onbious impact on the diagnostics > that are emitted (simplification -> dead code elimination (1st impact) > -> branch simplification/mergin (2nd impact)). > But theer exist other simple fixes. Suggestions of other simple fixes? This bug is holding the release. I would love to get some simple temporary way to work around the bug. It does not need to be perfect. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
