From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18570 invoked by alias); 5 Aug 2008 08:19:59 -0000 Received: (qmail 18560 invoked by uid 22791); 5 Aug 2008 08:19:58 -0000 X-Spam-Check-By: sourceware.org Received: from an-out-0708.google.com (HELO an-out-0708.google.com) (209.85.132.251) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Aug 2008 08:19:18 +0000 Received: by an-out-0708.google.com with SMTP id c28so440639ana.104 for ; Tue, 05 Aug 2008 01:19:16 -0700 (PDT) Received: by 10.100.112.9 with SMTP id k9mr936457anc.111.1217924356321; Tue, 05 Aug 2008 01:19:16 -0700 (PDT) Received: from dagda.uio.no ( [129.240.223.119]) by mx.google.com with ESMTPS id b19sm9483701ana.19.2008.08.05.01.19.15 (version=SSLv3 cipher=RC4-MD5); Tue, 05 Aug 2008 01:19:15 -0700 (PDT) From: Torquil Macdonald =?iso-8859-1?q?S=F8rensen?= To: gcc-help@gcc.gnu.org Subject: Re: Optimization and double comparison Date: Tue, 05 Aug 2008 08:19:00 -0000 User-Agent: KMail/1.9.4 References: <200808042334.05408.torquil@gmail.com> <489780AB.8852489@dessent.net> In-Reply-To: <489780AB.8852489@dessent.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808051019.13789.torquil@gmail.com> X-IsSubscribed: yes 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: 2008-08/txt/msg00043.txt.bz2 On Tuesday 5. August 2008 00:20, Brian Dessent wrote: > Torquil Macdonald S=F8rensen wrote: > > In short, how can it be that an if-test of the following form can print > > two exactly equal numbers?: > > > > if( a !=3D b) { > > cout << setprecision(70); > > cout << a << " " << b << endl; > > } > > You didn't mention what target this is. If it's x86 then this is the > classic issue of excess precision, wherein operations within the 387 > unit occur in extended (80 bit) precision but when transferred out of > the FP unit and stored to memory are truncated to double precision (64 > bit.) If you compare a value that has just been computed with one that > has been previously computed and then stored to memory, they won't > necessarily be equal since one has been truncated while the other still > has its excess precision. But by passing it on the stack to cout you > essentially force a memory store which discards the excess precision so > they both appear the same. > > Much has already been written on this topic, so I suggest just reading > PR323 or googling. There are numerous workarounds: use sse2 instead of > 387, set the 387 to double precision (e.g. -mpc64 or _FP_{GET,SET}CW), > use -ffloat-store, don't compare for absolute equality but against some > small delta, etc. > > Brian Hi Brian, thank you very much. Yes the target is x86. Your answer was very= =20 interesting. The comparison was just to make sure that a certain quantity=20 still had the value that it is supposed to have, so it was only for debuggi= ng=20 my algorithm. It should be allright if I instead allow a small error in the= =20 comparison, so I think that I don't have to worry about this problem then. Thanks again, Torquil S=F8rensen