[cfe-commits] mips16/nomips16 attr

[reed kotler]

On 01/14/2013 02:31 PM, Dmitri Gribenko wrote:
> On Mon, Jan 14, 2013 at 8:42 AM, Reed Kotler <rkotler at mips.com> wrote:
>> Forget to say that I need to have this patch reviewd.
> +__attribute((nomips16)) int a; // expected-warning {{attribute only
> applies to functions}}
This appears to be an error now. On an older version at home it was just 
a warning.
I'll make it an error.

What surprised me is that there are some special rules in gcc related to 
mips16 and nomips16 when it comes to attribute merging. I'd prefer to 
sort this out later.

Here is essentially the issue.
Normally mips16 is an inhertitable attribute. However, if you add one of 
the attributes of
mips16 or nomips16 to a function, then all function definitions or 
declarations must also
have that attribute.

i.e.
void __attribute__((nomips16, otherattribute1)) foo();

void __attribute__((nomips16, otherattribute2)) foo();

is okay.

but in any case:

void __attribute((nomips16) foo();
void foo();

is not okay.

I want to bring this up with the gcc developers before mimicking this 
behavior in clang.
This is the ONLY place in gcc that I could find where this kind of 
semantics for attributes occurs.
This seems like a bug to me.





I had checked the other
rkotler at ubuntu-rkotler:~/testmips16$ mips-linux-gnu-gcc 
~/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c -S
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:5:1: 
error: 'foo32' redeclared with conflicting 'nomips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:6:1: 
error: 'foo16' redeclared with conflicting 'mips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:10:1: 
error: 'foo32_' redeclared with conflicting 'nomips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:11:1: 
error: 'foo16_' redeclared with conflicting 'mips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:14:1: 
error: 'foo32__' redeclared with conflicting 'mips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:14:1: 
error: 'foo32__' redeclared with conflicting 'nomips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:16:1: 
error: wrong number of arguments specified for 'nomips16' attribute
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:16:1: 
error: 'foo32' redeclared with conflicting 'nomips16' attributes
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:17:1: 
error: wrong number of arguments specified for 'mips16' attribute
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:19:1: 
error: wrong number of arguments specified for 'nomips16' attribute
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:20:1: 
error: wrong number of arguments specified for 'mips16' attribute
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_allowed.c:23:1: 
error: 'nomips16' attribute only applies to functions

>
> I am concerned by the fact that this is just a warning -- I would
> suggest to make it an error.  This is a new attribute, so there's no
> code abusing this attribute (we don't need to be compatible with it).
>
> What does gcc do?
>
> +void __attribute__((nomips16)) foo32(); // expected-warning {{unknown
> attribute 'nomips16' ignored}}
This is what gcc does. (here I'm compiling on linux x86).

rkotler at ubuntu-rkotler:~/testmips16$ gcc 
~/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_not_allowed.c -S
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_not_allowed.c:3: 
warning: ‘nomips16’ attribute directive ignored
/home/rkotler/workspace/llvmpb3/tools/clang/test/Sema/mips16_attr_not_allowed.c:4: 
warning: ‘mips16’ attribute directive ignored

> Same here.  What does gcc do in this case?  (I know that this behavior
> can not be changed without some refactoring.  But if GCC gives an
> error, we should, too.  So we would leave a comment in the test, or
> better -- do the required refactoring...)
>
> Dmitri
>