> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>> 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.
- Got it, I think. Sorry for being dense. So in summary:
- an attribute may be defined, such as:
#define ROM __attribute__("ROM");
- and used following the above referenced ""Attribute Syntax", as
either a variable, or function parameter declaration/implementation:
int ROM x = 3;
int foo (int ROM y)
where the parameter's attribute is visible when ever that parameter
is used as an operand within the function tree, and correspondingly
during rtl/template matching; and further if there's an attribute
mismatch between the function argument and it's parameter, the
compiler will warn? (is there any way to force an error instead?)
And just to double check with respect to your other comments:
>> char y[] = ROM "some string"
>
> We know that being able to control sections of string constants is
> desirable ... 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.
- understood.
>> 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.
- except that when GCC treats it as a static constant value, accessed during
run-time to initialized the declared variable, just as strings and arrays
are; it must also have the same attribute the back end is relying on
to identify such references as needing to be accessed differently than
references to other variables are. (so suspect it would be appropriate to
be able to define programmatically an attribute which may be attached to
all such references to initializing data not just strings if not optimized
away, although agree it's not necessary to specify each individually)
Thanks again, and apologize for my confusion.
-paul-
