This is the mail archive of the gcc-patches@gcc.gnu.org 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: [ColdFire 53/63] Static chain fixes


Richard Sandiford <richard@codesourcery.com> writes:
> Jeffrey Law <law@redhat.com> writes:
>> On Wed, 2007-01-10 at 12:10 +0000, Richard Sandiford wrote:
>>> m68k*-elf targets use %a0 as both the incoming structure return address
>>> _and_ the static chain pointer.  This causes a conflict if a nested function
>>> returns a structure.
>>> 
>>> This patch moves the static chain register to %a1 for these targets only.
>>> It also generalises the template code to cope with static chain registers
>>> other than %a0.
>>> 
>>> Richard
>>> 
>>> 
>>> gcc/
>>> 200x-xx-xx  Nathan Sidwell  <nathan@codesourcery.com>
>>> 	    Richard Sandiford  <richard@codesourcery.com>
>>> 
>>> 	* config/m68k/m68k.h (M68K_STATIC_CHAIN_REG_NAME): New macro.
>>> 	(INITIALIZE_TRAMPOLINE): Use STATIC_CHAIN_REGNUM.
>>> 	(__transfer_from_trampoline): Use M68K_STATIC_CHAIN_REG_NAME.
>>> 	* config/m68k/m68kelf.h (STATIC_CHAIN_REGNUM): Override.
>>> 	(M68K_STATIC_CHAIN_REG_NAME): Likewise.
>>> 	* config/m68k/netbsd-elf.h (M68K_STATIC_CHAIN_REG_NAME): Likewise.
>>> 
>>> gcc/testsuite/
>>> 200x-xx-xx  Nathan Sidwell  <nathan@codesourcery.com>
>>> 
>>> 	* gcc.c-torture/execute/nestfunc-7.c: New.
>> Isn't this an ABI change?  If so it needs to be documented at the least
>> so that users of the m68k elf port aren't caught by surprise.
>
> Of sorts, although I'm not aware of any actual XFmode emulation
> code for ColdFire.  I suspect most ColdFire users just avoided
> using long double altogether.  This may be my ignorance though. ;)
>
> To be honest, I wasn't involved in the discussions that led to this
> change, but I thought lack of XFmode emulation was the main reason.

Sigh.  Sorry, I'd got myself confused, and thought you were talking
about the "long double" change.

No, I don't think this one is an ABI change.  Nested functions should
be internal a translation unit; I don't see how an external module
would tell the difference.

Richard


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