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

Adrian Chadd adrian at freebsd.org
Sun Dec 1 00:33:19 UTC 2013


On 30 November 2013 15:25, Dimitry Andric <dim at freebsd.org> wrote:
> 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. :-)

Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?

If there was a way to lint this stuff then yes, please lint it.

Otherwise we don't have the tools to know whether we're doing sane
things or not.

(Same with things like strict aliasing..)


-adrian


More information about the freebsd-current mailing list