Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #64 > unrolled thread

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

Started bytorbenm@diku.dk (Torben Ægidius Mogensen)
First post2011-03-28 11:25 +0200
Last post2011-03-28 11:25 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.compilers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: GCC/G++ compiler: Error goes away when run through debugger torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-03-28 11:25 +0200

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

Fromtorbenm@diku.dk (Torben Ægidius Mogensen)
Date2011-03-28 11:25 +0200
SubjectRe: GCC/G++ compiler: Error goes away when run through debugger
Message-ID<11-03-059@comp.compilers>
"rhoads@cs.rutgers.edu" <rhoads@cs.rutgers.edu> writes:

> I have an C++ application program that is producing incorrect results
> but the error goes away when I run it through the debugger.
>
> When I used the -ggdb compiler flag so I can run it under the gdb
> debugger, the error goes away.  It also runs fine if I do both of the
> following; extract a few of the input instances which generate
> incorrect results and put them in a separate input file.
> Use this input file and recompile the program with no optimization
> flags (I am otherwise using the -O3 optimization flag).

I have had a similar experience: My program was giving strange
results, so I inserted some print statements to write out intermediate
results.  And promptly the problem disappeared.  I traced the problem
to the compiler re-arranging some FP computations which caused a
change in the last bit, which made some values be unequal that would
otherwise be equal.

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.

	Torben

[toc] | [standalone]


Back to top | Article view | comp.compilers


csiph-web