Messages in this thread | | | Date | Mon, 16 Jan 2017 13:53:56 +0100 | From | Peter Zijlstra <> | Subject | Re: llist code relies on undefined behaviour, upsets llvm/clang |
| |
On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: > Hi Peter, > > > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not > > something I've ever ran into. > > > > Also, I would argue that this is broken in llvm, the kernel very much > > relies on things like this all over the place. Sure, we're way outside > > of what the C language spec says, but who bloody cares ;-) > > True, but is there anything preventing gcc from implementing this > optimisation in the future? If we are relying on undefined behaviour we > should have a -fno-strict-* option to cover it. > > > If llvm wants to compile the kernel, it needs to learn the C dialect > > the kernel uses. > > LLVM has done that before (eg adding -fno-strict-overflow). I don't > think that option covers this case however.
Our comment there states:
# disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
So this option should apply to pointer arithmetic, therefore I would expect -fno-strict-overflow to actually apply here, or am I missing something?
| |