(a couple of days to calm down is often useful...)
Sasha Pachev <sasha@stripped> writes:
> On Saturday 03 November 2001 01:53 pm, Trond Eivind Glomsrød wrote:
> > Let's be more precise here - this isn't about gnerating bad
> > code. The issues with "non-standard coding styles" are about 2.96RH
> > (and 3.0, for that matter) rejecting non-standards compliant
> > code. It's a lot stricter than earlier compilers.
>
> I understand the need for high standard compliance, and have nothing against
> it. What I am against is enforcing this compliance with the sword, so to
> speak - completely bailing out instead of just issuing a warning. Perhaps
> bailing out is a good idea for the author of the package, but it is terrible
> for the poor fellow that has just barely learned the ropes of system
> administration - now he cannot install half of the packages out there, and it
> would be very far from truth to say that every package that has not 100%
> standard-compilant source is useless.
Not useless - "Broken, can be fixed". (it does complain in some cases,
while continuing compiling, though - note that this is not a
RH-policy, but rather how gcc works)
> And speaking about generating buggy code, up to this day, the advice we offer
> to our customers is to stay away from anything compiled with gcc 2.96 as far
> as MySQL is concerned, which unfortunately includes your MySQL
> binary.
That's bad advice. 2.96RH is currently the least buggy compiler
around (none are bugfree)
> We've had several of our customers report random crashes and table corruption on
> binaries compiled with 2.96. All without exception solved their
> problems by installing our standard binary, which is compiled with
> gcc 2.91.
1) Make sure the latest 2.96RH update is installed, as bugs has been
fixed since RHL 7
2) The mysql assembly code may have yet undiscovered bugs (depending
on compiler-specific behaviour). Some have been fixed, but the
safest is to just not use it
3) Using the compat-compiler will cause old libraries (glibc 2.1) to
be used instead. One feature this will probably break is large
files.
> So, needless to say, our level of confidence in 2.96 is very low.
My confidence in it is very high - I trust it more than gcc 3 and gcc
2.95 (both of which were rather bad releases), and egcs 1.1.2 is
pretty old and doesn't compile code using C++ features which have been
available for years. It's also deemed good for e.g. kernel
development, and used for that (by Alan Cox and others). Unlike
earlier compilers, there isn't any known miscompilations with it.
> "It never crashed from me" quality assurance simply does not cut it
> when you deal with a mission-critical server handling a million queries per
> hour. Something so critical as a compiler cannot really be called stable
> until the maintainer of at least every major package confirms to you that it
> works OK with it.
Extensive test suites are used to verify every build of it.
> The binaries produced with gcc 2.95 and gcc 2.91 are good enough in terms of
> speed, and they are stable. Whatever advantage comes from using 2.96 is
> simply not worth the risk for us and for our users. And you can be sure that
> you would have heard a lot more good words for Redhat 7.x series from us if
> you held back your urge to be on the bleeding edge and at least compiled
> MySQL with gcc 2.95.
gcc 2.95 was just to buggy to use (especially on non-IA32 platforms,
but also on IA32). Some of the bugs in it has been fixed since then,
but many remain. Due to the need to preserve binary compatiblity, some
of them can't be fixed either.
> I still do not understand why you could not make kcc the default compiler and
> call gcc 2.96 bravesoulcc or something like that.
egcs 1.1.2 isn't used for anything anymore - it was used for 2.2
kernels when RHL 7 was released, the bug _in the kernel_ which made
that necesarry was fixed shortly after.
> Brave souls do not mind beta testing but they get really ticked when
>you give them beta quality and call it stable.
It's not beta, it's the best gcc-based compiler out there.
I'm not looking forward to the gcc 3 move we'll eventually do, I'm
very happy with what we have (gcc 3 is a lot buggier and moves even
closer to C++ standards compliance than 2.96RH).
More info can be found at http://www.bero.org/gcc296.html
--
Trond Eivind Glomsrød
Red Hat, Inc.
