This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
- From: James E Wilson <wilson at specifixinc dot com>
- To: Martin Koegler <mkoegler at auto dot tuwien dot ac dot at>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 20 Apr 2005 18:42:08 -0700
- Subject: Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
- References: <20050419091513.GA29005@ahab.auto.tuwien.ac.at>
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