Here is my usual test case for Clang:
gist.github.com/thestinger/139
Compile this with -O0 and it will infinite loop as it should. Compile it with -O2 and it won't. They've done this since long before standard allowed infinite loops to terminate and it doesn't allow this even now.
Conversation
Removing the conditional return bypasses the issue because it makes the function get marked as noreturn which is treated as an effect. However, there is no concept of a function that may not return, and they assume that all non-noreturn functions will return to let them do it.
2
That's just how they do things. They are determined to do the optimization (removing calls to pure functions) and will do it, even before they have a way to do the optimization correctly. They will get the standard changed to permit things like it as needed too, when they aren't.
2
Non-idiotic solution is obvious: a function with an infinite loop is not pure.
1
Well they should have an always_returns attribute and they cannot simply remove calls to functions based on that not being present. They already handle this correctly in terms of unwinding. For example, pure_may_unwind(); pure_may_unwind(); will be optimized to 1 call, but not 0.
1
I don't think it'd even be that hard to add support for always_returns. There's just no one particularly interested in arguing for a new function attribute and implementing it in order to *constrain* existing optimizations to make them correct, rather than making code faster.
2
One observation from having had many conversations like this with you: your fatalism about things like this often seems exaggerated, and makes it hard to get anything productive out of these exchanges.
1
My perspective on it is based on bugs.llvm.org/show_bug.cgi?i breaking Rust, LLVM falsely justifying it based on C semantics (even though even the C11 semantics don't permit it) and then throwing some scraps at other languages that aren't acceptable to use: reviews.llvm.org/D38336.
1
2
The way the C standard ends up working is they can just take the shortcut of making everything undefined, even changing things to be *retroactively* undefined, and then other languages without that option using the same compilers are just completely screwed.
1
So for example, type-based alias analysis is important for other languages, but in those other languages it actually has to be a sound model / implementation or it can't be used. Similarly, the pointer provenance stuff is important to them, but it actually has to be sound too.
1
So, I find the whole thing frustrating, based on my perspective where these rules are internal to the compiler, and don't actually make the language less safe to use, unless they are broken. Sadly, they are okay with stuff simply being broken or partially fleshed out for perf.
It's so stupid that they expect non-C / non-C++ languages to mark every maybe non-terminating loop or potentially recursive call as having a side effect. It would completely destroy optimization just to work around them not making a sound model and falsely justifying it via C.
2
And then the issue is they are in a position to get the C standard changed to whatever they want, further justifying what they want to do. I actually do want these optimizations, but correct versions of them, that are capable of being used underneath a safe language for speed.
Well I think they're lacking people who meet all of (1) having technical knowledge to fix it, (2) caring about it, and (3) being available and willing to work on it. That doesn't justify their haphazard attitude towards breaking things and breaking the standards, but...
1
...it is the cause analysis that needs to be done if someone wants to fix the situation.