From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 55FA0198005 for ; Mon, 25 Feb 2013 21:57:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 807BBE07E8; Mon, 25 Feb 2013 21:57:56 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A244CE07CA for ; Mon, 25 Feb 2013 21:57:55 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so3652047ieb.25 for ; Mon, 25 Feb 2013 13:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LRI82qjInKXcr8HWv5/4M4VtXsoWs2AiFQOC/6571/A=; b=0YCm0GcdOZoj7XOfnJBHAofhyBCfFg7BWUDe9Z2woV+2vcrtV9pIxHKOdikhJdtoRt pGN3Kp/KGR+y7f2uAPkTcZk3bSEjPWKVNCkQOvGCUkftQ9F/t/zjalicoXCaPMER9g8A ZvdKbCMEbIy8fg0mflYxhb9PqZWNJHGJa20GqrYeJOCABbeAUQZc0mgunPgRaTs7iY5q 2VsfjMbIZJkeL2rjNMl/Q6ZGdim7uWb6PXibiH9nLArTdISKLg0rH3E2bhDV9WMdhO7d 6H01SjvGAO3SiHyNg+UXs+SDqEfe4pxdzO+qVzYY10xrljzPgZ2nCPP4hVXQZmPf8sGx 7xuQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.160.201 with SMTP id xm9mr4147156igb.101.1361829474840; Mon, 25 Feb 2013 13:57:54 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.21.98 with HTTP; Mon, 25 Feb 2013 13:57:54 -0800 (PST) In-Reply-To: <512BD9B4.5050809@flameeyes.eu> References: <20130224230301.20ae2d62@caribou.gateway.2wire.net> <20130225205808.GI1672@wloczykij> <20130225221829.698cc908@gentoo.org> <512BD9B4.5050809@flameeyes.eu> Date: Mon, 25 Feb 2013 16:57:54 -0500 X-Google-Sender-Auth: qKk_mNNBY7krmbtDyDpaoq7Ho6o Message-ID: Subject: Re: [gentoo-dev] GCC 4.7 unmasking From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f02d1e30-0c88-4288-bd03-be825c53ac9a X-Archives-Hash: a0961674d8954a82e6d5eefded9187aa On Mon, Feb 25, 2013 at 4:37 PM, Diego Elio Petten=F2 wrote: > On 25/02/2013 22:32, Rich Freeman wrote: >> That isn't the same as saying that we can just break it in cases where >> it actually is appropriate. Calculating scroll bar movement is >> exactly the sort of thing that this flag was actually designed for - >> you don't care if it is off by 1/100th of a pixel. > > Rich.. please... don't try to talk about things you don't understand. > A sword that cuts two ways - judging understanding by an email is a dubious proposition, otherwise we wouldn't need job interviews. :) It is just as likely that we're simply miscommunicating. > If Chromium is not building *by itself* on -ffast-math, we should *not* > support building it with it. Full stop. Define what you mean by "building *by itself*" - I don't want to assume I understand what you're getting at here. I certainly wasn't suggesting that you could be able to run CFLAGS=3D"-O2 -ffast-math" emerge chromium and get anything usable. -ffast-math is a flag that should be applied to specific functions or even parts of functions where there is an understood performance vs accuracy tradeoff. > It's not that adding -ffast-math loses the 1/100th precision on a scroll > bar pixel: it has a truckload of changes to the whole mathematics in the > code, which _among other things_ will break that scrollbar, because the > calculation used to display it add up to a huge difference. If you're just using it to calculate how many pixels down it is, it certainly shouldn't be that inaccurate. If you're using it to do pointer arithmetic or something then you're just going to get segfaults. There are arithmetic functions in computing that are discrete/functional in nature, and there are those which relate more to real-world measurements. Adding a 0.001% error to a hash calculation breaks a hash. Adding 0.001% error to a scientific calculation where all the components have 1% measurement error is insignificant. > I would be wondering about it if it broke stuff that > already is designed to rely on it, but even in that case, it's hard to > actually say that it "broke", it's just "different". This is the case I'm concerned with only. Agree somewhat on "broken" being a loose term when the flag is intended to yield inaccurate results. However, it probably is not intended to yield grossly-inaccurate results. Then again, the bug cited things like 5 vs 7 and those are equivalent within an order of magnitude. Rich