| Issue |
171636
|
| Summary |
Inconsistent ubsan behavior (infinite loops)
|
| Labels |
compiler-rt:ubsan,
undefined behaviour
|
| Assignees |
|
| Reporter |
mikekben
|
Minimized example Program:
```
volatile int a;
int main() {
char b = 0;
short c[5][5];
for (; b < 5; b++) {
a = 0;
for (; a < 5; a++)
c[b][a] = 1;
}
for (; b;)
;
return 0;
}
```
Under the undefined behavior sanitizer, this program exhibits the surprising result of an undefined out of bounds array access.
```
$ clang-trunk -g -O3 -fsanitize=undefined -fno-sanitize-recover=all abc.c
$ ./a.out
abc.c:8:7: runtime error: index 5 out of bounds for type 'short[5]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior abc.c:8:7
```
It appears that clang interprets the trivial infinite loop at the end as undefined behavior, marks it as unreachable, and then CFGSimplify reduces branches so that the inner loop continues executing past a=5.
Under the assumption that infinte loops constitute undefined behavior (see https://github.com/llvm/llvm-project/issues/56819), the behavior of clang is correct. But, when using fsanitize=undefined, should the sanitizer identify loops that the analysis passes have proven to be non-terminating? **If we assume that infinite loops are undefined behavior, then in this case ubsan is incomplete. If we assume that infinte loops are not UB, then clang's optimizations are not correct.** The first of these seems the more likely explanation, so should ubsan report loops which the compiler has found to be infinite? The status quo is that ubsan reports an out of bounds access even though the source code doesn't contain such an access.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
