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/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
