This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

	move.l %d2,-(%sp)
	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

Good idea! I've just asked them.

 // Bernardo Innocenti - Develer S.r.l., R&D dept.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]