[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] gcc4 vs gcc2 crash "test case"
MiKRO wrote:
Yes, it hopefully produces "Bad surface extents" at runtime. The
code is
really wrong, because it does not consider the potential floor problem.
It would be interesting to investigate deeper that approximation
Can you give me some clue what to look for? Every floor()/ceil()
function? Isn't possible that different behaviour with different
optimization options are because different FPU precision is used?
(single vs double floats, fmul vs fsglmul etc..). I'll look at this asap.
I looked at the sources, the only problem seems to be the case I
explained previously.
http://sparemint.atariforge.net/mailinglist/Mailing-Lists/MiNT-List.200801/47970063.8010806@freesbee.fr.text
It is in CalcSurfaceExtents() in model.c
So I'll disable CAN_DEBUG_WITHOUT_FP it in my next patch, and we will
have to decide if it should be enabled again when GCC is fixed.
Wise idea. Please make that patch asap ;) So general rule, with your new
patch, will be *not* to use -fomit-frame-pointer in both debug and
release version, right? This probably apply to c++ code as well?
You can "easily" make the test.
In the GCC patched sources, open gcc/config/m68k/mint.h
Remove #define CAN_DEBUG_WITHOUT_FP
Then recompile gcc (at least, the cc1 executable).
In that case (CAN_DEBUG_WITHOUT_FP disabled), with the current buggy
GCC, the rule will be: Never use -fomit-frame-pointer on optimized code
compiled with -m68020 or higher.
However, with such a bug, I'm not really sure that not using
-fomit-frame-pointer is a fully functionnal workaround.
Your will test that !
damn it. btw if you'll have some time, try to look at gcc4 compilation
with make CFLAGS=-m68060 against gcc4 (in normal -m680000) -- it
produces error, too, however, totally different.
I tried -m68060, it seemed that the problem was the same... but I don't
remember everything. We will have more information with the new patch.
Things get better !
--
Vincent Rivière