GCC 4.0 RC1 Available

[Mark Mitchell]

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,

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

[Mark Mitchell]

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!

[Jakub Jelinek]

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]

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]

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.

[Andrew Haley]

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]

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.

[Eric Botcazou]

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.

[Giovanni Bajo]

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?

[Tom Tromey]

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]

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.

[Andrew Haley]

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]

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

[Per Bothner]

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]

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

[Mark Wielaard]

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]

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

[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
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]

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]

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]

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]

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]

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]

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

[Andrew Haley]

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]

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.

[Georg Bauhaus]

...

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]

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]

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]

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.

[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
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]

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]

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.

[Paolo Bonzini]

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]

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]

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]

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