This is the mail archive of the
mailing list for the GCC project.
Re: How to fix AVR progmem type attribute?
- From: Marek Michalkiewicz <marekm at amelek dot gda dot pl>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Marek Michalkiewicz <marekm at amelek dot gda dot pl>, gcc at gcc dot gnu dot org, denisc at overta dot ru
- Date: Fri, 24 May 2002 22:44:29 +0200 (CEST)
- Subject: Re: How to fix AVR progmem type attribute?
> In general, the cases where target attributes apply to both decls and
> types should at best have an implementation with table-driven attributes
> that is bug-compatible with the old implementation - but it would be a
> good idea to go over the exact meaning of the attributes, write testcases
> for them, and make sure that the implementation does exactly what's
> intended. (Table-driven attributes are at least as flexible as the old
> system; there may be cases where the exact semantics wanted can be better
> expressed with them than they were expressed previously.)
Could you help me, and write such a bug-compatible implementation?
I admit I don't know these parts of GCC well enough (as I'm mainly
optimizing assembler code generation in the back-end). Please...
You are much more likely to do it correctly on first try than I am :)
config/avr/avr.c (avr_progmem_p) appears to check for attributes in
decls as well as types, but it stopped working...
> The attribute in question also seems to be lacking any documentation.
True, but it worked in 3.0, so existing 3.0 source can be considered some
form of documentation... (Yes, I know, not sufficient. That's probably
why we have this issue now...)
Basically it is supposed to work like this: if the type has the "progmem"
attribute, any variables of that type, or arrays consisting of elements
of that type, or arrays of arrays of ... should get that attribute too.