Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)

[James E Wilson <wilson at specifixinc dot com>]

Martin Koegler wrote:
> Placing variables in a specfic section is only a part of the problem.

I am aware of that.  There are already many targets that have special 
handling for section attributes, that result in different code being 
generated when a section attribute is present.  Mostly these have to do 
with generating different kinds of address and/or addressing modes 
though, and your case sounds more complicated.  Handling different kinds 
of addresses can be done by setting SYMBOL_REF_FLAGS on a symbol_ref.

> My prototype for the m68hc05 does currently the following (based on GCC 4.1):

It looks like a reasonable plan.

It relies on MEM_EXPR always being set, which may not be true.  But if 
there are places creating MEMs from decls without setting MEM_EXPR, then 
they probably should be fixed.  MEMs created for things like spills to 
stack slots may not have MEM_EXPR set, but then they can't possibly have 
the eeprom attribute either, so that is OK.

This could be a maintenance problem if other developers make changes and 
forget to keep the MEM_EXPR fields accurate.  The more we use the 
MEM_EXPR fields, the less of a problem this will be.

> +  if (expr == NULL_TREE)
> +    expr = t;

This is setting MEM_EXPR to a type.

I see that this does work by accident, because MEM_EXPR can be either a 
decl or a COMPONENT_REF, and all of the code that excludes 
COMPONENT_REFs will also happen to excludes types.

I don't think it is a good idea in general though.  Overloading a field 
to have either an expression or a type may result in confusion later.

Presumably this is only a problem because some MEMs don't have the 
MEM_EXPR field set, in which case a better solution is to find the 
places that forget to set it and fix them.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com