> From: James E Wilson <[EMAIL PROTECTED]>
>> On Fri, 2005-04-22 at 04:58, Paul Schlie wrote:
>> Thanks. After going through the code, it's even further not clear why
>> STRING_CST string literal data references treated differently than
>> static const char array literal data references to begin wi
On Fri, 2005-04-22 at 04:58, Paul Schlie wrote:
> Thanks. After going through the code, it's even further not clear why
> STRING_CST string literal data references treated differently than
> static const char array literal data references to begin with?
> Why is this necessary?
Why is what necessa
On Fri, 2005-04-22 at 15:56, Paul Schlie wrote:
> - Why are string literal character arrays not constructed and expanded as
> character array literals are?
They are constructed and expanded differently, because, obviously, they
are different things. I don't understand the point of this question
> From: James E Wilson <[EMAIL PROTECTED]>
>> - 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 t
Paul Schlie wrote:
- 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?
This is already an easy function call. I don't see how adding a macro
mak
> 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
