Re: RFA: handling of mode attribute

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, Sep 27, 2009 at 9:57 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2009/9/26 Joseph S. Myers <joseph@codesourcery.com>:
>> On Sat, 26 Sep 2009, Kai Tietz wrote:
>>
>>> This patch makes sure, that the attribute mode is getting associated
>>> with the base type (as described in documentation, too). So the mode
>>> attribute can be used as type-specifier in code, too (eg ?'int
>>> __attribute__ ((mode(DI))) value[5];' ).
>>> The old attribute mode handler has treating of pointer type, but if I
>>> read documentation I don't find a single word about this. Also I
>>> searched testsuite and couldn't find any example of this. To allow
>>> proper association of this attribute, I removed the bogus pointer type
>>> handling. If this is necessary for some cases I didn't found, we could
>>> add a special attribute (eg. ptrmode) for handling and checking this.
>>> The only usecase I found in gcc's source is in vmsdbgout.c:typedef
>>> struct fibdef* __fibdef_ptr32 __attribute__ (( mode (SI) ));
>>
>> The handling is not bogus. ?There may not be tests for it, but it's a
>> relevant feature for any target where pointers can have multiple widths
>> (such as IA64).
>>
>> Following "Attribute Syntax" in the manual will tell you how to apply the
>> attribute in complex declarations. ?Normally you will define a typedef of
>> the simplest type to which you are applying the mode, and then define
>> other types in terms of it, and if your issues is built-in typedefs then
>> see bug 32187 regarding making them act more like keywords.
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
>>
>
> 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).

Try to at least conver more cases in your testcase, like for example

 const attr_int64 *p

or

 unsigned attr_int64 * const p,

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?

Thanks,
Richard.

> 2009-09-27 ?Kai Tietz ?<kai.tietz@onevision.com>
>
> ? ? ? ?* c-common.c (c_common_attribute_table) Add new
> ? ? ? ?attribute name basetype_mode.
> ? ? ? ?(handle_basetype_mode_attribute): New handler.
> ? ? ? ?* doc/extend.texi: Add documentation for attribute
> ? ? ? ?basetype_mode.
>
> 2009-09-27 ?Kai Tietz ?<kai.tietz@onevision.com>
>
> ? ? ? ?* gcc.c-torture/execute/attribute_mode.c: New testcase.
>
>
> Tested this patch on i686-pc-mingw32, x86_64-pc-mingw32, i686-pc-linux.
>
> Ok for apply?
>
> Cheers,
> Kai
>
> PS: ?Even a back-port to 4.4 could make sense to provide a possibility
> to solve PR/32187.
> --
> | ?(\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>