[clang++] extremely slow when trying to use undeclared identifiers · Issue #93308 · llvm/llvm-project (original) (raw)
Given a program in the following format:
void test() { int a11; [...] // a bunch more variable declarations not used afterwards
if( a97 == a95 ) {} // comparing non-existant variables }
clang++
can take up to 5 minutes compiling this or even crashes, while clang
can compile it just fine.
Full code example
void test() { int a11; int a12; int a13; int a14; int* a15; int a16; int a17; int a18; int a22; int a24; int a25; int a35; int a36; int a37; int a38; int a39; int a40; int a42; int a91; int a92; int a98; int a99;
if( a97 == a95, a96 == a96, a97 == a96, a95 == a93, a96 == a105 ) {} }
The example above compiles for more than 5 minutes for me. Variants can be created by adding/removing more variable declarations, but the code is somehow very sensitive to working correctly (compiling in less than 0.1 second) again.
I'm not able to pinpoint what actually causes this to create an even more minimized example, but as it seems to be influenced by the variable names, I believe that the generator for "did you mean variable x instead?" is somehow at fault here.
Here's some other things I tried/observed:
- Running
time
on it shows thatuser/sys
is really low, onlyreal
increases over time - meaningclang++
doesn't actually take so long for compiling, but waits for the most time. - Saving the code above as
test.c
and runningclang++ test.c
takes very long, while usingclang test.c
takes less than a second. - Changing that single pointer to a normal
int
"fixes" it. - Using standard assignments instead of
if
checks fixes it, but assigning it within theif
clause also causes the issue. - Changing the variable names too much results in taking less time, down to 0.1 seconds.
- The time it takes to finish "compiling" (display errors) varies with the number of declarations and comparisons, but removing the "wrong" ones can fix it again.
- When encountering it in my normal project, I first got some actual crashes from Clang - I cannot re-create those though, and they only occured after what felt like a timeout, when touching the file it read from (saving again)... I can't reproduce it though, so feel free to ignore this one and only focus on the long compile time.
After trying around with this for more than 3 hours without being able to further "destill" down the issue, let's hope someone else around here has a theory on why this occurs.
For experiments, feel free to test with this Godbolt:
Godbolt
- gcc: ~140 ms
- clang (any version): at least 25000 ms