On Thu, Jul 07, 2005 at 09:45:04PM -0400, Paul Schlie wrote:
> James E Wilson writes:
> >> On Sun, 2005-07-03 at 07:31, Martin Koegler wrote:
> >> * need to rewrite recursivly each element of type (which my contain
> >> structures, unions, ...) if a addre
On Fri, Jul 01, 2005 at 06:49:18PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I continued to work on the support for named address spaces in GCC.
>
> An possible issue is the effect on gcc memory usage and compile time. I
> see you increased the size of MEM rtl w
I continued to work on the support for named address spaces in GCC. I
managed to move much of the managing code for the namespace attribute
into the create funtions of tree nodes, so in most cases, only the
language frontends need to assign and check the named address spaces.
I moved to creation o
On Wed, May 04, 2005 at 01:02:18AM -0700, Richard Henderson wrote:
> On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> > For that instruction, instantiate_virtual_regs_in_insn
> > enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
> >
On Wed, May 04, 2005 at 01:02:18AM -0700, Richard Henderson wrote:
> On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> > For that instruction, instantiate_virtual_regs_in_insn
> > enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
> >
On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I notice, that your last change in function.c forgets virtual
> >registers in the RTL in some conditions. In older version (the last I used
> >was 20050412),
> >this has not happ
I notice, that your last change in function.c forgets virtual
registers in the RTL in some conditions. In older version (the last I used was
20050412),
this has not happend.
In 01.sibling, I have the instruction:
(insn 10 8 12 1 (set (mem/f/i:HI (plus:HI (reg/f:HI 23 virtual-stack-vars)
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
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 co
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 tree_copy_mem_area, which
will caus
On Mon, Apr 25, 2005 at 03:22:31PM +, Joseph S. Myers wrote:
> On Mon, 25 Apr 2005, Martin Koegler wrote:
>
> > The solution would be to add also for the base type of an array the
> > eeprom attribute. Additonally all elements of structures and unions must
> > also h
My current aproach, checking for the eeprom attribute in the GCC calculated
types,
is not sufficient in some situations:
struct y1 {
int x;
};
struct x {
struct y1 y;
};
typedef struct x ax __attribute__ ((eeprom));
void test1(ax* x)
{
x->y.x=1;
}
In this case, while expanding x->y.x=1, the type o
I discovered an out of bound access in reload.c, which can happen under
certain conditions (bug 18877).
The problem is, that in decompose (reload.c) assumes, that true_regnum
returns only value < 0 for pseudo registers, which is in certain
situations not true (all available register in use and a
On Sat, Apr 23, 2005 at 02:26:54PM -0400, Paul Schlie wrote:
> - sound's good, and a natural generalization of current mem ref attributes.
>
> (However ideally, function parameter and result value references would need
> to be similarly qualify-able in order to enable the proper attributes to
>
After some discussion, how to create transparent access to different
memory transparently, I propose the following solution:
We change the GCC core to store the type of each memory expression
in the MEM rtx. Backends can use this type information to create a diffent RTL
or output a different assem
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 r
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
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 att
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_attribut
I'm working on a GCC port and hit the error
x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362
while compiling
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
with dwarf-2 debugging information. The eeprom attribute is defined so:
s
20 matches
Mail list logo
