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

[Martin Koegler <mkoegler at auto dot tuwien dot ac dot at>]

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