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
