Re: attribute data structure rewrite

[Gabriel Dos Reis <gdr@cs.tamu.edu>]

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