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.
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.
I follow the instructions from this
website:http://gcc.gnu.org/wiki/DebuggingGCC.
but things is not going to be correct.
bacause when cc1 build libgcc2.c, some error occurred. I have debug
cc1. But If I have to build libgcc2.c, some complex parameter have to
pass.
I don't know what's xgcc is, bu
Thanks.
But how to debug cc1. Because now I port the gcc to my RISC target.
But when build the libgcc2.c. Some error occurred. So i have to debug
it.
Any advice about how to debug?
gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf
2009/9/28 Basile STARYNKEVITCH :
> daniel tian wrote:
>>
>> Thanks.
>> But how to debug cc1. Because now I port the gcc to my RISC target.
>> But when build the libgcc2.c. Some error occurred. So i have to debug
>> it.
>> Any advice about how to debug?
>
>
> Start gdb from the build directory (mor
daniel tian wrote:
> 2009/9/28 Basile STARYNKEVITCH :
>> daniel tian wrote:
>>> Thanks.
>>> But how to debug cc1. Because now I port the gcc to my RISC target.
>>> But when build the libgcc2.c. Some error occurred. So i have to debug
>>> it.
>>> Any advice about how to debug?
>>
>> Start gdb from
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
daniel tian wrote:
> And this is the debug problem. And hope somebody can give me a clue.
> command:
> gdb --args $(./xgcc -###
> -B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
> -B/usr/local/cross/rice-elf/rice-elf/bin/
> -B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
> /usr/
Hello all,
I doing a port for a 32bit target for GCC 4.4.0. I am getting the
following error:
rd_er.c:19: error: insn does not satisfy its constraints:
(insn 5 35 34 2 rd_er.c:8 (set (reg:SI 16 r0)
(plus:SI (reg:SI 16 r0)
(reg:SI 2 d2))) 57 {addsi3} (expr_list:REG_EQUAL (plus:
In preparation for the final merge into mainline. I need to test
the branch on various platforms. Richi is currently testing on
i586, ppc, ppc64, ia64, s390, s390x.
If anyone has free cycles I would appreciate results from other
ELF-capable targets.
$ svn co svn://gcc.gnu.org/svn/gcc/branches/l
Output of src/config.guess:
i686-pc-mingw32
gcc -v ouput:
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.4.1/configure --prefix=/e/gcc/install
Thread model: win32
gcc version 4.4.1 (GCC)
Setup: msys 1.0.11 with autoconfig and automake and MinGW gcc 4.4.0
compiler, make,
On Mon, Sep 28, 2009 at 8:58 AM, Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from other
> E
On Mon, Sep 28, 2009 at 12:21, H.J. Lu wrote:
> I think you should check the required libelf features in configure script:
It's checked. See configure.ac.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41336
Thanks. I will mark it fixed.
> FWTW, libelf in Fedora 11 works fine.
Yes, that's
On Fri, 25 Sep 2009, Vincent Lefevre wrote:
> [Cc to the gcc mailing-list]
>
> On 2009-09-25 02:18:55 +0200, Vincent Lefevre wrote:
> > Also, as EXP_BITS is the full (biased) exponent size, it seems that
> > the real.c comment is buggy (27 -> 26).
>
> Looking at the history:
>
> -#define EXP_BITS
On 09/28/2009 07:25 AM, Mohamed Shafi wrote:
Hope someone suggests me a solution.
The solution is almost certainly something involving the
TARGET_SECONDARY_RELOAD hook. You need to inform reload that it's going
to need some scratch registers in order to perform the operation.
It's been a l
Diego Novillo wrote:
On Mon, Sep 28, 2009 at 12:21, H.J. Lu wrote:
FWTW, libelf in Fedora 11 works fine.
Yes, that's what prompted the new check and requirement for libelf 0.8.12.
Unfortunately, libelf in Debian testing as of last Saturday, 19 UTC, is
libelf 0.8.10 - so no contributions
I posted the following question about GCC and Solaris locale support to
both gcc-help and libstdc++:
http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html
It was recommended I try darwin, or ieee_1003.1-2001 for
--enable-clocale when building GCC. None of these suggestions worked.
See here for de
On Mon, Sep 28, 2009 at 11:58:30AM -0400, Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from
On Mon, Sep 28, 2009 at 14:30, Jack Howarth wrote:
> Has this patch been tested on non-elf targets like darwin
> yet to make sure they still build? If not, is the proposed
> merge patch against current gcc trunk available somewhere for
> testing on darwin? It would be nice to get ahead of the
On 09/28/2009 11:30 AM, Jack Howarth wrote:
If not, is the proposed
merge patch against current gcc trunk available somewhere for
testing on darwin?
It's the top of the LTO branch.
r~
I will be sending the final 15 patches to bring all the
functionality from the LTO branch. I tried to divide the patches
along maintainer lines, but there are some overlaps
- C FE
Adds processing of -flto and -fwhopr.
- C++ FE
Adds a langhook used by need_assembler_name_p to hand
+(define_predicate "no_pic_small_symbol"
+ (match_code "symbol_ref")
+{
+ return !flag_pic & SYMBOL_REF_SMALL_P (op);
+})
s/&/&&/
Index: gcc/config/lm32/sfp-machine.h
Index: gcc/config/lm32/crti.S
Index: gcc/config/lm32/lib1funcs.S
Index: gcc/config/lm32/crtn.S
Index: gcc/config/lm32/arithme
On 09/28/2009 03:51 PM, Jon Beniston wrote:
(define_insn "*ashlsi3_const"
[(set (match_operand:SI 0 "register_operand" "=R1")
(ashift:SI (match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "const_5bit_operand" "i")))
(clobber (match_scratch:SI 3
On Mon, 28 Sep 2009, Diego Novillo wrote:
> - libiberty
> I need help with this one. When the linker plugin is
> enabled (if GCC is configured to use gold), LTO can
> detect LTO objects inside archives via the callbacks it
> gets from the linker. Since the linker plugin i
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
On Mon, 28 Sep 2009, Diego Novillo wrote:
> I will be sending the final 15 patches to bring all the
> functionality from the LTO branch. I tried to divide the patches
> along maintainer lines, but there are some overlaps
I'll go through the individual patches later, but a general comment:
You s
> gets from the linker. Since the linker plugin is a shared
> object, and it uses libiberty functions, it needs to use a
> shared libiberty.
Why can't they just link a static libiberty?
Hi all:
I have found something strange when scheduling instructions.
considering following piece of code:
-c start
int func(float x)
{
int r = 0;
r = (*(unsigned int*)&x) >> 23;
return r;
}
-c e
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
Thanks Eric Fisher, got the answer, Please ignore this message.
--
Best Regards.
30 matches
Mail list logo
