This is the mail archive of the
mailing list for the GCC project.
Re: Testsuite ad RedHat 7
- To: jfm2 at club-internet dot fr
- Subject: Re: Testsuite ad RedHat 7
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Tue, 10 Oct 2000 18:03:41 +0200
- Cc: gcc at gcc dot gnu dot org
- Organization: Ecole Normale Superieure (quatramaran)
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
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
Note that the 2.95 branch is fairly good. It is *quite* known that gcc 2.95
has issues with optimizations larger than -O2.
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 ?
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.