This is the mail archive of the
mailing list for the GCC project.
Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
- From: Markus Milleder <markus dot milleder at generali dot at>
- To: bunk at stusta dot de
- Cc: fortran at gcc dot gnu dot org, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, vincent+gcc at vinc17 dot org
- Date: Tue, 14 Oct 2008 14:23:48 +0200
- Subject: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
Adrian Bunk schrieb am 13.10.2008 17:41:15:
> On Mon, Oct 13, 2008 at 04:42:08PM +0200, Markus Milleder wrote:
> > Is there any reason not to demand 2.3.2 for GCC 4.4 ? Or even the
> newest MPFR version published before creating the GCC 4.4 release
> branch (which could be 2.3.3) ?
> Upgrading can cause the user some unneeded work.
> E.g. the next stable release of Debian will likely ship with 2.3.1 .
> So in this specific case fulfilling a 2.3.1 requirement would be easy,
> while a 2.3.2 requirement would make it much harder to build gcc 4.4 .
Much harder ?
I don't think anybody who tries to build GCC from source will have any
problem building MPFR first.
I can see how a distribution will probably want to have at least the
MPFR version GCC demands, which would force an MPFR upgrade to
accompany a GCC 4.4 package.
> And upgrading from 2.3.1 to let's say 3.0.0 might be a bad choice if
> the new version contains regressions.
That's why I said "before branching", this gives a time window to detect
such regressions. While the cutoff date for moving to a new revision
of MPFR may be somewhat earlier, my idea was to demand a rather current
Changing to 3.0.0 - which implies much larger changes than 2.3.3 - is
IMHO stage 1 material, maybe stage 2 if the release notes make it
exceedingly clear that the major version change is only because
of major new features, with no changes to existing ones.