JonasToth added a comment. It does still regress! In a sense this is a WIP that i did not clarify.(which i do now)
While debugging the issue it seemed that parsing the AST did result in the stack overflow and not my check specific code. Looping over all case Labels seems to be done in a recursive manner, which results in a massive stack (about 600 Frames or more while debugging). I am trying to better isolate the issue to be able to specify the problem more precise. The odd thing to me was, that only the RelWithDebInfo build showed this behaviour. Building clang with MinSizeRel + Sanitizer did not show a stack overflow. I assume that the Debug Info increase the stack frame size. The release builds should overflow as well but with more case labels. My goals for investigation: - Figure out exactly which part of the matcher is the problem - Rewrite the matchers and try to figure out a way to not use recursive functions to figure out the properties of the switch statement. Could information like `CaseCount` and `hasDefault` be interesting to have as member functions in the frontend? I think that can be added into Sema (i never touched anything there, so noo experience) - Figure out when the Release Build will stackoverflow. Would it be acceptable to allow a Stackoverflow when there are thousands of case labels? If i understand correctly (and AST-dump suggests it as well) each case label is another layer in the tree. If that is true other parts of clang might suffer from a similar issue. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D40737 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
