Cross compiler build instructions - PowerPC

2011-03-22 Thread Rohit Arul Raj
Hello All, I have been trying to build a cross compiler (for PowerPC) on x86_64 linux host. I followed the build procedure given in the link below: http://www.eglibc.org/archives/patches/msg00078.html The build instructions in the link works perfectly fine with the following revisions: GCC v4.1.

gcc-4.4-20110322 is now available

2011-03-22 Thread gccadmin
Snapshot gcc-4.4-20110322 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110322/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Target library disabling at toplevel

2011-03-22 Thread Hans-Peter Nilsson
On Tue, 22 Mar 2011, Joseph S. Myers wrote: > On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote: > > For MMIX, the issues I mentioned at > > are > > presumably fixed, but pragmatically the interest level for > > Those look like newlib-target iss

Re: debugging

2011-03-22 Thread Ian Lance Taylor
Mike Stump writes: > So, I was trying to debug some stuff with the top of the tree on a suse linux > x86_64 box and got: > > (gdb) p mode > Unhandled dwarf expression opcode 0xf3 > > which I don't find entertaining. I know I _could_ install a new gdb, and > most likely this would fix the probl

Re: debugging

2011-03-22 Thread Andrew Pinski
On Tue, Mar 22, 2011 at 3:15 PM, Mike Stump wrote: > So, I was trying to debug some stuff with the top of the tree on a suse linux > x86_64 box and got: > > (gdb) p mode > Unhandled dwarf expression opcode 0xf3 > > which I don't find entertaining.  I know I _could_ install a new gdb, and > most

debugging

2011-03-22 Thread Mike Stump
So, I was trying to debug some stuff with the top of the tree on a suse linux x86_64 box and got: (gdb) p mode Unhandled dwarf expression opcode 0xf3 which I don't find entertaining. I know I _could_ install a new gdb, and most likely this would fix the problem, but, I don't want to do that ri

Re: Target library disabling at toplevel

2011-03-22 Thread Ian Lance Taylor
"Joseph S. Myers" writes: > Why do a great many targets disable libgcj by default in the toplevel > configure.ac? I believe that it's just a hack: libgcj doesn't build on the target, but gcc/java does. Disabling libgcj lets the gcc configure/make complete in a natural way. unsupported_languag

Re: Target library disabling at toplevel

2011-03-22 Thread Joseph S. Myers
On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote: > > CRIS > > A closer inspection will show that it's only the subtarget > cris-*-aout. IIRC support for this target was removed for GCC, > it'd probably be a good idea to do the same here at the > top-level for the other projects (newlib, binutils,

Re: Target library disabling at toplevel

2011-03-22 Thread Hans-Peter Nilsson
> Date: Tue, 22 Mar 2011 19:51:38 + (UTC) > From: "Joseph S. Myers" > Why do a great many targets disable libgcj by default in the toplevel > configure.ac? Maybe because the right way, through unsupported_languages, never caught on and there never was a global conversion? :-) > Where GCC p

Target library disabling at toplevel

2011-03-22 Thread Joseph S. Myers
Why do a great many targets disable libgcj by default in the toplevel configure.ac? Where GCC provides a runtime library for a given language, I'd think the compiler isn't particularly useful without the library - and so if the compiler is built for that language, an attempt should be made to b

Re: RFC: Representing vector lane load/store operations

2011-03-22 Thread Richard Sandiford
Richard Guenther writes: > Simple. Just make them registers anyway (I did that in the past > when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P > on the decl. OK, thanks, I'll give that a go. TBH, I'm still hopeful we can do without it, because we do seem to cope quite well as thi

Re: segmentation fault with fclose

2011-03-22 Thread Jeremy Hall
Try the "comp.lang.c.moderated" group for C and C library questions. You probably meant: if( fp != NULL ) fclose( fp ); That is, "!= NULL" rather than "== NULL".

Re: RFC: Representing vector lane load/store operations

2011-03-22 Thread Richard Guenther
On Tue, Mar 22, 2011 at 5:52 PM, Richard Sandiford wrote: > This is an RFC about adding gimple and optab support for things like > ARM's load-lane and store-lane instructions.  It builds on an earlier > discussion between Ira and Julian, with the aim of allowing these > instructions to be used by

RFC: Representing vector lane load/store operations

2011-03-22 Thread Richard Sandiford
This is an RFC about adding gimple and optab support for things like ARM's load-lane and store-lane instructions. It builds on an earlier discussion between Ira and Julian, with the aim of allowing these instructions to be used by the vectoriser. These instructions operate on N vector registers o

Re: Hints for backporting gcc 4.5 powerpc fix to gcc 4.4.3?

2011-03-22 Thread David Edelsohn
On Tue, Mar 22, 2011 at 9:25 AM, Simon Baldwin wrote: > I'm currently trying to backport a small part of gcc 4.5 r151729 to > gcc 4.4.3.  This revision fixes a problem in powerpc code generation > that leads to gcc not using lmw/stmw instructions in function prologue > and epilogues, where it coul

Hints for backporting gcc 4.5 powerpc fix to gcc 4.4.3?

2011-03-22 Thread Simon Baldwin
I'm currently trying to backport a small part of gcc 4.5 r151729 to gcc 4.4.3. This revision fixes a problem in powerpc code generation that leads to gcc not using lmw/stmw instructions in function prologue and epilogues, where it could otherwise validly use them. On the face of things, the centr