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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


i tend to agree with your feelings on this matter.
when i find some time i will re-compile the dat.exe with mscv7 and test it again.
maybe it was just a dodgy build.

the mingw build was fine, so im not suggesting that gcc is causing this bug.
but i am pointing at msvc7  ( .0 i might add )  as being possibly the cause.
so if any non-optimz decision was made, it would be for msvc7 only.

but im not suggesting we do this after your enlightening comments below.

to help me investigate this problem, is there a make script for building the tools with msvc7 with _DEBUG and symbols, or must i hack one of the MAKEFILEs ? im not 100% confident of my msvc7 MAKEFILE hacking skills.. more like about 60%. my gcc makefile hacking skills are closer to 90%.

other things to note, i am using msvc7.0 which i am told is the older of the currently available msvc's i have heard that v7.1 is better.. but i do not know if this refers to the compiler or the IDE.






At 09:08 AM 14/10/2003 +0200, you wrote:
> 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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/