This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: m68k bootstrapping broken
On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> 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.
nope, I meant the line marked by "!!!!!".. meanwhile I figured out
that argpointer elimination must have failed in that example. This
happens only during native compilation so you cant reproduce it for
now :(
Richard