RFA: handling of mode attribute

[Richard Guenther]

On Sun, Sep 27, 2009 at 1:48 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2009/9/27 Richard Guenther <richard.guenther@gmail.com>:
>> On Sun, Sep 27, 2009 at 12:26 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>> 2009/9/27 Richard Guenther <richard.guenther@gmail.com>:
>>>> On Sun, Sep 27, 2009 at 9:57 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>>>>
>>>>> Hello Joseph,
>>>>>
>>>>> 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.
>>>>>
>>>>> As the "mode" attribute can't be changed, I rewrote my patch to use
>>>>> attribute "basetype_mode". Major difference between the "mode"
>>>>> attribute is, that it always associate to the base type, not to the
>>>>> current type declaration.
>>>>> Additionally it does not support vector types.
>>>>
>>>> I'm not really convinced that this will work (nor do I think this is the
>>>> best solution).
>>>
>>> Well, it seems to work as well (as the vector_size attribute works).
>>> The best way for sure would be to have ability in C/C++ FE to specify
>>> target specific types. But as the signed/unsigned/__complex__ checks
>>> aren't designed for this, and builtin-types are based to RID_...
>>> constants, it looks for me at the moment as the best way to go.
>>> The same mechanism would solve also the issues about float DFmode
>>> types, where some issues about the __complex__ extension are present,
>>> as typedefs can't get additional base type attributes.
>>>
>>>> Try to at least conver more cases in your testcase, like for example
>>>>
>>>>  const attr_int64 *p
>>>>
>>>> or
>>>>
>>>>  unsigned attr_int64 * const p,
>>>
>>> Well, I can add const/volatile pointer things here to test-case, if
>>> you think it is necessary. But I don't think that here something
>>> special will happen, as vector types would have then the same issues
>>> AFAICS.
>>>
>>>> I'd even suggest to run the compile torture with -Dint=__int32
>>>>
>>>> You only need the modes for types where you do not have a
>>>> keyword specifier, right?  Which means just TImode ints?  Wouldn't it make
>>>> sense to instead add new keywords to C that corresponds to that,
>>>> like __long_long_long?
>>>
>>> Hmm, well. TImode was the initial point, but even to express __int8,
>>> __int16, etc via this attribute can make sense here, as for example
>>> this prevents checks in gcc related to real 'long long' types.
>>
>> __int8 should map to char, __int16 to short.  I don't see the issue here.
>> After all if the result should behave as a builtin type it better should be one.
>>
>> Richard.
>>
>
> So I ran c-torture by defining int as 'int __attribute__
> ((basetype_mode(SI)))'. While running it there were no special failure
> by this (beside for those testcases using __attribute__ ((mode(XX)))
> on a int type (what was to be expecting).
>
> I extend the testcase to use some cases with const and volatile
> keywords for integer using basetype_mode attribute.

I think it's not a good solution.  I'd rather add new keywords here as
we have for the decimal floating-point types, or go the full way
of adding another attribute syntax that is applied to types the same
as qualifiers are, like __type__attribute__(()) or __qual__attribute_(()).

The present solution feels like the easiest hack possible to fit into
the current framework.

Richard.