"Gordon Magnusson" writes:
> I read http://gcc.gnu.org/install/build.html but wasn't completely
> enlightened.
>
> If I'm building C and C++ (i.e. configuring with
> --enable-languages=c,c++) and I want to build gcc, g++, and libstdc++
> with -O3 instead of the default (which I believe is -g -O2
I read http://gcc.gnu.org/install/build.html but wasn't completely enlightened.
If I'm building C and C++ (i.e. configuring with
--enable-languages=c,c++) and I want to build gcc, g++, and libstdc++
with -O3 instead of the default (which I believe is -g -O2), is this
correct:
make "BOOT_CFLAGS=-O
Snapshot gcc-4.2-20081217 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081217/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Dec 17, 2008 at 7:14 AM, Ian Lance Taylor wrote:
> "Guo, Xuepeng" writes:
>
>> Thanks for your comments. It's not exactly the entire basic
>> block. It should be from the current RTL to the end of the current
>> basic block. As you know GCC will optimize "addl %ebx, %eax" to
>> "leal (%eb
On Wed, Dec 17, 2008 at 01:33:38PM +0700, Ha Luong wrote:
> Thanks for your guide. When I debugged the exe file or make it ran on
> 8548 board, the vmhaddshs makes the exe file hang out. Could I compile
> the source for 8540 (e500v1 instructions) only?
Sure. But evstdd{,x} are e500v1 instructions
"Guo, Xuepeng" writes:
> Thanks for your comments. It's not exactly the entire basic
> block. It should be from the current RTL to the end of the current
> basic block. As you know GCC will optimize "addl %ebx, %eax" to
> "leal (%ebx, %eax), %eax" to avoid the flag register dependency
> through a
Would be great if such a thing could be detected at configure time (i.e.
like missing mpfr.h headers are already detected), with some kind of a
gentle error message.
It wouldn't be detected until the target libs are built, since that's the
first time any 32-bit headers are needed.
Patches welco
VandeVondele Joost wrote:
>>> thats is on a standard linux (x86_64) box running opensuse 11.0, and a
>>> clean checkout. Is this a known problem?
>>
>> You haven't installed the 32-bit glibc devel package.
>
> Many thanks, that fixed it.
>
> Would be great if such a thing could be detected at con
thats is on a standard linux (x86_64) box running opensuse 11.0, and a
clean checkout. Is this a known problem?
You haven't installed the 32-bit glibc devel package.
Many thanks, that fixed it.
Would be great if such a thing could be detected at configure time (i.e.
like missing mpfr.h head
VandeVondele Joost wrote:
> Current trunk fails for me with
>
> thats is on a standard linux (x86_64) box running opensuse 11.0, and a
> clean checkout. Is this a known problem?
You haven't installed the 32-bit glibc devel package.
Andrew.
Hello, Dr. Uday Khedker:
I just found that emit_move_insn function can't be used in define_expand
pattern in the spim gcc4.0.2 platform. It will cause the Segmentation Fault.
Something like recursion happened.
I changed the define_expand "movsi" from:
(define_expand "movsi"
[(set
Current trunk fails for me with
/data04/vondele/gcc_trunk/obj/./gcc/xgcc
-B/data04/vondele/gcc_trunk/obj/./gcc/
-B/data04/vondele/gcc_trunk/build/x86_64-unknown-linux-gnu/bin/
-B/data04/vondele/gcc_trunk/build/x86_64-unknown-linux-gnu/lib/ -isystem
/data04/vondele/gcc_trunk/build/x86_64-unkno
12 matches
Mail list logo
