Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds

On 30 Nov 2013, at 14:56, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
> I propose to unconditionally add the switch  -fno-strict-overflow to the
> kernel compilation.  See the patch at the end of message for exact change
> proposed.
> 
> What does it do. It disallows useless and counter-intuitive behaviour of
> the compiler(s) for the signed overflow. Basically, the issue is that
> the C standard left signed overflow as undefined to allow for different
> hardware implementation of signess to be used for signed arithmetic.
> De-facto, all architectures where FreeBSD works or have a chance to be
> ported, use two-complement signed integer representation, and developers
> intuition is right about it.

I think this is quite a misrepresentation.  Any C compiler is free to do
whatever it wants whenever it encounters undefined behavior.  Some
behavior is undefined in the C standards, so compilers can do a better
job at optimization.

If the optimized code fails to do what the programmer thinks it does, it
is almost always the programmer's fault, excluding actual compiler bugs
(which are unavoidable, as all software has bugs).

Basically, if you rely on undefined behavior, you are inventing your own
de facto language, which is *not* C.  That is fine with me, but let's
not pretend the FreeBSD kernel is written in C then. :-)


> The compiler authors take the undefined part there as a blanket to perform
> optimizations which are assuming that signed overflow cannot happen.  The
> problem with that approach is that typical checks for bounds are exactly
> the place where the overflow can happen.  Instead of making some artificial
> example, I would just point to my own r258088 and r258397.
> 
> What makes the things much worse is that the behaviour is highly depended
> on the optimization level of the exact version of compiler.

Of course it is: the behavior is undefined, so the compiler is free to
randomly do anything.  Garbage in, garbage out.


> What other projects did in this regard. They turned the same knob
> unconditionally. I can point at least to Linux kernel and Postgresql.
> Python uses -fwrapv, which is equivalent to the -fno-strict-overflow
> on the two-complement machines.  Linux used -fwrapv before switched
> to -fno-strict-overflow.

If this makes the life of kernel developers easier, so be it.  But I
still feel this is a bit of a cop-out, and we could also just fix the
bugs instead.

-Dimitry