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]

Re: Machine attributes and language attributes


On Tue, 3 Jul 2001, Mark Mitchell wrote:

> > Yes, a table of finite size initialized by the target, with a pointer to
> > it in the target structure, but without arbitrary limits; the common code
> > would then simply look through three tables (common attributes, language
> > ones, machine ones), each having either a size stored or an end marker.
> 
> Your plan is a good one.

Does anyone wish to comment on my questions in
<URL:http://gcc.gnu.org/ml/gcc/2001-06/msg01961.html> - asking whether a
single means for targets to insert attributes on decls (the present
INSERT_ATTRIBUTES, but moved to the target structure) is sufficient and
can replace PRAGMA_INSERT_ATTRIBUTES and SET_DEFAULT_DECL_ATTRIBUTES
(which would simplify the code - SET_DEFAULT_DECL_ATTRIBUTES is called
from many places, INSERT_ATTRIBUTES from only one) - which would be one of
the preliminary self-contained bits of cleanup in this area?  Or to review
<URL:http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00085.html>?

(The next cleanup stage will probably be to add documentation for how
attributes are stored.  Logically, DECL_MACHINE_ATTRIBUTES would be
renamed to DECL_ATTRIBUTES at that point as well, but I'll leave that
until it can actually store non-machine-attributes and the tables are
present, so that there can be a default version of
FUNCTION_ATTRIBUTE_INLINABLE_P that looks sensible in ignoring
non-machine-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]