Discussion:
GCC 4.0 RC1 Available
(too old to reply)
Mark Mitchell
2005-04-10 22:05:17 UTC
Permalink
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. In particular, for primary platforms:

* 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.

and, for secondary platforms:

* The compiler bootstraps successfully, and the C++ runtime library
builds.
* The DejaGNU testsuite has been run, and a substantial majority of
the tests pass.

N.B.: For all platforms, only C and C++ are part of the release
criteria. It's great to test other languages, but I am primary
interested in C and C++. For primary platforms, only *regressions* are
of interest, not merely failures.

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.

I may interpret silence as assent, meaning that I might elect to ship
GCC 4.0 without receiving information about one of the primary or
secondary platforms. Therefore, if you're a user of one of these
platforms, it's in your best interest to put the release candidate
through its paces.

Thanks,
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Eric Botcazou
2005-04-10 22:49:39 UTC
Permalink
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
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
Mark Mitchell
2005-04-10 22:57:22 UTC
Permalink
Post by Eric Botcazou
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
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
***@codesourcery.com
(916) 791-8304
Jakub Jelinek
2005-04-11 05:09:00 UTC
Permalink
Post by Eric Botcazou
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
Eric Botcazou
2005-04-11 06:12:32 UTC
Permalink
Post by Jakub Jelinek
Is that a regression though? builtin-apply4.c is a new test.
http://gcc.gnu.org/ml/gcc/2005-04/msg00299.html
--
Eric Botcazou
Eric Botcazou
2005-04-11 08:56:22 UTC
Permalink
Post by Eric Botcazou
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 <***@redhat.com>

* 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.
(classes.stamp): Updated.
(toolexeclib_LTLIBRARIES): Renamed from noinst_LTLIBRARIES.
Changed name of library.
(libw3c_gcj_la_SOURCES): New variable.
(libw3c_gcj_la_GCJFLAGS): Likewise.
(source_files): Renamed from lib3c_convenience_la_SOURCES.
* external/sax/Makefile.in: Rebuilt.
* external/sax/Makefile.am (MULTIBUILDTOP): New variable.
(sax.jar): New target.
(classes.stamp): Updated.
(toolexeclib_LTLIBRARIES): Renamed from noinst_LTLIBRARIES.
Changed name of library.
(libsax_gcj_la_SOURCES): New variable.
(libsax_gcj_la_GCJFLAGS): Likewise.
(source_files): Renamed from libsax_convenience_la_SOURCES.
* prims.cc (_Jv_CreateJavaVM): Initialize the bootstrap class
loader.
(_Jv_RunMain): Handle case where 'runtime' is NULL at exit.


Indeed reverting it has us back to the nominal status (a couple of failures).

Tom, I presume there was a very good reason for installing such a potentially
destabilizing patch a few days before the prerelease? What amount of testing
did it undergo before being backported?

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. These CPU cycles should not be simply wasted.
--
Eric Botcazou
Andrew Haley
2005-04-11 12:50:24 UTC
Permalink
Post by Eric Botcazou
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.
Post by Eric Botcazou
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.
Post by Eric Botcazou
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.
Mark Mitchell
2005-04-11 14:41:27 UTC
Permalink
Post by Andrew Haley
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.
That would be much appreciated. Java isn't release-critical, but it
still seems like it would be nice to understand what's wrong here.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Eric Botcazou
2005-04-11 21:25:23 UTC
Permalink
Post by Andrew Haley
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.
Congratulations!
Post by Andrew Haley
We're in a diffcult position here, because SPARC has few maintainers,
and Java has few maintainers.
Frankly, I don't see what the number of SPARC maintainers has to do with the
affair. libstdc++-v3 maintainers ask from time to time to test in advance
potentially controversial patches they intend to backport to stable branches
and the turnaround time is generally a matter of days.

And SPARC is the port that features the greatest number of officially
appointed maintainers. :-)
Post by Andrew Haley
However, if you can let me have a logon I can have a look.
Thanks for the offer. I'll try and see what I can do.
--
Eric Botcazou
Giovanni Bajo
2005-04-12 10:24:22 UTC
Permalink
Post by Andrew Haley
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.
This is a really great news!

So great that I wonder why changes.html does not mention it (and news.html
as well). Would you please prepare a patch about this?
--
Giovanni Bajo
Tom Tromey
2005-04-14 01:01:12 UTC
Permalink
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
Eric Botcazou
2005-04-14 06:03:11 UTC
Permalink
Post by Tom Tromey
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.
Post by Tom Tromey
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
Andrew Haley
2005-04-11 09:31:06 UTC
Permalink
Post by Eric Botcazou
We severely regressed for Java (22*2 new failures) 3 days ago.
Please post the list of failures to ***@gcc.gnu.org.

