>>>>> "Fons" == Fons Rademakers <Fons.Rademakers@cern.ch> writes:
Fons> Indeed the 2.96 compiler is very buggy and if it does not segv
Fons> itself, it produces numerical incorrect code with any optimization
Fons> higher than -O. Porting ROOT resulted in compiler segv's in three
Fons> files (and three bug reports to gcc-bugs). Two of the segv's
Fons> happened with -O2 and disappeared with -O and one happened with -O
Fons> but I could work around it with some change in the code. So in the
Fons> end I could compile everything with -O. Compiling with -O2 (except
Fons> for the two files that failed and that were done with -O) resulted
Fons> in an executable that produced so many errors in double precision
Fons> code that I did not even try to look in detail at the problems.
Fons> Note that by default on Linux with egcs 1.1.x and gcc 2.95.2 we
Fons> compile with -O2 and obtain correct results.
Hi Fons
Allow to point your attention to the attached article posted to
linux-kernel about the choice of compiler in Red Hat 7.0. For those who
don't know Richard, let me just say that he is one of the core gcc
developers who has contributed incredible amounts of work to both gcc
and Linux.
In your gripe about gcc in Red Hat 7 compares it with gcc-2.95.2 which
is known to be broken and quite a few gcc developers directly tell you
to stay away from it. This of course doesn't stop the usual bunch of
I-know-better-than-the-guy-who-wrote-the-code people from screaming
about how they have compiled the Linux kernel with it for ages and it
never failed for them. Or should we say, they never noticed the problems
in their specific configuration or because they don't run the kernel
long enough to notice. Never mind that gcc-2.95.2 has been abandonned
for a long time by now and is incompatible with gcc-2.96+.
As Richard points out, gcc-2.96 at least has the property that the C++
API is complete, though the ABI is not, so once you have ported your
code to the new compiler it is very likely to work with the final
3.0. Going for 2.95 would just give you yet another interem step to go
through.
With regard to the bugs you found in the compiler I asume you posted
those to bugzilla.redhat.com as well as gcc-bugs. If you expect Red Hat
to catch the bugs and fix them you need to tell them directly about it,
plus it is of course their problem to fix their mess, not the regular
gcc developers.
Fons> Another issue is that RH7.0 comes with a pre-release of glibc
Fons> 2.2. This new version is not compatible with the previous glibc
Fons> 2.1 and in some cases requires some porting effort. Assuming that
Fons> the data structures used by pre-glibc 2.2 stay the same in glibc
Fons> 2.2 this is not such a big issue as the bad compiler. One of the
Fons> incompatibilities I ran into was that the type fpos_t used by
Fons> fgetpos(), fsetpos() is now a struct and not anymore an long, so
Fons> code like: fpos_t oldpos, pos; ... if (oldpos == pos) ... fails
Fons> to compile.
As Dan Pop already pointed out to you your code is broken so this
complaint is void. glibc-2.2 in Red Hat 7.0 is a 2.1.94 beta snapshot
which is very very close to what we expect to see shipped in the final
glibc-2.2. I do not anticipate ABI changes though it of course cannot be
ruled out if someone discovers a major bug tomorrow that requires a real
change. In that case it is Red Hat's job to solve the problem in their
distribution though.
I have been working closely with the core glibc developers over the last
6 months and glibc-2.2 is in a very good state right now.
Fons> Application providers are really screwed by RedHat. Of course
Fons> people will install RH7.0 and of course they expect their apps to
Fons> be available. And the app providers have to clean up the mess!
Fons, have you been reading too much slashdot recently? Why are
application providers screwed? glibc-2.2 *is* the new standard libc in
Linux and it is what you can expect the LSB (eg. Linux Standards Base)
to standardize on, all vendors will switch to it at some point or stay
non standard. If you install Red Hat 7 at this point and expect
everything to work out of the box then it's really your own problem.
Fons> Everybody who wants RH7.0 for the new GUI features and other apps,
Fons> should at least install 2.95.2 if they also want to run scientific
Fons> codes.
*NOBODY* should install gcc-2.95.2 if they want any code to run at
all. Mixing 2.95.2 and 2.96 is brain damage and is going to cause you
problems, what you should do is to help iron out the problems/bugs in
2.96 and move on from there. Your gcc-2.95.2 compiled application will
definately not work with the libstdc++ libraries in the system which are
compiled with 2.96.
Installing gcc-2.95.2 now is like deliverately blowing off your leg with
a machine gun.
So I am not particular fond of Red Hat shipping all these items in Red
Hat 7.0 already, IMHO the should have waited until glibc-2.2 at least
was released as a release candiate, in particular as glibc-2.2 is very
close to shipping in the final version. However the choice of compiler
was correct and the same goes for them shipping a CVS snapshot of
XFree4.
Jes
<#part type=message/rfc822 disposition=inline>
X-From-Line: jes Mon Oct 2 11:12:21 2000
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from jes.mailbox.cern.ch
by localhost with IMAP (fetchmail-5.0.4)
for jes@localhost (single-drop); Mon, 02 Oct 2000 11:12:21 +0200 (CEST)
Received: via tmail-4.1(10) for jes; Sun, 1 Oct 2000 21:09:47 +0200 (MET DST)
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38])
by mail6.cern.ch (8.9.3/8.9.3) with ESMTP id VAA05247
for <jes@mail6.cern.ch>; Sun, 1 Oct 2000 21:09:46 +0200 (MET DST)
Received: from smtp.linuxcare.com ([216.88.157.131])
by smtp1.cern.ch (8.9.3/8.9.3) with SMTP id VAA26101
for <Jes.Sorensen@cern.ch>; Sun, 1 Oct 2000 21:09:45 +0200 (MET DST)
X-Authentication-Warning: smtp1.cern.ch: Host [216.88.157.131] claimed to be smtp.linuxcare.com
Received: (qmail 31059 invoked by uid 825); 1 Oct 2000 19:09:45 -0000
Delivered-To: sorensen@smtp.linuxcare.com
Received: (qmail 31026 invoked by alias); 1 Oct 2000 19:09:45 -0000
Delivered-To: jes@linuxcare.com
Received: (qmail 30986 invoked from network); 1 Oct 2000 19:09:44 -0000
Received: from vger.kernel.org (199.183.24.194)
by smtp.linuxcare.com with SMTP; 1 Oct 2000 19:09:44 -0000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id <S131169AbQJATXm>; Sun, 1 Oct 2000 15:23:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
id <S131015AbQJATXc>; Sun, 1 Oct 2000 15:23:32 -0400
Received: from piglet.twiddle.net ([207.104.6.26]:58127 "EHLO
piglet.twiddle.net") by vger.kernel.org with ESMTP
id <S129543AbQJATXU>; Sun, 1 Oct 2000 15:23:20 -0400
Received: (from rth@localhost)
by piglet.twiddle.net (8.9.3/8.9.3) id MAA15734;
Sun, 1 Oct 2000 12:08:31 -0700
Date: Sun, 1 Oct 2000 12:08:31 -0700
From: Richard Henderson <rth@twiddle.net>
To: pcg@goof.com
Cc: alan@lxorguk.ukuu.org.uk, stefan@hello-penguin.com, tytso@MIT.EDU,
linux-kernel@vger.kernel.org
Subject: Re: What is up with Redhat 7.0?
Message-ID: <20001001120831.A15707@twiddle.net>
References: <20000930204421.A11324@cerebro.laendle> <E13fS03-0002Yb-00@the-village.bc.nu> <20000930213656.G11324@cerebro.laendle>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <20000930213656.G11324@cerebro.laendle>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
On Sat, Sep 30, 2000 at 09:36:56PM +0200, Marc Lehmann wrote:
> > Various people I associate with being senior in both glibc and gcc (people
> > like Ulrich Drepper and Jeff Law) were involved in the compiler and glibc
>
> they were involved, but I have reason to doubt that they actually agreed.
You would be wrong then. Management asked what version of gcc would
be best to support, we answered, they followed our recomendation.
If you want to blame someone in Red Hat for making the decision to
ship a gcc snapshot, then you might as well blame me.
The reasons are the following:
(1) 2.95 is the least stable release that we (the fsf gcc team) have
shipped in a long time. It does ok on x86, but is pathetic on the
other platforms that Red Hat cares about -- especially Alpha.
The late July snapshot we shipped is most definitely more stable,
largely I think due to Geoff's automated regression tester bitching
at people when they break the tree.
(2) C++ in 2.95 is already ABI incompatible with egcs 1.1 and gcc 3.0,
so clearly (to my mind anyway) it didn't matter whether we
shipped 2.95 or a snapshot, we would still be incompatible with
Red Hat 6 and Red Hat 8.
(3) While the C++ ABI for 3.0 is not complete, the API is. That is,
the snapshot we chose will be compatible with 3.0 at the source
level. With the exception of "export" I understand from Jason
that we are now very close to standards conformance.
(4) We could either spend our QA time reviving the dead 2.95 branch,
or we could spend that QA effort on mainline, helping get 3.0
stable.
Someone on this thread complained that the RPM that we shipped
is highly patched. Bar two (the subreg_byte patches), all of
those patches are in current cvs. Since at some point procedure
would not allow us to take a new snapshot, those 85 patches are
a visible side-effect of the QA work that was done.
Frankly, I didn't even consider C++ ABI compatibility with other
Linux vendors, since I think that's a losing proposition until
everyone is using gcc3. We were _already_ incompatible, since
there are a mix of egcs and gcc versions involved.
Flame away.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
<#/part>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:34 MET