attribute data structure rewrite

Joseph S. Myers jsm@polyomino.org.uk
Fri Sep 24 14:03:00 GMT 2004


On Thu, 23 Sep 2004, Geoffrey Keating wrote:

> That's a very good point.  I noticed from looking at the C front-end that an
> attribute can have as a 'value' any of:
> 
> 1. NULL
> 2. an IDENTIFIER
> 3. an expression
> 
> From that, I suspect that what's happening here is that 'N' is an identifier,
> so that rule matches in preference to treating 'N' as an expression and
> evaluating it.
> 
> I would really like to avoid case (2), or at least make sure that you can tell
> which of (2) or (3) any particular attribute should have.

That's one of the shift-reduce conflicts in the C parser, between the 
alternatives

attrib:
    /* empty */
                { $$ = NULL_TREE; }
        | any_word
                { $$ = build_tree_list ($1, NULL_TREE); }
        | any_word '(' IDENTIFIER ')'
                { $$ = build_tree_list ($1, build_tree_list (NULL_TREE, $3)); }
        | any_word '(' IDENTIFIER ',' nonnull_exprlist ')'
                { $$ = build_tree_list ($1, tree_cons (NULL_TREE, $3, $5)); }
        | any_word '(' exprlist ')'
                { $$ = build_tree_list ($1, $3); }
        ;

where an identifier might be parsed either way.  The enum case means that 
looking up the identifier to get an expression is needed for C as well as 
C++ (though of course independent from changes to datastructures).

Empty attributes are no trouble.  Many attributes have no arguments.  The 
identifier case applies (for example) to "mode" attributes, "cleanup" 
attributes (where it names a function) and some target-specific 
attributes.  The identifier followed by expression list case applies to 
format attributes.  The expression list case applies to many attributes, 
most taking one argument, some such as "nonnull" taking multiple 
arguments.  It should be well-defined for each attribute what sort of 
arguments it takes.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)



More information about the Gcc mailing list