making a 2.95.4 release

making a 2.95.4 release

[David O'Brien]

Hello Jeff,

As GCC 2.95 release engineer, would you please create a 2.95.4 release
from the 'gcc-2_95-branch'?  Considering the maturity of the branch, I
cannot imagine this would take much more than creating the tarballs and
putting them on ftp.gnu.org.

The BSD's need 2.95.4 because critical setjump/longjump exception
handling bugs are finally fixed.  Debian uses 2.95 for other reasons.
EGCS 1.0.3 was created for the needs of Red Hat and GCC 2.95.3 for the
needs of glibc (Message-Id: <200203230150.RAA10697@atrus.synopsys.com>).
So I there is precedence for making a release for the needs of a class of
other, non-GCC, software.

For various reason people are still downloading and using 2.95.3 to this
day.  GCC 3.x is also inappropriate for some of the BSD releases due to
the major changes between 2.95->3.0.  Just this week someone else was
asking for a 2.95.4 release.

Below are the changes since 2.95.3.

-- 
-- David  (obrien@FreeBSD.org)


Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/egcs/gcc/ChangeLog,v
retrieving revision 1.3667.4.336
retrieving revision 1.3667.4.363
diff -u -r1.3667.4.336 -r1.3667.4.363
--- ChangeLog	2001/03/16 12:52:02	1.3667.4.336
+++ ChangeLog	2001/10/03 00:45:49	1.3667.4.363
@@ -1,3 +1,169 @@
+2001-10-02  Zack Weinberg  <zack@codesourcery.com>
+
+	* gcc.c (main): Set this_file_error if the appropriate
+	compiler for a language has not been installed.
+
+2001-09-17  Philip Blundell  <philb@gnu.org>
+
+	* cccp.c (print_help): Fix typos.
+
+2001-08-29  David O'Brien  <obrien@FreeBSD.org>
+
+	* config/alpha/crtbegin.asm: The normal calling convention for alpha is
+	to re-initialize gp using 'ldgp gp,0(ra)' after a jsr instruction.
+
+2001-06-19  Bernd Schmidt  <bernds@redhat.com>
+
+	* regmove.c (optimize_reg_copy_3): Do nothing if previous insn
+	carries a REG_EQUIV note.  If it carries REG_EQUAL, delete the
+	note.
+
+2001-05-22  Bernd Schmidt  <bernds@redhat.com>
+
+	* sparc.md (movsf, movdf): Allow constant to integer reg moves.
+	(movsf, movdf splitters): Always split if there's an alignment
+	problem.
+
+2001-05-22  David Edelsohn  <dje@watson.ibm.com>
+
+	* rs6000.md (movsfcc,movdfcc): Remove NE case.
+
+2001-05-17  Bernd Schmidt  <bernds@redhat.com>
+
+	* function.c: Small formatting change to prevent compilation errors
+	on broken hpux systems.
+
+	* expr.c (protect_from_queue): Protect against subsequent calls to
+	emit_queue.
+	(expand_expr, case ADDR_EXPR): Prevent protect_from_queue from being
+	too clever.
+
+2001-04-06  Bernd Schmidt  <bernds@redhat.com>
+
+	2000-10-17  Franz Sirl  <Franz.Sirl-kernel@lauterbach.com>
+	* function.c (locate_and_pad_parm): Don't align stack unconditionally.
+
+	Thu Oct 28 10:20:02 1999  Geoffrey Keating  <geoffk@cygnus.com>
+	* config/rs6000/rs6000.md (movsf): Don't convert a SUBREG
+	of the function return register into a plain REG until
+	after function inlining is done.
+
+2001-04-04  Bernd Schmidt  <bernds@redhat.com>
+
+	Fri Nov  5 10:07:25 1999  Nick Clifton  <nickc@cygnus.com>
+	* function.c (is_addressof): New function.  Returns true if
+	the given piece of RTL is an ADDRESSOF.
+	(purge_addressof_1): Make boolean.  Return false if the
+	ADDRESSOFs could not be purged.
+	(purge_addressof): If ADDRESSOFs could not be purged from the
+	notes attached to an insn, remove the offending note(s),
+	unless they are attached to a libcall.
+
+2001-04-03  Bernd Schmidt  <bernds@redhat.com>
+
+	2001-03-16  Jakub Jelinek  <jakub@redhat.com>
+	* crtstuff.c (init_dummy): Use CRT_END_INIT_DUMMY if defined.
+	Remove ia32 linux PIC kludge and move it...
+	* config/i386/linux.h (CRT_END_INIT_DUMMY): ...here.
+
+	* loop.c (combine_movables): Restrict combinations of constants with
+	different modes so that we don't introduce SUBREGs into memory
+	addresses.
+
+	2001-02-02  Philip Blundell  <philb@gnu.org>
+	* arm/linux-elf.h (MAKE_DECL_ONE_ONLY, UNIQUE_SECTION_P): Define.
+	(UNIQUE_SECTION): Define.                                  
+
+	Wed Aug 25 15:27:22 1999  Gavin Romig-Koch  <gavin@cygnus.com>
+	* combine.c (nonzero_bits) : Allow single-ly set registers to be
+	anywere in the function only if they are pseudos and set before
+	being used (not live at the start of the function).
+	(num_sign_bit_copies) : Same.
+	(get_last_value_validate) : Same.
+	(get_last_value) : Same.
+
+	Fri Mar  3 12:49:28 2000  J"orn Rennecke <amylaar@cygnus.co.uk>
+        * reload1.c (reload_combine_note_use): Handle return register USEs.
+	REG case: Handle multi-hard-register hard regs.
+
+2001-03-30  Bernd Schmidt  <bernds@redhat.com>
+
+	* jump.c (delete_barrier_successors): Fix error in last change.
+
+	* reload1.c (delete_output_reload): Call eliminate_regs on substed.
+	(reload_as_needed): Call update_eliminable_offsets a bit later.
+
+	* final.c (cleanup_subreg_operands): Also clean up inside MEMs.
+
+	Mon Oct  4 02:31:20 1999  Mark Mitchell  <mark@codesourcery.com>
+	* mips.md: Define conditional move patterns for floating point
+	operands and DI mode conditions.
+
+	2000-11-25  Jakub Jelinek  <jakub@redhat.com>
+	* config/sparc/sparc.md (muldi3_v8plus): Remove H constraint.
+	Handle CONST_INT as second argument.
+
+2001-03-28  Bernd Schmidt  <bernds@redhat.com>
+
+	* flow.c (propagate_block): When trying to delete a case vector, cope
+	if its label has LABEL_PRESERVE_P set.
+	* jump.c (jump_optimize_1): Move call to delete_barrier_successors to
+	a point where JUMP_LABELS and LABEL_NUSES are set up properly.
+	(delete_barrier_successors): If deleting a table jump, delete the case
+	vector as well.
+	* varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
+	so it won't get deleted.
+
+Tue Mar 20 18:31:48 2001  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
+
+	1999-11-30  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
+        * c-lex.c (yylex): With -Wtraditional, when the ANSI type of an
+	integer constant does not match the traditional type, limit the
+	warnings to cases where the base of the type is ten.
+
+        * invoke.texi (-Wtraditional): Document it.
+
+2001-03-20  David O'Brien  <obrien@FreeBSD.org>
+
+	from 2000-07-12  Zack Weinberg  <zack@wolery.cumb.org>
+	* final.c (profile_function): Do not emit profile counters in
+	the data section, if NO_PROFILE_COUNTERS is defined.
+	* tm.texi: Document NO_PROFILE_COUNTERS.  Update doc for
+	FUNCTION_PROFILER.
+
+	from 2000-10-02  David O'Brien  <obrien@dragon.nuxi.com>
+	* config/i386/freebsd.h (NO_PROFILE_COUNTERS): Define.
+
+2001-03-19  Bernd Schmidt  <bernds@redhat.com>
+
+	* version.c: Bump.
+
+	2000-01-18  Martin v. Löwis  <loewis@informatik.hu-berlin.de>
+	* c-parse.in (SAVE_WARN_FLAGS): Create an INTEGER_CST.
+	(RESTORE_WARN_FLAGS): Unpack it.
+	Change semantic type of extension to ttype.
+	* c-common.c (split_specs_attrs): Expect an INTEGER_CST.
+	* c-parse.y, c-parse.c, objc/objc-parse.y,
+	objc/objc-parse.c: Regenerate.
+
+	Wed Sep  1 09:12:02 1999  Jim Kingdon  <http://developer.redhat.com>
+	* c-parse.in: save and restore warn_pointer_arith on __extension__
+	along with pedantic.
+	(SAVE_WARN_FLAGS, RESTORE_WARN_FLAGS): Added.
+	Set the type of extension to itype rather than $<itype>1 kludge.
+	* extend.texi (Alternate Keywords): Adjust documentation.
+
+	Bring back the sjlj eh fixes.
+	* expr.c (expand_builtin_setjmp_setup): New.
+	(expand_builtin_setjmp_receiver): New.
+	(expand_builtin_setjmp): Split out _setup and _receiver functions.
+	Move argument parsing in from ...
+	(expand_builtin): ... here.
+	* except.c (receive_exception_label): Branch around receiver
+	unless new-style exceptions.  Call expand_builtin_setjmp_receiver.
+	(start_dynamic_handler): Call expand_builtin_setjmp_setup.
+	* expr.h: Update builtin setjmp decls.
+
 Fri Mar 16 12:46:19 GMT 2001 Bernd Schmidt  (bernds@redhat.com)
 
 	* gcc-2.95.3 Released.

Re: making a 2.95.4 release

[law]

In message <20020328092214.A87939@dragon.nuxi.com>, "David O'Brien" writes:
 > Hello Jeff,
 > 
 > As GCC 2.95 release engineer, would you please create a 2.95.4 release
 > from the 'gcc-2_95-branch'?  Considering the maturity of the branch, I
 > cannot imagine this would take much more than creating the tarballs and
 > putting them on ftp.gnu.org.
Sorry.  I have no plans to make additional 2.95.x releases.


jeff

Re: making a 2.95.4 release

[Gerald Pfeifer]

On Thu, 28 Mar 2002, David O'Brien wrote:
> As GCC 2.95 release engineer, would you please create a 2.95.4 release
> from the 'gcc-2_95-branch'?

Bernd Schmidt is now release manager for GCC 2.95.x (so I'm Cc:ing him).

(Bernd, David's original message with detailed rationale and ChangeLog
is at <http://gcc.gnu.org/ml/gcc/2002-03/msg01772.html>.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: making a 2.95.4 release

[Bernd Schmidt]

On Thu, 28 Mar 2002, David O'Brien wrote:

> Hello Jeff,
> 
> As GCC 2.95 release engineer, would you please create a 2.95.4 release
> from the 'gcc-2_95-branch'?  Considering the maturity of the branch, I
> cannot imagine this would take much more than creating the tarballs and
> putting them on ftp.gnu.org.

It would be nice if the problems the 2.95 branch has with compiling glibc
could be fixed - that might motivate me to have another go at a release.
There's also at least one bug report about miscompilations with 2.95.x.

> For various reason people are still downloading and using 2.95.3 to this
> day.  GCC 3.x is also inappropriate for some of the BSD releases due to
> the major changes between 2.95->3.0.  Just this week someone else was
> asking for a 2.95.4 release.

Why can't you just use the current sources on the branch for BSD?
What about gcc 3.1 which is about to be released?


Bernd

Re: making a 2.95.4 release

[David O'Brien]

On Thu, Mar 28, 2002 at 06:10:24PM +0000, Bernd Schmidt wrote:
> On Thu, 28 Mar 2002, David O'Brien wrote:
> 
> > Hello Jeff,
> > 
> > As GCC 2.95 release engineer, would you please create a 2.95.4 release
> > from the 'gcc-2_95-branch'?  Considering the maturity of the branch, I
> > cannot imagine this would take much more than creating the tarballs and
> > putting them on ftp.gnu.org.
> 
> It would be nice if the problems the 2.95 branch has with compiling glibc
> could be fixed - that might motivate me to have another go at a release.
> There's also at least one bug report about miscompilations with 2.95.x.
> 
> > For various reason people are still downloading and using 2.95.3 to this
> > day.  GCC 3.x is also inappropriate for some of the BSD releases due to
> > the major changes between 2.95->3.0.  Just this week someone else was
> > asking for a 2.95.4 release.
> 
> Why can't you just use the current sources on the branch for BSD?
> What about gcc 3.1 which is about to be released?

Why couldn't Red Hat do that in the EGCS 1.0 days?
Why didn't you tell the people trying to build glibc that?
Because switching FreeBSD 4.6 from GCC 2.95 to 3.x is totally
unreasonable.  Same for switching for OpenBSD 3.1.  Same for Debian I
guess (why aren't they using 3.0)?
Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
OpenBSD combined?  We had a bug fix in 2.95.3_test3, but it was removed
for the 2.95.3 release because of HP-UX issues (I think *BSD outnumbers
the number of people using GCC on HP-UX).  Well now we have a fix
committed in the tree and we can't get a release made with it?

Re: making a 2.95.4 release

[Philip Blundell]

On Thu, 2002-03-28 at 18:18, David O'Brien wrote:
> Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
> OpenBSD combined?  

To be fair, from Debian's point of view a 2.95.4 release would make
virtually no practical difference.  The source tarball we currently use
is essentially a snapshot from the top of the 2.95 branch in CVS, and we
apply a whole pile of Debian-specific patches anyway, so it makes no
real odds to us whether it's annointed as an FSF release or not.

p.

Re: making a 2.95.4 release

[Daniel Jacobowitz]

On Thu, Mar 28, 2002 at 10:18:09AM -0800, David O'Brien wrote:
> unreasonable.  Same for switching for OpenBSD 3.1.  Same for Debian I
> guess (why aren't they using 3.0)?

Because (ugh) we've been in the process of working-on-releasing-3.0 for
a very long time.  It's our intention to switch to (probably) 3.1 not
long after it's released, if our own release finally goes out
eventually.

At least I think that's our intention :)  I speak for no one.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: making a 2.95.4 release

[Bernd Schmidt]

On Thu, 28 Mar 2002, David O'Brien wrote:

> Why couldn't Red Hat do that in the EGCS 1.0 days?

Do what, exactly?

> Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
> OpenBSD combined?

Not sure how Red Hat factors into the equation, since our OS people are
no longer using 2.95.x.
I thought you are shipping a separate set of gcc sources for BSD - so
where's the problem with just using code from the branch for that?  I fail
to see how making it an official release would be of any help.

I might be persuaded, but it's not a simple matter of making tarballs
and putting them on ftp.gnu.org.  There needs to be more testing to make
sure there are no regressions, and it could be difficult to find the
volunteers for that with 3.1 around the corner.  And if we make another
official release, I simply think it would be nice to fix more problems
first.


Bernd

Re: making a 2.95.4 release

[David O'Brien]

On Thu, Mar 28, 2002 at 07:21:16PM +0000, Philip Blundell wrote:
> On Thu, 2002-03-28 at 18:18, David O'Brien wrote:
> > Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
> > OpenBSD combined?  
> 
> To be fair, from Debian's point of view a 2.95.4 release would make
> virtually no practical difference.  The source tarball we currently use
> is essentially a snapshot from the top of the 2.95 branch in CVS, and we
> apply a whole pile of Debian-specific patches anyway, so it makes no
> real odds to us whether it's annointed as an FSF release or not.

Debian should probably not be calling its GCC "2.95.4" as that confuses
things as Red Hat's "2.96" did.  Having an offical 2.95.4 release would
legitimize the version of Debian GCC.

-- 
-- David  (obrien@FreeBSD.org)

Re: making a 2.95.4 release

[David O'Brien]

On Thu, Mar 28, 2002 at 07:46:36PM +0000, Bernd Schmidt wrote:
> > Why couldn't Red Hat do that in the EGCS 1.0 days?
> 
> Do what, exactly?

Why couldn't Red Hat use EGCS 1.0.2 + patches.  Instead EGCS 1.0.3 as
released for Red Hat's needs.
    http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html
    EGCS 1.0.3 is a minor update to the EGCS 1.0.2 compiler to fix a few
    problems reported by Red Hat for builds of Red Hat 5.1.


> > Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
> > OpenBSD combined?
> 
> Not sure how Red Hat factors into the equation, since our OS people are
> no longer using 2.95.x.

See above.  It factors in because a need of Red Hat was the reason for a
release from what was suppose to be a "dead" branch.


> I thought you are shipping a separate set of gcc sources for BSD - so
> where's the problem with just using code from the branch for that?  I fail
> to see how making it an official release would be of any help.

Ok, but then I will call it 2.95.4 and I don't want any crap for using a
non-"real" version number.  Also I will have to move our port to using
CVS for distfile fetching as when we switch to 3.1, about 1/2 of the 6000
3rd party apps will not compile with 3.1.  Thus they will have to depend
our our gcc295 port.

Making a 2.95.4 release also helps the other people out there that are
still using 2.95.3 get a few bug fixes.


> There needs to be more testing to make
> sure there are no regressions, and it could be difficult to find the
> volunteers for that with 3.1 around the corner.  And if we make another
> official release, I simply think it would be nice to fix more problems
> first.

Fixing more problems would be nice, but will people make any more commits
to the 2.95 branch?

-- 
-- David  (obrien@FreeBSD.org)

Re: making a 2.95.4 release

[Daniel Jacobowitz]

On Thu, Mar 28, 2002 at 11:49:00AM -0800, David O'Brien wrote:
> On Thu, Mar 28, 2002 at 07:21:16PM +0000, Philip Blundell wrote:
> > On Thu, 2002-03-28 at 18:18, David O'Brien wrote:
> > > Does Red Hat and glibc carry more stock than Debian, FreeBSD, NetBSD,
> > > OpenBSD combined?  
> > 
> > To be fair, from Debian's point of view a 2.95.4 release would make
> > virtually no practical difference.  The source tarball we currently use
> > is essentially a snapshot from the top of the 2.95 branch in CVS, and we
> > apply a whole pile of Debian-specific patches anyway, so it makes no
> > real odds to us whether it's annointed as an FSF release or not.
> 
> Debian should probably not be calling its GCC "2.95.4" as that confuses
> things as Red Hat's "2.96" did.  Having an offical 2.95.4 release would
> legitimize the version of Debian GCC.

drow@nevyn:~% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

We don't feel any need to "legitimize" it - we still would almost
certainly be applying patches to a new branch release.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: making a 2.95.4 release

[Bernd Schmidt]

On Thu, 28 Mar 2002, David O'Brien wrote:

> On Thu, Mar 28, 2002 at 07:46:36PM +0000, Bernd Schmidt wrote:
> > > Why couldn't Red Hat do that in the EGCS 1.0 days?
> > 
> > Do what, exactly?
> 
> Why couldn't Red Hat use EGCS 1.0.2 + patches.  Instead EGCS 1.0.3 as
> released for Red Hat's needs.
>     http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html
>     EGCS 1.0.3 is a minor update to the EGCS 1.0.2 compiler to fix a few
>     problems reported by Red Hat for builds of Red Hat 5.1.

I don't really recall the history, but I'm guessing that the egcs-1.0
branch wasn't as ancient as 2.95 is these days, and fixing bugs that
showed up in a RH build was considered a good idea.  Not sure it was made
"just for Red Hat's needs".  If it was, the idea may have been to make it
possible for them to use egcs instead of gcc - the egcs project was fairly
new back then and getting one of the Linux distros to include it may have
been considered important to pick up more momentum.  Just guessing.


Bernd

Re: making a 2.95.4 release

[law]

In message <20020328115609.E90592@dragon.nuxi.com>, "David O'Brien" writes:
 > On Thu, Mar 28, 2002 at 07:46:36PM +0000, Bernd Schmidt wrote:
 > > > Why couldn't Red Hat do that in the EGCS 1.0 days?
 > > 
 > > Do what, exactly?
 > 
 > Why couldn't Red Hat use EGCS 1.0.2 + patches.  Instead EGCS 1.0.3 as
 > released for Red Hat's needs.
 >     http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html
 >     EGCS 1.0.3 is a minor update to the EGCS 1.0.2 compiler to fix a few
 >     problems reported by Red Hat for builds of Red Hat 5.1.
Are we going to beat that dead horse again?  Yes we worked closely with Red Hat
to fix problems they were having.  We also fixed bugs that were brought to
our attention by other parties.


jeff

Re: making a 2.95.4 release

[Richard Zidlicky]

On Thu, Mar 28, 2002 at 09:22:14AM -0800, David O'Brien wrote:

> For various reason people are still downloading and using 2.95.3 to this
> day.  GCC 3.x is also inappropriate for some of the BSD releases due to
> the major changes between 2.95->3.0.  Just this week someone else was
> asking for a 2.95.4 release.

yes, there are difference between 2.95 and 3.0 or 3.1. However for 
many architectures 2.95 is too old and only additional headache.
I would really appreciate if some of the bigger distributions would
finally drop the old c**p. The fact that a few packages need little 
patches is imho not an excuse to use a broken compiler forever.

Personally I use various 3.0 snapshots ever since the first 3.0 
prerelease to keep the m68k/Q40 distribution up to date (well 
trying desperately) and most problems were really minor. 
Generally my experiences with 3.0 are extremely positive, only 
2.7.2.3 was similarly reliable - great thanks to the gcc hackers 
and especially Roman Zippel who fixed the m68k port.
2.95 official releases otoh appear to get worse with every release
- at least for m68k - so I have stopped using it at all after briefly 
testing 2.95.3.

Richard

Re: making a 2.95.4 release

[Gerald Pfeifer]

Over the weekend I thought a bit about this issue, and there might be
an alternate solution:

David, does FreeBSD need a "full-blown" GCC 2.95.4 release, or would some
GCC 2.95.4-20020402 "snapshot" suffice as well?  (We could even put that
on ftp.gnu.org, I suppose.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: making a 2.95.4 release

[Joe Buck]

> Over the weekend I thought a bit about this issue, and there might be
> an alternate solution:
> 
> David, does FreeBSD need a "full-blown" GCC 2.95.4 release, or would some
> GCC 2.95.4-20020402 "snapshot" suffice as well?  (We could even put that
> on ftp.gnu.org, I suppose.)

If we put it on ftp.gnu.org it will be perceived as a release and should
be tested as a release.  The Debian folks are also going with something
they label "2.95.4", so some unification might be in order.

On the other hand, the timing right now is not good, with people focused
on 3.1

Re: making a 2.95.4 release

[Wolfram Gloger]

Hello,

> It would be nice if the problems the 2.95 branch has with compiling glibc
> could be fixed - that might motivate me to have another go at a release.

What problems exactly are you referring to?  FWIW, I have successfully
compiled glibc-2.2.5 and glibc-2.2.90 from CVS (a couple of weeks ago)
with gcc-2.95-2.95.4.ds2-0.010604 (the Debian release from last June).
The former is my production glibc package and I see no problems.

So I suspect that whatever problems you mean, have been _long_ fixed,
at least in the Debian patch set.

Regards,
Wolfram.

Re: making a 2.95.4 release

[Erik Schnetter]

On Sun, 31 Mar 2002 14:06:18 +0200, Richard Zidlicky wrote:

> On Thu, Mar 28, 2002 at 09:22:14AM -0800, David O'Brien wrote:
>
> > For various reason people are still downloading and using 2.95.3 to this
> > day.  GCC 3.x is also inappropriate for some of the BSD releases due to
> > the major changes between 2.95->3.0.  Just this week someone else was
> > asking for a 2.95.4 release.
>
> yes, there are difference between 2.95 and 3.0 or 3.1. However for 
> many architectures 2.95 is too old and only additional headache.
> I would really appreciate if some of the bigger distributions would
> finally drop the old c**p. The fact that a few packages need little 
> patches is imho not an excuse to use a broken compiler forever.

gcc 3.0 was for a long time unsuitable for me due to bugs in preprocessing 
Fortran code.  gcc 3.0.4 is (finally) the first version that works for me.  I 
decided to switch not yet, because the C++ incompatibilities between 2.95 and 
3.0 would force me to recompile many libraries, and force me to compile some 
libraries myself where I can right now use a precompiled package.

I am using SuSE 7.3, and I am glad they did not swich to 3.0 that quickly.  
For me, the compilers are not the tools I develop, but are the tools I 
develop /with/.  Just knowing about the old bugs is often good enough for me, 
and is better than to spend a week or two recompiling everything, and finding 
new workarounds for the new bugs.

I am not asking for a 2.95.4 release, because 2.95.3 works fine for me.  But 
you should not call these versions "old c**p", because -- from my point of 
view -- the 3.0 releases are more broken than 2.95, in the very personal 
sense that I have had more problems with them so far.  3.0.4 seems to be all 
right by now, but I would still trust it less than 2.95.3.  I hope that the 
new SuSE 8.0 will be based on 3.0.4, but I even more hope it won't be based 
on 3.0.3.

-erik

-- 
Erik Schnetter <schnetter@uni-tuebingen.de>
Web: http://www.tat.physik.uni-tuebingen.de/~schnette/