Re: comparing DejaGNU results
On Fri, 2006-06-02 at 16:26 -0700, Mike Stump wrote: > On Jun 2, 2006, at 11:08 AM, James Lemke wrote: > > I took a quick pass at implementing the comparisons in a more suitable > > lanugage. Run time is now a few seconds on both platforms. About the > > same as compare_tests on my old ibook/OSX and much faster on FC3. > > Since Ben and I seem interested in this, I think we should check in > this version. It seems portable enough and useful enough. Any > objections from the crowd? If not, I'll commit it to contrib/ on Monday. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Re: Solaris 2.8 build failure for 4.1.1 (libtool/libjava)
> My attempt to build on Solaris 2.8 with binutils 2.16.1 died with > > /bin/ksh ./libtool --tag=GCJ --mode=link > /remote/atg2/jbuck/solaris.tmp/411/gcc/gcj > -B/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava/ > -B/remote/atg2/jbuck/solaris.tmp/411/gcc/ > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava -g -O2 > -o jv-convert --main=gnu.gcj.convert.Convert -rpath > /u/jbuck/cvs.sol2/4.1.1/lib -shared-libgcc > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava/.libs > libgcj.la /remote/atg2/jbuck/solaris.tmp/411/gcc/gcj > -B/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava/ > -B/remote/atg2/jbuck/solaris.tmp/411/gcc/ -g -O2 -o .libs/jv-convert > --main=gnu.gcj.convert.Convert -shared-libgcc > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libjava/.libs > ./.libs/libgcj.so > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libstdc++-v3/src > -L/remote/atg2/jbuck/solaris.tmp/411/sparc-sun-solaris2.8/libstdc++-v3/src/ >.libs -lpthread -lrt -ldl -L/remote/atg2/jbuck/solaris.tmp/411/./gcc > -L/usr/ccs/lib -lgcc_s -lgcc_s -Wl,--rpath -Wl,/u/jbuck/cvs.sol2/4.1.1/lib > /u/jbuck/gnu.sol2/bin/ld: unrecognized option '-Wl,-rpath' > /u/jbuck/gnu.sol2/bin/ld: use the --help option for usage information > collect2: ld returned 1 exit status I cannot reproduce with the same setup: /bin/ksh ./libtool --tag=GCJ --mode=link /opt/build/eric/gcc-4_1-branch/gcc/gcj-B/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava/ -B/opt/build/eric/gcc-4_1-branch/gcc/ -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /opt/build/eric/gcc-4_1-branch/lib -shared-libgcc -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava/.libs libgcj.la /opt/build/eric/gcc-4_1-branch/gcc/gcj -B/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava/ -B/opt/build/eric/gcc-4_1-branch/gcc/ -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava/.libs ./.libs/libgcj.so -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libstdc++-v3/src -L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/opt/build/eric/gcc-4_1-branch/./gcc -L/usr/ccs/lib -lgcc_s -lgcc_s -Wl,--rpath -Wl,/opt/build/eric/gcc-4_1-branch/lib creating jv-convert gax% uname -a SunOS gax 5.8 Generic_117350-25 sun4u sparc SUNW,Sun-Fire-V250 gax% gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /home/eric/svn/gcc-4_1-branch/configure --prefix=/opt/build/eric/gcc-4_1-branch --with-as=/opt/build/eric/local/bin/as --with-ld=/opt/build/eric/local/bin/ld --with-gmp=/opt/build/eric/local --with-mpfr=/opt/build/eric/local --with-local-prefix=/opt/build/eric/local --enable-languages=c,c++,objc,obj-c++,java,fortran Thread model: posix gcc version 4.1.2 20060603 (prerelease) gax% /opt/build/eric/local/bin/as --version GNU assembler 2.16.1 20060126 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.8'. gax% /opt/build/eric/local/bin/ld --version GNU ld version 2.16.1 20060126 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. > It's GNU ld version 2.16.1. This is strange; I would have expected the > linker to get just -rpath: -Wl should tell gcj to pass the following > option to the linker. Rather weird indeed. Can you reproduce it manually by replaying the command? -- Eric Botcazou
[wwwdocs] Re: ftp://ftp.eos.hokudai.ac.jp/pub/gcc/
On Sat, 22 Apr 2006, Gerald Pfeifer wrote: > ftp://ftp.eos.hokudai.ac.jp/pub/gcc/ is listed as an official mirror > site of gcc.gnu.org at http://gcc.gnu.org/mirrors.html. > > However, for several weeks, DNS queries for ftp.eos.hokudai.ac.jp have > provided MX records, but no A nor CNAME records, which means that the > server/service is not reachable. > > Can you please advise how to proceed? Shall we remove this server from > our mirror list, or is this a temporary issue you expect to be resolved > soon? I now removed ftp://ftp.eos.hokudai.ac.jp/pub/gcc/ from the GCC mirror list, by means of the patch below. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.173 diff -u -3 -p -r1.173 mirrors.html --- mirrors.html28 Apr 2006 11:28:36 - 1.173 +++ mirrors.html3 Jun 2006 16:24:28 - @@ -37,7 +37,6 @@ Key fingerprint = 90AA 4704 69D3 965A 87 Germany: ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/";>ftp.mpi-sb.mpg.de, thanks to ftpadmin at mpi-sb.mpg dot de Greece: ftp://ftp.ntua.gr/pub/gnu/gcc/";>ftp.ntua.gr, thanks to ftpadm at ntua dot gr Japan: ftp://ftp.dti.ad.jp/pub/lang/gcc/";>ftp.dti.ad.jp, thanks to IWAIZAKO Takahiro (ftp-admin at dti dot ad dot jp) -Japan: ftp://ftp.eos.hokudai.ac.jp/pub/gcc/";>ftp.eos.hokudai.ac.jp, thanks to ftp-admin at eos dot hokudai dot ac dot jp Japan: ftp://ftp.iij.ad.jp/pub/gcc/";>ftp.iij.ad.jp, thanks to ftp at ftp dot iij dot ad dot jp Japan: ftp://ring.etl.go.jp/pub/lang/egcs/";>ring.etl.go.jp The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan Cristiaan van Winkel (jc at ATComputing dot nl)
Re: GCC SC request about ecj
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes: Per> Note this does not mean importing Eclispe code into the gcc source or Per> release tree. We need to decide on a practical way to have people Per> grab a compatible version of ecj. My short-term plan is to make a branch in gcc svn, and commit what I've got. I'll also post my current ecj patch somewhere, along with instructions on how to set it up. (It is easy.) Longer term, I think the Eclipse JDT guys have been talking about doing separate ecj jar releases. So, ideally we would have the needed gcj-related patches upstream and people could simply download these jars or check out sources from eclipse cvs. I haven't sent my ecj patch upstream yet since I wanted to iron out most of the issues before proposing it. libgcj builds with the new compiler, but there is still some runtime bug. I suspect there's a compiler bug somewhere; I haven't investigated yet. I have successfully built a libgcj based on the classpath generics branch though -- pretty fun. This required a number of changes in libgcj. I suppose we could import classpath generics branch and merge it to the new branch I make, and proceed from there. Tom
gcc-4.2-20060603 is now available
Snapshot gcc-4.2-20060603 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060603/ 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/trunk revision 114346 You'll find: gcc-4.2-20060603.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060603.tar.bz2 C front end and core compiler gcc-ada-4.2-20060603.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060603.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060603.tar.bz2 C++ front end and runtime gcc-java-4.2-20060603.tar.bz2 Java front end and runtime gcc-objc-4.2-20060603.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060603.tar.bz2The GCC testsuite Diffs from 4.2-20060527 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Release Schedule issues and doubts
Hi, First if anyone has a problem with this email please tell me instead of just hating me, this email is not to make anyone hate me worse but instead try get some attention to the problem with our current planned release schedule [1]. The current release plan as I understand it (please correct me if I am wrong): stage 1: 2 months to get big (infrastructure) changes in stage 2: 2 months to get smaller (non-infrastructure) in stage 3: 2 months to get other bug fixes (and maybe add new ports) in branch: release once regressions are fixed Now once the branch is created, there is nothing in the release schedule what happens so I am going on past experiences (though this is were the problem is). Once either stage 3 happens and then again once the branch happens, the development of regression and bug fixes go down and people start working on their own projects again. Now at this point, we could say this because we are all volunteers working on GCC which has happened when someone reports a regression and figures out who caused it and the person who caused it goes and basically says that. Now we have a policy for regression causing patches but it does not get followed for regressions that don't show up in the testsuite. The rationale of this policy is keep the release schedule on track. Now for the fix I have in mind (which might or might not work): If you are a maintainer of an area and you approve a patch which causes a regression in that new code, you have to fix it or have the person whos patch it was fix it or face losing your maintainer-ship if it is not handled 2 months after the regression was (openly) reported (which means either to the gcc email lists or to bugzilla). If the patch exposes a latent bug in some other code, the person who approved the code is let off the hook and maintainers of that area would be required to look into the problem if the patch's own is not able to figure out the fix. - The rational behind this proposal is to make the release schedule of GCC faster and less plain-full at the end when all the regressions have piled up. Also it keeps GCC maintainership more of alive value rather than just sitting back and not fixing problems. We have currently at least 10 regressions which have been reported and publicly mentioned which patch caused the regression for at least 2 months. Yes getting these fix will not allow us to branch 4.2 but a lot more regressions are already publicly mentioned which patch caused it. I know this is a tough problem to deal with but we need to try to solve this even if that means not doing any more releases. The other problem I see currently is not getting patches reviewed in a timely fashion but that is for a different email and it looks like it is getting fixed. Thanks, Andrew Pinski [1] http://gcc.gnu.org/develop.html
