This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[RFC] Attributes on types
- From: "Svein E. Seldal" <svein dot seldal at solidas dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 13 May 2004 21:18:01 +0200
- Subject: [RFC] Attributes on types
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