gcc-4.3-20100228 is now available
Snapshot gcc-4.3-20100228 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100228/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 157127 You'll find: gcc-4.3-20100228.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100228.tar.bz2 C front end and core compiler gcc-ada-4.3-20100228.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100228.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100228.tar.bz2 C++ front end and runtime gcc-java-4.3-20100228.tar.bz2 Java front end and runtime gcc-objc-4.3-20100228.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100228.tar.bz2The GCC testsuite Diffs from 4.3-20100221 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
why multiple libiberty directories
While looking at PR42308 and trying to understand why the make check is leaky and starts to call the system compiler instead of the xgcc during a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed that we seem to build libiberty both at the toplevel and within the multilib subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively). Is this expected behavior as I don't see anything other than libiberty duplicated in this fashion? I am wondering if this duplication of the libiberty build might have something to do with the inappropriate CC assignment during a toplevel 'make -k check' for these two targets. Any advice for trying to pin down the origin of this testsuite harness bug would be most appreciated. Jack
Re: why multiple libiberty directories
Jack Howarth writes: >While looking at PR42308 and trying to understand why the make check > is leaky and starts to call the system compiler instead of the xgcc during > a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed > that we seem to build libiberty both at the toplevel and within the multilib > subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively). > Is this expected behavior as I don't see anything other than libiberty > duplicated in this fashion? The toplevel libiberty is the host library, the others are the target libraries. There is another one in the build-$build directory which is the build library. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: why multiple libiberty directories
On Mon, 1 Mar 2010, Andreas Schwab wrote: > Jack Howarth writes: > > >While looking at PR42308 and trying to understand why the make check > > is leaky and starts to call the system compiler instead of the xgcc during > > a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I > > noticed > > that we seem to build libiberty both at the toplevel and within the multilib > > subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively). > > Is this expected behavior as I don't see anything other than libiberty > > duplicated in this fashion? > > The toplevel libiberty is the host library, the others are the target > libraries. There is another one in the build-$build directory which is > the build library. But I've previously noted that target libiberty seems completely useless; libstdc++-v3 uses a demangler source file but the target libiberty.a (with a mixture of licenses some of which are unsuitable for target library code) doesn't get used as far as I can tell. -- Joseph S. Myers jos...@codesourcery.com
Re: why multiple libiberty directories
On Mon, Mar 01, 2010 at 02:31:52AM +0100, Andreas Schwab wrote: > Jack Howarth writes: > > >While looking at PR42308 and trying to understand why the make check > > is leaky and starts to call the system compiler instead of the xgcc during > > a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I > > noticed > > that we seem to build libiberty both at the toplevel and within the multilib > > subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively). > > Is this expected behavior as I don't see anything other than libiberty > > duplicated in this fashion? > > The toplevel libiberty is the host library, the others are the target > libraries. There is another one in the build-$build directory which is > the build library. > I find on i686-apple-darwin10 that the problem can be recreated with... make -k check-libiberty executed in the toplevel of the build directory. Interestingly, if I comment out... # Flags to pass to a recursive make. FLAGS_TO_PASS = \ "AR=$(AR)" \ "AR_FLAGS=$(AR_FLAGS)" \ # "CC=$(CC)" \ "CFLAGS=$(CFLAGS)" \ in the generated Makefile in darwin_objdir/libiberty, the correct, xgcc, compiler is used for those tests. Somehow the recursive make is broken for libiberty and is silently using the system compiler. Jack
Re: why multiple libiberty directories
On Mon, 1 Mar 2010, Jack Howarth wrote: > Somehow the recursive make is broken for libiberty and is silently using > the system compiler. > Jack I believe this is PR29404. IIRC, in addition to libiberty, other recursive "make check"s fail too due to using the system (stage1) compiler. --Kaveh
