Re: [AD] crash, tools/dat.exe v411, msvc7

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> why is it optimized anyway ?    wouldn't a debug build be sufficient, then
> when a crash occurs and Windows offers to debug/send M$ a report :(  i can
> hit debug and find the problem.   as a tool i thought it would be more
> important to have it working reliably, instead of fast.

There are two aspects: compiling with no optimization and compiling with 
debug symbols. There are roughly orthogonal (at least with GCC).

Compiling with no optimization produces horrible code (at least with GCC), 
compiling with debug symbols produces very large binaries.

I don't think we should switch off optimization for tools in the release 
build of Allegro: this would mean real performance drops, e.g. for the 
grabber.

I think we could turn on debug symbols for tools in the release build, at 
least for the development series. However, for GCC this would mean tweaking 
a bit the optimization options (in particular -fomit-frame-pointer should be 
removed, at least until GDB 6.x is in widespread use) and imply that we 
can't re-enable them later.

> or  what about using -O0 (no optimz) for tools, as i have a feeling that
> compilers tend to get non-optimized code more right then optimized code.

IMHO this is a slippery slope: if we start to make generic changes because of 
a problem with a particular version of a particular compiler, we'll never 
stop. On the other hand, it you can detect at compile time the version at 
stake, we could tweak the optimization options automatically. We did that 
for GCC 3.0.x that had a buggy -fomit-frame-pointer.

-- 
Eric Botcazou