This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]