Re: Testing m68k changes on AmigaOS and Linux/m68k

[Gunther Nikl <gni at gecko dot de>]

On Tue, Oct 14, 2003 at 06:47:42PM +0200, Bernardo Innocenti wrote:
> >>Have you ever tried defining MOTOROLA? If you're luckly, it should work
> >>out of the box.
> >
> >  I never tried [MOTOROLA] and I won't try it because the assembler I
> >  am using doesn't support it.
> 
> I seem to recall you told me that too, but I can't remember why.
> Can't you use gas?

  I do use gas but its an enhanced pre-bfd version which is just fine for
  the AmigaOS/m68k port because it's a simple a.out port.
  My "problem" with BFD is that read and write support is always included
  even if only one is needed. That makes them fat (and thus slow) on a
  system that doesn't have un*x style shared libraries.

> Anyway, since the MIT syntax is going to stay in 3.4 and probably
> even in 3.5, I favour your proposal [defining MOTOROLA to 0/1]
> 
> We could get rid of several lines of code, those that confuse patch
> and my eye the most :-)

  I am looking forward for your patch :-)

> >>>I going to test the coss-built native compiler tonight.
> >
> >  Unfortunately the cross-built compiler doesn't work :-( It seems to be
> >  miscompiled since I get this error message:
> >
> >    ./cc1 -E foo.c 
> >    <internal>:0: internal compiler error: tree check: expected class 'd',
> >     have 'd' (function_decl) in make_decl_rtl, at varasm.c:882
> >
> >  The compiler was built by a cross-compiler built from the same source as
> >  this one. A native 3.4 built at the beginning of September 2003 works. I
> >  am going to test whether 3.3 and an older 3.4 as build compiler will do
> >  better. Currently I don't know when it broke :-/
> 
> The compiler used to work fine with m68k-elf and m68k-uclinux last week
> (last tested from CVS sources on 20031011).

  Are you sure? ;-) Its a bug with local variables stored in the frame
  without a frame-pointer which trashes the saved register set. Within
  GCC ggc_alloc() is affected (which then caused the failure I saw).
  Its easily reproducible with the AmigaOS port since there I can take
  the address of a local variable and pass it in a register. Without that
  ability the frame-pointer can't be eliminated. Anyway here is some example
  code which is compiled with "-O -fomit-frame-pointer -S"

    void __regargs bar(int *i, int *j);
    void foo(int i) { int j; bar(&i,&j); }


  3.3 (release):
   _foo:
     subqw #8,sp
     movel sp,a1
     lea sp@(12),a0
     jbsr _bar
     addqw #8,sp
     rts

  3.4 (20031013):
   _foo:
     subqw #4,sp
     lea sp@(-4),a1  <- should bas as with 3.3
     lea sp@(8),a0
     jbsr _bar
     addqw #4,sp
     rts

  I believe thats a bug within your patch from 2003-09-08. I only checked
  whether passed arguments are passed correctly. I didn't inspect local
  variables in the frame. I hope you can locate the problem.

  Gunther