Andrew.
Eric Botcazou
2005-04-11 19:40:14 UTC
Permalink
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html
--
Eric Botcazou
Per Bothner
2005-04-11 21:51:39 UTC
Permalink
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
***@bothner.com http://per.bothner.com/
Per Bothner
2005-04-11 22:33:17 UTC
Permalink
Post by Per Bothner
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
***@bothner.com http://per.bothner.com/
Mark Wielaard
2005-04-12 18:11:27 UTC
Permalink
Hi,
Post by Per Bothner
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
Per Bothner
2005-04-12 18:23:36 UTC
Permalink
Post by Mark Wielaard
I tried to replicate this issue with some simple example,
...
$ 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}}
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}}

(Of course to be picky "file:/usr/" is not a valid URL ...)
--
--Per Bothner
***@bothner.com http://per.bothner.com/
Mark Wielaard
2005-04-12 18:45:12 UTC
Permalink
Post by Per Bothner
$ 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
Bryce McKinlay
2005-04-12 21:51:04 UTC
Permalink
Post by Mark Wielaard
Post by Per Bothner
$ 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
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 <***@redhat.com>

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
Thomas Fitzsimmons
2005-04-12 22:19:52 UTC
Permalink
Post by Bryce McKinlay
Post by Mark Wielaard
Post by Per Bothner
$ 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
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.
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
Mark Wielaard
2005-04-12 22:08:00 UTC
Permalink
Hi Per,
Post by Mark Wielaard
I am looking for a real solution.
Does the following work for you?

2005-04-02 Mark Wielaard <***@klomp.org>

* 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
Per Bothner
2005-04-12 23:15:59 UTC
Permalink
Post by Mark Wielaard
Hi Per,
Post by Mark Wielaard
I am looking for a real solution.
Does the following work for you?
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.
Yes, Kawa builds with this patch. Thanks!
--
--Per Bothner
***@bothner.com http://per.bothner.com/
Per Bothner
2005-04-12 23:27:42 UTC
Permalink
Post by Per Bothner
Post by Eric Botcazou
* 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
***@bothner.com http://per.bothner.com/
Per Bothner
2005-04-13 01:00:13 UTC
Permalink
Post by Per Bothner
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
***@bothner.com http://per.bothner.com/
Andrew Haley
2005-04-13 09:24:33 UTC
Permalink
Post by Per Bothner
Post by Per Bothner
However, the Kawa testsuite fails, raising a ClassNotFoundException.
I'm looking into it.
clas = Class.forName(cname);
clas = Class.forName(cname, true, getClass().getClassLoader());
Okay, a stack trace failure. And a new one, despite the fact that the
release branch still has the unchanged old stack trace machinery.
Post by Per Bothner
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.
Class.forName(NAME)
Class.forName(NAME, true, getClass().getClassLoader())
to avoid the fragility and ugliness and performance lossage
of doing the stack trace ...
I started to do this, but there are quite a few places that need it:
it's not just Class.forName().

Andrew.
Mark Mitchell
2005-04-13 04:32:10 UTC
Permalink
Post by Per Bothner
Post by Mark Wielaard
Hi Per,
Post by Mark Wielaard
I am looking for a real solution.
Does the following work for you?
* 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
***@codesourcery.com
(916) 791-8304
Georg Bauhaus
2005-04-11 13:22:19 UTC
Permalink
...
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
Kaveh R. Ghazi
2005-04-11 18:48:56 UTC
Permalink
Post by Georg Bauhaus
--- 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 ***@caip.rutgers.edu
Paolo Bonzini
2005-04-12 07:10:17 UTC
Permalink
Post by Kaveh R. Ghazi
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 <***@gnu.org>

* configure: Regenerate.

config:
2005-04-12 Paolo Bonzini <***@gnu.org>

