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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"