This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Machine attributes and language attributes
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Machine attributes and language attributes
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Wed, 4 Jul 2001 12:36:48 +0100 (BST)
- cc: Joern Rennecke <amylaar at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
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