[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] gcc4 vs gcc2 crash "test case"
MiKRO wrote:
3) Alignment.
Wow. This is the first time I see something like that -- are you sure
you shouldn't enable this things in gcc4 then? (alignment on 32bit).
Alignement will have to be discussed here (but I'm tired, now).
4) cross-compiling Quake.
hm, I don't remember the exact algorithm of this generator, there's no
chance to make this OK also for cross-building? You know, it's the
same gcc (alignment, int size etc should be same) but maybe I'm wrong
here..
The file gendefs.c displays the offsets of the different memebers of the
structures. It must be compiled with the target compiler in order to
have the good offsets (they really vary among the platforms because of
different alignement requirements). But it that case it can only be run
on the target for generating the file quakedef68k.i. I don't know how a
cross-compiler could determine the structure offsets et run time. A
solution would be to provide the file quakedef68k.i with the sources,
but it would be less safe.
The weird thing is that the precision problem is not exactly the same
when using different optimization options.
Wow again. How it's possible this didn't appeared in gcc2? I can't
even imagine how you observed this behaviour, it generates some kind
of error?
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
behavior. Maybe some differences in the FPU and soft-float implementations.
I appreciate your work, I really prey you'll find that nasty problem
why it refuses to work.
And I finally found it ! It is a bug in GCC 4.2.2. I posted a detailed
bug report on the GCC Bugzilla.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34947
That damn bus error comes from the file view.c, in the function
V_DriftPitch(). The FPU registers are backuped at the beginning of the
function... then the compiler forgets to restore them on return. So RTS
is reached, then the FPU backup on the stack is used as the return
address, and of course... bus error.
Note that bug appears only in some cases when the famous frame pointer
is not used. Usually the frame pointer (link/unlnk a6) is always used
(even when useless), unless -fomit-frame-pointer is used. However, there
is an internal setting in GCC called CAN_DEBUG_WITHOUT_FP. When that
setting is turned on (in the GCC sources), -fomit-frame-pointer is
implicitly used when -O is used.
The advantage of CAN_DEBUG_WITHOUT_FP is that -O2 (or -O3) uses
automatically the best settings, without additional options. The frame
pointer is totally useless for the Release executables.
The drawback of not using the frame pointer is that the debuggers (like
gdb) cannot display an accurate call stack.
The drawback of CAN_DEBUG_WITHOUT_FP is that the frame pointer cannot be
occasionally enabled on optimized code.
At first it seemed to me that CAN_DEBUG_WITHOUT_FP was a good thing, So
I enabled it in the GCC patch. I don't really know if it is good or not.
However, due to the bug in the current GCC 4.2.2, it is impossible to
produce reliable optimized code for the FPU without the frame pointer.
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.
A note about the frame pointer: it is automatically enabled for
functions using alloca(), even if -fomit-frame-pointer is used.
So I put alloca(1) at the top of V_DriftPitch(), and it "fixed" it !
Unfortunately, Quake uses a lot of floats, so it crashes later in
another function. Definitely: the current GCC 4.2.2 is unusable with
-m68020-60 and -O
The mystery is solved... but not the problem.
MiKRO: I don't think I have something useful for you... I put a lot of
printf() in the sources. The warning fixes are obvious (mostly casts). I
may send you a diff if you really care.
Note for other readers: in order make debugging easier, MiKRO made a
special version of Quake that displays nothing on the screen, only the
Quake console messages are displayed in the TosWin console. I was very
amused when I first saw "You got the shells"... in the bash window !
Anyway, is it possible to play the real Quake (not the Unreal :-) ) on
ARAnyM, with OpenGL ?
--
Vincent Rivière