typedef struct x ax __attribute__ ((eeprom)); void test1(ax* x)
One possible solution is to change your syntax. eeprom is supposed to be an attribute that applies to a decl. You are using a trick here to apply it to a type via a typedef, which takes advantage of the fact that typedefs are implemented internally as decls. So, maybe you should stop using tricks, and apply the attribute to the decl where it belongs. e.g something like "struct x __attribute__ ((eprom)) * x". This also lets you eliminate the TYPE_DECL hackery in your attribute handler. This requires that the attribute work a bit like the const type qualifier, since we can have pointers to eeprom and eeprom pointers, and they need to be handled differently.
In this case, while expanding x->y.x=1, the type of x->y is integer. Even the expression, which the MEM_EXPR gets, contains not the information, that the eeprom attribute is present. Similar problems occure, if pointers to elements of structures (or pointer to array elements) are used.
Presumably the info is there somewhere in the exander. It should simply be a matter of keeping track of it and carrying it along. Maybe this works better with the attribute on the decl instead of on the type?
The solution would be to add also for the base type of an array the eeprom attribute. Additonally all elements of structures and unions must also have the eeprom attribute added.
Bad idea. Far too much hackery.
Another alternative would be to implement backend specific qualifiers (like volatile) in the tree representation. This would need large changes in GCC (at each location, where a new tree expression is created, these qualifiers would also need to be set).
Yes, this seems reasonable. This seems to agree with what I mentioned at the top, and also seems to agree with the proposed address spaces extension that Joseph Myers pointed at.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
