This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add named address support to GCC 4.5

On Apr 20, 2009, at 2:51 AM, Joseph S. Myers wrote:
On Fri, 2009-04-17 at 09:58 -0700, Chris Lattner wrote:
Out of curiosity, what is the motivation for making these actual
keywords? Clang has support for address spaces as well, and clients
that use them just install a predefine that expands to an attribute.
For example, cellspu could install:

#define __ea __attribute__((address_space(1)))
Which enables, stuff like:

int __ea *P;

Won't the attribute apply to the whole type? We want to be able to have
a multiplicity of types like:

	int __ea *p;
	int * __ea p;

No, attribute address_space is parsed as part of type-qualifier- list (and
apply to types, not decls), which means that things like:

int __attribute__((address_space(1))) * __attribute__((address_space(2)))
*__attribute__((address_space(3))) P;

Do what you'd expect.

The attribute syntax rules for GNU C ("Attribute Syntax" in the manual)
mean that an attribute among the initial declaration specifiers generally
applies to the declaration as a whole rather than acting like a type
qualifier. If you want a particular attribute to act like a type
qualifier there you have to do some elaborate type reconstruction, as done
for vector_size attributes. No doubt that reconstruction code could be
reused, but it's still a significant complication.

In general, experience shows that having the implementation not follow the
terminology and concepts of the specification is liable to cause trouble
and lead to an inaccurate implementation. In this case, TR 18037
describes address spaces as type qualifiers, so the implementation is most
likely to be accurate if they go through the code paths for qualifiers
instead of those for attributes.

Hi Joseph,

Your argument basically boils down to "GCC doesn't have existing clean infrastructure for attributes to be type qualifiers". I won't debate you on that, you know better than I do. However, this is an implementation consideration - both approaches correctly implement TR 18037.

However, adding target-specific keywords adds its own set of complexities. It might be worthwhile to consider which is more ugly: extending the general functionality and usefulness of attributes, or adding a specific hack for address spaces.

Attributes that act like type specifiers are useful for more than just address spaces. In Objective-C 2.0 for example, this is needed for Garbage collection, to indicate whether (potentially multi-level) pointers are weak or strong references, etc. This hangs very nicely on a clean and simple framework.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]