> From: Martin Koegler <[EMAIL PROTECTED]>
>> On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
>>> For the MEM_AREA for the tree, I have eliminated many explicit set operation
>>> of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
>>>
>>> For certain tree codes, t
On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
> > For the MEM_AREA for the tree, I have eliminated many explicit set operation
> > of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
> >
> > For certain tree codes, the build{1,2,3,4} automatically generate the
> From: Martin Koegler <[EMAIL PROTECTED]>
>> On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
>>> Martin Koegler wrote:
>>> I have redone the implementation of the eeprom attribute in my prototype.
>>> It is now a cleaner solution, but requires larger changes in the core,
>>> but the c
On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
> > Martin Koegler wrote:
> > I have redone the implementation of the eeprom attribute in my prototype.
> > It is now a cleaner solution, but requires larger changes in the core,
> > but the changes in the core should not affect any backe
> Martin Koegler wrote:
> I have redone the implementation of the eeprom attribute in my prototype.
> It is now a cleaner solution, but requires larger changes in the core,
> but the changes in the core should not affect any backend/frontend, if
> it does not uses them (except a missing case in tre
On Apr 27, 2005, at 1:04 PM, Martin Koegler wrote:
@@ -2070,6 +2078,7 @@
result = build3 (CALL_EXPR, TREE_TYPE (fntype),
function, coerced_params, NULL_TREE);
+ EXPR_MEM_AREA (result) = DEFAULT_MEM_AREA;
TREE_SIDE_EFFECTS (result) = 1;
In the future, please use -p to diff.
> From: Paul Schlie <[EMAIL PROTECTED]>
> ...
> (with respect to: -Wwrite-strings, I would have thought that the option,
> although presently depreciated and disabled by default, would only have
> enabled writes to string literal references be specified at the language
> front-end level, but not
> From: Zack Weinberg <[EMAIL PROTECTED]>
>> James E Wilson <[EMAIL PROTECTED]> writes:
>>
>>> unnecessary, and error prone (as evidenced by string literal memory
>>> references not being properly identified as READONLY, although their
>>> equivalent array representations are treated properly
> 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
James E Wilson <[EMAIL PROTECTED]> writes:
>> unnecessary, and error prone (as evidenced by string literal memory
>> references not being properly identified as READONLY, although their
>> equivalent array representations are treated properly for example?)
>
> If true, that sounds like a bug
> 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
Martin Koegler wrote:
arg 1 >>
So, how to change this function? As a MEM_EXPR may only be a DECL or a
COMPONENT_REF,
storing a indriect_ref of a plus_expr is also not valid. This is, why I had to
change
the other functions.
There is a var_decl here inside the indirect_ref. Will using
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
Martin,
I think that the AVR people would very much appreciate if you would report
occasionally on your progresses concerning your realization of the different
address space issue on your personal HC05 port. (In my opionion, the lack for
support of different memory spaces is the key weakness of
On Wed, Apr 20, 2005 at 06:42:08PM -0700, James E Wilson wrote:
> 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 co
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 hav
19 matches
Mail list logo
