From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25425 invoked by alias); 4 Aug 2008 22:21:07 -0000 Received: (qmail 25417 invoked by uid 22791); 4 Aug 2008 22:21:06 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 22:20:32 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1KQ8Pk-0006TF-Vm; Mon, 04 Aug 2008 22:20:29 +0000 Message-ID: <489780AB.8852489@dessent.net> Date: Mon, 04 Aug 2008 22:21:00 -0000 From: Brian Dessent Reply-To: gcc-help@gcc.gnu.org X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: Torquil Macdonald =?iso-8859-1?Q?S=F8rensen?= CC: gcc-help@gcc.gnu.org Subject: Re: Optimization and double comparison References: <200808042334.05408.torquil@gmail.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00037.txt.bz2 Torquil Macdonald S=F8rensen wrote: > In short, how can it be that an if-test of the following form can print t= wo > exactly equal numbers?: >=20 > 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