This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bernd Schmidt, release manager for GCC 2.95.3


On Thu, 30 Nov 2000, Gerald Pfeifer wrote:

> We are happy to announce Bernd Schmidt as release manager for GCC 2.95.3.
> 
> GCC 2.95.3 will be a maintainance release from the "old" 2.95.x release
> branch with a strong focus on addressing critical problems, especially
> code generation bugs.
> 
> This release should not affect the schedule of GCC 3.0 negatively and
> we hope to get it out of the door relatively quickly.
> 
> Please support both Bernd and Mark as much as possible; serving as
> release managers surely is not an easy task!
> 
> And now, over to Bernd... ;-)

Thank you :)

Here's what I imagine the process to look like.

We'll start with a two-week interval in which people can suggest patches to
be applied, or bugs that need to be fixed.  The deadline for that is Dec 17.
I'll review the suggestions and apply patches to the branch.

Here are the criteria whether or not a given patch will be accepted:
1. Type of the patch: what does it fix?  The highest priority goes to
   unpredictable code generation bugs that may cause miscompilations of
   any kind of software.  At a lower priority, we have failures to compile
   valid code and predictable code generation problems (e.g. "using the GNU
   C extension foo always causes bad code to be generated").  I'm not really
   interested in fixing ICEs on invalid code.  Given my lack of expertise I
   also can't do anything about language conformance problems in g++ (or
   Fortran, or Chill...).
2. How safe is the patch?  If the problem has been solved for a year in the
   mainline sources, then it can be considered relatively unlikely to cause
   problems.  Small changes are usually easy to review.  It's less likely
   that a large patch that hasn't yet been applied to the mainline would be
   accepted.
3. What is affected?  VAX code generation problems are less critical than
   i386 ones.
4. For bug reports (not patches), how much time will it take to fix the
   problem?
No new features will be added in 2.95.3.

Once that is done, there'll be a phase in which we'll have test releases
which will hopefully get widely tested.  I can build and test on a variety
of platforms here, but I'm looking for volunteers with less common hardware
and/or operating systems.

If you want to volunteer for testing, please send an email to gcc@gcc.gnu.org.
You can start already by bootstrapping gcc-2.95.2 on your system and running
the current (!) regression testsuite against it.  Download
  ftp://gcc.gnu.org/pub/gcc/snapshots/2000-11-27/gcc-tests-20001127.tar.gz
then extract it and move the directory "gcc-20001127/gcc/testsuite" to
"gcc-2.95.2/gcc/testsuite" and apply the patch below, which should make the
current testsuite work with 2.95.
We'll need results for 2.95.2 to make sure there are no regressions against
that release.  If you send results for 2.95.2 please make sure you'll also
have the time in a few weeks to test the prereleases.

Test results should be sent to gcc-testresults@gcc.gnu.org.  Please state
clearly the target name (e.g. sparc-sun-solaris2.5.1) and any special
configuration options you used when building the compiler.

Other than the gcc regression testsuite, I can build and test a number of
programs across a set of platforms.  I'd like to get suggestions as to which
programs we should use for this, and on which platforms to test.  Preferrably
this should be packages that come with built-in testsuites.  Here's a list
of programs I plan to test on the machines available to me:
1. SPEC95 (mind that we are not primarily interested in performance for this
   release, but we should be able to compile this set of benchmarks
   correctly).
2. glibc-2.2 (on various linux targets)
3. e2fsprogs-1.18 (on various linux targets).  It has a regression testsuite.
4. gawk-3.0.4.  It also has a regression testsuite.
5. crafty-17.13.  This comes with a builtin "benchmark" command which should
   produce a log file that looks similar to the 2.95 one (i.e. no diagonal
   rook moves...)  Again, this is not for performance testing.
6. We'll need a C++ program or two.  I'm open to suggestions.

I also plan to build XFree86-4.0.1 on i686-linux.  I don't think there's a good
testsuite for that, but it should compile and "seem to" work.  I'll probably do
the same with a few other random programs.  I encourage people to do the same
on the platforms they care about, and if it turns out that somebody's favourite
program broke between 2.95.2 and any given test release, it may be considered a
showstopper if it seems critical enough to me (or it may not if it doesn't).

The plan is to finish testing and have a release out by the end of the year.

I'm open to suggestions if someone has a better plan or would like details
changed.

I hope and expect that it will be possible to get this release out the door
quickly.  A lot of work has already been done thanks to efforts by people like
Jeff Law who have tried to keep the branch up-to-date for a while, and Franz
Sirl who has collected candidate backport patches.


Bernd

diff --width=160 -du lib/g++.exp lib.1/g++.exp
--- lib/g++.exp	Sun Nov 26 12:20:50 2000
+++ lib/g++.exp	Thu Nov 30 11:02:19 2000
@@ -68,7 +68,6 @@
 #
 proc g++_include_flags { args } {
     global srcdir
-    global HAVE_LIBSTDCXX_V3
 
     set flags ""
 
@@ -83,15 +82,9 @@
 
     set gccpath [get_multilibs]
 
-    if { ${HAVE_LIBSTDCXX_V3} } {
-      set odir_v3 [lookfor_file ${gccpath} libstdc++-v3]
-      set sdir_v3 [lookfor_file ${srcdir} libstdc++-v3]
-      append flags [exec ${odir_v3}/tests_flags --compiler ${odir_v3} ${sdir_v3}]
-    } else {
-      set odir_v2 [lookfor_file ${gccpath} libstdc++]
-      set sdir_v2 [lookfor_file ${srcdir} libstdc++]
-      append flags "-I${sdir_v2} -I${sdir_v2}/stl "
-    }
+    set odir_v2 [lookfor_file ${gccpath} libstdc++]
+    set sdir_v2 [lookfor_file ${srcdir} libstdc++]
+    append flags "-I${sdir_v2} -I${sdir_v2}/stl "
 
     return "$flags"
 }
@@ -223,7 +216,7 @@
 
     # Make sure that lines are not wrapped.  That can confuse the
     # error-message parsing machinery.
-    lappend ALWAYS_CXXFLAGS "additional_flags=-fmessage-length=0"
+    # lappend ALWAYS_CXXFLAGS "additional_flags=-fmessage-length=0"
 
     verbose -log "ALWAYS_CXXFLAGS set to $ALWAYS_CXXFLAGS"
 
diff --width=160 -du lib/objc.exp lib.1/objc.exp
--- lib/objc.exp	Sun Aug  6 19:41:49 2000
+++ lib/objc.exp	Thu Nov 30 11:02:03 2000
@@ -143,7 +143,7 @@
 	lappend options "additional_flags=-DNO_VARARGS"
     }
     set objcpath "[get_multilibs]"
-    set libobjc_dir [lookfor_file ${objcpath} libobjc/.libs/libobjc.a]
+    set libobjc_dir [lookfor_file ${objcpath} libobjc/libobjc.a]
     if { $libobjc_dir != "" } {
 	set libobjc_dir [file dirname ${libobjc_dir}]
 	set objc_link_flags "-L${libobjc_dir}"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]