Author: Dann Corbit
Date: 18:33:15 07/03/03
Go up one level in this thread
On July 03, 2003 at 10:08:14, Jon Dart wrote: >On July 03, 2003 at 04:48:34, Jens Kahlenberg wrote: > >>I read good news from Normand regarding level 4. Most of the debug vs release >>"problems" are _not_ compiler-bugs. > >I'd agree with this, but I also think that if changing the optimization flags >changes the program behavior (i.e. you are comparing two release builds, not a >release build and a debug build), that is a good indication that it's a compiler >problem. It seems that is the case here. Just about as often, I find that changing behavior from optimization flags is still caused by a programming error. This is especially true in integer only programs. The only optimization flag that is genuinely dangerous to use is to 'assume no aliasing' when you are not absolutely sure that aliasing cannot occur. Floating point programs will often change a bit under different optimization flags, but only by some expected delta in the trailing bits of precision. Sometimes (for instance) a compiler will initialize auto variables in debug mode to some recognizable value, but leave them as "whatever" in release mode. Or some variable might get completely optimized away. That would be unimportant, but it changes the location of things. So now, an 1 byte overwrite that used to have little effect can suddenly become traumatic. Lint & splint, bounds-checker & electric-fence and things of that nature are the best way to find out what is really going haywire. I have found compiler errors. But most things I originally thought were compiler errors turned out to be ... [cough] me.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.