Re: GCC/G++ compiler: Error goes away when run through debugger

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Tue, 29 Mar 2011 18:47:59 +0000 (UTC)

          From comp.compilers

Related articles
[2 earlier articles]
Re: GCC/G++ compiler: Error goes away when run through debugger bobduff@shell01.TheWorld.com (Robert A Duff) (2011-03-27)
Re: GCC/G++ compiler: Error goes away when run through debugger robin51@dodo.com.au (robin) (2011-03-28)
Re: GCC/G++ compiler: Error goes away when run through debugger Pidgeot18@verizon.invalid (Joshua Cranmer) (2011-03-27)
Re: GCC/G++ compiler: Error goes away when run through debugger torbenm@diku.dk (2011-03-28)
Re: GCC/G++ compiler: Error goes away when run through debugger bc@freeuk.com (BartC) (2011-03-28)
Re: GCC/G++ compiler: Error goes away when run through debugger gneuner2@comcast.net (George Neuner) (2011-03-29)
Re: GCC/G++ compiler: Error goes away when run through debugger gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-03-29)
Re: GCC/G++ compiler: Error goes away when run through debugger ike@localhost.claranet.nl (2011-03-29)
Re: GCC/G++ compiler: Error goes away when run through debugger gneuner2@comcast.net (George Neuner) (2011-03-31)
Re: GCC/G++ compiler: Error goes away when run through debugger shankarke@gmail.com (Shankar) (2011-04-01)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Tue, 29 Mar 2011 18:47:59 +0000 (UTC)
Organization: A noiseless patient Spider
References: 11-03-054 11-03-059
Keywords: C, arithmetic, debug
Posted-Date: 29 Mar 2011 15:14:50 EDT

Torben Fgidius Mogensen <torbenm@diku.dk> 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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.