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
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
Am Dienstag, 19. April 2005 00:30 schrieb James E Wilson:
> Björn Haase wrote:
> > In case that one should not use machine specific atttributes, *is* there
> > a standard way for GCC how to implement different address spaces?
>
> Use section attributes to force functions/variables into different
>
James E Wilson wrote:
>Björn Haase wrote:
>>In case that one should not use machine specific atttributes, *is*
>>there a standard way for GCC how to implement different address spaces?
>
>Use section attributes to force functions/variables into different sections,
>and then use linker scripts t
Martin Koegler wrote:
I added to the i386 version the following code (using a unmodified gcc for the rest):
With this change, I can reproduce the problem.
I noticed that I get a failure for all types, not just array types.
This is different than what you described earlier, but perhaps the
differe
Björn Haase wrote:
In case that one should not use machine specific atttributes, *is* there a
standard way for GCC how to implement different address spaces?
Use section attributes to force functions/variables into different
sections, and then use linker scripts to place different sections into
James E Wilson wrote
>You shouldn't be trying to build your own types in a machine dependent
>attribute handler function. The compiler's type system is determined by
>front-ends mainly, and some middle-end infrastructure, and isn't your domain
>to mess with. This stuff is subject to change, at
On Thu, Apr 14, 2005 at 03:02:36PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I changed the attribute handler to only return NULL_TREE in any case, but
> >the result is still the same (using the same gcc core).
>
> But you are still creating the types in the attribute function right?
James E Wilson wrote:
I tried grepping the sources, and I see this same code appears in the
avr and ip2k ports. That gives me a way to try to reproduce the
problem with FSF sources. Avr doesn't support DWARF2, and ip2k is
being obsoleted because it is unmaintained.
As a side note, the AVR por
Martin Koegler wrote:
I changed the attribute handler to only return NULL_TREE in any case, but
the result is still the same (using the same gcc core).
But you are still creating the types in the attribute function right?
If so, that is probably why you still have a problem.
You mentioned that th
On Wed, Apr 13, 2005 at 01:55:07PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> > tree type = TREE_TYPE (*node);
> > tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
> > tree newtype = build_type_attribute_variant (type, attr);
> > TYPE_MAIN_
Martin Koegler wrote:
tree type = TREE_TYPE (*node);
tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
tree newtype = build_type_attribute_variant (type, attr);
TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
TREE_TYPE (*node) = ne
14 matches
Mail list logo
