RFA: handling of mode attribute

Kai Tietz ktietz70@googlemail.com
Sun Sep 27 15:20:00 GMT 2009


2009/9/27 Joseph S. Myers <joseph@codesourcery.com>:
> 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
>

You are right that the initial point for this patch was to have new
types, which are combine-able with type specifiers, like
unsigned/signed/_Complex. To have the ability to define such types in
target scope would be of course the best, but as far as I can see the
current type-system in C/C++ FE doesn't provide this pretty easily. Eg
the type __int64 won't be present for x86, but it is for x64 (somehow
the same as you described it for the floating point types).
So I begun to use for a work-a-round of this to use the "mode"
attribute. The bad thing about it is, that it is in fact just usable
in typedefs (which should be IMHO explicit described in documentation
for it), as otherwise unexpected behavior can be noticed. Eg. the
definition 'typedef void * __attribute__ ((mode(SI)));' works as
expected, but is somebody would use here 'typedef void * __attribute__
((mode (SI))) [4];' leads not to the proper result. To let it work, we
need here two typedef instead of one. So the issue about this
"basetype_mode" attribute is to work-a-round in C/C++ FE parser, as
those attributes are associated with complete type declaration and not
in place (which seems to be related to problems in separating
attributes to current type or to declaration).
As Richard suggested, to have a __type_attribute__ , which gets
handled in place in declaration, would be here also a good fix, as
then the mode attribute could be used as documented.

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



More information about the Gcc-patches mailing list