This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Revert controversial apply_{args,result}_size change
On Mon, 2005-04-11 at 06:24, Mark Mitchell wrote:
> Eric Christopher wrote:
>
> >
> > I've gone back to look at some of the original discussion that prompted
> > this patch, most of it came from here:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00402.html
>
> I don't entirely follow.
>
> The current documentation still says:
>
> "@defmac FUNCTION_VALUE_REGNO_P (@var{regno})
> A C expression that is nonzero if @var{regno} is the number of a hard
> register in which the values of called function may come back.
>
> A register whose use for returning values is limited to serving as the
> second of a pair (for a value of type @code{double}, say) need not be
> recognized by this macro."
>
> That seems reasonable enough, although an alternate form in which the
> second-of-a-pair register *did* have to be recognized would also seem
> reasonable. I wouldn't object to switching to that definition -- but
> the person implementing the switch should go through and update all ports.
>
> What seems to have happened is that your change modified the behavior of
> the API used by back ends, but did not modify the back ends to
> compensate for that change. I think we should get back in synch, either
> by undoing your change, or by updating the back ends. I don't have a
> preference as to which approach is taken, though I suspect that undoing
> your change is easier, in that it probably requires auditing less code.
I think it requires more than that. It also requires analysing all
other USEs of this API to confirm that they are not adversely affected.
I had a quick look before I started travelling last week, and it looked
to me as though it *might* be OK, but that the other uses may well be
using this API in another way that is ill-specified. In particular look
at keep_with_call_p and its callers.
[If the above doesn't make much sense, then I apologise and blame jet
lag...]
R.