Re: Testsuite ad RedHat 7

[jfm2 at club-internet dot fr]

> 
> In article <20001010005052.3DBDCF428@agnes.fremen.dune> you write:
> >
> >
> >Has anyone run a testsuite on the compiler in RedHat 7 and compared
> >with a run using gcc-2.95.  This could settle the question of what
> >compiler is the less buggier once and for all.  It is not that
> >difficult to make gcc 2.95.2 core dump if you are agressive with
> >optimization flags so it cannot deemed perfect.
> 
> I think the Steering Committee made it pretty clear that shipping a 2.96
> e.g., *development* snapshot, with an official `release' is a very stupid
> decision.
> 

I think you know the expression "being more royalist than the king"
is't it?  First the steering commitee did not say that.

Also I couldn't care less of what is the official status of gcc 2.95
versus the compiler in RH 7.  What matters for me is which one has the
lesser and smaller bugs.  For that as in many other subjects I tend to
use a method called _measuring_.

And the situation now is:

-egcs is old and produces mediocre code for floating point

-gcc 2.95 breaks compatibility with egcs and will not be compatible
 with gcc 3 (I am referring to C++).  I have also found several bugs
 in it.  It also has not been updated in months, thus meaning that we
 are still suffering the same bugs month after month and this
 agreviated by the fact patches fxing them are not made public

-the so-called gcc-2.96 is not compatrible with egcs or gcc-2.95 and 
 probably not with gcc 3.  

> By and large, if we needed proof that RedHat does not own gcc yet, we've
> got in a very major way.
> 
> The best thing to do *right now* is ignore the RedHat blunder and forge on
> to 3.0.
> 
> Note that the 2.95 branch is fairly good. It is *quite* known that gcc 2.95
> has issues with optimizations larger than -O2. 
> 

In french this  is called a bug.  BTW try compiling the glibc with
gcc 2.95 and the following flags: -O2 -finline-functions -mcpu=i686 
-malign-stack=2  and all you will get is a core dump


> One goal of 3.0 is to get things more stable in that regards.
> 
> Who would dare to use large optimizations on gcc 2.95.x except for those
> daredevil linux people anyways ?
> 

People looking for speed bonus.  You see one of the ways to get faster
apps is with better compilers and more agressive flags.  Those flags
exist to be exerted and in case they generate buggy code to be fixed
(and in the interim documented or disabled).  The first phase of this
is trying them.  And if the compilers used for free software generate
slower code than those used by competition it means free software will
have a hand tied behind the back.  That is why it is important to know
what flags work and what flags don't instead of just compiling with
-O2 and never exerting other flags


> Minor flame: in my opinion, ceasing all development on the 2.95 branch 
> precipitated the problem. Not having frequent enough FSF releases is another
> part of the problem. When lots of packages have critical bugs that are only
> fixed in development versions, when actual maintainers who should know better
> brew their own major linux releases on top of development snapshots, suddenly
> the distinction between `stable' and `highly experimental' blurs.
> 
> I respect the recent gcc cleanup (more releases, better managed development,
> good focus on 3.0 issues), I would just ask for slightly more Public  Relation
> where 2.95 vs. 2.96 vs. 3.0 is concerned.  In my mind, gcc has the possibility
> to set a much better standard of robustness and shipping schedule than 
> your average GNU tool.
> 
> 

This is one of the problems in gcc, releases and bug fixes are
unfrequent.  That means that we users of gcc have to live for months
and months with suboptimal compilers and in addition htting the same
bugs again and again.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org