From: | Robert A Duff <bobduff@shell01.TheWorld.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 27 Mar 2011 13:09:53 -0400 |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 11-03-054 |
Keywords: | C, debug |
Posted-Date: | 27 Mar 2011 19:00:33 EDT |
"rhoads@cs.rutgers.edu" <rhoads@cs.rutgers.edu> writes:
> The -O3 optimizations are supposed to always produce the same
> results.
No, that's not true. Optimization should preserve the semantics.
But the semantics often allow more than one result.
If you do something that is "undefined behavior" in C,
the semantics allow more than one result. In fact, an
infinite number of results. So turning on optimizations
can easily change which one of those results actually
happens at run time.
>... Running through the debugger is not supposed to change the
> results either.
Gcc and gdb go to a lot of trouble to make sure the debugger
doesn't perturb the results. But it's impossible to do that
100%. For example, stopping at a breakpoint changes the timing
of things, which can cause a multi-threaded program to behave
differently. Is your program multi-threaded by any chance?
Or handling interrupts/signals?
>... Has anybody else encountered this behavior?
It's fairly common that turning on optimizations changes results.
Solution: Use a language with fewer cases of "undefined behavior".
It's uncommon for debugging to change results.
But I've seen it happen.
Solution: print-out statements. (Those can change results, too,
if you're doing undefined behavior. But you might get lucky.)
- Bob
Return to the
comp.compilers page.
Search the
comp.compilers archives again.