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 i386]: Enable ms_abi/sysv_abi and add testcases


"Joseph S. Myers" <joseph@codesourcery.com> wrote on 17.06.2008 15:32:48:

> On Tue, 17 Jun 2008, Kai Tietz wrote:
> 
> >         * doc/tm.texi (TARGET_GET_VALIST_TYPE): New.
> 
> This definition doesn't make sense to me.  The "used calling convention" 

> for what?  A particular variable of va_list type?  A va_list resulting 
> from calling va_start in a particular function?  Surely such a macro 
needs 
> to have something passed to it indicating the particular ABI convention?
May the name could be better, but it makes absolutely sense! The va_list 
type is call abi dependent. It makes absolutely sense to do this as macro, 
so targets, which have just one va_list abi have no disadvantage (and need 
no change). Secondly, the type of va_list is always specified proper via 
the global cfun.
May you can point me to an variant of how to implement this - without the 
need to touch all targets and compile time punishing all targets with just 
one va_list type.

> If you want to support multiple ABIs like this, it will be possible for 
> one function to have va_list variables of both types, passed in from 
> callers using different ABIs.  I think that everywhere you use this 
macro 
> you need instead to (a) possibly call a target hook (a hook in the 
target 
> structure, not a target macro) that verifies that the type being used in 

> that context is one of the valid va_list types, to replace existing 
> comparisons against a single va_list type and (b) use the particular 
> va_list type deduced from the context (e.g. if a tree for a va_list 
object 
> is in use at that point, that tree indicates the ABI in use through its 
> type).  I don't think you should need TARGET_GET_VALIST_TYPE.
This I verified and the stdarg checking shown, that it catches the use of 
*foreign* va_list type by telling it has a wrong type.
>  Nor should you need TARGET_ENUM_VA_LIST, targets can already initialize 
any built-in 
> types they want from TARGET_INIT_BUILTINS without needing new hooks.
Here I wasn't sure. I made bad experience with builtin deletion 
(especially for fortran) in targets and distrust the provided abi of 
backend.
Also it is necessary, that those types are initialized in an early stage. 
But I can give it a try, if fortran then still works.

Regards,
 i.A. Kai Tietz

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


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