Re: RFA: handling of mode attribute

[Richard Guenther <richard dot guenther at gmail dot 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.