[PATCH] Fix web/60933

[PATCH] Fix web/60933

[Richard Biener]

The GMP people complained that we "advertise" outdated versions
in our install instructions.  I tried to address that by not
explicitely listing a "good" version but only mention the version
that is the minimum requirement.  I also added a reference to
contrib/download_prerequesites as the recommended way to do
in-tree builds (so we don't get random bugreports for that
with untested combinations of gmp/mpfr/mpc versions).

We probably should try to bump the versions used by that script
to something more recent though (should we do that for the 4.9
branch even?).  Any idea what to choose here?  I'd say mpc
1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
of gmp?  We shouldn't change those versions too often, otherwise
we end up with a lot of garbage in gcc/infrastructure (we don't
want to break old versions of the script).

Meanwhile is does the patch look ok?

Thanks,
Richard.

2014-04-24  Richard Biener  <rguenther@suse.de>

	PR web/60933
	* doc/install.texi: Mention download_prerequesites as the
	recommended way to setup in-tree builds of gmp, mpfr, mpc,
	cloog and isl.  Do not advertise outdated versions of gmp,
	mpfr and mpc.

Index: gcc/doc/install.texi
===================================================================
--- gcc/doc/install.texi	(revision 209677)
+++ gcc/doc/install.texi	(working copy)
@@ -351,32 +351,41 @@ versions may work in some cases, but it'
 versions documented.  We appreciate bug reports about problems with
 newer versions, though.  If your OS vendor provides packages for the
 support libraries then using those packages may be the simplest way to
-install the libraries.
+install the libraries.  If you choose to build the library dependencies
+together with GCC you are encouraged to use the
+@command{download_prerequesites} script that comes with the GCC
+source tarball in the @file{contrib} directory.
+This downloads versions that were tested to build and
+work ok and prepares the source tree appropriately.
 
 @table @asis
-@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
+@item GNU Multiple Precision Library (GMP)
 
