Re: Omit frame pointer bug in m68k gcc 3.3.1

["David Brown" <david at westcontrol dot com>]

>
> >I've found a bug in the gcc build on
> >http://www.davehylands.com/avi/index.htm that I've been trying.  This
isn't
> >just an inconvenience thing, but a matter of incorrectly generated code
when
> >the -fomit-frame-pointer flag is on.  I normally have that flag on, since
> >gdb does not need the frame pointer for debugging, and without it the
> >compiler saves a few instructions and cycles, and has another free
register
> >to use.  But with it enabled, the compiler produces incorrect code
(example
> >below) - it reads function parameters from the wrong place, and it uses
> >incorrect addresses for local variables.  I notice (from
> >http://www.davehylands.com/avi/compile_instructions_for_gcc.htm ) that
this
> >build has a patch called gcc-3.3.1-coldfire-frame.patch.txt (available
from
> >Avi's site) - I don't know if this is a standard or commonly used patch,
but
> >it seems to provide the "interrupt" attribute (which is essential for my
> >program - I am running bare-bones without an OS on one of our own cards,
and
> >I much prefer the "interrupt" attribute to writing assembly wrappers).  I
> >don't know if the patch is related to the problem or not.
>
> Check out the patches at:
> http://www.develer.com/uclinux/uclinux-elf-tools.html
>
> One of which is gcc-3.3.1-coldfire-reload.patch which contains a small
> patch to gcc/reload1.c which isn't acceptable to the GCC maintainers
> since it makes an assumption about how instructions like:
>
>   move.l 4(%sp),-(%sp)
>
> update %sp, before or after the access to 4(%sp).  This patch has been
> found to fix problems using -fomit-frame-pointer on ColdFire.  You'd
> best pick up the *complete* gcc-3.3.1 patch set...
>
> Good Luck!
>

Thanks for the information.  I've been meaning to do a build myself for a
while now, and the uclinux site looks like a convenient place to get the
patches and information.

Is it worth trying 3.4 rather than 3.3.1 ?  From my testing and brief
benchtesting, it looks like the back-end of 3.3.1 is pretty much the same as
for my old 2.95 version (a few things were slightly faster, and bitfield
manipulation seemed to be a bit slower) on the cpu32.  The front-end
optomisations (such as moving blocks of code around, and inline functions
even if they were defined later in the code, with -O3 turned on) have
definitely improved.  As far as I can tell, changes in 3.4 are going to be
more on improving the speed of the compiler itself rather than changes at
the back-end - is that correct?

Also, I am going to have to get gcc going for the MPC56x in the very near
future.  I know there are some windows binaries available from Macraigor,
but are there any good pages with build instructions and necessary patches
like there are for the cpu32/coldfire ?

Thanks,

David




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com