This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]