Note that the proposed text breaks lots of important valuable use cases like xor lists.
Conversation
Clang and GCC already consider that broken per the standard. It was also very explicitly made to be broken in C++ already, which tends to trickle back to the C standard since it's a lot of the same people making the decisions and they reference each other as justifications.
2
open-std.org/jtc1/sc22/wg14 appears to be a more recent draft of what I linked earlier by the way. We'll see how they end up deciding to clarify it for C2X. My feeling is they will bend over backwards to permit / attempt to formalize existing real world compiler interpretations.
1
I'm not arguing that what Clang and GCC currently do is correct, but I am saying that they currently do it, and that it's likely to become officially correct *because* they want to it. Type-based alias analysis is similar. They tried to allow it, and will readjust it as needed.
1
1
Type-based alias analysis is possible to specify consistently, and has clear reasons you want to do it. This provenance stuff has absolutely no motivation, because deriving pointers from ints/reprs is rare, and when you do it, you actually mean it.
2
1
All the special cases they talk about in the draft are ill-defined and impossible to specify formally in a consistent manner. The people trying to do this have no idea what they're doing and it shows.
1
That's true for a lot of the standard process including how they defined TBAA. Their decision that all side effect free loops can be assumed to terminate (unless the condition is a constant) is pretty messed up and Clang uses that to justify the issue I mentioned earlier.
1
1
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.
1
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.
The C11 infinite loop termination thing resulted in fixing this issue becoming an extremely low priority. It's a major problem for other languages built on LLVM with safe semantics too. It also applies to an infinite loop via recursion including via a guaranteed tail call.
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
Show replies