This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: m68k bootstrapping broken
Richard Zidlicky wrote:
No, it shouldn't be possible. There might some obscure bug somewhere
in corner cases such as functions with big frames or functions with
strange attributes...
even if it doesnt bomb it generates code like this:
__cmpdi2:
.LFB38:
.file 1 "../../gcc-3.4-20031210/gcc/libgcc2.c"
.loc 1 1068 0
pea (%a6)
move.l %sp,%a6
This is equivalent to:
link #0,a6
It's done only with -m68040 because it's faster.
.LCFI0:
move.l %d2,-(%sp)
.LCFI1:
lea (8,%a6),%a0 !!!!!!!!
move.l (%a0),%d0
move.l 4(%a0),%d1
.....
The use of %a0 is not incorrect but completely unnecessary.. same
optimisation settings etc again. What would cause this kind of code
get generated? Wrong cost estimate? Some comparison against +/32K
run amuck?
I believe this is how GCC has always worked. Unless you specify
-fomit-frame-pointer, a6 will be loaded with sp in function
prologue, even if the frame size is 0. This is done because older
debuggers relied on it in order to find local variables.
Of course, we could change the default for m68k to imply
-fomit-frame-pointer with -O, as described in the manual:
`-O' also turns on `-fomit-frame-pointer' on machines where doing
so does not interfere with debugging.
The new code couldn't be regtested with dejagnu because there is
no m68k simulator in GDB and there were too many issues with remote
testsuite execution on embedded ColdFire boards.
If you want to debug this it should be possible to get an account
on some of the m68k boxes of the Debian project,
mail debian-68k@lists.debian.org
Good idea! I've just asked them.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/