From owner-freebsd-current@FreeBSD.ORG Sat Nov 30 23:25:47 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 8E80472B for ; Sat, 30 Nov 2013 23:25:47 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37D8110D1 for ; Sat, 30 Nov 2013 23:25:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::85ac:c2ca:692d:9ae] (unknown [IPv6:2001:7b8:3a7:0:85ac:c2ca:692d:9ae]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 83C285C43; Sun, 1 Dec 2013 00:25:39 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Dimitry Andric In-Reply-To: <20131130135616.GA59496@kib.kiev.ua> Date: Sun, 1 Dec 2013 00:25:21 +0100 Message-Id: References: <20131130135616.GA59496@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1822) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 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: Sat, 30 Nov 2013 23:25:47 -0000 --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 30 Nov 2013, at 14:56, Konstantin Belousov 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 --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKac+4ACgkQsF6jCi4glqPwcQCcC/uDUmEJZQquITSUxwSHu6U2 lNQAn2gArUEn9uDnIyYrSeBfpkIVOJt0 =6u3V -----END PGP SIGNATURE----- --Apple-Mail=_58A31E6E-76CD-4ADB-81F8-9BDF34F6B0A8--