-Necessary to build GCC@.  If a GMP source distribution is found in a
+Necessary to build GCC@.  It can be downloaded from @uref{https://gmplib.org/}.
+Older versions than 4.2.3 will not work.
+If a GMP source distribution is found in a
 subdirectory of your GCC sources named @file{gmp}, it will be built
 together with GCC.  Alternatively, if GMP is already installed but it
 is not in your library search path, you will have to configure with the
 @option{--with-gmp} configure option.  See also @option{--with-gmp-lib}
 and @option{--with-gmp-include}.
 
-@item MPFR Library version 2.4.2 (or later)
+@item MPFR Library
 
 Necessary to build GCC@.  It can be downloaded from
-@uref{http://www.mpfr.org/}.  If an MPFR source distribution is found
+@uref{http://www.mpfr.org/}.  Older versions than 2.4.0 will not work.
+If an MPFR source distribution is found
 in a subdirectory of your GCC sources named @file{mpfr}, it will be
 built together with GCC.  Alternatively, if MPFR is already installed
 but it is not in your default library search path, the
 @option{--with-mpfr} configure option should be used.  See also
 @option{--with-mpfr-lib} and @option{--with-mpfr-include}.
 
-@item MPC Library version 0.8.1 (or later)
+@item MPC Library
 
 Necessary to build GCC@.  It can be downloaded from
-@uref{http://www.multiprecision.org/}.  If an MPC source distribution
+@uref{http://www.multiprecision.org/}.  Older versions than
+0.8.0 will not work.  If an MPC source distribution
 is found in a subdirectory of your GCC sources named @file{mpc}, it
 will be built together with GCC.  Alternatively, if MPC is already
 installed but it is not in your default library search path, the

Re: [PATCH] Fix web/60933

[Jakub Jelinek]

On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote:
> We probably should try to bump the versions used by that script
> to something more recent though (should we do that for the 4.9
> branch even?).  Any idea what to choose here?  I'd say mpc
> 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> of gmp?  We shouldn't change those versions too often, otherwise

For gmp 6.0.0, there were some issues with miscompilation of that on
Solaris, right?  Does it work elsewhere fine?  Just fuzzy memories.

> -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
> +@item GNU Multiple Precision Library (GMP)
>  
> -Necessary to build GCC@.  If a GMP source distribution is found in a
> +Necessary to build GCC@.  It can be downloaded from @uref{https://gmplib.org/}.
> +Older versions than 4.2.3 will not work.
> +If a GMP source distribution is found in a

Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3,
2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)?

	Jakub

Re: [PATCH] Fix web/60933

[Rainer Orth]

Richard Biener <rguenther@suse.de> writes:

> The GMP people complained that we "advertise" outdated versions
> in our install instructions.  I tried to address that by not
> explicitely listing a "good" version but only mention the version
> that is the minimum requirement.  I also added a reference to
> contrib/download_prerequesites as the recommended way to do
> in-tree builds (so we don't get random bugreports for that
> with untested combinations of gmp/mpfr/mpc versions).
>
> We probably should try to bump the versions used by that script
> to something more recent though (should we do that for the 4.9
> branch even?).  Any idea what to choose here?  I'd say mpc
> 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> of gmp?  We shouldn't change those versions too often, otherwise
> we end up with a lot of garbage in gcc/infrastructure (we don't
> want to break old versions of the script).
>
> Meanwhile is does the patch look ok?

I'd strongly advise against it: in the past we've had serious problems
with versions newer than advertised in install.texi on some platforms.
Until we have positive evidence that specific newer versions work on a
wide range of platforms, we shouldn't suggest to our users that they
might.  Many users tried with the then-current versions in the past, and
the failures are often quite hard to trace back to this.

For the 4.9 branch, we should leave this as is: the benefit is almost
certainly not worth the trouble.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix web/60933

[Richard Biener]

On Thu, 24 Apr 2014, Rainer Orth wrote:

> Richard Biener <rguenther@suse.de> writes:
> 
> > The GMP people complained that we "advertise" outdated versions
> > in our install instructions.  I tried to address that by not
> > explicitely listing a "good" version but only mention the version
> > that is the minimum requirement.  I also added a reference to
> > contrib/download_prerequesites as the recommended way to do
> > in-tree builds (so we don't get random bugreports for that
> > with untested combinations of gmp/mpfr/mpc versions).
> >
> > We probably should try to bump the versions used by that script
> > to something more recent though (should we do that for the 4.9
> > branch even?).  Any idea what to choose here?  I'd say mpc
> > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> > of gmp?  We shouldn't change those versions too often, otherwise
> > we end up with a lot of garbage in gcc/infrastructure (we don't
> > want to break old versions of the script).
> >
> > Meanwhile is does the patch look ok?
> 
> I'd strongly advise against it: in the past we've had serious problems
> with versions newer than advertised in install.texi on some platforms.
> Until we have positive evidence that specific newer versions work on a
> wide range of platforms, we shouldn't suggest to our users that they
> might.  Many users tried with the then-current versions in the past, and
> the failures are often quite hard to trace back to this.

Note that I explicitely added the reference to download_prerequesites
for the case the user wants/needs to build the libraries together
with GCC.  That should address this concern, no?

> For the 4.9 branch, we should leave this as is: the benefit is almost
> certainly not worth the trouble.

Of course.  Though the version referenced from http://gcc.gnu.org/install
is the one from trunk.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

Re: [PATCH] Fix web/60933

[Richard Biener]

On Thu, 24 Apr 2014, Jakub Jelinek wrote:

> On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote:
> > We probably should try to bump the versions used by that script
> > to something more recent though (should we do that for the 4.9
> > branch even?).  Any idea what to choose here?  I'd say mpc
> > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> > of gmp?  We shouldn't change those versions too often, otherwise
> 
> For gmp 6.0.0, there were some issues with miscompilation of that on
> Solaris, right?  Does it work elsewhere fine?  Just fuzzy memories.
> 
> > -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
> > +@item GNU Multiple Precision Library (GMP)
> >  
> > -Necessary to build GCC@.  If a GMP source distribution is found in a
> > +Necessary to build GCC@.  It can be downloaded from @uref{https://gmplib.org/}.
> > +Older versions than 4.2.3 will not work.
> > +If a GMP source distribution is found in a
> 
> Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3,
> 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)?

As I say "will not work" I checked what we reject at configure time
(for the oldest versions that work we'll complain "buggy but acceptable").
We can of course make configure more strict and at this time reject
the known buggy versions.  Shall we do that?

Thanks,
Richard.

Re: [PATCH] Fix web/60933

[Jakub Jelinek]

On Thu, Apr 24, 2014 at 10:38:38AM +0200, Richard Biener wrote:
> > Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3,
> > 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)?
> 
> As I say "will not work" I checked what we reject at configure time
> (for the oldest versions that work we'll complain "buggy but acceptable").
> We can of course make configure more strict and at this time reject
> the known buggy versions.  Shall we do that?

Ah, ok, guess it is fine then.  Dunno what the bugs in the "buggy but
acceptable" were, and in any case that can be bumped independently (in both
places, configure and web).

	Jakub

Re: [PATCH] Fix web/60933

[Rainer Orth]

Richard Biener <rguenther@suse.de> writes:

>> I'd strongly advise against it: in the past we've had serious problems
>> with versions newer than advertised in install.texi on some platforms.
>> Until we have positive evidence that specific newer versions work on a
>> wide range of platforms, we shouldn't suggest to our users that they
>> might.  Many users tried with the then-current versions in the past, and
>> the failures are often quite hard to trace back to this.
>
> Note that I explicitely added the reference to download_prerequesites
> for the case the user wants/needs to build the libraries together
> with GCC.  That should address this concern, no?

I fear it won't: some people will use it, others just download the
latest versions from gmp.org etc. and build them out-of-tree themselves.

If we want to recommend newer versions (and no complaint from me there),
we should first make sure they work *ourselves* and then again require
*those specific versions*, no weasle-wording for anything else, given
lots of bad experience in the past.

>> For the 4.9 branch, we should leave this as is: the benefit is almost
>> certainly not worth the trouble.
>
> Of course.  Though the version referenced from http://gcc.gnu.org/install
> is the one from trunk.

Unfortunately true.  Perhaps we should change that?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix web/60933

[Eric Botcazou]

> Meanwhile is does the patch look ok?

No, the current wording is just fine and yours doesn't bring anything (even 
the contrary, since you're listing known problematic versions).  This will 
also break http://gcc.gnu.org/install/specific.html#sparc-x-x

I don't see why we should special case GMP, MPFR and MPC here, look at all the 
other dependencies on http://gcc.gnu.org/install/prerequisites.html

And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ 
contains obsolete versions.

-- 
Eric Botcazou

Re: [PATCH] Fix web/60933

[Richard Biener]

On Thu, 24 Apr 2014, Eric Botcazou wrote:

> > Meanwhile is does the patch look ok?
> 
> No, the current wording is just fine and yours doesn't bring anything (even 
> the contrary, since you're listing known problematic versions).  This will 
> also break http://gcc.gnu.org/install/specific.html#sparc-x-x

Ah, I didn't see that.  So the issue here is that the host compiler
miscompiles the in-tree copy?  Maybe we should compile host libraries with
-O0 during stage1 (and require recent host GCC for compiling
cross compilers - which we probably do anyway).

It's an issue anyway as soon as we bump the versions downloaded
by contrib/download_prerequesites.  What "newer" versions are
affected, btw?  Are "very newer" versions fixed maybe?

> I don't see why we should special case GMP, MPFR and MPC here, look at all the 
> other dependencies on http://gcc.gnu.org/install/prerequisites.html
> 
> And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ 
> contains obsolete versions.

Hmm, ok.  Is the piece referencing contrib/download_prerequesites
and documenting that as the recommended way to setup and do
in-tree builds?

Generally we have conflicting goals - we want to make sure
GCC works with system supplied versions of the libraries
(thus the configure version checks), and we want to specify
versions that work for the in-tree builds (because of the
somewhat awkward setup of the build because of their inter-dependencies
and not doing intermediate installs).

-- 
Richard Biener <rguenther@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

Re: [PATCH] Fix web/60933

[Richard Biener]

On Thu, 24 Apr 2014, Richard Biener wrote:

> On Thu, 24 Apr 2014, Eric Botcazou wrote:
> 
> > > Meanwhile is does the patch look ok?
> > 
> > No, the current wording is just fine and yours doesn't bring anything (even 
> > the contrary, since you're listing known problematic versions).  This will 
> > also break http://gcc.gnu.org/install/specific.html#sparc-x-x
> 
> Ah, I didn't see that.  So the issue here is that the host compiler
> miscompiles the in-tree copy?  Maybe we should compile host libraries with
> -O0 during stage1 (and require recent host GCC for compiling
> cross compilers - which we probably do anyway).
> 
> It's an issue anyway as soon as we bump the versions downloaded
> by contrib/download_prerequesites.  What "newer" versions are
> affected, btw?  Are "very newer" versions fixed maybe?

@@ -4321,8 +4330,8 @@ read all other sections that match your
 Newer versions of the GNU Multiple Precision Library (GMP), the MPFR
 library and the MPC library are known to be miscompiled by earlier
 versions of GCC on these platforms.  We therefore recommend the use
-of the exact versions of these libraries listed as minimal versions
-in @uref{prerequisites.html,,the prerequisites}.
+of the @command{download_prerequesites} script to download
+versions that are known to work.

 @html
 <hr />

> > I don't see why we should special case GMP, MPFR and MPC here, look at all the 
> > other dependencies on http://gcc.gnu.org/install/prerequisites.html
> > 
> > And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ 
> > contains obsolete versions.
> 
> Hmm, ok.  Is the piece referencing contrib/download_prerequesites
> and documenting that as the recommended way to setup and do
> in-tree builds?
> 
> Generally we have conflicting goals - we want to make sure
> GCC works with system supplied versions of the libraries
> (thus the configure version checks), and we want to specify
> versions that work for the in-tree builds (because of the
> somewhat awkward setup of the build because of their inter-dependencies
> and not doing intermediate installs).
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer

Re: [PATCH] Fix web/60933

[Eric Botcazou]

> Ah, I didn't see that.  So the issue here is that the host compiler
> miscompiles the in-tree copy?  Maybe we should compile host libraries with
> -O0 during stage1 (and require recent host GCC for compiling
> cross compilers - which we probably do anyway).

In-tree is a red herring, very few people do that.  People download libraries, 
compile them with the base compiler, install them and bootstrap the compiler.

> It's an issue anyway as soon as we bump the versions downloaded
> by contrib/download_prerequesites.  What "newer" versions are
> affected, btw?  Are "very newer" versions fixed maybe?

GMP 5.x is known to be problematic on SPARC, I don't know for 6.x.

> Generally we have conflicting goals - we want to make sure
> GCC works with system supplied versions of the libraries
> (thus the configure version checks), and we want to specify
> versions that work for the in-tree builds (because of the
> somewhat awkward setup of the build because of their inter-dependencies
> and not doing intermediate installs).

Agreed, but the current situation is relatively satisfactory if you ask me.
If something needs to be changed because of web/60933, then it's probably the 
versions provided at ftp://gcc.gnu.org/pub/gcc/infrastructure/

-- 
Eric Botcazou

Re: [PATCH] Fix web/60933

[Richard Biener]

On Fri, 25 Apr 2014, Eric Botcazou wrote:

> > Ah, I didn't see that.  So the issue here is that the host compiler
> > miscompiles the in-tree copy?  Maybe we should compile host libraries with
> > -O0 during stage1 (and require recent host GCC for compiling
> > cross compilers - which we probably do anyway).
> 
> In-tree is a red herring, very few people do that.  People download libraries, 
> compile them with the base compiler, install them and bootstrap the compiler.

I'm not sure about that.  In fact I'm always suggesting the in-tree
variant to people (because then they don't need to fiddle with
LD_LIBRARY_PATH).  After suggesting to simply install the requirements
from vendor provided packages, of course.

Maybe we should simply import the requirements into our tree
and use them unless the system provides what we need (or
--with/without-system-FOO is supplied).  We do that for other
stuff like zlib, intl, boehm, etc..  gmp 6.0 now has 'mini-gmp'
which is a slow but very small variant for example.  Not sure
if that's enough for our gmp needs for example.

> > It's an issue anyway as soon as we bump the versions downloaded
> > by contrib/download_prerequesites.  What "newer" versions are
> > affected, btw?  Are "very newer" versions fixed maybe?
> 
> GMP 5.x is known to be problematic on SPARC, I don't know for 6.x.

Ok, 6.x is know to be problematic on *BSD.

> > Generally we have conflicting goals - we want to make sure
> > GCC works with system supplied versions of the libraries
> > (thus the configure version checks), and we want to specify
> > versions that work for the in-tree builds (because of the
> > somewhat awkward setup of the build because of their inter-dependencies
> > and not doing intermediate installs).
> 
> Agreed, but the current situation is relatively satisfactory if you ask me.
> If something needs to be changed because of web/60933, then it's probably the 
> versions provided at ftp://gcc.gnu.org/pub/gcc/infrastructure/

Well, if 5.x doesnt' work for SPARC and 6.x doesn't work for *BSD
that leaves us with 4.x, exactly what is already present there.

Richard.

Re: [PATCH] Fix web/60933

[Eric Botcazou]

> I'm not sure about that.  In fact I'm always suggesting the in-tree
> variant to people (because then they don't need to fiddle with
> LD_LIBRARY_PATH).  After suggesting to simply install the requirements
> from vendor provided packages, of course.

The proper fix to the LD_LIBRARY_PATH issue is rather --disable-shared in my 
opinion...

> Maybe we should simply import the requirements into our tree
> and use them unless the system provides what we need (or
> --with/without-system-FOO is supplied).  We do that for other
> stuff like zlib, intl, boehm, etc..  gmp 6.0 now has 'mini-gmp'
> which is a slow but very small variant for example.  Not sure
> if that's enough for our gmp needs for example.

That would clearly be the definitive answer, but I don't know if it's 
doable in practice.

-- 
Eric Botcazou