This is the mail archive of the
mailing list for the GCC project.
Re: Announce: MPFR 2.2.1 is released
- From: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- To: Joe Buck <Joe dot Buck at synopsys dot COM>
- Cc: Vincent Lefevre <vincent at vinc17 dot org>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, gerald at pfeifer dot com
- Date: Mon, 4 Dec 2006 21:32:19 -0500 (EST)
- Subject: Re: Announce: MPFR 2.2.1 is released
- References: <20061129110210.GA24271@prunille.vinc17.org> <Pine.GSO.firstname.lastname@example.org> <20061204174841.GL21441@synopsys.com>
On Mon, 4 Dec 2006, Joe Buck wrote:
> On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> > Hi Vincent, thanks for making this release. Since this version of mpfr
> > fixes important bugs encountered by GCC, I've updated the gcc
> > documentation and error messages to refer to version 2.2.1.
> > I have NOT (yet) updated gcc's configure to force the issue. I'll wait a
> > little while to let people upgrade.
> IMHO, you should *never* update gcc's configure to force the issue. To do
> so would be unprecedented.
> configure doesn't refuse to build gcc with older binutils versions, even
> though those versions cause some tests to fail that pass with newer
> versions. Similarly, people aren't forced to upgrade their glibc
> because some tests fail with older versions.
> In my view, the only time configure should fail because of an
> old library version is if going ahead with the build would produce a
> completely nonfunctional compiler. I wouldn't care if a warning message
> is generated.
Some people have argued we should wait until stage3 because upgrading
gmp/mpfr on a lot of machines is a pain in the butt. I sympathize and
agree, however I worry that if we wait until then and then see that
mpfr-2.2.1 introduces a problem we won't find out until very late in the
release process. My philosophy is we should test ASAP (now) what we
intend to ship later on.
OTOH, Joe you're arguing we should never require people to upgrade. Well
I think that's unfair to people who rely on gcc to produce correct code.
Yes, I know *all* compilers have bugs. But these are known fixed bugs (in
mpfr) that you're essentially saying we shouldn't ever "fix" through the
minimum library required. I think it's unworkable to freeze our gmp/mpfr
requirements for all time. Once more in stage3 might be acceptable, but
frozen forever is too extreme IMHO.
With all modestly in mind, I foresaw these problems when I started this
project. My initial gut instinct was to include the gmp/mpfr sources in
the tree and have the top level configure build them. That way we could
ship gcc with the latest greatest sources for these libraries and avoid
pain for anyone (gcc developers or users) who want to build gcc. We could
import fixes to the libs without disrupting gcc work. No one would have
to propagate or install the libraries on their test machines.
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
I believe then these problems go away.
Kaveh R. Ghazi email@example.com