From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7060 invoked by alias); 21 Dec 2011 07:53:34 -0000 Received: (qmail 7041 invoked by uid 22791); 21 Dec 2011 07:53:31 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from asav3.lyse.net (HELO asav3.lyse.net) (81.167.37.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Dec 2011 07:53:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by asav3.lyse.net (Postfix) with ESMTP id 2994484194; Wed, 21 Dec 2011 08:53:15 +0100 (CET) Received: from localhost.localdomain (unknown [79.161.10.130]) by asav3.lyse.net (Postfix) with ESMTP id AE90C8415B; Wed, 21 Dec 2011 08:53:14 +0100 (CET) Received: from [192.168.0.60] (helo=[192.168.0.60]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1RdGzC-0007Pg-32; Wed, 21 Dec 2011 08:53:14 +0100 Message-ID: <4EF1900B.1020602@westcontrol.com> Date: Wed, 21 Dec 2011 08:32:00 -0000 From: David Brown User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Miles Bader CC: David Brown , Dario Saccavino , Jonathan Wakely , Ico , gcc-help Subject: Re: Floating point performance issue References: <1324374252-sup-7043@pruts.nl> <4EF05DDD.1090303@mejor.pl> <1324376083-sup-8851@pruts.nl> <20111220112357.GC3072@xvii.vinc17.org> <20111220120157.GD3072@xvii.vinc17.org> <4EF0871F.1010802@westcontrol.com> <20111220134308.GF3072@xvii.vinc17.org> <4EF0943C.2070609@westcontrol.com> <20111220142459.GG3072@xvii.vinc17.org> <4EF0A3E5.6040406@westcontrol.com> <87wr9qzs4i.fsf@catnip.gol.com> <4EF133F7.70304@hesbynett.no> <87fwgezmy5.fsf@catnip.gol.com> In-Reply-To: <87fwgezmy5.fsf@catnip.gol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg00195.txt.bz2 On 21/12/2011 03:18, Miles Bader wrote: > David Brown writes: >>> David Brown writes: >>>> Making "-Wfloat-equal" a default flag would eliminate many of these >>>> mistakes. >>> >>> It also results in false positives, so it shouldn't be on by default. >>> >>> [E.g. "float x = 0; .... y = x; ... if (y == 0) ..." should not result >>> in a warning.] >>> >>> -Miles >>> >> >> I gather (from the bug report mentioned by Vincent Lefevre) that code >> like this will not always give the result you expect - so the compiler >> should definitely warn in such cases. > > No. The bug cited by Vincent is a completely different case. > > Calculation and assignment are not the same. > > -Miles > My impression was that they were the same, or at least related, since the calculations in the examples would probably be done in advance by the compiler and reduced to simple assignments. But I expect that you know the details a lot better than me. If the compiler can guarantee consistent and expected results in cases like yours involving simple assignments, then it would make sense to change the "-Wfloat-equal" not to trigger in such situations. After all, the point of the warning is to help users avoid code that might not do what it seems to do - if it /does/ do the expected thing, then there is no need of a warning. In other words, the best course (IMHO) is to fix -Wfloat-equal to eliminate common false positives, and /then/ enable it by default. mvh., David