This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: attribute data structure rewrite
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: gcc List <gcc at gcc dot gnu dot org>
- Date: 23 Sep 2004 19:47:15 -0500
- Subject: Re: attribute data structure rewrite
- Organization: Texas A&M University, Department of Computer Science
- References: <FA388EC7-0DBB-11D9-8B78-000A95B1F520@apple.com>
Geoffrey Keating <geoffk@apple.com> writes:
| As a precondition for other compile speed improvements, I've been
| rewriting the way that GCC represents attributes. The result is a
| medium-size patch that touches every language and many targets (a
| surprising number of targets don't define any special attributes at
| all).
|
| The basic principle is that DECL_ATTRIBUTES and TREE_ATTRIBUTES now
| point to an attribute_list:
|
| /* A structure representing 'attributes' on a DECL or TYPE node.
| Each attribute has a NAME (an IDENTIFIER_NODE) and possibly a
| VALUE. */
| struct one_attribute GTY(())
| {
| tree name;
| tree value;
| };
|
| /* A counted list of attributes. */
| struct attribute_list_s GTY(())
| {
| attribute_count n_attributes;
| /* There are 16 bits free here. */
| struct one_attribute GTY((length ("%h.n_attributes"))) attribs[1];
| };
|
| This has many benefits, mostly flowing from the fact that it's not a
| TREE_LIST any more.
|
| 1. Do we think this would be acceptable for stage 3, or should I make
| a branch?
I would argue that such a change should be accepted, at this phase of
stage 3; now. As:
(1) it addresses compile-time/memory regression;
(2) it is no less interesting no less useful that the various cleanup
we've been having, in particular in the C++ front-end.
I would even take a further step and ask an official position about
how we how attributes to play with language rules.
Currently, the compiler fails on any of the following fails,
complaining about non-"integral constant expression"-ness, which is
pure nonense.
const int N = 4;
struct S {
enum { M = 4 };
float x __attibute__((__aligned__(N)));
float x __attibute__((__aligned__(M)));
};
template<typename T, int N>
struct buffer {
typedef char U[sizeof(T)];
U data __attribute__((__aligned__(N)));
};
They should be accepted.
-- Gaby