From owner-freebsd-current@FreeBSD.ORG Thu Dec 19 09:16:29 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 96087B22 for ; Thu, 19 Dec 2013 09:16:29 +0000 (UTC) Received: from nm16-vm1.bullet.mail.ird.yahoo.com (nm16-vm1.bullet.mail.ird.yahoo.com [77.238.189.88]) by mx1.freebsd.org (Postfix) with SMTP id E5AFB1D13 for ; Thu, 19 Dec 2013 09:16:28 +0000 (UTC) Received: from [77.238.189.233] by nm16.bullet.mail.ird.yahoo.com with NNFMP; 19 Dec 2013 09:16:22 -0000 Received: from [46.228.39.83] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 19 Dec 2013 09:16:22 -0000 Received: from [127.0.0.1] by smtp120.mail.ir2.yahoo.com with NNFMP; 19 Dec 2013 09:16:22 -0000 X-Yahoo-Newman-Id: 502981.98668.bm@smtp120.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: C9AWGUYVM1kodYCW_JBwAX1kBCLOmF2ss7_dDerlws3QGaL XX_0ehgA9AjAnWFe8A1NHRDzL2dOQ5vB1C7J3Tku3PNACSrNyq.rSuugLEPv w1wnWknyG5iqEsQ8xld24wYZm8_wqmCKMQlZnG8yCK8LV1g0OnNW0WwX4.P6 Cg.hRAywcnKitibBw2mFyUYQG4E021y0q8Qxm_fBgRLTP5ThO2wD0_gTVugS 1hV1gwZe1SVmNTfKbpQL8y1Ymi_0wVBWfLPBW6OJpyEIgXN7NrUUVtRYdbRm Nmax.poS5dGagXXQvqPyAFf2tcWsYrpUbTBYYmffvVnsufTQZ3NXSKZGrX6s o4tiKeEpMfIDUpTNAxOUnRGifMaGjZjfVsDqCF2kzB0ECoddMjc7wXu5z6rZ ccx_3Iyc4sZmORkxa05a0uPS.qso1ZzwiDymJW_bp2mcFn6.jiyQIO7t4Rw_ yfODkqml_zJwer8KZOZX657QCaZdt1aGyYu5d5gL7UPX3q2V8U7JpgPxmhkS ISJiAtylaM9Y0Fv1zOcR1Zzmo88Zupw-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.112.54 with plain [188.125.69.59]) by smtp120.mail.ir2.yahoo.com with SMTP; 19 Dec 2013 09:16:22 +0000 UTC Message-ID: <52B2B960.7040607@freebsd.org> Date: Thu, 19 Dec 2013 10:16:16 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Konstantin Belousov , current@freebsd.org Subject: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds) References: <20131130135616.GA59496@kib.kiev.ua> In-Reply-To: <20131130135616.GA59496@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 09:16:29 -0000 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