From owner-freebsd-current@FreeBSD.ORG Thu Dec 19 18:09:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 902B6EB9; Thu, 19 Dec 2013 18:09:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1BA418B4; Thu, 19 Dec 2013 18:09:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rBJI9VY1054010; Thu, 19 Dec 2013 20:09:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rBJI9VY1054010 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rBJI9UV7054009; Thu, 19 Dec 2013 20:09:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Dec 2013 20:09:30 +0200 From: Konstantin Belousov To: Stefan Esser Subject: Re: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds) Message-ID: <20131219180930.GO59496@kib.kiev.ua> References: <20131130135616.GA59496@kib.kiev.ua> <52B2B960.7040607@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RFCOFvroxiuDGXoi" Content-Disposition: inline In-Reply-To: <52B2B960.7040607@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 18:09:36 -0000 --RFCOFvroxiuDGXoi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 19, 2013 at 10:16:16AM +0100, Stefan Esser wrote: > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > What makes the things much worse is that the behaviour is highly > > depended on the optimization level of the exact version of > > compiler. > >=20 > > What other projects did in this regard. They turned the same knob=20 > > 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. >=20 > Hi Konstantin, >=20 > you may put back -fno-strict-overflow after I found and fixed the > problem uncovered by enabling it in -CURRENT (SVN rev. 259609). >=20 > 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. >=20 > 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). >=20 > So, -fno-strict-overflow has already proved itself to be useful > in uncovering a bug that would have been hard to find, otherwise. Feel free to restore the commit, I have no plans to do this. --RFCOFvroxiuDGXoi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSszZaAAoJEJDCuSvBvK1B7eMP/j8s0eVEhYXPaBYxhzY5iYoq ARrXN3rdscDFvBBo3Ftg6L8qJgD1xV4rXv7rCLMvGoo47sv+zXrBMmIZ1RLWf+DB n8DIuHC9B5xrmM7RzcMMPrVG4l8nPrrvGSGJtwVfsZVsO6bwjLtHMq4V9lpnDeYG Exp/JKRbpV/Ct2fT+3m4vIEjXGgUnIMIlKFbiKyLqWmuWVFLKLLzISV9NPCeBcMI CMrq8PZRUtGnIXtQF1zCwz74zGgkJBo151cPftv1/xXAfJkYXN9C76o+UOYFwd/I V0XGx3TiHTml2nNQmykWXEzwV1+id3/mRZVuoxml1cUylBN9OXMR7gz2smYpZCfD 4TJSF9/tFnPwXcbwx2Jq1BAbx6DFRXOrj18R1LBNKeHTAxiN4oukcFMBB8WuVINB gOcuSMMCMiU9ZqbyU+JLp4IgcrfUYKbCfQ6oaRK/lYEC4CwCh/8ABkCIX/Xmq7Tr 3GiEAfjXtiaUGBG7r8XKjrofdY4+TjzP53cD9ampR8QrYTcTjI7kX6cwPP1CMPIE 6Tmo671WCjTS1rhzoe2eTA2nFD9XSgnX0a13iVOjo77tuo3WQeyD28ruCNXMsYYP OAwmTEH/CyqxiRoJfR/cO6YHYa+e5BXCRmXLaHHjCHqi0puiEjTkdPF5aLtAup9B arGS8FCQ2AGHWbhpK3zN =irJA -----END PGP SIGNATURE----- --RFCOFvroxiuDGXoi--