Re: GCC 4.0 RC1 Available
Kaveh R. Ghazi wrote: 2005-04-12 Paolo Bonzini [EMAIL PROTECTED] * acx.m4 (ACX_PROG_GNAT): Remove stray break. OK for 4.0.0. Mark, When this patch went into 4.0, Paolo didn't regenerate the top level configure, although the ChangeLog claims he did: http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00842.html Would you care to take care of that? (I am travelling, and don't have much time online.) If so, I'd be very appreciative. The patch should also be applied to mainline, since the break problem exists there too. I'm not sure why it wasn't, but perhaps your OK for 4.0.0 didn't specify mainline and Paolo was being conservative. I think we should fix it there also. Yes, indeed. The patch is certainly OK for mainline as well. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
Would you care to take care of that? (I am travelling, and don't have much time online.) If so, I'd be very appreciative. Done. I'll apply to mainline soon. Paolo
Re: GCC 4.0 RC1 Available
Would you care to take care of that? (I am travelling, and don't have much time online.) If so, I'd be very appreciative. Sure but... Done. I'll apply to mainline soon. Paolo Aleady done. Thanks Paolo! :-) -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC 4.0 RC1 Available
Geoffrey Keating writes: Andrew Haley [EMAIL PROTECTED] writes: Ranjit Mathew writes: Geoffrey Keating wrote: [...] which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at [...] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. It might be helpful to put your libjava.log somewhere or if all the Java failures seem similar, to post the error messages around the FAIL lines from your libjava.log. # of unexpected failures5 powerpc-apple-darwin7.8.0 dejagnu HEAD So, this is unrepro, as far as I can see. It seems like this could be the CLASSPATH issue; did you have gcj installed on your system? I didn't. I don't think it was installed. Unfortunately, the machine isn't online at the moment, so I can't check. Anyway, Eric Botcazou seems to think the problems is fixed on Solaris, so I hope the problem is fixed on Darwin too. Andrew.
Re: GCC 4.0 RC1 Available
Andrew Haley [EMAIL PROTECTED] writes: Ranjit Mathew writes: Geoffrey Keating wrote: [...] which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at [...] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. It might be helpful to put your libjava.log somewhere or if all the Java failures seem similar, to post the error messages around the FAIL lines from your libjava.log. # of unexpected failures5 powerpc-apple-darwin7.8.0 dejagnu HEAD So, this is unrepro, as far as I can see. It seems like this could be the CLASSPATH issue; did you have gcj installed on your system? I didn't.
Re: GCC 4.0 RC1 Available
Ian Lance Taylor wrote: touch testsuite_wchar_t Does anybody else see this? I imagine this would be fairly annoying for some people. This actually relates to the same V3 testsuite stuff that I've been trying to solve on the mainline. Fundamentally, this happens because test-related stuff is being done outside of DejaGNU. In particular, make install depends on make all (Automake does that), and make all recursively does make all in the V3 testsuite directory, which ought to be a no-op (testsuite things should only happen with make check), but is not a no-op because the V3 testsuite wants libv3test.a, and that gets built as part of make all, again via Automake. We could, in theory, fix this, in that it's only testsuite stuff that would have to change, not code. But, it's a big change, and not fully done or settled on mainline. So, we'll fix it in 4.0.1, at the earliest. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
Did this get resolved? We found that PowerPC/Darwin and SPARC/Solaris have regressed the same way. Andrew should be looking at the failures on the Darwin side. Eric Tom, I presume there was a very good reason for installing such Eric a potentially destabilizing patch a few days before the Eric prerelease? What amount of testing did it undergo before being Eric backported? More than the usual; I ran the test suite on two architectures (x86 and ppc, the latter a multilib build), plus I tested it against eclipse and jonas. OK. That doesn't cover many architectures/OSes though. -- Eric Botcazou
Re: GCC 4.0 RC1 Available
Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin machine at hand? Yes, but I cannot reproduce the failure. See http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00990.html Andrew.
Re: GCC 4.0 RC1 Available
On Wed, 13 Apr 2005, Paul Jarc wrote:
gcc/doc/install.texi still mentions gcc 3.5 in a few places.
Fixed thus (and a similar reference in cpp.texi). It passes make info,
make dvi and install.texi2html. Applied to mainline and 4.0 branch
(as a doc patch for which the branch is still open).
In checking for any similar references which should be fixed I noticed
that config/arm/libgcc-bpabi.ver defines a GCC_3.5 symbol version, but
it's probably rather too late to change that and may not be desirable to
change it anyway.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
2005-04-14 Joseph S. Myers [EMAIL PROTECTED]
* doc/cpp.texi, doc/install.texi: Change references to GCC 3.5 to
refer to 4.0.
diff -rupN GCC.orig/gcc/doc/cpp.texi GCC/gcc/doc/cpp.texi
--- GCC.orig/gcc/doc/cpp.texi 2005-03-06 13:02:34.0 +
+++ GCC/gcc/doc/cpp.texi2005-04-14 17:09:20.0 +
@@ -4045,7 +4045,7 @@ they generally represent bugs in the sna
@item -I- deprecated
-This option has been deprecated in 3.5. @option{-iquote} is meant to
+This option has been deprecated in 4.0. @option{-iquote} is meant to
replace the need for this option.
@item Order of evaluation of @samp{#} and @samp{##} operators
diff -rupN GCC.orig/gcc/doc/install.texi GCC/gcc/doc/install.texi
--- GCC.orig/gcc/doc/install.texi 2005-04-06 17:01:03.0 +
+++ GCC/gcc/doc/install.texi2005-04-14 17:09:12.0 +
@@ -442,7 +442,7 @@ Please refer to the @uref{http://gcc.gnu
for information on how to obtain [EMAIL PROTECTED]
The full distribution includes the C, C++, Objective-C, Fortran 77, Fortran
-(in case of GCC 3.5 and later), Java, and Ada (in case of GCC 3.1 and later)
+(in case of GCC 4.0 and later), Java, and Ada (in case of GCC 3.1 and later)
compilers. The full distribution also includes runtime libraries for C++,
Objective-C, Fortran 77, Fortran, and Java. In GCC 3.0 and later versions,
GNU compiler testsuites are also included in the full distribution.
@@ -2685,7 +2685,7 @@ configuring if you want a model other th
TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
default scheduling model is desired.
-As of GCC 3.5, GCC uses the UNIX 95 namespace for HP-UX 10.10
+As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10
through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later.
This namespace change might cause problems when bootstrapping with
an earlier version of GCC or the HP compiler as essentially the same
@@ -2726,10 +2726,10 @@ the 3-stage comparison test to fail duri
You should be able to continue by saying @samp{make all} after getting
the failure from @samp{make bootstrap}.
-GCC 3.5 requires CVS binutils as of April 28, 2004 or later. Earlier
+GCC 4.0 requires CVS binutils as of April 28, 2004 or later. Earlier
versions require binutils 2.8 or later.
-The C++ ABI has changed incompatibly in GCC 3.5. COMDAT subspaces are
+The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces are
used for one-only code and data. This resolves many of the previous
problems in using C++ on this target. However, the ABI is not compatible
with the one implemented under HP-UX 11 using secondary definitions.
@@ -2802,7 +2802,7 @@ This has been been reported to sometimes
binutils and [EMAIL PROTECTED]
GCC 3.0 through 3.2 require binutils 2.11 or above. GCC 3.3 through
-GCC 3.5 require binutils 2.14 or later.
+GCC 4.0 require binutils 2.14 or later.
Although the HP assembler can be used for an initial build, it shouldn't
be used with any languages other than C and perhaps Fortran due to its
Re: GCC 4.0 RC1 Available
Joseph S. Myers wrote: On Wed, 13 Apr 2005, Paul Jarc wrote: gcc/doc/install.texi still mentions gcc 3.5 in a few places. Fixed thus (and a similar reference in cpp.texi). It passes make info, make dvi and install.texi2html. Applied to mainline and 4.0 branch (as a doc patch for which the branch is still open). Thanks! In checking for any similar references which should be fixed I noticed that config/arm/libgcc-bpabi.ver defines a GCC_3.5 symbol version, but it's probably rather too late to change that and may not be desirable to change it anyway. Correct. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
On Thu, 14 Apr 2005, Joseph S. Myers wrote: gcc/doc/install.texi still mentions gcc 3.5 in a few places. Fixed thus (and a similar reference in cpp.texi). It passes make info, make dvi and install.texi2html. Applied to mainline and 4.0 branch (as a doc patch for which the branch is still open). Fortunately I just checked my mailbox, because I was going to the same. Well, in that case I'll take the other open doc issue. ;-) Gerald
Re: GCC 4.0 RC1 Available
On Apr 13, 2005, at 1:41 AM, Ranjit Mathew wrote: Exception in thread main java.lang.RuntimeException: test failed:5 No stacktrace available FAIL: Array_3 -O3 execution - bytecode-native test This one is expected I think, though not XFAILed (it fails only at -O3). BTW, you keep getting No stacktrace available everywhere - is addr2line from binutils not present somewhere in your default executable search path? On darwin, addr2line does not exist, yes I know this is weird but binutils is not ported really to mach-o. If anyone wants to do it, go for it. -- Pinski
Re: GCC 4.0 RC1 Available
Andrew Haley writes: Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin machine at hand? Surprisingly enough, yes. But I'm having trouble finding a compiler binary for it. It's now building. I don't have a very fast Darwin box, so it probably won't get fixed today. Andrew.
Re: GCC 4.0 RC1 Available
My Darwin build of 4.0 failed in libstdc++: ibsupc++convenience.a -lm -lm -lc -Wl,-single_module -Wl,-flat_namespace -install_name /Users/aph/gcc/install/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.4 ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__textcoal_nt) from section (__TEXT,__eh_frame) relocation entry (4)) ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__textcoal_nt) from section (__TEXT,__eh_frame) relocation entry (8)) ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__textcoal_nt) from section (__TEXT,__eh_frame) relocation entry (12)) This is with a fresh download of Xcode. Andrew.
Re: GCC 4.0 RC1 Available
gcc/doc/install.texi still mentions gcc 3.5 in a few places. paul
Re: GCC 4.0 RC1 Available
Eric Ugh. Not very surprising, given that a jumbo patch landed by Eric that time: Did this get resolved? Eric Tom, I presume there was a very good reason for installing such Eric a potentially destabilizing patch a few days before the Eric prerelease? What amount of testing did it undergo before being Eric backported? More than the usual; I ran the test suite on two architectures (x86 and ppc, the latter a multilib build), plus I tested it against eclipse and jonas. Tom
Re: GCC 4.0 RC1 Available
Kaveh R. Ghazi wrote:
Nathanael removed the surrounding for-stmt but left
the break inside the if-stmt.
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html
I think it is enough to remove it. bash does not complain if it finds a
stray break, it seems.
Ok to commit to mainline (and src)? Mark, if you decide to fix it in
4.0, I think it is better that you do it yourself also because of the
time zone difference (I'll be out of home this evening, which is
morning/afternoon for you).
Paolo
2005-04-12 Paolo Bonzini [EMAIL PROTECTED]
* configure: Regenerate.
config:
2005-04-12 Paolo Bonzini [EMAIL PROTECTED]
* acx.m4 (ACX_PROG_GNAT): Remove stray break.
Index: acx.m4
===
RCS file: /cvs/gcc/gcc/config/acx.m4,v
retrieving revision 1.11
diff -p -u -r1.11 acx.m4
--- acx.m4 28 Feb 2005 13:25:55 - 1.11
+++ acx.m4 12 Apr 2005 07:04:16 -
@@ -212,7 +212,6 @@ acx_cv_cc_gcc_supports_ada=no
errors=`(${CC} -c conftest.adb) 21 || echo failure`
if test x$errors = x test -f conftest.$ac_objext; then
acx_cv_cc_gcc_supports_ada=yes
- break
fi
rm -f conftest.*])
Re: GCC 4.0 RC1 Available
c,ada show no unexpected failure on x86 and x86_64 (SuSE 9.2), great! A minor thing: I configured with c,ada only (no C++) on x86 and x86_64-linux and got http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00791.html http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00790.html [...] === libmudflap tests === Running target unix FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx compilation failed to produce executable [...] On surface, it looks like libmudflap is running C++ tests even when C++ isn't there. Should I open a PR? Laurent
Re: GCC 4.0 RC1 Available
FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler (3.3.3 based) I get no such issue in configure: checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... gnatbind checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... no The following languages will be built: c,ada *** This configuration is not supported in the following subdirectories: target-libstdc++-v3 target-libgfortran target-libffi target-boehm-gc target-zlib target-libjava zlib fastjar target-libobjc (Any other directories should still work fine.) Ada then builds and install fine. Laurent On Mon, 2005-04-11 at 14:48 -0400, Kaveh R. Ghazi wrote: --- here --- checking whether compiler driver understands Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only meaningful in a `for', `while', or `until' loop yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 ... looks like there is a break without the (usual?) for around it. Georg On closer inspection, I'm seeing the same thing on 4.0 and mainline. I believe the offending break was added to config/acx.m4 here: http://gcc.gnu.org/ml/gcc/2004-02/msg00755.html Although it seems to be that Paolo simply moved existing code from gcc/aclocal.m4 to config/acx.m4. Going back through aclocal.m4, the original breakage (no pun intended) occurred here when Nathanael removed the surrounding for-stmt but left the break inside the if-stmt. http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html Nathanael, can you please take a look?
Re: GCC 4.0 RC1 Available
Mark Mitchell wrote: Marcus Meissner wrote: Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem triggering in ncurses (all platforms) PR/20929 triggers a miscompilation of Mozilla. Any chance of getting this m68k specific one added to the RC2 list? 18421 ICE in reload_cse_simplify_operands, at postreload.c:391 Those are all on the Wiki page as possible patches for an RC2. Thanks, -- Joel Sherrill, Ph.D. Director of Research Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.0 RC1 Available
Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin machine at hand? Surprisingly enough, yes. But I'm having trouble finding a compiler binary for it. Andrew.
Re: GCC 4.0 RC1 Available
On 12/04/2005, at 6:31 AM, Andrew Haley wrote: Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin machine at hand? Surprisingly enough, yes. But I'm having trouble finding a compiler binary for it. Assuming it's a powerpc Darwin machine, you can get compiler binaries from http://developer.apple.com/tools/download/. smime.p7s Description: S/MIME cryptographic signature
Re: GCC 4.0 RC1 Available
On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote: Geoffrey Keating wrote: [...] which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at [...] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. It might be helpful to put your libjava.log somewhere or if all the Java failures seem similar, to post the error messages around the FAIL lines from your libjava.log. Many seem to be NoClassDefFoundError exceptions. Some examples of those plus all the unusual cases are: Setting LD_LIBRARY_PATH to .:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/ ./libjava/.libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc:.:/ Volumes/Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/./ libjava/.libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc:.:/Volumes/ Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/./libjava/ .libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc Exception in thread main java.lang.RuntimeException: test failed:5 No stacktrace available FAIL: Array_3 -O3 execution - bytecode-native test UNTESTED: Array_3 -O3 output - bytecode-native test ... Testing class `Class_1'... Exception in thread main java.lang.NoClassDefFoundError: C No stacktrace available FAIL: Class_1 execution - gij test ... Exception in thread Thread-1 Exception in thread Thread-2 Exception in thread Thread-3 Exception in thread Thread-4 java.lang.NoClassDefFoundError: SyncTest No stacktrace available java.lang.NoClassDefFoundError: SyncTest No stacktrace available java.lang.NoClassDefFoundError: SyncTest No stacktrace available java.lang.NoClassDefFoundError: SyncTest No stacktrace available fail: 0 FAIL: SyncTest execution - gij test UNTESTED: SyncTest output - gij test ... PASS: stringconst2 execution - gij test FAIL: stringconst2 output - gij test I can mail the full log to anyone interested, but I don't think the list needs it. smime.p7s Description: S/MIME cryptographic signature
Re: GCC 4.0 RC1 Available
On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote: Geoffrey Keating wrote: [...] which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at [...] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410. It might be helpful to put your libjava.log somewhere or if all the Java failures seem similar, to post the error messages around the FAIL lines from your libjava.log. Many seem to be NoClassDefFoundError exceptions. Some examples of those plus all the unusual cases are: What I don't understand is why does this only show up in 4.0 branch and not the mainline. -- Pinski
Re: GCC 4.0 RC1 Available
Hi,
On Mon, 2005-04-11 at 15:33 -0700, Per Bothner wrote:
Printing getClass().getClassLoader() yields:
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Note the urls=[file:./]. Looks like it's ignoring the CLASSPATH
environment option.
I tried to replicate this issue with some simple example, but all my
tries just work as expected. Could you give some information about your
system? How can I replicate this? (what do I download, how do I
compile/run it) What does the following program output for you?
public class CL
{
public static void main(String[] args) throws Exception
{
System.out.println(ClassLoader.getSystemClassLoader());
}
}
$ gcj -C CL.java
$ CLASSPATH=.:/:/usr:/random gij CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/,file:/usr/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
So on my system (Debian GNU/Linux testing/x86) setting CLASSPATH seems
to work as expected. (Note that /random gets dropped since it doesn't
exist.)
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Re: GCC 4.0 RC1 Available
On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Re: GCC 4.0 RC1 Available
Mark Wielaard wrote:
On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
It looks like this was caused by this patch:
2005-04-01 Thomas Fitzsimmons [EMAIL PROTECTED]
PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options. Set java.class.path. Don't set
_Jv_Jar_Class_Path.
...
Tom is working on a solution.
Regards
Bryce
Re: GCC 4.0 RC1 Available
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
I am looking for a real solution.
Does the following work for you?
2005-04-02 Mark Wielaard [EMAIL PROTECTED]
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.
It is the most minimal, non-intrusive way to fix this issue without
needing to mess with the gij.cc launcher or prims.cc invocation
interface.
Running a clean bootstrap and make check now.
Cheers,
Mark
Index: java/lang/natRuntime.cc
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/natRuntime.cc,v
retrieving revision 1.53
diff -u -r1.53 natRuntime.cc
--- java/lang/natRuntime.cc 2 Apr 2005 02:26:51 - 1.53
+++ java/lang/natRuntime.cc 12 Apr 2005 22:05:23 -
@@ -593,6 +593,18 @@
// LD_LIBRARY_PATH, etc.
SET (java.library.path, );
}
+
+ // If java.class.path is still not set then set it according to the
+ // CLASSPATH environment variable if given. See gij.cc main () and
+ // prims.cc _Jv_CreateJavaVM () for all the ways this could have
+ // been set much earlier.
+ path = newprops-getProperty(JvNewStringLatin1(java.class.path));
+ if (!path)
+{
+ char *classpath = getenv(CLASSPATH);
+ if (classpath)
+ SET (java.class.path, classpath);
+}
}
java::lang::Process *
signature.asc
Description: This is a digitally signed message part
Re: GCC 4.0 RC1 Available
On Tue, 2005-04-12 at 17:51 -0400, Bryce McKinlay wrote:
Mark Wielaard wrote:
On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
It looks like this was caused by this patch:
2005-04-01 Thomas Fitzsimmons [EMAIL PROTECTED]
PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options. Set java.class.path. Don't set
_Jv_Jar_Class_Path.
...
Tom is working on a solution.
Sorry, I missed this thread. Mark Wielaard beat me to the fix.
Tom
Re: GCC 4.0 RC1 Available
Mark Wielaard wrote: Hi Per, On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote: I am looking for a real solution. Does the following work for you? 2005-04-02 Mark Wielaard [EMAIL PROTECTED] * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPATH if not already set. Yes, Kawa builds with this patch. Thanks! -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote: 2005-04-02 Mark Wielaard [EMAIL PROTECTED] * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPATH if not already set. Yes, Kawa builds with this patch. Thanks! However, the Kawa testsuite fails, raising a ClassNotFoundException. I'm looking into it. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote: However, the Kawa testsuite fails, raising a ClassNotFoundException. I'm looking into it. Hm. This fails, with or without the patch: clas = Class.forName(cname); This works: clas = Class.forName(cname, true, getClass().getClassLoader()); This is with make all make install in the libjav directory. I'm doing a 'cvs update' and rebuild from a clean tree in case the problem is an artifact of the way I just rebuilt part of the tree. BTW, I've always though we should have the compiler rewrite: Class.forName(NAME) to: Class.forName(NAME, true, getClass().getClassLoader()) to avoid the fragility and ugliness and performance lossage of doing the stack trace ... -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Mark Mitchell [EMAIL PROTECTED] writes: If you are willing to help, please download the release candidate, build it on appropriate platforms, and post testresults by using contrib/test_summary. Please use the release candidate itself, *not* the CVS 4.0 release branch, as part of the goal is to ensure that the packaging scripts are working. Not a full test or a full report, but I downloaded RC1 (just gcc-core and gcc-g++) on an NFS mounted directory, ran make bootstrap as myself, and then ran make install as root. Since the directory is NFS mounted, root does not have write privileges on the object directory. The bootstrap went fine, but the install failed with: Making install in testsuite make[2]: Entering directory `/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3/testsuite' touch testsuite_wchar_t touch: cannot touch `testsuite_wchar_t': Permission denied make[2]: *** [stamp_wchar] Error 1 make[2]: Leaving directory `/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3/testsuite' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3' make: *** [install-target-libstdc++-v3] Error 2 Does anybody else see this? I imagine this would be fairly annoying for some people. Ian
Re: GCC 4.0 RC1 Available
Per Bothner wrote: Mark Wielaard wrote: Hi Per, On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote: I am looking for a real solution. Does the following work for you? 2005-04-02 Mark Wielaard [EMAIL PROTECTED] * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPATH if not already set. Yes, Kawa builds with this patch. Thanks! This is OK for 4.0 if approved for mainline. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
We severely regressed for Java (22*2 new failures) 3 days ago. Ugh. Not very surprising, given that a jumbo patch landed by that time: 2005-04-06 Tom Tromey [EMAIL PROTECTED] * Makefile.in: Rebuilt. * Makefile.am (lib_gnu_java_awt_peer_gtk_la_SOURCES): Removed gtk_awt_peer_sources. (lib_gnu_java_awt_peer_gtk_la_LIBADD): Added gtk-awt-peer.lo. (lib_gnu_java_awt_peer_gtk_la_DEPENDENCIES): Likewise. ($(gtk_awt_peer_sources:.java=.lo)): Removed. (gtk-awt-peer.lo): New target. * java/lang/natVMClassLoader.cc (getSystemClassLoaderInternal): Updated for name change. (nativeFindClass): New method. (loadClass): Use nativeFindClass. * java/lang/natClassLoader.cc (_Jv_FindClass): Use single-argument form of loadClass. * java/lang/VMClassLoader.java (tried_libraries, lib_control, LIB_FULL, LIB_CACHE, LIB_NEVER): New fields from old VMClassLoader. (initialize): New method. (nativeFindClass): Declare. * gnu/gcj/runtime/natVMClassLoader.cc: Removed. * gnu/gcj/runtime/VMClassLoader.java: Removed. * gnu/gcj/runtime/ExtensionClassLoader.java: Renamed from VMClassLoader.java. (definePackageForNative): Removed. (tried_libraries, LIB_CACHE, LIB_FULL, LIB_NEVER, lib_control): Moved to VMClassLoader.java. * prims.cc (_Jv_CreateJavaVM): Updated for renaming. * Makefile.am (gnu/gcj/runtime/ExtensionClassLoader.h): Renamed. (ordinary_java_source_files): Added ExtensionClassLoader.java, removed VMClassLoader.java. (nat_source_files): Removed natVMClassLoader.cc. * java/lang/natRuntime.cc (insertSystemProperties): Set gnu.gcj.runtime.endorsed.dirs. * Makefile.in: Rebuilt. * Makefile.am (ordinary_java_source_files): Added HelperClassLoader.java. (AM_CXXFLAGS): Define GCJ_ENDORSED_DIRS. * gnu/gcj/runtime/VMClassLoader.java (VMClassLoader): Extends HelperClassLoader. (init): Use addDirectoriesFromProperty. * gnu/gcj/runtime/BootClassLoader.java (BootClassLoader): Extends HelperClassLoader. Use addDirectoriesFromProperty. Handle gnu.gcj.runtime.endorsed.dirs. * gnu/gcj/runtime/HelperClassLoader.java: New file. * gnu/gcj/runtime/BootClassLoader.java (BootClassLoader): Don't add sax and w3c libraries. * Makefile.am (libgij_la_LIBADD): Added libsax-gcj.la and libw3c-gcj.la. * external/w3c_dom/Makefile.in: Rebuilt. * external/w3c_dom/Makefile.am (libw3c_gcj_la_GCJFLAGS): Include AM_GCJFLAGS. (libw3c_gcj_la_LDFLAGS): New variable. (noinst_LTLIBRARIES): Renamed. * external/sax/Makefile.in: Rebuilt. * external/sax/Makefile.am (libsax_gcj_la_GCJFLAGS): Include AM_GCJFLAGS. (libsax_gcj_la_LDFLAGS): New variable. (noinst_LTLIBRARIES): Renamed. * Makefile.in: Rebuilt. * Makefile.am (AM_CXXFLAGS): Define TOOLEXECLIBDIR. (libgcj0_convenience_la_SOURCES): Don't include gnu_xml_source_files. (libgcj0_convenience_la_LIBADD): New variable. (libgcj_la_LIBADD): Don't include sax or w3c_dom. (all_java_source_files): javax_imageio_source_files, javax_xml_source_files, and gnu_java_beans_source_files. ($(gnu_xml_source_files:.java=.lo)): Removed target. (gnu-xml.lo): New target. (javax-imageio.lo): Likewise. (javax-xml.lo): Likewise. (gnu-java-beans.lo): Likewise. (gnu_java_beans_source_files): New variable. (javax_imageio_source_files): Likewise. (javax_xml_source_files): Likewise. (javax_source_files): Moved files to other variable. (awt_java_source_files): Likewise. (ordinary_java_source_files): Added BootClassLoader.java. * java/lang/natVMClassLoader.cc (defineClass): Use boot loader, not system class loader. (initBootLoader): New method. (loadClass): Search bootLoader. * java/lang/natClassLoader.cc (_Jv_RegisterInitiatingLoader): Use boot loader, not system class loader. (_Jv_UnregisterInitiatingLoader): Likewise. (_Jv_FindClass): Likewise. Ensure entries in bootstrap_class_list are unique. * java/lang/natClass.cc (getClassLoader): Don't special case system class loader. * java/lang/VMClassLoader.java (bootLoader): New field. (getResource): Use bootLoader. (getResources): Likewise. (initBootLoader): Declare. * gnu/gcj/runtime/BootClassLoader.java: New file. * external/sax/org/xml/sax/helpers/NamespaceSupport.java (EMPTY_ENUMERATION): Now package-private. * external/w3c_com/Makefile.in: Rebuilt. * external/w3c_com/Makefile.am (MULTIBUILDTOP): New variable. (w3c.jar): New target.
Re: GCC 4.0 RC1 Available
Eric Botcazou writes: We severely regressed for Java (22*2 new failures) 3 days ago. Please post the list of failures to [EMAIL PROTECTED] Andrew.
Re: GCC 4.0 RC1 Available
Eric Botcazou writes: Tom, I presume there was a very good reason for installing such a potentially destabilizing patch a few days before the prerelease? In defence of my fellow maintainer: There was. We are now, for the first time ever, in a position where we can run a large number of big Java applications using entirely free software. What amount of testing did it undergo before being backported? A good deal. It was in mainline for some time before, after some contemplation, we decided that it was so important that it should go into 4.0. Without this patch many important applications will not work correctly. I appreciate that it's important that gcc runs on many platforms and that Solaris has been an important platform for gcc. But it's also important that we can run a large number of real world applications on gcj on free platforms. Still, we are a bit stuck on SPARC/Solaris because there is not much interest for that platform among the Java hackers (for SPARC/Linux either, I think). AFAIK the only Java patches aimed at fixing problems there have been posted or initiated by me. So I suspect nobody will step up to investigate what broke. I understand that Java on SPARC is not a priority, but I think in such extreme cases Java hackers should coordinate with the platform maintainers that try to keep the Java compiler healthy on their architecture, despite the huge tax of CPU cycles this entails. We're in a diffcult position here, because SPARC has few maintainers, and Java has few maintainers. However, if you can let me have a logon I can have a look. Andrew.
Re: GCC 4.0 RC1 Available
Mark Mitchell wrote: The first GCC 4.0 candidate is available from: ... a minor issue with the configure script: ... checking whether gcc-3.4 accepts -g... yes checking for gnatbind... gnatbind --- here --- checking whether compiler driver understands Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only meaningful in a `for', `while', or `until' loop yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 ... looks like there is a break without the (usual?) for around it. Georg
Re: GCC 4.0 RC1 Available
Mark Mitchell [EMAIL PROTECTED] writes: If you are willing to help, please download the release candidate, build it on appropriate platforms, and post testresults by using contrib/test_summary. Please use the release candidate itself, *not* the CVS 4.0 release branch, as part of the goal is to ensure that the packaging scripts are working. Then, if you are running on a primary or secondary platform, please send me an email pointing me at the results you've posted, and highlighting any failures to meet the release criteria. Results for mips-elf posted here: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00792.html I think these results are OK: - copysign1.c is a new test. It fails because the MIPS neg.fmt instruction implements arithmetic negation, not the sign-flipping implementation suggested in the IEEE appendix. Signs are therefore not correctly copied to NaNs. I'm still trying to make my mind up what the best fix is. - The gcsec-1.c failures are caused by a problem in the libgloss linker scripts. - execute/20020720-1.c is a standard soft-float failure. - The two PCH glitches (one gcc and one g++) were caused by running make check -j2. The gcc and g++ PCH tests happened to collide at one point, both trying to handle system-1. - Wdtor-1.C fails for the same reason as discussed on [EMAIL PROTECTED] Richard
Re: GCC 4.0 RC1 Available
--- here --- checking whether compiler driver understands Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only meaningful in a `for', `while', or `until' loop yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 ... looks like there is a break without the (usual?) for around it. Georg On closer inspection, I'm seeing the same thing on 4.0 and mainline. I believe the offending break was added to config/acx.m4 here: http://gcc.gnu.org/ml/gcc/2004-02/msg00755.html Although it seems to be that Paolo simply moved existing code from gcc/aclocal.m4 to config/acx.m4. Going back through aclocal.m4, the original breakage (no pun intended) occurred here when Nathanael removed the surrounding for-stmt but left the break inside the if-stmt. http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html Nathanael, can you please take a look? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC 4.0 RC1 Available
Please post the list of failures to [EMAIL PROTECTED] http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html -- Eric Botcazou
Re: GCC 4.0 RC1 Available
I can no longer build Kawa using the 4.0 branch. This is with a 'cvs update' late last night. Kawa did built last time I tried the 4.0 branch. Unfortunately, I don't know how long ago that was, but it wasn't *that* long ago. The cause appears to failure to find a class in the CLASSPATH. That suggests it might be related to Tom's check-in. I'll track it down a little bit further. This is on Fedora Core 3, x86. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote:
I can no longer build Kawa using the 4.0 branch.
Some more information:
The failing statement is:
Class.forName(kawa.lib.prim_syntax, false,
getClass().getClassLoader());
prim_syntax.class exists in the current directory,
which is ../../kawa/lib. The program is run with
CLASSPATH=../..
Printing getClass().getClassLoader() yields:
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Note the urls=[file:./]. Looks like it's ignoring the CLASSPATH
environment option.
It works after I do:
mkdir kawa kawa/lib cp prim_syntax.class kawa/lib
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
On 2005-04-11, Julian Brown [EMAIL PROTECTED] wrote: On 2005-04-10, Mark Mitchell [EMAIL PROTECTED] wrote: * The DejaGNU testsuite has been run, and compared with a run of the testsuite on the previous release of GCC, and no regressions are observed. If you are willing to help, please download the release candidate, build it on appropriate platforms, and post testresults by using contrib/test_summary. Please use the release candidate itself, *not* the CVS 4.0 release branch, as part of the goal is to ensure that the packaging scripts are working. For arm-none-elf (cross from i686-pc-linux-gnu), with binutils and newlib from CVS: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00800.html And, for comparison, 3.4.3 tests: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00799.html Quite a few of the 4.0 RC1 tests FAIL, though I'm not sure how many of these are regressions, and how many are just new tests which fail. In more detail, for gcc.sum: Tests that now fail, but worked before: gcc.c-torture/execute/bitfld-1.c execution, -O0 gcc.c-torture/execute/bitfld-1.c execution, -O1 gcc.c-torture/execute/bitfld-1.c execution, -O2 gcc.c-torture/execute/bitfld-1.c execution, -O3 -fomit-frame-pointer gcc.c-torture/execute/bitfld-1.c execution, -O3 -g gcc.c-torture/execute/bitfld-1.c execution, -Os gcc.c-torture/execute/builtin-constant.c execution, -O1 gcc.dg/array-5.c bad vla handling (test for bogus messages, line 40) gcc.dg/bitfld-2.c (test for warnings, line 14) gcc.dg/bitfld-2.c (test for warnings, line 15) gcc.dg/bitfld-2.c (test for warnings, line 20) gcc.dg/bitfld-2.c (test for warnings, line 21) gcc.dg/builtins-18.c (test for excess errors) gcc.dg/builtins-20.c (test for excess errors) gcc.dg/const-elim-1.c scan-assembler-not L\\$?C[^A-Z] gcc.dg/cpp/trad/include.c (test for excess errors) gcc.dg/redecl-1.c (test for errors, line 67) gcc.dg/sequence-pt-1.c sequence point warning (test for warnings, line 59) gcc.dg/uninit-1.c uninitialized variable warning (test for bogus messages, line 16) gcc.dg/uninit-2.c uninitialized variable warning (test for bogus messages, line 28) gcc.dg/uninit-3.c uninitialized variable warning (test for bogus messages, line 11) gcc.dg/uninit-8.c uninitialized variable warning (test for bogus messages, line 14) gcc.dg/Wunreachable-1.c (test for excess errors) For g++.sum: Tests that now fail, but worked before: g++.dg/other/error8.C duplicate error messages (test for bogus messages, line 8) g++.dg/other/error8.C duplicate error messages (test for bogus messages, line 9) g++.dg/rtti/tinfo1.C scan-assembler-not .section[^\n\r]*_ZTIP9CTemplateIhE[^\n\r ]* g++.dg/template/nested3.C (test for errors, line 12) g++.dg/template/nested3.C (test for errors, line 14) g++.dg/template/nested3.C (test for errors, line 25) g++.dg/template/nested3.C (test for errors, line 8) g++.old-deja/g++.jason/cond.C (test for errors, line 20) g++.old-deja/g++.jason/cond.C (test for errors, line 22) g++.old-deja/g++.jason/cond.C (test for errors, line 25) g++.old-deja/g++.jason/cond.C (test for errors, line 27) g++.old-deja/g++.oliva/expr2.C execution test g++.old-deja/g++.oliva/template10.C (test for errors, line 22) g++.old-deja/g++.other/decl5.C (test for warnings, line 55) g++.old-deja/g++.other/decl5.C (test for warnings, line 56) For libstdc++.sum: Tests that now fail, but worked before: 27_io/basic_filebuf/open/char/9507.cc (test for excess errors) That's a total of about 39 regressions, I think. I also got quite a few Old tests that passed, that have disappeared results. Is that expected? Julian
Re: GCC 4.0 RC1 Available
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote: The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ My test results on i686-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html All looks good except for the libmudflap failures which I'm not sure about.. but browsing the results from others indicates I'm not alone with those. Regards Greg
Re: GCC 4.0 RC1 Available
Mark Mitchell [EMAIL PROTECTED] writes: The first GCC 4.0 candidate is available ... Then, if you are running on a primary or secondary platform, please send me an email pointing me at the results you've posted, and highlighting any failures to meet the release criteria. Hi Mark, I'm pleased to say that there are no regressions in RC1 on powerpc-darwin8 compared to 3.4.3, except for: gcc/testsuite/g++.sum:FAIL: g++.dg/warn/Wdtor1.C (test for excess errors) which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00801.html for 3.4.3, and http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html for 4.0.0-20050410.
Re: GCC 4.0 RC1 Available
Marcus Meissner wrote: Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem triggering in ncurses (all platforms) PR/20929 triggers a miscompilation of Mozilla. Those are all on the Wiki page as possible patches for an RC2. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ on the usual gcc.gnu.org mirrors: http://gcc.gnu.org/mirrors.html I would like to know whether or not we have achieved the objective aspects of the release criteria: http://gcc.gnu.org/gcc-4.0/criteria.html for primary and secondary platforms. sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except FAIL: gcc.dg/builtin-apply4.c execution test in 32-bit mode. Patch in testing. We severely regressed for Java (22*2 new failures) 3 days ago. -- Eric Botcazou
Re: GCC 4.0 RC1 Available
Eric Botcazou wrote: The first GCC 4.0 candidate is available from: /pub/gcc/prerelease-4.0.0-20050410/ on the usual gcc.gnu.org mirrors: http://gcc.gnu.org/mirrors.html I would like to know whether or not we have achieved the objective aspects of the release criteria: http://gcc.gnu.org/gcc-4.0/criteria.html for primary and secondary platforms. sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except FAIL: gcc.dg/builtin-apply4.c execution test in 32-bit mode. Patch in testing. We severely regressed for Java (22*2 new failures) 3 days ago. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0 RC1 Available
On Mon, Apr 11, 2005 at 12:49:39AM +0200, Eric Botcazou wrote: sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except FAIL: gcc.dg/builtin-apply4.c execution test Is that a regression though? builtin-apply4.c is a new test. Jakub
