Didn't know about it... btw for the purpose of creating a compiler with well-defined behavior, I would start with clang+llvm and then just refactor the UB out of llvm.
Conversation
This Tweet was deleted by the Tweet author. Learn more
Nah! There are two kinds of UB: UB in the IR that the compiler uses and UB in the language. LLVM has the former. That doesn't imply UB in the latter. It happens to imply that in llvm and gcc because of policy decisions.
1
2
For example: introduce a pass that runs before llvm opt pipeline that removes all TBAA, changes all geps to int math, remove all nsw/nuw flags from int math, replace all undef's with 0, and 0-initialize all alloca's. That gets you very close to no UB.
1
1
not really but it would reduce the amount of UB exploitation. there's a long tail scattered around many passes that you can't find so easily, requires a fine-toothed comb.
1
8
Not sure that’s really true. WebKit’s LLVM-based FTL JIT encountered no such problems to my knowledge. High probability we would have known. We even ran tests with the full -O3 pipeline. Maybe there are bugs, but I wouldn’t conflate that with UB.
2
To name one off the top of my head: You have to do something to sanitize float-to-int casts or else they become undefs if out of range. For a long time “array[x as usize]” with x: f64 could cause UB in safe Rust for this reason.
2
2
5
There's also the perpetually annoying 'a function calling itself in an infinite loop is UB'
3
3
Check out this example using a loop:
gist.github.com/thestinger/7e6
LLVM considers noreturn to be an effect, and yet it doesn't consider a function that *may* not return to have an effect. This is a bug, but an intentional one because they chose to keep an unsafe optimization around.
1
4
They properly preserve functions that are pure but not nounwind, such as a chain of them like foo(); foo(); foo(); being optimized to foo(); but never being completely removed. They are missing an attribute for 'returns' or 'halts' and yet optimize without checking anyways.
1
1
So, even though it's known that this is broken for many years, they have kept the optimization enabled. No one has been motivated to deal with implementing a 'halts' attribute and adding support for detecting / propagating it in the function attribute pass and making it required.
I think if the broken optimization was disabled, someone would become motivated to get the infrastructure implemented to enable it again. There are many known bugs like this. The burden is placed on people who want correctness to fix all optimizations, instead of the other way.
1
1
Really, an optimization that has known to be broken for years should just be disabled at some point. If people care about the optimization, they can fix the known bugs and get it enabled again. It's an issue of priorities and values. That would need to change for it to be sane.
1
4
Show replies
That's just broken, but not too surprising, since it's not uncommon for compilers to have miscompile bugs in tough and unusual corner cases. But the context of this conversation is: do you need a new compiler to fix UB?
1
The fact that llvm has bugs doesn't really change the answer. Even a compiler that was designed to avoid UB could have miscompile bugs. Also, the context of the conversation allows for making changes to llvm - so this seems like the kind of thing that could be fixed.
1
1
Show replies