This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.0 Status Report (2004-01-05)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Toon Moene <toon at moene dot indiv dot nluug dot nl>, Giovanni Bajo <giovannibajo at libero dot it>, Mark Mitchell <mark at codesourcery dot com>
- Date: Sun, 9 Jan 2005 19:56:07 +0100
- Subject: Re: GCC 4.0 Status Report (2004-01-05)
- References: <41DBA1E9.7090804@codesourcery.com> <11457226.1105268829984.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net> <41E12873.1070102@moene.indiv.nluug.nl> <200501091837.43067.paul@codesourcery.com>
- Reply-to: Richard Guenther <richard dot guenther at gmail dot com>
On Sun, 9 Jan 2005 18:37:41 +0000, Paul Brook <paul@codesourcery.com> wrote:
> On Sunday 09 January 2005 12:49, Toon Moene wrote:
> > Giovanni Bajo wrote:
> > > Nonetheless, I would like to bring (again) to your attention the fact
> > > that gfortran regressions (wrt to g77) are not considered in this count.
> > > I understand that a new frontend means that we are going to live with
> > > regressions for quite a while (as you correctly said here:
> > > http://gcc.gnu.org/ml/gcc/2004-12/msg00614.html), but I reckon that we
> > > should at least consider the most important problems in the new frontend
> > > (wrong-code and the such). Tobias kindly grouped all the gfortran
> > > regressions in a meta-bug, http://gcc.gnu.org/PR19292.
> >
> > Our, i.e., the gfortran maintainers', assumption is that GNU/Linux
> > distributors (and other whole-OS distributors who use the GNU
> > compiler/linker/debugger toolchain) will offer access to the g77 binary
> > via some method (e.g., by installing it in /opt/bin and the run-time
> > library in /opt/lib). In that way, people who need g77 because they're
> > bitten by the incompatibilities in gfortran have a way out.
>
> Right. I think including gfortran in the 4.0 release criteria, hence implying
> a release-worthy level of quality would be a lie.
>
> Obviously we'll continue fixing bugs, and things like the meta-bug you mention
> help. However I don't see what benefit including this in the official gcc4
> stats gives us.
I think that at least known wrong-code bugs for primary release
platforms should be fixed or documented as such.
Richard.