[RFC] Attributes on types

[Svein E. Seldal]

Hi,

I am looking at extending gcc's features by adding the ability to 
declare attributes on types. I.e. Making persistent attributes that 
stick to the type decleration and will give warnings/errors if any 
assignments across types are made:

1)   int var __attribute__((a));

2)   int *ptr = &var;     // Should give warning because ptr's
                          // type does not contain the attribute 'a'
3)   int __attribute__((a)) *ptr = &var;
                          // Valid because of the attribute decl.
The first problem that arises from this syntax the fact that some 
attributes will work against the object, while obviously other 
attributes will target the type decleration involved with the object.

I have two proposals:

1a)  int var __attribute__((a, weak));

'weak' will address the object 'var', while 'a' indicates type 'int 
__attribute__((a))'. Based by the design of the attribute 'a', it will 
tag itself to the decleration not the object.

1b)  int __attribute__((a)) var __attribute__((weak));

As long as 'a' is listed prior to the object name, its a part of the 
type. It has better readability. And it might be simpler to implement, 
as the two attribute categories are not mixed.

In the 3rd line, please note that the attribute must be present before 
the '*'. If not, intermixed pointers to pointers (and so on and so 
forth) with or without attribute a will not be possible.

Other changes would include:
- typedef must support attributes
I have been digging hard into tree.h and the various c-xxx files, 
without any immediate enlightenments. Does anyone have any suggestion on 
where I should look and start working on this, please? If I can get this 
to work it would be a part of a /major/ feature enhancement for gcc and 
especially the AVR port.

The main point of this is to make GCC able to use different memory 
access methods based on the usage of these attributes. The AVR has more 
than one memory space; code and data space, and one needs to use 
completely different opcodes to access the code space than compared to 
the data space.

Regards,
Svein