Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell <mark at codesourcery dot com>]

Kai Tietz wrote:

>> I'm sorry -- that doesn't really answer the question I was trying to
>> ask.  To be clear, if we're calling through a function pointer, we still
>> need to be able to do the right thing, and in that case we don't have a
>> FUNCTION_DECL.  So, I don't understand how you can have a macro to
>> control the calling convention that accepts a FUNCTION_DECL; I would
>> think it would have to accept a FUNCTION_TYPE.
> 
> Sorry, I think I missed your question. To make the macro 
> OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no 
> special reason for it. I deceided this to make it accepting a 
> FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. 

> If this is a serious
> problem, of course I can move this to a FUNCTION_TYPE. Are there some 
> special needs to have here FUNCTION_TYPE ?

Yes, I think this -- and any other macros/hooks that affect calling
convention -- must be based on FUNCTION_TYPEs, not FUNCTION_DECLs.
Otherwise, we cannot properly support calling through a function pointer.

>From (one) type-theoretic perspective, types tell you what set of
operations you can perform.  You can't perform the operation "call this
function, putting its parameters in the usual place" if the function
doesn't want its parameters there; ergo, this must be a property of the
type.

Furthermore, I would argue that the attributes here should be recorded
*only* on the type, in order to avoid duplication.  That's not strictly
speaking necessary, but calling conventions are certainly properly
thought of as a property of types, not of declarations.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713