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: [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.


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