llist code relies on undefined behaviour, upsets llvm/clang

[Peter Zijlstra]

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?