This is the mail archive of the gcc@gcc.gnu.org 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]

Machine attributes and language attributes


Currently, machine-dependent __attribute__s are handled via target
functions target.valid_decl_attribute and target.valid_type_attribute.  
These custom functions for each target determine whether an attribute is
valid; if so, it is attached to the type or decl by code in tree.c
(valid_machine_attribute).  Some of the targets use is_attribute_p, some
use custom parsing of names or may not handle the __ versions properly at
all.  This, and the corresponding handling for language-dependent
attributes, potentially allow for a target or language to have infinitely
many attributes, but none seem to use this flexibility.

I'd like to move to more uniformity with other attribute parsing, and have
targets and front ends provide instead a table of accepted attributes.  
This would contain function pointers for each attribute to handle that
attribute, but would lose the ability to have infinitely many attributes
for a target.  Does anyone see problems with such a change?

I'd also like to make all attributes (rather than just the target ones) go
on the attribute lists associated with decls and types in the tree
structure, so making attributes such as "format" work properly with
function pointers, etc., and allow for multiple attributes with the same
name but different arguments in those lists (rather than making a new
attribute override the arguments of the old one with the same name) -
which is entirely natural for representing the properties of "ngettext",
which should have two format_arg attributes.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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