Re: [Bug target/13312] [m68k] C++ produces stack frame damaging codefor Coldfire

[Bernardo Innocenti <bernie at develer dot com>]

Steve Zook wrote:

> I built gcc-3.4-20040121. It took a little doing because newlib-1.11.0
> (the revision I've been using) had a bunch of fatal compile errors that
> I had to fixup (apparently the 3.4 compile is pickier about certain
> things). The same problem persists.

:-(

> Attached is the output assembly code which on line 384 has the problem.

I see.  I'll try to fix it next week, but if it's a middle-end issue,
I'm afraid I don't have the necessary expertise to do it.


> One big question (rhetorical question) I've always had is why does the
> compiled code copy the function parameters to the local area of the
> frame in the first place? This processor family should only make that
> advisable if the stack frame is larger than +-32K (the amount of
> distance from the %fp that can be accessed directly). The parameters
> would have to be larger than 32K and/or the locals larger than 32K
> before the normal %fp relative accessing won't work. I suspect there's
> something deeper than the back-end that is not using the processor
> optimally here. Then, of course, there's this bug that then screws up
> the stack.

I think copying to the frame is only done when the variable needs to
be written to.  The m68k ABI doesn't allow to alter data put on the
stack by the caller.

Gunther Nikl is soon going to contribute the -mregparm=N option that
enables a more efficient parameter passing convention, altough it
changes the ABI so it's not an option for regular applications.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/