Hi,
Thanks for your guys advice. Now the gcc is built succeed first
time(without headers).
Now I have to keep going for newlib.
Thanks very much.
daniel tian writes:
> when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg.
> Here is the info:
>
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable
> insn:
> (insn 24 26 25
Hi Dave:
when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg.
Here is the info:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable insn:
(insn 24 26 25 3 ../../../rice-gcc-4.3.0
Yeah. You are right. I debuged the cc1 file with insight. It caused by
FUNCTION_VALUE macro which means the error happened in function
return. Because my target always return a SImode. I fixed it.
To debug the cc1 is always a good point to hack the bug.
But there are still other error exist. I st
daniel tian wrote:
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3':
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
> error: in emit_move_insn, at expr.c:3379
> make[2]: *** [_muldi3.o] Error 1
> gcc_assert (mode != BLKmode
> && (GET
Sorry, Dove, I just gotta the solution to debug the cc1. Dove told me
the link, and I just missed. Now I checked. So sorry, I ask the stupid
question again.
But the former question, I am still puzzled.
Thanks.
HｉDave:
I add the DI, SF, DFpattern. But when build the libgcc2.c, it
still cause errors.
The error information：
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in emit_move_insn, at expr.
daniel tian wrote:
> Another problem I found when hacking other port.
> Do I need to write SF, DF move operations?
> And basic arithmetic insn patterns like ADD, SUB in DImode?
>
> Because in CRX port (as I knew, there is no float point unit in this
> cpu), DI,SF,DF mode have 'move' operation. an
daniel tian wrote:
> Thanks. I am working for it now.
> But I have a question about how to debug the cc1 with libgcc1.c.
> because if I run the cc1 to build the libgcc2.c, lots of errors
> occurred.
>
> Run the cc1 with the command:
> ./cc1 -g -I../../rice-gcc-4.3.0/gcc
> -I../../rice-gcc-4.3.0/gc
Another problem I found when hacking other port.
Do I need to write SF, DF move operations?
And basic arithmetic insn patterns like ADD, SUB in DImode?
Because in CRX port (as I knew, there is no float point unit in this
cpu), DI,SF,DF mode have 'move' operation. and there are subtract,
add opera
Thanks. I am working for it now.
But I have a question about how to debug the cc1 with libgcc1.c.
because if I run the cc1 to build the libgcc2.c, lots of errors
occurred.
Run the cc1 with the command:
./cc1 -g -I../../rice-gcc-4.3.0/gcc
-I../../rice-gcc-4.3.0/gcc/../include
../../rice-gcc-4.3.0/g
daniel tian wrote:
> Hi:
>
> Do I have to write the DImode operations on my *.md target description
> file?
Yes. movMM must be implemented for all types that you want the compiler to
be able to handle at all; it's the only way it knows to move them around.
(Technically,
Hi:
Do I have to write the DImode operations on my *.md target description file?
Now I build my gcc first, there is an error on libgcc2.c. which is
an __muldi3 function.
The error information is:
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3:
../../../rice-gcc
13 matches
Mail list logo
