SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds)
Stefan Esser
se at freebsd.org
Thu Dec 19 09:16:29 UTC 2013
Am 30.11.2013 14:56, schrieb Konstantin Belousov:
> 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.
>
> 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.
>
> 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.
Hi Konstantin,
you may put back -fno-strict-overflow after I found and fixed the
problem uncovered by enabling it in -CURRENT (SVN rev. 259609).
The problem was an overflow in the conversion of timeout values to
sbintine, which lead to negative values being detected with
-fno-strict-overflow, while the compiler performed the signedness
test before the multiplication, without that option.
I found that timeout values of more than 1000 years were requested
by some programs, which are now capped at 68 years (the maximum that
can be represented by sbintime, 2^31 seconds).
So, -fno-strict-overflow has already proved itself to be useful
in uncovering a bug that would have been hard to find, otherwise.
Regards, STefan
More information about the freebsd-current
mailing list