Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: GCC/G++ compiler: Error goes away when run through debugger Date: Tue, 29 Mar 2011 18:47:59 +0000 (UTC) Organization: A noiseless patient Spider Lines: 29 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-03-062@comp.compilers> References: <11-03-054@comp.compilers> <11-03-059@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1301426090 56760 64.57.183.58 (29 Mar 2011 19:14:50 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 29 Mar 2011 19:14:50 +0000 (UTC) Keywords: C, arithmetic, debug Posted-Date: 29 Mar 2011 15:14:50 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:62 Torben Fgidius Mogensen wrote: (snip) > The moral is, of course, that I should not have used equality tests > for FP numbers, but instead used an "within epsilon" test. In > general, you should not expect FP calculations to give exactly the > same result after optimisation in C or C++, as the order of evaluation > is not fully specified and because the compiler might optimise a > multiplication followed by an addition to a multiply-and-add, which > can change rounding behaviour. In addition, many compilers do constant expression evaluation sufficiently different from run-time evaluation that comparisons may fail for that reason. There are even some that use special libraries to evaluate constant expressions to very high precision when there is no need for such precision. With x87 floating point, intermediate results are kept with 64 significant bits, unless the value is stored. Sometimes even though as written the value is stored, the optimizer will keep it in a register. Fortran, unlike C89 (but I believe like C99) requires parentheses to be respected regarding evaluation order, even with mathematically equivalent expressions. Other than that, there are many other optimizations that can change the value of floating point expressions, and that are legal. -- glen