<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/60652>60652</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
[clang++] Functions with trivial infinite loop are wrongly optimized
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
pbo-linaro
</td>
</tr>
</table>
<pre>
Given this C++ program:
```
#include <cstdio>
int main() {for(;;) {}}
```
compiled using: `clang++-15 -01 file.cpp && a.out`
One might expect to get a program never terminating.
That's the case in O0, but *not* in O1, where it returns a non-zero error code.
---
Now, consider this other program:
```
#include <cstdio>
int main() {for(;;) {} printf("Unreachable");}
void never_called() {printf("Hello world\n");}
```
In O1, it still returns a non-zero error code, but calls `never_called`!
This kind of behavior is found only in C++ (not when compiling in C).
---
**Note: The following analysis applies to any other function, not only main.**
By looking at LLVM IR (`clang++-15 -S -emit-llvm file.cpp -o -`), in O1:
```
; Function Attrs: mustprogress nofree norecurse noreturn nosync nounwind readnone willreturn uwtable
define dso_local noundef i32 @main() local_unnamed_addr #0 {
unreachable
}
```
The body of the function was deleted for a single `unreachable` llvm instruction.
When generating code, we obtain a main *without* any instruction, not even a `ret`.
Looking at object file generated, we can notice main is a 0 sized symbol, and "shares" same address than `never_called`, thus triggering this funny side effect.
```
$ readelf -s main.o
Symbol table '.symtab' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name
...
4: 0000000000000000 0 FUNC GLOBAL DEFAULT 2 main
5: 0000000000000000 12 FUNC GLOBAL DEFAULT 2 _Z12never_calledv
```
---
I didn't find any [absolute answer](https://stackoverflow.com/questions/2178115/are-compilers-allowed-to-eliminate-infinite-loops) on the fact a C++ compiler could optimize out an infinite loop with constant condition.
In our program, `clang` never removes the loop, but `clang++` does from O1.
This problem appeared in LLVM-13, and `git bisect` finds 6c3129549374c0e81e28fd0a21e96f8087b63a78.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy8Vl1v47oR_TX0y0CGRFmS_eAHO7m-XSBNgG52C_QloMSRxC5FuiRlr_fXF0P5K9ukj9cQEkkkD4dzzpyR8F51BnHNii0rHmdiDL11631tE62McHZWW3la_6kOaCD0ysMD41vGt7B3tnNiYPmGpY8s3bAyPV_TI8-VafQoEVj-0PgglWX5H9OgMgEGoQzjS8ZXwKptax095Fu6pleseqTrI_DGDnulUcLolelYvgFWpo0WppuCS7ICkjSDVmmcN_s9MF4yXoKY2zHcQox_XwzCoLo-AP7cYxMgWOgwgLicEAwe0EFANygjgjLdfFr52ovAeOUh9AiN8AjKwEvK-APUYwDGN8YGxjfxdUavjz06BBXAYRid8SDAWJP8QmcBnbMOGitxfh9ekiT3j8_2SECNNV5JiooosaFH95cQAnunTGjjNP7NOBRNL2qNjHPGVzT1wtjBKjll7q0RWqO8Qd9j_A21tnC0TktWPJj_xfntFF8uqVQBfFBa__9UXrigEDyJ5F1EZcp4duFSefihjATbQo29OCjrQHlo7UgvjT4RjRfxM740NhCfBiYxKtOdJ6w-4Y_T9WwDkl5fe4TWam2PtFAYoU9eeRD7vVboSYPCnM7EtqNpgrKGDkO7xmCIrfmEOeFvT6Ct_RHhAjw9ff87fPkHBfpBaXyFBAcVEq0Pw61IEgtJzMkqJjhm-jMx5VvYncOCTQjO06GG0YeoQvQejG0dIhjrsBmdn-6IKjDWn0wDxo7mSBl3KKSxBuGotD7PGY8h6iruJrFVBkF6-6ZtI3RcKrEFlXNgi_ROuXH8bTRGDCjfhJQOGM_TKN-IBeOdaqezfCK1izAQyAJJF1TnFzLgKDxI1BhQQmsdCCAv0kgqu9-jTCGmWRkf3BjXngXyT1JPhwZddJWrYI8Itg5CGRCRZnKSowo9eRffRGHcgV1UgeTQgnZ3SB73ToVPN2XY-t_kcsT6ZXMqzrhtI4idoBqcNiZFQgpe_UIJ_jTUVtNMYSQwzn0vHHrGOXgxIFCyifjQC_NhqT1A6EcPwamuQ0fhRPdqR2NOQHYG2LbYhPkn_rWISkHdQuIn_dtp6GuMDKJigPFq7k9DEDXjFRklZdJDBWiCU-ivkgaA55HsEgDgu9AjwvX3Vf1CeD3t46stiRTgu_LT4LP8Cc9iwCsMwHw-v3taEGj62y-OpLD79vxAd38-vWw3T_D4x27z7ekV-GS_N4ziM4yMf4YBABze_pXx-8wf7mXwocKvDvUFpJKG8YrUYWQUGiu2ovZWjwFBGH9Ex4pHxpd9CPuYSr5jfOeDaH7YA7pW2-O8sQPju_-M6EmfnvEdz6pllhWM74TD5Ny9nU8EGSDKJNgEtYrtFRNlWmVUwERbu_dU1NZMpScaassXD77AQGNHLcHugxqINjsGEAYuMOSKe6D6iV0zCBPoRqq7SvxiwI63Dsofbt8TZXru_w4He8Cp2RPktc2_s1eaLy16aJ0d4CWbv_cS5WmTWuNAVo_CoSSjJbdOsvxaW2XaqQC18thQKUc6PJRNnvFVsVjl1aJJcZkhX7YyFTzDVdku02VVl7molu_2nMl1Llf5SsxwnZVVmWZVsShm_brFbFE2C1lgW9d8ucqkrJarkheYtct6uZypNU95nvIsTZe8WBTzXGbtqi7yqqmwStuCLVIchNJz8re5dd1MeT_iukzLgs-0qFH7-F3JucEjxEFq8MXjzK1pTVKPnWeLVCsf_A0lqKDjB-l9XovHa8PxE5vBqYMS-jeihUM4Oms6fbpKQs5Gp9fvJdup0I_1Wau09flfsneWDJLxXQyY5BsP9N8AAAD__1weZ10">