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

[Paul Schlie <schlie at comcast dot net>]

> James E Wilson wrote:
> ...
> 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.

- Might it be possible to introduce and use by convention a new macro which
  will always wrap a new pointer in a mem expression with attributes copied
  from the previous mem/symbol's reference enforced?
  
  (Thereby hopefully making it more convenient and less error prone? Ideally
  possibly supporting at least a few generic target definable attributes
  which are correspondingly preserved for all variable, literal-data, and
  function result and parameter object declaration references by default.)
 
> ...
> 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.

- One of the things that's been eluding me, is that I can't seem to find
  where literal string constant mem references aren't being properly
  declared and/or preserved as READONLY/unchanging references, resulting
  in MEM_READONLY_P failing to identify them; although literal char array
  references, which seem logically equivalent, do seem to be properly
  declared/preserved?

  Any insight would be appreciated, -paul-