This is the mail archive of the
mailing list for the GCC project.
Re: [Bug target/13312] [m68k] C++ produces stack frame damaging codefor Coldfire
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Steve Zook <Steve at Zook dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 25 Jan 2004 11:07:54 +0100
- Subject: Re: [Bug target/13312] [m68k] C++ produces stack frame damaging codefor Coldfire
- Organization: Develer S.r.l.
- References: <000001c3e300$8fe99160$0201a8c0@parents>
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
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.