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 address space is set
In http://gcc.gnu.org/ml/gcc/2005
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 which will increase memory
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
is entered, where if (safe_insn_predicate
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 happend.
Patches should go to gcc
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 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 backend
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
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
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 of
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 have the eeprom attribute added
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
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 code
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 to place
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
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:
15 matches
Mail list logo
