Infinite loop at -O2 and above at compile-time on clang 12.0.x to trunk version #50999
Comments
|
Not sure whether this is helpful, but this bug exists after commit 49623fa. |
|
Apparently inscombine stuck on visiting trunc/shl/and instructions, IC: Visiting: %sext199 = shl i64 %shl, 24 Not sure how bad is badref occurrence in this case. |
|
The exact commit is 7b0d59d. |
Can you paste the full IR for that function before it enters instcombine? |
Thanks! |
|
I wasn't thinking about backporting a fix to the 13.0 release since the bug was already hidden in trunk using this example...so I did some cleanup and tried to fix another bug before this one: So if we do want to backport a fix, I think we'd need to take all of those to patch cleanly. I'll mark this as fixed for now. If someone wants to fix it in 13.0 too, please re-open. |
Thank you all for your checking and fix! And hey, Sanjay. Just for curious, may I ask do you know why the source code example can not reproduce the issue but IR code can? Or in other words, does it happen oftentimes that some bugs can only be triggered by IR code? I don't know in what situations that source code may lose information after transforming to IR. I super appreciate it if you can give me any hints. Thanks for your time! Best wishes, |
Hi Haoxin - Thank you for finding and reporting bugs! For this example, it takes a rare sequence of unoptimized IR instructions to trigger the bug in instcombine. (It is possible that the regression test that I created for this could be reduced a bit more, but not too much.) And so that IR sequence would usually be optimized away by other passes or instcombine itself. That's why the bug has been hiding silently in LLVM for a very long time (maybe 10 years!). I did not check exactly how https://reviews.llvm.org/rG7b0d59da9af4bf4eb made the bug invisible, but we know from Dawid's comment 2 that the bug must be in instcombine, so a patch in another pass could not have fixed or caused the root problem. So I do not have a good answer to your question about frequency of bugs like this, but there are definitely many cases where a bug in some particular LLVM pass is invisible from C source (Clang) because other optimization passes prevent the problem pattern from being encountered. Some other researchers/bots are fuzzing specific IR passes or sets of passes, and it yields bugs. The disadvantage of that approach is that the importance may not be as high if people think we can't possibly see the bug from Clang. |
|
Hey Sanjay. Thanks for your time and insightful comments here! I think I got the answer from your detailed explanation. I am happy to find important (potentially) bugs in compilers to make them more reliable and thank you so much again for spending time to fix them! Best, |
Extended Description
Hi all.
The following test program makes clang 12.0.x to trunk version hang on -O2 and above.
$cat small.c
#include <stdint.h>
int a,b,c;
void d(int e) {
int8_t *f;
int16_t g;
int32_t i = &a;
uint16_t *j;
int8_t *k = &c;
int16_t l = 246;
uint64_t m;
int8_t **n = &k;
int64_t o;
int16_t *p;
for (; p;) {
int64_t *q = o;
for (*q = 5; *q; *q += 1)
if (*k = b)
for (*j = 3; *j; j++) {
int8_t r;
o = r;
}
for (; p <= 2; p++)
s:
l = 1;
}
g = m = e;
uint64_t v;
int32_t **u = &i;
uint64_t t = &v;
f = *u;
*f = c = l;
v = (g ?: (**u = m << **n)) == *f;
for (; i <= 8; *f = t)
;
goto s;
}
$clang -w -O2 -m32 small.c
//endless compiling, same as -O3 and -Os
$time clang -c -w -O1 -m32 small.c
real 0m0.059s
user 0m0.028s
sys 0m0.031s
The clang version I used:
clang version 14.0.0 (https://github.com/llvm/llvm-project 022538f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/haoxin/haoxin-data/compilers/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@MX32
Selected multilib: .;@m64
Reproduced in Godbolt: https://godbolt.org/z/ndxn1cT91
Thanks,
Haoxin
The text was updated successfully, but these errors were encountered: