Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 09/22/16 20:07, Moritz Klammler wrote: > Martin Sebor writes: > >> [...] >> >>> In-tree only the versions that download_prerequisite picks are >>> tested and guaranteed to work. >> >> I was made aware today that my recent patch for pr49905 broke >> bootstrap with MPFR 2.4: >> >>https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html >> >> In light of this risk and given that the recommended MPFR version >> is still 2.4 I wonder if the download_prerequisites script shouldn't >> instead download the minimum supported version. That way those of >> us working with MPFR but not intimately familiar with its version >> specific details would have an easier way of avoiding such breakage. >> >> Alternatively, perhaps the script could be extended to make it >> possible to choose between the most recent and the recommended >> versions of the prerequisites that GCC is intended to work with, >> and people who make use of either in their code encouraged to >> test with both. > > As some of you might already be aware of, I'm currently trying to get a > new version of the `contrib/download_prerequisites` script approved that > will verify the checksums of the tarballs it downloads and also provides > additional options. If it is considered useful, I could add an option > to it that would do what you suggest. Am I understanding correctly that > we have a "minimum", "recommended" and "most recent" version for each > dependency and that the script currently uses the "most recent" one? If > the feature is wanted, all I'd need is somebody to tell me the version > numbers. > No, the problem is, that these packages are not designed for in-tree builds but for stand-alone. Likewise they are not designed for cross-target builds. So for each version there are different work-arounds necessary from the toplevel configure scripts. And until I updated that top-level script, only the very old versions did *actually* work on all targets. Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Thu, 22 Sep 2016, Moritz Klammler wrote: > As some of you might already be aware of, I'm currently trying to get a > new version of the `contrib/download_prerequisites` script approved that > will verify the checksums of the tarballs it downloads and also provides > additional options. If it is considered useful, I could add an option > to it that would do what you suggest. Am I understanding correctly that > we have a "minimum", "recommended" and "most recent" version for each > dependency and that the script currently uses the "most recent" one? If > the feature is wanted, all I'd need is somebody to tell me the version > numbers. The script should not handle multiple versions; only recommended versions, which should be the most recent known to work with it. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 09/22/16 20:00, Joseph Myers wrote: > On Thu, 22 Sep 2016, Bernd Edlinger wrote: > >> There is no feasible way how to make all gmp/mpfr/mpc versions from >> minimal to latest build for all targets and all possible >> cross-configurations. >> >> I hope that we do not "recommend" these versions. >> >> They are only the minimum versions for pre-installed packages. > > And personally I think it would by now be reasonable to require MPFR 3.0 > or 3.1 as a minimum version should someone wish to make the various > cleanups mentioned in the April discussion, so avoiding claiming to > support configurations few developers will be testing. (MPFR 3.1 came out > nearly five years ago - 3 Oct 2011.) > Yes, and we have workarounds for more than just convenience features that are missing in MPFR 2.4. I proposed to remove them in April but Richard was against it. Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
Martin Sebor writes: > [...] > >> In-tree only the versions that download_prerequisite picks are >> tested and guaranteed to work. > > I was made aware today that my recent patch for pr49905 broke > bootstrap with MPFR 2.4: > > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html > > In light of this risk and given that the recommended MPFR version > is still 2.4 I wonder if the download_prerequisites script shouldn't > instead download the minimum supported version. That way those of > us working with MPFR but not intimately familiar with its version > specific details would have an easier way of avoiding such breakage. > > Alternatively, perhaps the script could be extended to make it > possible to choose between the most recent and the recommended > versions of the prerequisites that GCC is intended to work with, > and people who make use of either in their code encouraged to > test with both. As some of you might already be aware of, I'm currently trying to get a new version of the `contrib/download_prerequisites` script approved that will verify the checksums of the tarballs it downloads and also provides additional options. If it is considered useful, I could add an option to it that would do what you suggest. Am I understanding correctly that we have a "minimum", "recommended" and "most recent" version for each dependency and that the script currently uses the "most recent" one? If the feature is wanted, all I'd need is somebody to tell me the version numbers.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Thu, 22 Sep 2016, Bernd Edlinger wrote: > There is no feasible way how to make all gmp/mpfr/mpc versions from > minimal to latest build for all targets and all possible > cross-configurations. > > I hope that we do not "recommend" these versions. > > They are only the minimum versions for pre-installed packages. And personally I think it would by now be reasonable to require MPFR 3.0 or 3.1 as a minimum version should someone wish to make the various cleanups mentioned in the April discussion, so avoiding claiming to support configurations few developers will be testing. (MPFR 3.1 came out nearly five years ago - 3 Oct 2011.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On September 22, 2016 8:00:40 PM GMT+02:00, Joseph Myers wrote: >On Thu, 22 Sep 2016, Bernd Edlinger wrote: > >> There is no feasible way how to make all gmp/mpfr/mpc versions from >> minimal to latest build for all targets and all possible >> cross-configurations. >> >> I hope that we do not "recommend" these versions. >> >> They are only the minimum versions for pre-installed packages. > >And personally I think it would by now be reasonable to require MPFR >3.0 >or 3.1 as a minimum version should someone wish to make the various >cleanups mentioned in the April discussion, so avoiding claiming to >support configurations few developers will be testing. (MPFR 3.1 came >out >nearly five years ago - 3 Oct 2011.) Hmpf, it will be a hassle to update all our auto-testers again... So, yes, we are 'testing' with those versions. Richard.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 09/22/16 19:26, Martin Sebor wrote: > On 04/27/2016 09:47 AM, Bernd Edlinger wrote: >> >> >> Yes, when they are pre-installed there should be no problem. >> Also newer versions than these seem to work. >> >> In-tree only the versions that download_prerequisite picks are >> tested and guaranteed to work. > > I was made aware today that my recent patch for pr49905 broke > bootstrap with MPFR 2.4: > >https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html > > In light of this risk and given that the recommended MPFR version > is still 2.4 I wonder if the download_prerequisites script shouldn't > instead download the minimum supported version. That way those of > us working with MPFR but not intimately familiar with its version > specific details would have an easier way of avoiding such breakage. > > Alternatively, perhaps the script could be extended to make it > possible to choose between the most recent and the recommended > versions of the prerequisites that GCC is intended to work with, > and people who make use of either in their code encouraged to > test with both. > > Martin > There is no feasible way how to make all gmp/mpfr/mpc versions from minimal to latest build for all targets and all possible cross-configurations. I hope that we do not "recommend" these versions. They are only the minimum versions for pre-installed packages. Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Thu, 22 Sep 2016, Martin Sebor wrote: > In light of this risk and given that the recommended MPFR version > is still 2.4 I wonder if the download_prerequisites script shouldn't > instead download the minimum supported version. That way those of No, it should download the latest version known to work with the script and we should routinely review and update those versions (preferably they should be the latest releases of the libraries, subject to avoiding major updates while in bug-fixing mode). We should not encourage use of ancient versions, although we should only update the minimum when there's actually a new feature we want to use (that feature may just be a convenience rather than something hard to avoid, if the minimum version with it is old enough). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 04/27/2016 09:47 AM, Bernd Edlinger wrote: Am 27.04.2016 um 17:37 schrieb Rainer Orth: Bernd Edlinger writes: On 26.04.2016 22:14, Joseph Myers wrote: On Tue, 26 Apr 2016, Bernd Edlinger wrote: Hi, as we all know, it's high time now to adjust the minimum supported gmp/mpfr/mpc versions for gcc-7. I think updating the minimum versions (when using previously built libraries, not in-tree) is only appropriate when it allows some cleanup in GCC, such as removing conditionals on whether a more recently added function is available, adding functionality that depends on a newer interface, or using newer interfaces instead of older ones that are now deprecated. For example, you could justify a move to requiring MPFR 3.0.0 or later with cleanups to use MPFR_RND* instead of the older GMP_RND*, and similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t and mpfr_prec_t in fortran/. You could justify a move to requiring MPC 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what if any newer GMP interfaces would be beneficial in GCC. And as always in such cases, it's a good idea to look at e.g. how widespread the newer versions are in GNU/Linux distributions, which indicates how many people might be affected by an increase in the version requirement. Yes I see. I would justify it this way: gmp-6.0.0 is the first version that does not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0 we could emit at least a warning in cstddef for this invalid code. Once we have gmp-6.0.0, the earliest mpfr version that compiles at all is mpfr-3.1.1 and the earliest mpc version that compiles at all is mpc-0.9. This would be the supported installed versions. In-tree gmp-6.0.0 does _not_ work for ARM. But gmp-6.1.0 does (with a little quirk). All supported mpfr and mpc versions are working in-tree too, even for the ARM target. When we have at least mpfr-3.1.1, it is straight forward to remove the pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance. So I would propose this updated patch for gcc-7. would this version combo (gmp 6.0.0, mpfr 3.1.1, mpc 0.9) also work on the active release branches (gcc-5 and gcc-6, gcc-4.9 is on it's way out)? Having to install two different sets of the libraries for trunk and branch work would be extremely tedious. Rainer Yes, when they are pre-installed there should be no problem. Also newer versions than these seem to work. In-tree only the versions that download_prerequisite picks are tested and guaranteed to work. I was made aware today that my recent patch for pr49905 broke bootstrap with MPFR 2.4: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html In light of this risk and given that the recommended MPFR version is still 2.4 I wonder if the download_prerequisites script shouldn't instead download the minimum supported version. That way those of us working with MPFR but not intimately familiar with its version specific details would have an easier way of avoiding such breakage. Alternatively, perhaps the script could be extended to make it possible to choose between the most recent and the recommended versions of the prerequisites that GCC is intended to work with, and people who make use of either in their code encouraged to test with both. Martin
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Tue, 3 May 2016, Bernd Edlinger wrote: > On 28.04.2016 09:09, Richard Biener wrote: > > > > As said elsewhere the main reason for all of this is to make the > > in-tree builds work better for newer archs that are not happy with > > the versions provided by download_prerequesites. This should come > > with a documentation adjustment that the only tested in-tree > > versions are those downloaded by dowload_prerequesites. > > That patch is installed now, and so far nothing bad has happened. > > > Please address updating the minimum supported _installed_ version > > separately (in fact I do maintain a patch to disable stuff to be > > able to go back to even older mpfr versions ... :/). > > > > SLES 11 ships with mpfr 2.3.2, mpc 0.8 and gmp 4.2.3 while SLES 12 > > and openSUSE Leap have gmp 5.1.3, mpfr 3.1.2 and mpc 1.0.2. > > Of course updating to a more recent gmp version is not the most > important thing in the world, and I am not trying to make gcc emit > an error when compiling gmp 5.1.3, but I think emitting a warning > for this code would be fair. > > So here is the next step. > > This patch raises the installed gmp version to 6.0.0 or higher, > the installed mpfr version to 3.1.1 or higher and the > installed mpc version to 0.9 or higher. So Jakub's currently > installed versions will be fine, even a bit older versions > will work, but unfortunately gmp 5.1.3 will not work. > > I also attached a sketch of what I'd like to propose on the > libstdc++ list, once we can rely on the gmp.h not to trigger > these new warnings in cstddef. With the gmp 5.1.3 or earlier > one of this warnings made the boot-strap fail in stage2. > > Boot-strapped and reg-tested on x86_64-linux-gnu. > Is it OK for trunk? No, I don't see a compelling reason to force the minimum installed version to be higher than today. Richard.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 28.04.2016 09:09, Richard Biener wrote:
>
> As said elsewhere the main reason for all of this is to make the
> in-tree builds work better for newer archs that are not happy with
> the versions provided by download_prerequesites. This should come
> with a documentation adjustment that the only tested in-tree
> versions are those downloaded by dowload_prerequesites.
That patch is installed now, and so far nothing bad has happened.
> Please address updating the minimum supported _installed_ version
> separately (in fact I do maintain a patch to disable stuff to be
> able to go back to even older mpfr versions ... :/).
>
> SLES 11 ships with mpfr 2.3.2, mpc 0.8 and gmp 4.2.3 while SLES 12
> and openSUSE Leap have gmp 5.1.3, mpfr 3.1.2 and mpc 1.0.2.
Of course updating to a more recent gmp version is not the most
important thing in the world, and I am not trying to make gcc emit
an error when compiling gmp 5.1.3, but I think emitting a warning
for this code would be fair.
So here is the next step.
This patch raises the installed gmp version to 6.0.0 or higher,
the installed mpfr version to 3.1.1 or higher and the
installed mpc version to 0.9 or higher. So Jakub's currently
installed versions will be fine, even a bit older versions
will work, but unfortunately gmp 5.1.3 will not work.
I also attached a sketch of what I'd like to propose on the
libstdc++ list, once we can rely on the gmp.h not to trigger
these new warnings in cstddef. With the gmp 5.1.3 or earlier
one of this warnings made the boot-strap fail in stage2.
Boot-strapped and reg-tested on x86_64-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2016-05-03 Bernd Edlinger
* configure.ac (mpfr): Adjust check to new minimum gmp, mpfr and mpc
versions.
* configure: Regenerated.
gcc/
2016-05-03 Bernd Edlinger
* doc/install.texi: Adjust gmp/mpfr/mpc minimum versions.
gcc/fortran/
2016-05-03 Bernd Edlinger
* simplify.c (gfc_simplify_fraction): Remove pre-3.1.0 mpfr
compatibility code.
Index: configure
===
--- configure (revision 235816)
+++ configure (working copy)
@@ -5640,24 +5640,6 @@ $as_echo_n "checking for the correct version of gm
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-#include "gmp.h"
-int
-main ()
-{
-
- #define GCC_GMP_VERSION_NUM(a,b,c) (((a) << 16L) | ((b) << 8) | (c))
- #define GCC_GMP_VERSION GCC_GMP_VERSION_NUM(__GNU_MP_VERSION,__GNU_MP_VERSION_MINOR,__GNU_MP_VERSION_PATCHLEVEL)
- #if GCC_GMP_VERSION < GCC_GMP_VERSION_NUM(4,2,3)
- choke me
- #endif
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
#include
int
main ()
@@ -5665,7 +5647,7 @@ main ()
#define GCC_GMP_VERSION_NUM(a,b,c) (((a) << 16L) | ((b) << 8) | (c))
#define GCC_GMP_VERSION GCC_GMP_VERSION_NUM(__GNU_MP_VERSION,__GNU_MP_VERSION_MINOR,__GNU_MP_VERSION_PATCHLEVEL)
- #if GCC_GMP_VERSION < GCC_GMP_VERSION_NUM(4,3,2)
+ #if GCC_GMP_VERSION < GCC_GMP_VERSION_NUM(6,0,0)
choke me
#endif
@@ -5677,11 +5659,6 @@ if ac_fn_c_try_compile "$LINENO"; then :
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }
else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: buggy but acceptable" >&5
-$as_echo "buggy but acceptable" >&6; }
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }; have_gmp=no
fi
@@ -5700,7 +5677,7 @@ int
main ()
{
-#if MPFR_VERSION < MPFR_VERSION_NUM(2,4,0)
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,1)
choke me
#endif
@@ -5709,31 +5686,9 @@ main ()
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-#include
-#include
-int
-main ()
-{
-
-#if MPFR_VERSION < MPFR_VERSION_NUM(2,4,2)
-choke me
-#endif
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }
else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: buggy but acceptable" >&5
-$as_echo "buggy but acceptable" >&6; }
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }; have_gmp=no
fi
@@ -5752,7 +5707,7 @@ int
main ()
{
-#if MPC_VERSION < MPC_VERSION_NUM(0,8,0)
+#if MPC_VERSION < MPC_VERSION_NUM(0,9,0)
choke me
#endif
@@ -5761,30 +5716,9 @@ main ()
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-#include
-int
-main ()
-{
-
-#if MPC_VERSION < MPC_VERSION_NUM(0,8,1)
-choke me
-#endif
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
{ $as_echo "$as_me:${as_li
Re: [RFC] Update gmp/mpfr/mpc minimum versions
Hi Bernd, >> would this version combo (gmp 6.0.0, mpfr 3.1.1, mpc 0.9) also work on >> the active release branches (gcc-5 and gcc-6, gcc-4.9 is on it's way >> out)? Having to install two different sets of the libraries for trunk >> and branch work would be extremely tedious. >> >> Rainer >> > > Yes, when they are pre-installed there should be no problem. > Also newer versions than these seem to work. > > In-tree only the versions that download_prerequisite picks are > tested and guaranteed to work. fine with me: I never cared about (or even got the point of) in-tree builds of this stuff. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Wed, 27 Apr 2016, Bernd Edlinger wrote: > On 26.04.2016 22:14, Joseph Myers wrote: > > On Tue, 26 Apr 2016, Bernd Edlinger wrote: > > > >> Hi, > >> > >> as we all know, it's high time now to adjust the minimum supported > >> gmp/mpfr/mpc versions for gcc-7. > > > > I think updating the minimum versions (when using previously built > > libraries, not in-tree) is only appropriate when it allows some cleanup in > > GCC, such as removing conditionals on whether a more recently added > > function is available, adding functionality that depends on a newer > > interface, or using newer interfaces instead of older ones that are now > > deprecated. > > > > For example, you could justify a move to requiring MPFR 3.0.0 or later > > with cleanups to use MPFR_RND* instead of the older GMP_RND*, and > > similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t > > and mpfr_prec_t in fortran/. You could justify a move to requiring MPC > > 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what > > if any newer GMP interfaces would be beneficial in GCC. And as always in > > such cases, it's a good idea to look at e.g. how widespread the newer > > versions are in GNU/Linux distributions, which indicates how many people > > might be affected by an increase in the version requirement. > > > > Yes I see. > > I would justify it this way: gmp-6.0.0 is the first version that does > not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0 > we could emit at least a warning in cstddef for this invalid code. > > Once we have gmp-6.0.0, the earliest mpfr version that compiles at all > is mpfr-3.1.1 and the earliest mpc version that compiles at all is > mpc-0.9. This would be the supported installed versions. > > In-tree gmp-6.0.0 does _not_ work for ARM. But gmp-6.1.0 does (with a > little quirk). All supported mpfr and mpc versions are working in-tree > too, even for the ARM target. > > When we have at least mpfr-3.1.1, it is straight forward to remove the > pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance. > > So I would propose this updated patch for gcc-7. As said elsewhere the main reason for all of this is to make the in-tree builds work better for newer archs that are not happy with the versions provided by download_prerequesites. This should come with a documentation adjustment that the only tested in-tree versions are those downloaded by dowload_prerequesites. Please address updating the minimum supported _installed_ version separately (in fact I do maintain a patch to disable stuff to be able to go back to even older mpfr versions ... :/). SLES 11 ships with mpfr 2.3.2, mpc 0.8 and gmp 4.2.3 while SLES 12 and openSUSE Leap have gmp 5.1.3, mpfr 3.1.2 and mpc 1.0.2. Thanks, Richard.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
Am 27.04.2016 um 17:37 schrieb Rainer Orth: > Bernd Edlinger writes: > >> On 26.04.2016 22:14, Joseph Myers wrote: >>> On Tue, 26 Apr 2016, Bernd Edlinger wrote: >>> Hi, as we all know, it's high time now to adjust the minimum supported gmp/mpfr/mpc versions for gcc-7. >>> >>> I think updating the minimum versions (when using previously built >>> libraries, not in-tree) is only appropriate when it allows some cleanup in >>> GCC, such as removing conditionals on whether a more recently added >>> function is available, adding functionality that depends on a newer >>> interface, or using newer interfaces instead of older ones that are now >>> deprecated. >>> >>> For example, you could justify a move to requiring MPFR 3.0.0 or later >>> with cleanups to use MPFR_RND* instead of the older GMP_RND*, and >>> similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t >>> and mpfr_prec_t in fortran/. You could justify a move to requiring MPC >>> 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what >>> if any newer GMP interfaces would be beneficial in GCC. And as always in >>> such cases, it's a good idea to look at e.g. how widespread the newer >>> versions are in GNU/Linux distributions, which indicates how many people >>> might be affected by an increase in the version requirement. >>> >> >> Yes I see. >> >> I would justify it this way: gmp-6.0.0 is the first version that does >> not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0 >> we could emit at least a warning in cstddef for this invalid code. >> >> Once we have gmp-6.0.0, the earliest mpfr version that compiles at all >> is mpfr-3.1.1 and the earliest mpc version that compiles at all is >> mpc-0.9. This would be the supported installed versions. >> >> In-tree gmp-6.0.0 does _not_ work for ARM. But gmp-6.1.0 does (with a >> little quirk). All supported mpfr and mpc versions are working in-tree >> too, even for the ARM target. >> >> When we have at least mpfr-3.1.1, it is straight forward to remove the >> pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance. >> >> So I would propose this updated patch for gcc-7. > > would this version combo (gmp 6.0.0, mpfr 3.1.1, mpc 0.9) also work on > the active release branches (gcc-5 and gcc-6, gcc-4.9 is on it's way > out)? Having to install two different sets of the libraries for trunk > and branch work would be extremely tedious. > > Rainer > Yes, when they are pre-installed there should be no problem. Also newer versions than these seem to work. In-tree only the versions that download_prerequisite picks are tested and guaranteed to work.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
Bernd Edlinger writes: > On 26.04.2016 22:14, Joseph Myers wrote: >> On Tue, 26 Apr 2016, Bernd Edlinger wrote: >> >>> Hi, >>> >>> as we all know, it's high time now to adjust the minimum supported >>> gmp/mpfr/mpc versions for gcc-7. >> >> I think updating the minimum versions (when using previously built >> libraries, not in-tree) is only appropriate when it allows some cleanup in >> GCC, such as removing conditionals on whether a more recently added >> function is available, adding functionality that depends on a newer >> interface, or using newer interfaces instead of older ones that are now >> deprecated. >> >> For example, you could justify a move to requiring MPFR 3.0.0 or later >> with cleanups to use MPFR_RND* instead of the older GMP_RND*, and >> similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t >> and mpfr_prec_t in fortran/. You could justify a move to requiring MPC >> 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what >> if any newer GMP interfaces would be beneficial in GCC. And as always in >> such cases, it's a good idea to look at e.g. how widespread the newer >> versions are in GNU/Linux distributions, which indicates how many people >> might be affected by an increase in the version requirement. >> > > Yes I see. > > I would justify it this way: gmp-6.0.0 is the first version that does > not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0 > we could emit at least a warning in cstddef for this invalid code. > > Once we have gmp-6.0.0, the earliest mpfr version that compiles at all > is mpfr-3.1.1 and the earliest mpc version that compiles at all is > mpc-0.9. This would be the supported installed versions. > > In-tree gmp-6.0.0 does _not_ work for ARM. But gmp-6.1.0 does (with a > little quirk). All supported mpfr and mpc versions are working in-tree > too, even for the ARM target. > > When we have at least mpfr-3.1.1, it is straight forward to remove the > pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance. > > So I would propose this updated patch for gcc-7. would this version combo (gmp 6.0.0, mpfr 3.1.1, mpc 0.9) also work on the active release branches (gcc-5 and gcc-6, gcc-4.9 is on it's way out)? Having to install two different sets of the libraries for trunk and branch work would be extremely tedious. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 26.04.2016 22:14, Joseph Myers wrote:
> On Tue, 26 Apr 2016, Bernd Edlinger wrote:
>
>> Hi,
>>
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>
> I think updating the minimum versions (when using previously built
> libraries, not in-tree) is only appropriate when it allows some cleanup in
> GCC, such as removing conditionals on whether a more recently added
> function is available, adding functionality that depends on a newer
> interface, or using newer interfaces instead of older ones that are now
> deprecated.
>
> For example, you could justify a move to requiring MPFR 3.0.0 or later
> with cleanups to use MPFR_RND* instead of the older GMP_RND*, and
> similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t
> and mpfr_prec_t in fortran/. You could justify a move to requiring MPC
> 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what
> if any newer GMP interfaces would be beneficial in GCC. And as always in
> such cases, it's a good idea to look at e.g. how widespread the newer
> versions are in GNU/Linux distributions, which indicates how many people
> might be affected by an increase in the version requirement.
>
Yes I see.
I would justify it this way: gmp-6.0.0 is the first version that does
not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0
we could emit at least a warning in cstddef for this invalid code.
Once we have gmp-6.0.0, the earliest mpfr version that compiles at all
is mpfr-3.1.1 and the earliest mpc version that compiles at all is
mpc-0.9. This would be the supported installed versions.
In-tree gmp-6.0.0 does _not_ work for ARM. But gmp-6.1.0 does (with a
little quirk). All supported mpfr and mpc versions are working in-tree
too, even for the ARM target.
When we have at least mpfr-3.1.1, it is straight forward to remove the
pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance.
So I would propose this updated patch for gcc-7.
Thanks
Bernd.
2016-04-26 Bernd Edlinger
* configure.ac (mpfr): Remove pre-3.1.0 mpfr compatibility code.
Adjust check to new minimum gmp, mpfr and mpc versions.
* configure: Regenerated.
* Makefile.def (gmp): Explicitly disable assembler.
(mpfr): Adjust lib_path.
(mpc): Likewise.
* Makefile.in: Regenerated.
gcc/
2016-04-26 Bernd Edlinger
* doc/install.texi: Adjust gmp/mpfr/mpc minimum versions.
gcc/fortran/
2016-04-26 Bernd Edlinger
* simplify.c (gfc_simplify_fraction): Remove pre-3.1.0 mpfr
compatibility code.
contrib/
2016-04-26 Bernd Edlinger
* download_prerequisites: Adjust gmp/mpfr/mpc versions.
Index: Makefile.def
===
--- Makefile.def (Revision 235487)
+++ Makefile.def (Arbeitskopie)
@@ -50,6 +50,7 @@ host_modules= { module= gcc; bootstrap=true;
host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
// Work around in-tree gmp configure bug with missing flex.
extra_configure_flags='--disable-shared LEX="touch lex.yy.c"';
+ extra_make_flags='AM_CFLAGS="-DNO_ASM"';
no_install= true;
// none-*-* disables asm optimizations, bootstrap-testing
// the compiler more thoroughly.
@@ -57,11 +58,11 @@ host_modules= { module= gmp; lib_path=.libs; boots
// gmp's configure will complain if given anything
// different from host for target.
target="none-${host_vendor}-${host_os}"; };
-host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
+host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared @extra_mpfr_configure_flags@';
extra_make_flags='AM_CFLAGS="-DNO_ASM"';
no_install= true; };
-host_modules= { module= mpc; lib_path=.libs; bootstrap=true;
+host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared @extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
no_install= true; };
host_modules= { module= isl; lib_path=.libs; bootstrap=true;
Index: Makefile.in
===
--- Makefile.in (Revision 235487)
+++ Makefile.in (Arbeitskopie)
@@ -639,12 +639,12 @@ HOST_LIB_PATH_gmp = \
@if mpfr
HOST_LIB_PATH_mpfr = \
- $$r/$(HOST_SUBDIR)/mpfr/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/.libs:
+ $$r/$(HOST_SUBDIR)/mpfr/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/src/.libs:
@endif mpfr
@if mpc
HOST_LIB_PATH_mpc = \
- $$r/$(HOST_SUBDIR)/mpc/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/.libs:
+ $$r/$(HOST_SUBDIR)/mpc/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/src/.libs:
@endif mpc
@if isl
@@ -11300,7 +11300,7 @@ all-gmp: configure-gmp
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/gmp && \
- $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) \
+ $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 26.04.2016 21:28, Marc Glisse wrote: > On Tue, 26 Apr 2016, Bernd Edlinger wrote: > >> For instance PR libstdc++/69881: gmp.h did this: >> >> #define __need_size_t /* tell gcc stddef.h we only want size_t */ >> #include /* for size_t */ >> >> I've persuaded Jonathan to work around that in libstdc++. >> >> Of course the in-tree build does work with less versions than >> otherwise. > > IIUC, the bug only shows up if you compile in C++11 or later, so > basically g++-6 or later, and there is a workaround in libstdc++ > starting from version 6 that means that it doesn't cause any problem. So > there might be a problem if someone tries to build gcc using CXX='g++-5 > -std=c++11' or CXX='clang++ -stdlib=libc++' on a glibc system (I don't > think others use __need_size_t?), but those are rather odd cases. > Yea, but Jonathan did not like this workaround at all, and my personal preference would also just have been a better error message for this clearly invalid code. Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Tue, 26 Apr 2016, Bernd Edlinger wrote: > Hi, > > as we all know, it's high time now to adjust the minimum supported > gmp/mpfr/mpc versions for gcc-7. I think updating the minimum versions (when using previously built libraries, not in-tree) is only appropriate when it allows some cleanup in GCC, such as removing conditionals on whether a more recently added function is available, adding functionality that depends on a newer interface, or using newer interfaces instead of older ones that are now deprecated. For example, you could justify a move to requiring MPFR 3.0.0 or later with cleanups to use MPFR_RND* instead of the older GMP_RND*, and similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t and mpfr_prec_t in fortran/. You could justify a move to requiring MPC 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what if any newer GMP interfaces would be beneficial in GCC. And as always in such cases, it's a good idea to look at e.g. how widespread the newer versions are in GNU/Linux distributions, which indicates how many people might be affected by an increase in the version requirement. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Tue, 26 Apr 2016, Bernd Edlinger wrote: For instance PR libstdc++/69881: gmp.h did this: #define __need_size_t /* tell gcc stddef.h we only want size_t */ #include /* for size_t */ I've persuaded Jonathan to work around that in libstdc++. Of course the in-tree build does work with less versions than otherwise. IIUC, the bug only shows up if you compile in C++11 or later, so basically g++-6 or later, and there is a workaround in libstdc++ starting from version 6 that means that it doesn't cause any problem. So there might be a problem if someone tries to build gcc using CXX='g++-5 -std=c++11' or CXX='clang++ -stdlib=libc++' on a glibc system (I don't think others use __need_size_t?), but those are rather odd cases. To support gmp-6.1.0 in-tree we have to set AM_CFLAGS=-DNO_ASM as already done with mpfr. This was already discussed recently on this list. Note that gmp-6.1.1 is supposed to be out any day now and will not require -DNO_ASM anymore. Yes, I know. I mean, I have tested the patch already with the gmp snapshots, but was not aware that it will be available so soon. However I think it would not really hurt to allow a little more interoperability, even for in-tree builds. It is just a matter what versions we want to test, I have not really any idea where the limits will be, just that it can no longer be 4.3.2. Even if in-tree builds work with several versions, we may still want to document only one as supported. -- Marc Glisse
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 26.04.2016 20:39, Marc Glisse wrote: > On Tue, 26 Apr 2016, Bernd Edlinger wrote: > >> as we all know, it's high time now to adjust the minimum supported >> gmp/mpfr/mpc versions for gcc-7. >> >> So this attached patch is now targeting at only supporting the currently >> latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying >> to support all previous versions, especially in-tree, but also without >> the >> in-tree configuration the previously used versions are really creating >> trouble nowadays. > > For in-tree builds, requiring the latest version makes sense to me. When > building gcc with a pre-installed gmp/mpfr/mpc (say the one provided by > your linux distribution), that's much more painful, and the benefit is > not as clear. What "trouble" do you have in mind? > For instance PR libstdc++/69881: gmp.h did this: #define __need_size_t /* tell gcc stddef.h we only want size_t */ #include /* for size_t */ I've persuaded Jonathan to work around that in libstdc++. Of course the in-tree build does work with less versions than otherwise. >> To support gmp-6.1.0 in-tree we have to set AM_CFLAGS=-DNO_ASM >> as already done with mpfr. This was already discussed recently on >> this list. > > Note that gmp-6.1.1 is supposed to be out any day now and will not > require -DNO_ASM anymore. > Yes, I know. I mean, I have tested the patch already with the gmp snapshots, but was not aware that it will be available so soon. However I think it would not really hurt to allow a little more interoperability, even for in-tree builds. It is just a matter what versions we want to test, I have not really any idea where the limits will be, just that it can no longer be 4.3.2. Thanks Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On April 26, 2016 8:39:28 PM GMT+02:00, Marc Glisse wrote: >On Tue, 26 Apr 2016, Bernd Edlinger wrote: > >> as we all know, it's high time now to adjust the minimum supported >> gmp/mpfr/mpc versions for gcc-7. >> >> So this attached patch is now targeting at only supporting the >currently >> latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying >> to support all previous versions, especially in-tree, but also >without the >> in-tree configuration the previously used versions are really >creating >> trouble nowadays. > >For in-tree builds, requiring the latest version makes sense to me. >When >building gcc with a pre-installed gmp/mpfr/mpc (say the one provided by > >your linux distribution), that's much more painful, and the benefit is >not >as clear. What "trouble" do you have in mind? > >> To support gmp-6.1.0 in-tree we have to set AM_CFLAGS=-DNO_ASM >> as already done with mpfr. This was already discussed recently on >this list. > >Note that gmp-6.1.1 is supposed to be out any day now and will not >require >-DNO_ASM anymore. I agree with Marc here - we should only update the version used by download prerequisites and document that this is the only supported version for in-tree builds. Richard.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On 26.04.2016 20:29, Jakub Jelinek wrote: > On Tue, Apr 26, 2016 at 06:23:17PM +, Bernd Edlinger wrote: >> as we all know, it's high time now to adjust the minimum supported >> gmp/mpfr/mpc versions for gcc-7. > > I'm not saying we shouldn't bump the minimum supported versions, but bumping > them immediately to the latest releases is IMHO undesirable unless the > benefits can justify it. > E.g. I don't consider gmp-6.0.0, or mpfr-3.1.2, or mpc-1.0.2 that obsolete > that I'd have to download a newer one for my daily use. > > Jakub > Yes, thanks. That would be acceptable as well. I think the patch will work with these versions too. I'd even use these versions for download_prerequisites if they are more widespread in use today. Bernd.
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Tue, 26 Apr 2016, Bernd Edlinger wrote: as we all know, it's high time now to adjust the minimum supported gmp/mpfr/mpc versions for gcc-7. So this attached patch is now targeting at only supporting the currently latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying to support all previous versions, especially in-tree, but also without the in-tree configuration the previously used versions are really creating trouble nowadays. For in-tree builds, requiring the latest version makes sense to me. When building gcc with a pre-installed gmp/mpfr/mpc (say the one provided by your linux distribution), that's much more painful, and the benefit is not as clear. What "trouble" do you have in mind? To support gmp-6.1.0 in-tree we have to set AM_CFLAGS=-DNO_ASM as already done with mpfr. This was already discussed recently on this list. Note that gmp-6.1.1 is supposed to be out any day now and will not require -DNO_ASM anymore. -- Marc Glisse
Re: [RFC] Update gmp/mpfr/mpc minimum versions
On Tue, Apr 26, 2016 at 06:23:17PM +, Bernd Edlinger wrote: > as we all know, it's high time now to adjust the minimum supported > gmp/mpfr/mpc versions for gcc-7. I'm not saying we shouldn't bump the minimum supported versions, but bumping them immediately to the latest releases is IMHO undesirable unless the benefits can justify it. E.g. I don't consider gmp-6.0.0, or mpfr-3.1.2, or mpc-1.0.2 that obsolete that I'd have to download a newer one for my daily use. Jakub
[RFC] Update gmp/mpfr/mpc minimum versions
Hi,
as we all know, it's high time now to adjust the minimum supported
gmp/mpfr/mpc versions for gcc-7.
So this attached patch is now targeting at only supporting the currently
latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying
to support all previous versions, especially in-tree, but also without the
in-tree configuration the previously used versions are really creating
trouble nowadays.
To support gmp-6.1.0 in-tree we have to set AM_CFLAGS=-DNO_ASM
as already done with mpfr. This was already discussed recently on this list.
Initially I was trying to use gmp's new --disable-assembly, but
after careful consideration, I think that we still need to set gmp's
target to none-host-vendor triplet, because only that prevents
gmp to get smart on selecting one of the different possible
target-ABIs. This would not really work in general, because
gcc overrides the CFLAGS an thus defeats the ABI selection
again.
What do you think, is this patch generally acceptable?
Of course it would mean that everybody would have to use
the recent gmp/mpfr/mpc tar balls immediately, and someone would
have to upload them to ftp://gcc.gnu.org/pub/gcc/infrastructure/
before this patch can be applied of course (I don't know how to).
Thanks
Bernd.2016-04-26 Bernd Edlinger
* configure.ac (mpfr): Remove pre-3.1.0 compatibility.
* configure: Regenerated.
* Makefile.def (gmp): Explicitly disable assembler.
(mpfr): Adjust lib_path.
(mpc): Likewise.
* Makefile.in: Regenerated.
gcc/
2016-04-26 Bernd Edlinger
* doc/install.texi: Adjust gmp/mpfr/mpc minimum versions.
contrib/
2016-04-26 Bernd Edlinger
* download_prerequisites: Adjust gmp/mpfr/mpc versions.
Index: Makefile.def
===
--- Makefile.def (revision 234533)
+++ Makefile.def (working copy)
@@ -50,6 +50,7 @@ host_modules= { module= gcc; bootstrap=true;
host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
// Work around in-tree gmp configure bug with missing flex.
extra_configure_flags='--disable-shared LEX="touch lex.yy.c"';
+ extra_make_flags='AM_CFLAGS="-DNO_ASM"';
no_install= true;
// none-*-* disables asm optimizations, bootstrap-testing
// the compiler more thoroughly.
@@ -57,11 +58,11 @@ host_modules= { module= gmp; lib_path=.libs; boots
// gmp's configure will complain if given anything
// different from host for target.
target="none-${host_vendor}-${host_os}"; };
-host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
+host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared @extra_mpfr_configure_flags@';
extra_make_flags='AM_CFLAGS="-DNO_ASM"';
no_install= true; };
-host_modules= { module= mpc; lib_path=.libs; bootstrap=true;
+host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared @extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
no_install= true; };
host_modules= { module= isl; lib_path=.libs; bootstrap=true;
Index: Makefile.in
===
--- Makefile.in (revision 234533)
+++ Makefile.in (working copy)
@@ -639,12 +639,12 @@ HOST_LIB_PATH_gmp = \
@if mpfr
HOST_LIB_PATH_mpfr = \
- $$r/$(HOST_SUBDIR)/mpfr/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/.libs:
+ $$r/$(HOST_SUBDIR)/mpfr/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/src/.libs:
@endif mpfr
@if mpc
HOST_LIB_PATH_mpc = \
- $$r/$(HOST_SUBDIR)/mpc/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/.libs:
+ $$r/$(HOST_SUBDIR)/mpc/src/.libs:$$r/$(HOST_SUBDIR)/prev-mpc/src/.libs:
@endif mpc
@if isl
@@ -11299,7 +11299,7 @@ all-gmp: configure-gmp
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/gmp && \
- $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) \
+ $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
$(TARGET-gmp))
@endif gmp
@@ -11328,7 +11328,7 @@ all-stage1-gmp: configure-stage1-gmp
CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
$(EXTRA_HOST_FLAGS) \
- $(STAGE1_FLAGS_TO_PASS) \
+ $(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
TFLAGS="$(STAGE1_TFLAGS)" \
$(TARGET-stage1-gmp)
@@ -11343,7 +11343,7 @@ clean-stage1-gmp:
fi; \
cd $(HOST_SUBDIR)/gmp && \
$(MAKE) $(EXTRA_HOST_FLAGS) \
- $(STAGE1_FLAGS_TO_PASS) clean
+ $(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" clean
@endif gmp-bootstrap
@@ -11370,7 +11370,7 @@ all-stage2-gmp: configure-stage2-gmp
CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
- $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) \
+ $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
TFLAGS="$(STAGE2_TFLAGS)
