From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 13:23:03 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 408C9FC2 for ; Sun, 1 Dec 2013 13:23:03 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64F7814C7 for ; Sun, 1 Dec 2013 13:23:02 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MJjvw-1VoDRo1sXs-001CNL for ; Sun, 01 Dec 2013 14:23:00 +0100 Message-ID: <529B3813.8080906@gmx.com> Date: Sun, 01 Dec 2013 14:22:27 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Konstantin Belousov , Adrian Chadd Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds References: <20131130135616.GA59496@kib.kiev.ua> <20131201075914.GE59496@kib.kiev.ua> In-Reply-To: <20131201075914.GE59496@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aXbOGQPAb9CvlCyckKRt+wXnujkz1DsHBFK1ArjPRiyCeuquloz LVd1eWtBPj1zyle5+9qfBfKSfpe0ToQAH0XXyb3e46yi/BH7Txc9vfBwiVq1cMdfocl6gku 3z7mmE9G7mt4Q8vDcRSEoa2JncTFDQOINZLD6uLsq4W8xLXcwF88eY4ehvbtGxzTxht1hih sBk8NavJPOZUC+b89iH5g== Cc: Dimitry Andric , "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: Sun, 01 Dec 2013 13:23:03 -0000 Konstantin Belousov wrote, On 11/30/2013 13:56: > The compiler authors take the undefined part there as a blanket to perform > optimizations which are assuming that signed overflow cannot happen. Personally, when I first heard about such assumptions, it was inspiring to write code in a way that automatically gives the compiler certain ``overflow cannot happer'' (for example, because the input values given are always small) hints, such as turning some uses of ``unsigned int'' (where a negative value logically doesn't make sense, such as in a size/length value) into ``signed int''. However, I quickly found that this way of thinking leads to counter-production: coding becomes slower, the resulting code becomes less readable, while the performance gain remains questionable. It would be much better if hints could be given to the compiler using assert() (which would have effect even in non-debug mode). How do others feel? Konstantin Belousov wrote, On 12/01/2013 08:59: > It is written in C, but no useful program can be written in the pure > standard C. We must rely on the assumptions about underlying architecture, > and compiler must provide sane access to the features of the underlying > architecture to be useful. But what behavior do you want for signed arithmetic? Modular, saturating, or some other? And how do you signal that? Or maybe you just want to check for (signed/unsigned) integer overflow (which can't be done "cleanly and efficiently" in C), in which case someone should write a check_add_overflow() function...