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] Preparations for SYSV/MS ABI attributes in middle-backend may before stage 3 and implementation in i386


Mark Mitchell wrote on 17.09.2007 20:56:10:

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

Ok, I changed documentation and implementation for this patch (see 
attachment).
Now, OUTGOING_REG_PARM_STACK_SPACE has a FUNCTION_TYPE as argument.
Additionally, I attached the updated second part of this patch for Jan to 
this e-mail, too.
I replaced the documentation you suggested for 
OUTGOING_REG_PARM_STACK_SPACE. Also I added the "old" RETURN_IN_MEMORY 
macro to tm.texi with reference to TARGET_RETURN_IN_MEMORY.

Is this OK for apply ?

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-StraÃe 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  KomplementÃrin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-StraÃe 9 â 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - GeschÃftsfÃhrer: 
Ulrike DÃhler, Manuela Kluger


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