This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problem in locate_and_pad_parm
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Problem in locate_and_pad_parm
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: 19 Oct 2000 13:43:56 -0700
- Cc: gcc at gcc dot gnu dot org
- References: <10010191056.AA28425@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> The definition of MUST_PASS_IN_STACK is seriously broken.
>
> I'm certainly quite willing to believe that, since it represented the state of
> the compiler quite a while ago: I don't think anybody changed it since
> I first defined it and the compiler has gotten more capable.
...
> Unfortunately, changing MUST_PASS_IN_STACK is problematic. There are
> a lot of ports whose ABI is defined by the code that gcc happens to
> emit for them. If we change MUST_PASS_IN_STACK, then we are
> implicitly changing the ABI for all of those ports.
>
> True, but I suspect it's the case that such ports were never obeying
> the system ABI in those areas, so it would make them better: at least
> that's my guess based on the cases I knew about.
I believe that Jim is referring to those ports where there is no
published API, it is defined by the code that GCC generates. The
effect of this is that any change to the parameter-passing mechanism
could break the ABI for those ports, and this macro is one of the
places where it could most easily break.
[IMHO, it was not a good design decision to make the behavour of the
compiler change when support for a particular case is added. I hope
that what we would now do is handle the cases we know and abort() for
the rest.]
--
- Geoffrey Keating <geoffk@cygnus.com>