RFA: handling of mode attribute

Joseph S. Myers joseph@codesourcery.com
Sun Sep 27 15:19:00 GMT 2009


On Sun, 27 Sep 2009, Kai Tietz wrote:

> well the issue described in 32187 is related. I want to use base type
> mode specifiers to have an ability to provide for mingw x64 target
> __int128 type and also for 32-bit mingw targets the types __int8,
> __int16, __int32, and __int64. I spoke here with Ian about this, as we
> would have here also the possibility to extend C/C++ FE keywords, but
> we both came to the opinion that it would be better to be able to
> implement them as pre-defined macros. The patch I attached could be
> used for the __float128 type, too.

I do not think predefined macros using attributes are a good approach 
here; I think they are a solution in search of a problem.

I believe what's wanted is the possibility of defining target-specific 
types that act like keywords to the extent of being able to use them with 
"signed", "unsigned" or "_Complex" (signed and unsigned only for integer 
types, _Complex for both integer and floating-point types).  You could 
arrange for some built-in typedefs to be handled specially (both allowed 
after other type specifier keywords, and allowing those modifiers to 
follow them).  Or you could, maybe more simply, add some 
target-independent keywords

__int64
__int128
__float80
__float128

with target hooks to determine whether they are accepted.  The C parser 
and declaration specifiers handling could then handle these directly (and 
likewise C++).  The set of such types is fairly limited; there is no need 
for IA64 __fpreg or ARM __fp16 to be handled like this since the relevant 
API specifications for them do not include support for corresponding 
complex types.  (Actually, the x86-64 SYSV ABI seems silent on the 
question of _Complex __float128 as well, but __float80 and __float128 are 
certainly more like normal floating-point types in terms of what can be 
done with them than __fp16 is.)

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list