Propagating attributes for to structure elements (needed for different address spaces)

[James E Wilson]

Martin Koegler wrote:
> 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