My current aproach, checking for the eeprom attribute in the GCC calculated types, is not sufficient in some situations: struct y1 { int x; }; struct x { struct y1 y; }; typedef struct x ax __attribute__ ((eeprom)); void test1(ax* x) { x->y.x=1; } 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.
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. As this is quite complicated to handle for a programmer, I tried to do this automatically in the attribute handler: static tree m68hc05_handle_eeprom_attribute (tree * node, tree name, tree args ATTRIBUTE_UNUSED, int flags ATTRIBUTE_UNUSED, bool * no_add_attrs) { gcc_assert(TYPE_P(*node)); tree* type = (node); tree attr = tree_cons (name, args, NULL_TREE); tree* field; switch(TREE_CODE(*type)) { case ARRAY_TYPE: *type=copy_node(*type); decl_attributes(&TREE_TYPE(*type),attr,0); break; case RECORD_TYPE: case UNION_TYPE: case QUAL_UNION_TYPE: *type=copy_node(*type); for (field = &TYPE_FIELDS (*type); *field; field = &TREE_CHAIN (*field)) { decl_attributes(field,attr,0); } } return NULL_TREE; } This code is not correct, as it does not handle a lot of side effects and problems. If I neglect the problems (DWARF-2 output totally broken, pointer type warnings,...), it makes GCC pass the type information with the neccessary attribute information to the RTL expanders. 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). Any better ideas, how to solve this? mfg Martin Kögler