This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extension compatibility policy
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Giovanni Bajo <giovannibajo at libero dot it>, Mike Hearn <mike at navi dot cx>, gcc at gcc dot gnu dot org
- Date: Wed, 2 Mar 2005 02:18:11 +0000 (UTC)
- Subject: Re: Extension compatibility policy
- References: <BE4A7D78.94D3%schlie@comcast.net>
On Tue, 1 Mar 2005, Paul Schlie wrote:
> Might it be possible to alternatively add an attribute symbol hook so that a
> target may easily define an arbitrary target specific named attribute which
> may be utilized without having to patch the parser, etc. to do so?
>
> Thereby one could easily define a ROM and/or PMEM attribute hypothetically
> for not only __FUNCTION__, but any arbitrary declared type or parameter
> declaration, preserved through to the back end to aid in target specific
> code generation and/or memory allocation?
The insert_attributes hook *already exists*. It can insert arbitrary
attributes on arbitrary declarations completely under target control.
You can have target command-line options to control what it does. You can
have target pragmas that control what it does. And of course source code
can explicitly use attributes in any place documented in "Attribute
Syntax". I was simply suggesting filling a lacuna by applying this hook
to implicit __func__ declarations as well as to explicit declarations.
> PMEM __FUNCTION__
This syntax doesn't make sense and you haven't explained what you want it
to mean. But you can have a pragma or command line option to put
__FUNCTION__ in a special section if you want.
> ROM static const x[] = "some string"
You can already apply attributes to variables if you want.
> char y[] = ROM "some string"
We know that being able to control sections of string constants is
desirable. Bug 192 concerns one case. Attributes in addition to
command-line options is a natural extension. (I noted some implementation
issues in <http://gcc.gnu.org/ml/gcc/2001-06/msg01653.html>, though
without considering the issue of suitable syntax for attributes on the
string constants themselves which doesn't involve syntactic ambiguity for
C or C++; it may be best not to allow attributes on individual strings,
only a strings_section attribute to control the section of strings within
an object or function definition.)
> struct {int a; int b;} z = PMEM {5312, 3421};
This syntax makes even less sense. A brace-enclosed initializer is not an
object! If z has static storage duration, put the attribute on z. If it
doesn't, how it is initialized is a matter of compiler optimization and
specifying attributes of where a copy of the initializer might go doesn't
seem to make sense.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)