[LLVMbugs] [Bug 13731] New: RecursiveASTVisitor crashes on very long if/else chains (1000~2000 cases)

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13731

             Bug #: 13731
           Summary: RecursiveASTVisitor crashes on very long if/else
                    chains (1000~2000 cases)
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jordan_rose at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9136
  --> http://llvm.org/bugs/attachment.cgi?id=9136
2000 if statements in a chain

My friend sent me a block of code the analyzer crashed on; we eventually
reduced it down to a single chain of maybe 1000 if/else cases -- a
presumably-autogenerated poor implementation of option parsing. On statement
trees this deep, RecursiveASTVisitor crashes; both 'clang --analyze' and 'clang
-Wimplicit-fallthrough' will crash on the attached test case...in release
builds only.

Curious, I tested more carefully. Under -O0 and -O1 RecursiveASTVisitor does
manage to visit all the statements (presumably). Under -O2 and -O3 the crash
occurs -- it's a stack overflow.

I know for BinaryOperators we switch to an iterative data path if requested. I
realize that this is pretty unlikely code, but we shouldn't /crash/ trying to
traverse it. I'm not sure why it is only optimized builds that crash, and that
worries me.

This is a recent build of trunk clang compiled using a recent Apple clang. I
did not try compiling with GCC, bootstrapping, or digging up an older Apple
clang.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.