Re: [PATCH] Fix web/60933
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
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
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
Re: [PATCH] Fix web/60933
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
Richard Biener rguent...@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
On Thu, 24 Apr 2014, Rainer Orth wrote: Richard Biener rguent...@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 rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
Re: [PATCH] Fix web/60933
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
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
Richard Biener rguent...@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
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
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 rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
Re: [PATCH] Fix web/60933
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 rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