* 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 -0000 1.11
+++ acx.m4 12 Apr 2005 07:04:16 -0000
@@ -212,7 +212,6 @@ acx_cv_cc_gcc_supports_ada=no
errors=`(${CC} -c conftest.adb) 2>&1 || 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.*])
Mark Mitchell
2005-04-15 19:39:09 UTC
Permalink
Post by Paolo Bonzini
Post by Kaveh R. Ghazi
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
* acx.m4 (ACX_PROG_GNAT): Remove stray break.
OK for 4.0.0.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Kaveh R. Ghazi
2005-04-19 02:06:25 UTC
Permalink
Post by Mark Mitchell
Post by Paolo Bonzini
* 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


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.

Thanks,
--Kaveh
--
Kaveh R. Ghazi ***@caip.rutgers.edu
Paolo Bonzini
2005-04-19 06:59:31 UTC
Permalink
Post by Kaveh R. Ghazi
When this patch went into 4.0, Paolo didn't regenerate the top level
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00842.html
You're right. I was being conservative and typed the "cvs ci" filenames
manually, but in this case there was no need because I worked off a
fresh checkout. Sorry.
Post by Kaveh R. Ghazi
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, I was. But it looks like build machinery maintainers are being
busy and toplevel patches are largely unnoticed.

Paolo
Mark Mitchell
2005-04-19 15:31:17 UTC
Permalink
Post by Kaveh R. Ghazi
Post by Mark Mitchell
Post by Paolo Bonzini
* 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
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.
Post by Kaveh R. Ghazi
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
***@codesourcery.com
(916) 791-8304
Paolo Bonzini
2005-04-19 15:34:42 UTC
Permalink
Post by Mark Mitchell
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
Kaveh R. Ghazi
2005-04-20 02:45:50 UTC
Permalink
Post by Paolo Bonzini
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...
Post by Paolo Bonzini
Done.
I'll apply to mainline soon.
Paolo
Aleady done.
Thanks Paolo! :-)

--
Kaveh R. Ghazi ***@caip.rutgers.edu

Laurent GUERBY
2005-04-12 10:42:09 UTC
Permalink
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
Post by Kaveh R. Ghazi
Post by Georg Bauhaus
--- 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.
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?
Georg Bauhaus
2005-04-12 11:22:43 UTC
Permalink
Post by Laurent GUERBY
FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler (3.3.3 based)
/bin/bash triggers the message, /bin/sh doesn't.

Debian/bash 2.05b; SuSE 9.2/bash 3.00.0(1),
if true; then break; fi
I had run

% bash ../src/gcc-4.0.0-20050410/configure ...
Post by Laurent GUERBY
checking whether compiler driver understands Ada... yes
Post by Georg Bauhaus
--- 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
Joe Buck
2005-04-11 16:56:59 UTC
Permalink
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
My first build result is at

http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00742.html

However, the system info is wrong due to my error; it is really a
Fedora Core 2 system, with "up2date" components for the kernel, gcc,
and binutils, and there are no Ada tests -- configure reports that
libada isn't supported (despite the presence of gnat), though I haven't
investigated why.

I will be doing tests on more platforms.
Jakub Jelinek
2005-04-11 17:04:38 UTC
Permalink
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
http://gcc.gnu.org/gcc-4.0/criteria.html
* 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.
Just an early warning.
We are seeing (possible) miscompilation of KDE 3.4.0's cssstyleselector.cpp
on i386-linux, a regression between 20050330 (where it worked) and 20050403.
The resulting assembly with 20050403+ is also ~ 17% bigger.
There are no differences in *.generic dump, but already in *.gimple
dump the difference is huge.
We'll keep looking into this.

Jakub
Mark Mitchell
2005-04-11 17:09:12 UTC
Permalink
Post by Jakub Jelinek
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
http://gcc.gnu.org/gcc-4.0/criteria.html
* 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.
Just an early warning.
Thanks for the heads up.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Andrew Pinski
2005-04-11 17:14:18 UTC
Permalink
Post by Jakub Jelinek
Post by Mark Mitchell
/pub/gcc/prerelease-4.0.0-20050410/
http://gcc.gnu.org/mirrors.html
I would like to know whether or not we have achieved the objective
http://gcc.gnu.org/gcc-4.0/criteria.html
* 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.
Just an early warning.
We are seeing (possible) miscompilation of KDE 3.4.0's
cssstyleselector.cpp
on i386-linux, a regression between 20050330 (where it worked) and 20050403.
The resulting assembly with 20050403+ is also ~ 17% bigger.
There are no differences in *.generic dump, but already in *.gimple
dump the difference is huge.
We'll keep looking into this.
This with optimization turned on right, then there is more inlining
happening,
which was caused by:
2005-04-01 Richard Guenther <***@tat.physik.uni-tuebingen.de>
Jan Hubicka <***@suse.cz>
Steven Bosscher <***@suse.de>

* cgraphunit.c (cgraph_estimate_size_after_inlining): Compute
call cost based on argument sizes.
(cgraph_mark_inline_edge): Avoid inline unit from shrinking by
inlining.
* params.def: (max-inline-inssn-single): Set to 450.
(max-inline-insns-auto): Set to 90.
(max-inline-insns-recursive): Set to 450
(max-inline-insns-recursive-auto): Set to 450.
(large-function-insns): Set to 2700.
(inline-call-cost): New parameter.
* tree-inline.c (estimate_move_cost): New function.
(estimate_num_insns_1): Compute move sizes costs by
estimate_move_cost
for non-gimple-regs, set cost to 0 for gimple-regs. Compute
call size
based on arguments.
* tree-inline.h (estimate_move_cost): Declare.
* invoke.texi: (max-inline-inssn-single): Change default to 450.
(max-inline-insns-auto): Change default to 90.
(max-inline-insns-recursive): Change default to 450
(max-inline-insns-recursive-auto): Change default to 450.
(large-function-insns): Change default to 2700.
(inline-call-cost): Document new parameter.

-- Pinski
Richard Sandiford
2005-04-11 18:40:44 UTC
Permalink
Post by Mark Mitchell
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 gcc-***@.

Richard
Marcus Meissner
2005-04-11 19:02:21 UTC
Permalink
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.


At least 20126 should probably be considered for 4.0.

Ciao, Marcus
Mark Mitchell
2005-04-12 03:11:20 UTC
Permalink
Post by Marcus Meissner
Btw,
We still see some critical 4.0 problems, ordered by my view of
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
***@codesourcery.com
(916) 791-8304
Joel Sherrill
2005-04-12 11:16:35 UTC
Permalink
Post by Mark Mitchell
Post by Marcus Meissner
Btw,
We still see some critical 4.0 problems, ordered by my view of
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
Post by Mark Mitchell
Those are all on the Wiki page as possible patches for an RC2.
Thanks,
--
Joel Sherrill, Ph.D. Director of Research & Development
***@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Julian Brown
2005-04-11 23:06:21 UTC
Permalink
Post by Mark Mitchell
* 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.

Julian
Julian Brown
2005-04-11 23:34:46 UTC
Permalink
Post by Julian Brown
Post by Mark Mitchell
* 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
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00800.html
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
Joseph S. Myers
2005-04-13 00:33:30 UTC
Permalink
Post by Julian Brown
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.
And a new test which fails may or may not be a regression - finding out
whether it is requires either testing the old compiler with the new
testsuite (e.g. using contrib/test_installed, but that doesn't do
libstdc++ testing), or running the tests manually with the old compiler.
(Whether or not it is a regression, it is still worth a bug report in
Bugzilla, as is any FAIL or XFAIL.)
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
***@polyomino.org.uk (personal mail)
***@codesourcery.com (CodeSourcery mail)
***@gcc.gnu.org (Bugzilla assignments and CCs)
Greg Schafer
2005-04-12 02:02:59 UTC
Permalink
Post by Mark Mitchell
/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
Geoffrey Keating
2005-04-12 02:56:04 UTC
Permalink
Post by Mark Mitchell
The first GCC 4.0 candidate is available
...
Post by Mark Mitchell
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.
Eric Botcazou
2005-04-12 05:59:19 UTC
Permalink
Post by Geoffrey Keating
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?
--
Eric Botcazou
Andrew Haley
2005-04-12 13:31:51 UTC
Permalink
Post by Eric Botcazou
Post by Geoffrey Keating
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.
Geoff Keating
2005-04-12 13:39:40 UTC
Permalink
Post by Andrew Haley
Post by Eric Botcazou
Post by Geoffrey Keating
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/>.
Andrew Haley
2005-04-12 13:47:35 UTC
Permalink
Post by Geoff Keating
Post by Andrew Haley
Post by Eric Botcazou
Post by Geoffrey Keating
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/>.
I'm there, but all I can see is Xcode and CHUD. No compilers or other tools.

Andrew.
Geoff Keating
2005-04-12 13:54:35 UTC
Permalink
Post by Andrew Haley
Post by Geoff Keating
Post by Andrew Haley
Post by Eric Botcazou
Post by Geoffrey Keating
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/>.
I'm there, but all I can see is Xcode and CHUD. No compilers or other tools.
Xcode is Apple's name for IDE+compiler+debugger+binutils+etc.
Andrew Haley
2005-04-13 13:00:09 UTC
Permalink
Post by Andrew Haley
Post by Eric Botcazou
Post by Geoffrey Keating
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.
Andrew Haley
2005-04-13 13:25:16 UTC
Permalink
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.
Andrew Haley
2005-04-13 13:50:56 UTC
Permalink
Post by Andrew Haley
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.
which didn't contain cctools-528.5. Continuing.

Andrew.
Andrew Haley
2005-04-14 14:31:30 UTC
Permalink
Post by Eric Botcazou
Post by Geoffrey Keating
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.
Ranjit Mathew
2005-04-12 06:23:11 UTC
Permalink
Geoffrey Keating wrote:
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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.

Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Geoff Keating
2005-04-12 13:55:19 UTC
Permalink
Post by Ranjit Mathew
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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.
Andrew Pinski
2005-04-12 14:32:13 UTC
Permalink
Post by Geoff Keating
Post by Ranjit Mathew
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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
What I don't understand is why does this only show up in 4.0 branch and
not the mainline.


-- Pinski
Ranjit Mathew
2005-04-13 05:41:29 UTC
Permalink
Post by Geoff Keating
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?

Beyond this, the other FAILs seem to be the
result of the Java interpreter (gij) getting confused
about loading classes.

You might try:

http://gcc.gnu.org/ml/java/2005-04/msg00075.html

but it might or might not help. Sorry for being
this vague, but without access to a Darwin
machine and any knowledge about that system,
I can't shed much light on these FAILs.

Ranjit.

PS: As Andrew Pinski remarked, I wonder why
you don't see these on mainline? Perhaps Tom
missed a hunk or two while backporting his
patch?
--
Ranjit Mathew Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Andrew Pinski
2005-04-13 09:49:49 UTC
Permalink
Post by Ranjit Mathew
Post by Geoff Keating
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
Andrew Haley
2005-04-13 17:07:59 UTC
Permalink
Post by Ranjit Mathew
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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.
My results:

FAIL: Array_3 -O3 execution - bytecode->native test
FAIL: LargeFile execution - source compiled test
FAIL: LargeFile execution - bytecode->native test
FAIL: LargeFile -O3 execution - source compiled test
FAIL: LargeFile -O3 execution - bytecode->native test

=== libjava Summary ===

# of expected passes 3062
# of unexpected failures 5
# of expected failures 14
# of untested testcases 23

Array_3 is extected to fail at -O3. LargeFile fails if it can't
create a huge file.

powerpc-apple-darwin7.8.0
dejagnu HEAD

So, this is unrepro, as far as I can see.

Andrew.
Geoffrey Keating
2005-04-17 19:55:27 UTC
Permalink
Post by Andrew Haley
Post by Ranjit Mathew
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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 failures 5
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.
Andrew Haley
2005-04-18 10:25:52 UTC
Permalink
Post by Geoffrey Keating
Post by Andrew Haley
Post by Ranjit Mathew
[...]
Post by Geoffrey Keating
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
Post by Geoffrey Keating
<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 failures 5
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.
Laurent GUERBY
2005-04-12 10:35:17 UTC
Permalink
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
Laurent GUERBY
2005-04-18 20:47:35 UTC
Permalink
The minor "problem" is still there in RC2, I opened PR21094 about it:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21094

Laurent
Post by Laurent GUERBY
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
Ian Lance Taylor
2005-04-13 03:41:03 UTC
Permalink
Post by Mark Mitchell
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
Mark Mitchell
2005-04-13 19:43:38 UTC
Permalink
Post by Ian Lance Taylor
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
***@codesourcery.com
(916) 791-8304
Paul Jarc
2005-04-13 21:48:52 UTC
Permalink
gcc/doc/install.texi still mentions gcc 3.5 in a few places.


paul
Joseph S. Myers
2005-04-14 17:20:15 UTC
Permalink
Post by Paul Jarc
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/
***@polyomino.org.uk (personal mail)
***@codesourcery.com (CodeSourcery mail)
***@gcc.gnu.org (Bugzilla assignments and CCs)

2005-04-14 Joseph S. Myers <***@codesourcery.com>

* 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.000000000 +0000
+++ GCC/gcc/doc/cpp.texi 2005-04-14 17:09:20.000000000 +0000
@@ -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.000000000 +0000
+++ GCC/gcc/doc/install.texi 2005-04-14 17:09:12.000000000 +0000
@@ -442,7 +442,7 @@ Please refer to the @uref{http://gcc.gnu
for information on how to obtain ***@.

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 ***@.

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
Mark Mitchell
2005-04-14 17:21:52 UTC
Permalink
Post by Joseph S. Myers
Post by Paul Jarc
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!
Post by Joseph S. Myers
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
***@codesourcery.com
(916) 791-8304
Gerald Pfeifer
2005-04-14 19:35:04 UTC
Permalink
Post by Joseph S. Myers
Post by Paul Jarc
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
Continue reading on narkive:
Loading...