* [PATCH]: bump minimum MPFR version, (includes some fortran bits)
@ 2008-10-05 5:56 Kaveh R. GHAZI
2008-10-05 13:52 ` Richard Guenther
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Kaveh R. GHAZI @ 2008-10-05 5:56 UTC (permalink / raw)
To: gcc, gcc-patches; +Cc: fortran
Since we're in stage3, I'm raising the issue of the MPFR version we
require for GCC, just as in last year's stage3 for gcc-4.3:
http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
released since Aug 2007). The "recommended" version of MPFR can be bumped
to the latest which is 2.3.2.
Doing this will allow me to remove several MPFR cpp conditionals in the
middle-end as well as in the fortran frontend. It also helps for future
work I plan to do with folding c99 complex number math functions, as that
work will require mpfr-2.3.0.
Patch bootstrapped on x86_64-unknown-linux-gnu using mpfr-2.3.2, no
regresions. I also configured with mpfr-2.2.0 to ensure that GCC still
fails the relevant checks with older versions of mpfr.
If approved, I'll again wait a week before installing so people can
upgrade their regtesters if necessary.
Okay for mainline?
Thanks,
--Kaveh
2008-10-04 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* configure.ac (MPFR check): Bump minimum version to 2.3.0 and
recommended version to 2.3.2.
* builtins.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
* doc/install.texi: Bump recommended MPFR to 2.3.2.
* configure: Regenerate.
fortran:
* simplify.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
diff -rup orig/egcc-SVN20081001/configure.ac egcc-SVN20081001/configure.ac
--- orig/egcc-SVN20081001/configure.ac 2008-09-06 02:00:10.000000000 +0200
+++ egcc-SVN20081001/configure.ac 2008-10-04 20:19:15.000000000 +0200
@@ -1267,11 +1267,11 @@ if test -d ${srcdir}/gcc && test "x$have
if test x"$have_gmp" = xyes; then
saved_LIBS="$LIBS"
LIBS="$LIBS $gmplibs"
- dnl MPFR 2.2.1 is acceptable, but MPFR 2.3.0 is better.
+ dnl MPFR 2.3.0 is acceptable, but MPFR 2.3.2 is better.
AC_MSG_CHECKING([for correct version of mpfr.h])
AC_TRY_LINK([#include <gmp.h>
#include <mpfr.h>],[
- #if MPFR_VERSION < MPFR_VERSION_NUM(2,2,1)
+ #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0)
choke me
#endif
mpfr_t n;
@@ -1284,7 +1284,7 @@ if test -d ${srcdir}/gcc && test "x$have
mpfr_subnormalize (x, t, GMP_RNDN);
], [AC_TRY_LINK([#include <gmp.h>
#include <mpfr.h>],[
- #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0)
+ #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,2)
choke me
#endif
mpfr_t n; mpfr_init(n);
@@ -1295,7 +1295,7 @@ if test -d ${srcdir}/gcc && test "x$have
CFLAGS="$saved_CFLAGS"
if test x$have_gmp != xyes; then
- AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
+ AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
diff -rup orig/egcc-SVN20081001/gcc/builtins.c egcc-SVN20081001/gcc/builtins.c
--- orig/egcc-SVN20081001/gcc/builtins.c 2008-08-30 02:00:13.000000000 +0200
+++ egcc-SVN20081001/gcc/builtins.c 2008-10-04 20:22:06.000000000 +0200
@@ -231,13 +231,11 @@ static tree do_mpfr_arg2 (tree, tree, tr
static tree do_mpfr_arg3 (tree, tree, tree, tree,
int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_srcptr, mp_rnd_t));
static tree do_mpfr_sincos (tree, tree, tree);
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
static tree do_mpfr_bessel_n (tree, tree, tree,
int (*)(mpfr_ptr, long, mpfr_srcptr, mp_rnd_t),
const REAL_VALUE_TYPE *, bool);
static tree do_mpfr_remquo (tree, tree, tree);
static tree do_mpfr_lgamma_r (tree, tree, tree);
-#endif
/* Return true if NODE should be considered for inline expansion regardless
of the optimization level. This means whenever a function is invoked with
@@ -10112,7 +10110,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
&dconstm1, NULL, false);
break;
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
CASE_FLT_FN (BUILT_IN_J0):
if (validate_arg (arg0, REAL_TYPE))
return do_mpfr_arg1 (arg0, type, mpfr_j0,
@@ -10136,7 +10133,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
return do_mpfr_arg1 (arg0, type, mpfr_y1,
&dconst0, NULL, false);
break;
-#endif
CASE_FLT_FN (BUILT_IN_NAN):
case BUILT_IN_NAND32:
@@ -10252,7 +10248,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
switch (fcode)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
CASE_FLT_FN (BUILT_IN_JN):
if (validate_arg (arg0, INTEGER_TYPE)
&& validate_arg (arg1, REAL_TYPE))
@@ -10279,7 +10274,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
&& validate_arg(arg1, POINTER_TYPE))
return do_mpfr_lgamma_r (arg0, arg1, type);
break;
-#endif
CASE_FLT_FN (BUILT_IN_ATAN2):
if (validate_arg (arg0, REAL_TYPE)
@@ -10436,14 +10430,12 @@ fold_builtin_3 (tree fndecl, tree arg0,
return do_mpfr_arg3 (arg0, arg1, arg2, type, mpfr_fma);
break;
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
CASE_FLT_FN (BUILT_IN_REMQUO):
if (validate_arg (arg0, REAL_TYPE)
&& validate_arg(arg1, REAL_TYPE)
&& validate_arg(arg2, POINTER_TYPE))
return do_mpfr_remquo (arg0, arg1, arg2);
break;
-#endif
case BUILT_IN_MEMSET:
return fold_builtin_memset (arg0, arg1, arg2, type, ignore);
@@ -13054,7 +13046,6 @@ do_mpfr_sincos (tree arg, tree arg_sinp,
return result;
}
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
/* If argument ARG1 is an INTEGER_CST and ARG2 is a REAL_CST, call the
two-argument mpfr order N Bessel function FUNC on them and return
the resulting value as a tree with type TYPE. The mpfr precision
@@ -13239,7 +13230,6 @@ do_mpfr_lgamma_r (tree arg, tree arg_sg,
return result;
}
-#endif
/* FIXME tuples.
The functions below provide an alternate interface for folding
diff -rup orig/egcc-SVN20081001/gcc/doc/install.texi egcc-SVN20081001/gcc/doc/install.texi
--- orig/egcc-SVN20081001/gcc/doc/install.texi 2008-09-14 02:00:04.000000000 +0200
+++ egcc-SVN20081001/gcc/doc/install.texi 2008-10-04 20:20:03.000000000 +0200
@@ -309,7 +309,7 @@ library search path, you will have to co
@option{--with-gmp} configure option. See also
@option{--with-gmp-lib} and @option{--with-gmp-include}.
-@item MPFR Library version 2.3.0 (or later)
+@item MPFR Library version 2.3.2 (or later)
Necessary to build GCC@. It can be downloaded from
@uref{http://www.mpfr.org/}. The version of MPFR that is bundled with
diff -rup orig/egcc-SVN20081001/gcc/fortran/simplify.c egcc-SVN20081001/gcc/fortran/simplify.c
--- orig/egcc-SVN20081001/gcc/fortran/simplify.c 2008-09-12 02:00:04.000000000 +0200
+++ egcc-SVN20081001/gcc/fortran/simplify.c 2008-10-04 20:22:58.000000000 +0200
@@ -668,7 +668,6 @@ gfc_simplify_atan2 (gfc_expr *y, gfc_exp
gfc_expr *
gfc_simplify_bessel_j0 (gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
if (x->expr_type != EXPR_CONSTANT)
@@ -678,16 +677,12 @@ gfc_simplify_bessel_j0 (gfc_expr *x ATTR
mpfr_j0 (result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_J0");
-#else
- return NULL;
-#endif
}
gfc_expr *
gfc_simplify_bessel_j1 (gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
if (x->expr_type != EXPR_CONSTANT)
@@ -697,9 +692,6 @@ gfc_simplify_bessel_j1 (gfc_expr *x ATTR
mpfr_j1 (result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_J1");
-#else
- return NULL;
-#endif
}
@@ -707,7 +699,6 @@ gfc_expr *
gfc_simplify_bessel_jn (gfc_expr *order ATTRIBUTE_UNUSED,
gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
long n;
@@ -719,16 +710,12 @@ gfc_simplify_bessel_jn (gfc_expr *order
mpfr_jn (result->value.real, n, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_JN");
-#else
- return NULL;
-#endif
}
gfc_expr *
gfc_simplify_bessel_y0 (gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
if (x->expr_type != EXPR_CONSTANT)
@@ -738,16 +725,12 @@ gfc_simplify_bessel_y0 (gfc_expr *x ATTR
mpfr_y0 (result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_Y0");
-#else
- return NULL;
-#endif
}
gfc_expr *
gfc_simplify_bessel_y1 (gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
if (x->expr_type != EXPR_CONSTANT)
@@ -757,9 +740,6 @@ gfc_simplify_bessel_y1 (gfc_expr *x ATTR
mpfr_y1 (result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_Y1");
-#else
- return NULL;
-#endif
}
@@ -767,7 +747,6 @@ gfc_expr *
gfc_simplify_bessel_yn (gfc_expr *order ATTRIBUTE_UNUSED,
gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
long n;
@@ -779,9 +758,6 @@ gfc_simplify_bessel_yn (gfc_expr *order
mpfr_yn (result->value.real, n, x->value.real, GFC_RND_MODE);
return range_check (result, "BESSEL_YN");
-#else
- return NULL;
-#endif
}
@@ -2459,7 +2435,6 @@ gfc_simplify_len_trim (gfc_expr *e, gfc_
gfc_expr *
gfc_simplify_lgamma (gfc_expr *x ATTRIBUTE_UNUSED)
{
-#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
gfc_expr *result;
int sg;
@@ -2471,9 +2446,6 @@ gfc_simplify_lgamma (gfc_expr *x ATTRIBU
mpfr_lgamma (result->value.real, &sg, x->value.real, GFC_RND_MODE);
return range_check (result, "LGAMMA");
-#else
- return NULL;
-#endif
}
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 5:56 [PATCH]: bump minimum MPFR version, (includes some fortran bits) Kaveh R. GHAZI
@ 2008-10-05 13:52 ` Richard Guenther
2008-10-05 14:10 ` Gerald Pfeifer
2008-10-06 23:37 ` Kaveh R. Ghazi
2008-10-06 13:56 ` Adrian Bunk
2008-10-26 12:59 ` [PATCH]: bump minimum MPFR version, (includes some fortran bits) Geoff Keating
2 siblings, 2 replies; 36+ messages in thread
From: Richard Guenther @ 2008-10-05 13:52 UTC (permalink / raw)
To: Kaveh R. GHAZI; +Cc: gcc, gcc-patches, fortran
On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> Since we're in stage3, I'm raising the issue of the MPFR version we
> require for GCC, just as in last year's stage3 for gcc-4.3:
> http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
>
> I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
> released since Aug 2007). The "recommended" version of MPFR can be bumped
> to the latest which is 2.3.2.
>
> Doing this will allow me to remove several MPFR cpp conditionals in the
> middle-end as well as in the fortran frontend. It also helps for future
> work I plan to do with folding c99 complex number math functions, as that
> work will require mpfr-2.3.0.
>
> Patch bootstrapped on x86_64-unknown-linux-gnu using mpfr-2.3.2, no
> regresions. I also configured with mpfr-2.2.0 to ensure that GCC still
> fails the relevant checks with older versions of mpfr.
>
> If approved, I'll again wait a week before installing so people can
> upgrade their regtesters if necessary.
This is reasonable. Note that
http://gcc.gnu.org/install/prerequisites.html already lists
mpfr 2.3.0 as prerequesite (that page still might need an update for
clarification).
> Okay for mainline?
Ok if there are no objections within the week.
Thanks,
Richard.
> Thanks,
> --Kaveh
>
>
> 2008-10-04 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
>
> * configure.ac (MPFR check): Bump minimum version to 2.3.0 and
> recommended version to 2.3.2.
> * builtins.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
> * doc/install.texi: Bump recommended MPFR to 2.3.2.
>
> * configure: Regenerate.
>
> fortran:
> * simplify.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
>
> diff -rup orig/egcc-SVN20081001/configure.ac egcc-SVN20081001/configure.ac
> --- orig/egcc-SVN20081001/configure.ac 2008-09-06 02:00:10.000000000 +0200
> +++ egcc-SVN20081001/configure.ac 2008-10-04 20:19:15.000000000 +0200
> @@ -1267,11 +1267,11 @@ if test -d ${srcdir}/gcc && test "x$have
> if test x"$have_gmp" = xyes; then
> saved_LIBS="$LIBS"
> LIBS="$LIBS $gmplibs"
> - dnl MPFR 2.2.1 is acceptable, but MPFR 2.3.0 is better.
> + dnl MPFR 2.3.0 is acceptable, but MPFR 2.3.2 is better.
> AC_MSG_CHECKING([for correct version of mpfr.h])
> AC_TRY_LINK([#include <gmp.h>
> #include <mpfr.h>],[
> - #if MPFR_VERSION < MPFR_VERSION_NUM(2,2,1)
> + #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0)
> choke me
> #endif
> mpfr_t n;
> @@ -1284,7 +1284,7 @@ if test -d ${srcdir}/gcc && test "x$have
> mpfr_subnormalize (x, t, GMP_RNDN);
> ], [AC_TRY_LINK([#include <gmp.h>
> #include <mpfr.h>],[
> - #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0)
> + #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,2)
> choke me
> #endif
> mpfr_t n; mpfr_init(n);
> @@ -1295,7 +1295,7 @@ if test -d ${srcdir}/gcc && test "x$have
> CFLAGS="$saved_CFLAGS"
>
> if test x$have_gmp != xyes; then
> - AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
> + AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
> Try the --with-gmp and/or --with-mpfr options to specify their locations.
> Copies of these libraries' source code can be found at their respective
> hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
> diff -rup orig/egcc-SVN20081001/gcc/builtins.c egcc-SVN20081001/gcc/builtins.c
> --- orig/egcc-SVN20081001/gcc/builtins.c 2008-08-30 02:00:13.000000000 +0200
> +++ egcc-SVN20081001/gcc/builtins.c 2008-10-04 20:22:06.000000000 +0200
> @@ -231,13 +231,11 @@ static tree do_mpfr_arg2 (tree, tree, tr
> static tree do_mpfr_arg3 (tree, tree, tree, tree,
> int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_srcptr, mp_rnd_t));
> static tree do_mpfr_sincos (tree, tree, tree);
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> static tree do_mpfr_bessel_n (tree, tree, tree,
> int (*)(mpfr_ptr, long, mpfr_srcptr, mp_rnd_t),
> const REAL_VALUE_TYPE *, bool);
> static tree do_mpfr_remquo (tree, tree, tree);
> static tree do_mpfr_lgamma_r (tree, tree, tree);
> -#endif
>
> /* Return true if NODE should be considered for inline expansion regardless
> of the optimization level. This means whenever a function is invoked with
> @@ -10112,7 +10110,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
> &dconstm1, NULL, false);
> break;
>
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> CASE_FLT_FN (BUILT_IN_J0):
> if (validate_arg (arg0, REAL_TYPE))
> return do_mpfr_arg1 (arg0, type, mpfr_j0,
> @@ -10136,7 +10133,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
> return do_mpfr_arg1 (arg0, type, mpfr_y1,
> &dconst0, NULL, false);
> break;
> -#endif
>
> CASE_FLT_FN (BUILT_IN_NAN):
> case BUILT_IN_NAND32:
> @@ -10252,7 +10248,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
>
> switch (fcode)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> CASE_FLT_FN (BUILT_IN_JN):
> if (validate_arg (arg0, INTEGER_TYPE)
> && validate_arg (arg1, REAL_TYPE))
> @@ -10279,7 +10274,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
> && validate_arg(arg1, POINTER_TYPE))
> return do_mpfr_lgamma_r (arg0, arg1, type);
> break;
> -#endif
>
> CASE_FLT_FN (BUILT_IN_ATAN2):
> if (validate_arg (arg0, REAL_TYPE)
> @@ -10436,14 +10430,12 @@ fold_builtin_3 (tree fndecl, tree arg0,
> return do_mpfr_arg3 (arg0, arg1, arg2, type, mpfr_fma);
> break;
>
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> CASE_FLT_FN (BUILT_IN_REMQUO):
> if (validate_arg (arg0, REAL_TYPE)
> && validate_arg(arg1, REAL_TYPE)
> && validate_arg(arg2, POINTER_TYPE))
> return do_mpfr_remquo (arg0, arg1, arg2);
> break;
> -#endif
>
> case BUILT_IN_MEMSET:
> return fold_builtin_memset (arg0, arg1, arg2, type, ignore);
> @@ -13054,7 +13046,6 @@ do_mpfr_sincos (tree arg, tree arg_sinp,
> return result;
> }
>
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> /* If argument ARG1 is an INTEGER_CST and ARG2 is a REAL_CST, call the
> two-argument mpfr order N Bessel function FUNC on them and return
> the resulting value as a tree with type TYPE. The mpfr precision
> @@ -13239,7 +13230,6 @@ do_mpfr_lgamma_r (tree arg, tree arg_sg,
>
> return result;
> }
> -#endif
>
> /* FIXME tuples.
> The functions below provide an alternate interface for folding
> diff -rup orig/egcc-SVN20081001/gcc/doc/install.texi egcc-SVN20081001/gcc/doc/install.texi
> --- orig/egcc-SVN20081001/gcc/doc/install.texi 2008-09-14 02:00:04.000000000 +0200
> +++ egcc-SVN20081001/gcc/doc/install.texi 2008-10-04 20:20:03.000000000 +0200
> @@ -309,7 +309,7 @@ library search path, you will have to co
> @option{--with-gmp} configure option. See also
> @option{--with-gmp-lib} and @option{--with-gmp-include}.
>
> -@item MPFR Library version 2.3.0 (or later)
> +@item MPFR Library version 2.3.2 (or later)
>
> Necessary to build GCC@. It can be downloaded from
> @uref{http://www.mpfr.org/}. The version of MPFR that is bundled with
> diff -rup orig/egcc-SVN20081001/gcc/fortran/simplify.c egcc-SVN20081001/gcc/fortran/simplify.c
> --- orig/egcc-SVN20081001/gcc/fortran/simplify.c 2008-09-12 02:00:04.000000000 +0200
> +++ egcc-SVN20081001/gcc/fortran/simplify.c 2008-10-04 20:22:58.000000000 +0200
> @@ -668,7 +668,6 @@ gfc_simplify_atan2 (gfc_expr *y, gfc_exp
> gfc_expr *
> gfc_simplify_bessel_j0 (gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
>
> if (x->expr_type != EXPR_CONSTANT)
> @@ -678,16 +677,12 @@ gfc_simplify_bessel_j0 (gfc_expr *x ATTR
> mpfr_j0 (result->value.real, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_J0");
> -#else
> - return NULL;
> -#endif
> }
>
>
> gfc_expr *
> gfc_simplify_bessel_j1 (gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
>
> if (x->expr_type != EXPR_CONSTANT)
> @@ -697,9 +692,6 @@ gfc_simplify_bessel_j1 (gfc_expr *x ATTR
> mpfr_j1 (result->value.real, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_J1");
> -#else
> - return NULL;
> -#endif
> }
>
>
> @@ -707,7 +699,6 @@ gfc_expr *
> gfc_simplify_bessel_jn (gfc_expr *order ATTRIBUTE_UNUSED,
> gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
> long n;
>
> @@ -719,16 +710,12 @@ gfc_simplify_bessel_jn (gfc_expr *order
> mpfr_jn (result->value.real, n, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_JN");
> -#else
> - return NULL;
> -#endif
> }
>
>
> gfc_expr *
> gfc_simplify_bessel_y0 (gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
>
> if (x->expr_type != EXPR_CONSTANT)
> @@ -738,16 +725,12 @@ gfc_simplify_bessel_y0 (gfc_expr *x ATTR
> mpfr_y0 (result->value.real, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_Y0");
> -#else
> - return NULL;
> -#endif
> }
>
>
> gfc_expr *
> gfc_simplify_bessel_y1 (gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
>
> if (x->expr_type != EXPR_CONSTANT)
> @@ -757,9 +740,6 @@ gfc_simplify_bessel_y1 (gfc_expr *x ATTR
> mpfr_y1 (result->value.real, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_Y1");
> -#else
> - return NULL;
> -#endif
> }
>
>
> @@ -767,7 +747,6 @@ gfc_expr *
> gfc_simplify_bessel_yn (gfc_expr *order ATTRIBUTE_UNUSED,
> gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
> long n;
>
> @@ -779,9 +758,6 @@ gfc_simplify_bessel_yn (gfc_expr *order
> mpfr_yn (result->value.real, n, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "BESSEL_YN");
> -#else
> - return NULL;
> -#endif
> }
>
>
> @@ -2459,7 +2435,6 @@ gfc_simplify_len_trim (gfc_expr *e, gfc_
> gfc_expr *
> gfc_simplify_lgamma (gfc_expr *x ATTRIBUTE_UNUSED)
> {
> -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0)
> gfc_expr *result;
> int sg;
>
> @@ -2471,9 +2446,6 @@ gfc_simplify_lgamma (gfc_expr *x ATTRIBU
> mpfr_lgamma (result->value.real, &sg, x->value.real, GFC_RND_MODE);
>
> return range_check (result, "LGAMMA");
> -#else
> - return NULL;
> -#endif
> }
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 13:52 ` Richard Guenther
@ 2008-10-05 14:10 ` Gerald Pfeifer
2008-10-05 14:43 ` Richard Guenther
2008-10-06 23:37 ` Kaveh R. Ghazi
1 sibling, 1 reply; 36+ messages in thread
From: Gerald Pfeifer @ 2008-10-05 14:10 UTC (permalink / raw)
To: Richard Guenther; +Cc: Kaveh R. GHAZI, gcc, gcc-patches, fortran
On Sun, 5 Oct 2008, Richard Guenther wrote:
> This is reasonable. Note that
> http://gcc.gnu.org/install/prerequisites.html already lists
> mpfr 2.3.0 as prerequesite (that page still might need an update for
> clarification).
That page is generated from gcc/doc/install.texi, so once Kaveh has
committed his patch it should be updated within (at most) 24 hours.
If not, let me know guys, and I'll try to debug it. :-)
Gerald
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 14:10 ` Gerald Pfeifer
@ 2008-10-05 14:43 ` Richard Guenther
2008-10-05 16:34 ` Manuel López-Ibáñez
0 siblings, 1 reply; 36+ messages in thread
From: Richard Guenther @ 2008-10-05 14:43 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Kaveh R. GHAZI, gcc, gcc-patches, fortran
On Sun, Oct 5, 2008 at 3:51 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Sun, 5 Oct 2008, Richard Guenther wrote:
>> This is reasonable. Note that
>> http://gcc.gnu.org/install/prerequisites.html already lists
>> mpfr 2.3.0 as prerequesite (that page still might need an update for
>> clarification).
>
> That page is generated from gcc/doc/install.texi, so once Kaveh has
> committed his patch it should be updated within (at most) 24 hours.
>
> If not, let me know guys, and I'll try to debug it. :-)
Ah, right. Don't we want this page to be version-specific beyond
gcc.gnu.org/gcc-X.Y/?
(like all of the installation instructions, liked from onlinedocs/
there is only instructions
for trunk).
Richard.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 14:43 ` Richard Guenther
@ 2008-10-05 16:34 ` Manuel López-Ibáñez
0 siblings, 0 replies; 36+ messages in thread
From: Manuel López-Ibáñez @ 2008-10-05 16:34 UTC (permalink / raw)
To: Richard Guenther
Cc: Gerald Pfeifer, Kaveh R. GHAZI, gcc, gcc-patches, fortran
2008/10/5 Richard Guenther <richard.guenther@gmail.com>:
> Ah, right. Don't we want this page to be version-specific beyond
> gcc.gnu.org/gcc-X.Y/?
> (like all of the installation instructions, liked from onlinedocs/
> there is only instructions
> for trunk).
This is bug 32927.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
Cheers,
Manuel.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 5:56 [PATCH]: bump minimum MPFR version, (includes some fortran bits) Kaveh R. GHAZI
2008-10-05 13:52 ` Richard Guenther
@ 2008-10-06 13:56 ` Adrian Bunk
2008-10-06 23:16 ` [PATCH]: bump minimum MPFR version, (includes some fortranbits) Kaveh R. Ghazi
2008-10-26 12:59 ` [PATCH]: bump minimum MPFR version, (includes some fortran bits) Geoff Keating
2 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2008-10-06 13:56 UTC (permalink / raw)
To: Kaveh R. GHAZI; +Cc: gcc, gcc-patches, fortran
On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote:
> Since we're in stage3, I'm raising the issue of the MPFR version we
> require for GCC, just as in last year's stage3 for gcc-4.3:
> http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
>
> I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
> released since Aug 2007). The "recommended" version of MPFR can be bumped
> to the latest which is 2.3.2.
>...
Considering that your patch removes the conditionals on MPFR versions
from the code (good!), is there any reason for gcc to keep this unusual
minimum/recommended split in the requirement?
Either 2.3.0 is good enough, or 2.3.2 contains some critical fix
and should be the minimum version.
Anything I miss?
> Thanks,
> --Kaveh
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-06 13:56 ` Adrian Bunk
@ 2008-10-06 23:16 ` Kaveh R. Ghazi
2008-10-06 23:40 ` Ben Elliston
2008-10-07 18:52 ` Adrian Bunk
0 siblings, 2 replies; 36+ messages in thread
From: Kaveh R. Ghazi @ 2008-10-06 23:16 UTC (permalink / raw)
To: Adrian Bunk; +Cc: gcc, gcc-patches, fortran
From: "Adrian Bunk" <bunk@stusta.de>
> On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote:
>> Since we're in stage3, I'm raising the issue of the MPFR version we
>> require for GCC, just as in last year's stage3 for gcc-4.3:
>> http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
>>
>> I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
>> released since Aug 2007). The "recommended" version of MPFR can be
>> bumped
>> to the latest which is 2.3.2.
>>...
>
> Considering that your patch removes the conditionals on MPFR versions
> from the code (good!), is there any reason for gcc to keep this unusual
> minimum/recommended split in the requirement?
>
> Either 2.3.0 is good enough, or 2.3.2 contains some critical fix
> and should be the minimum version.
The last time this came up, the consensus was that we should not hard fail
the configure script even if the user would then be missing some mpfr bugfix
in the latest/greatest release. That's why we have the minimum/recommended
split.
But I see no reason not to encourage people and/or make them aware of the
need to upgrade if they are so inclined. Whether a particular fix is
"critical" can be in the eye of the beholder.
--Kaveh
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 13:52 ` Richard Guenther
2008-10-05 14:10 ` Gerald Pfeifer
@ 2008-10-06 23:37 ` Kaveh R. Ghazi
2008-10-07 7:55 ` Janne Blomqvist
1 sibling, 1 reply; 36+ messages in thread
From: Kaveh R. Ghazi @ 2008-10-06 23:37 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc, gcc-patches, fortran
From: "Richard Guenther" <richard.guenther@gmail.com>
> On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu>
> wrote:
>> Okay for mainline?
>
> Ok if there are no objections within the week.
>
> Thanks,
> Richard.
Great, thanks. Can I get an explicit ack from a fortran maintainer as well?
Regards,
--Kaveh
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-06 23:16 ` [PATCH]: bump minimum MPFR version, (includes some fortranbits) Kaveh R. Ghazi
@ 2008-10-06 23:40 ` Ben Elliston
2008-10-07 0:35 ` Andrew Pinski
2008-10-07 18:52 ` Adrian Bunk
1 sibling, 1 reply; 36+ messages in thread
From: Ben Elliston @ 2008-10-06 23:40 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: Adrian Bunk, gcc, gcc-patches, fortran
On Mon, 2008-10-06 at 16:10 -0700, Kaveh R. Ghazi wrote:
> The last time this came up, the consensus was that we should not hard fail
> the configure script even if the user would then be missing some mpfr bugfix
> in the latest/greatest release. That's why we have the minimum/recommended
> split.
Doesn't this mean that we can then have two different versions of GCC
(as identified by gcc --version), linked with different mpfr libraries,
that may exhibit different behaviour?
Ben
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-06 23:40 ` Ben Elliston
@ 2008-10-07 0:35 ` Andrew Pinski
0 siblings, 0 replies; 36+ messages in thread
From: Andrew Pinski @ 2008-10-07 0:35 UTC (permalink / raw)
To: Ben Elliston; +Cc: Kaveh R. Ghazi, Adrian Bunk, gcc, gcc-patches, fortran
On Mon, Oct 6, 2008 at 4:36 PM, Ben Elliston <bje@au1.ibm.com> wrote:
> On Mon, 2008-10-06 at 16:10 -0700, Kaveh R. Ghazi wrote:
>
>> The last time this came up, the consensus was that we should not hard fail
>> the configure script even if the user would then be missing some mpfr bugfix
>> in the latest/greatest release. That's why we have the minimum/recommended
>> split.
>
> Doesn't this mean that we can then have two different versions of GCC
> (as identified by gcc --version), linked with different mpfr libraries,
> that may exhibit different behaviour?
Semi, we do output the version of MPFR in cc1 --version output:
GNU C (GCC) version 4.4.0 20081003 (experimental) [trunk revision
140850] (i386-apple-darwin8.11.1)
compiled by GNU C version 4.4.0 20081003 (experimental) [trunk
revision 140850], GMP version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-06 23:37 ` Kaveh R. Ghazi
@ 2008-10-07 7:55 ` Janne Blomqvist
0 siblings, 0 replies; 36+ messages in thread
From: Janne Blomqvist @ 2008-10-07 7:55 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc, gcc-patches, fortran
On Tue, Oct 7, 2008 at 2:15 AM, Kaveh R. Ghazi <ghazi@caip.rutgers.edu> wrote:
> From: "Richard Guenther" <richard.guenther@gmail.com>
>
>> On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu>
>> wrote:
>>>
>>> Okay for mainline?
>>
>> Ok if there are no objections within the week.
>>
>> Thanks,
>> Richard.
>
> Great, thanks. Can I get an explicit ack from a fortran maintainer as well?
Ok.
--
Janne Blomqvist
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-06 23:16 ` [PATCH]: bump minimum MPFR version, (includes some fortranbits) Kaveh R. Ghazi
2008-10-06 23:40 ` Ben Elliston
@ 2008-10-07 18:52 ` Adrian Bunk
2008-10-13 16:00 ` Vincent Lefevre
1 sibling, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2008-10-07 18:52 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc, gcc-patches, fortran
On Mon, Oct 06, 2008 at 04:10:04PM -0700, Kaveh R. Ghazi wrote:
> From: "Adrian Bunk" <bunk@stusta.de>
>
>> On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote:
>>> Since we're in stage3, I'm raising the issue of the MPFR version we
>>> require for GCC, just as in last year's stage3 for gcc-4.3:
>>> http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
>>>
>>> I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
>>> released since Aug 2007). The "recommended" version of MPFR can be
>>> bumped
>>> to the latest which is 2.3.2.
>>> ...
>>
>> Considering that your patch removes the conditionals on MPFR versions
>> from the code (good!), is there any reason for gcc to keep this unusual
>> minimum/recommended split in the requirement?
>>
>> Either 2.3.0 is good enough, or 2.3.2 contains some critical fix
>> and should be the minimum version.
>
> The last time this came up, the consensus was that we should not hard
> fail the configure script even if the user would then be missing some
> mpfr bugfix in the latest/greatest release. That's why we have the
> minimum/recommended split.
I see the point for the 2.2.1/2.3.0 versions since 2.3.0 introduced
additional functionality gcc can use.
> But I see no reason not to encourage people and/or make them aware of the
> need to upgrade if they are so inclined. Whether a particular fix is
> "critical" can be in the eye of the beholder.
But is there any "need to upgrade" to 2.3.2 since it would fix a bug gcc
ran into?
IMHO it's not "in the eye of the beholder" whether 2.3.2 contains a
"critical" fix _for usage by gcc_.
> --Kaveh
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-07 18:52 ` Adrian Bunk
@ 2008-10-13 16:00 ` Vincent Lefevre
2008-10-13 16:42 ` Antwort: " Markus Milleder
0 siblings, 1 reply; 36+ messages in thread
From: Vincent Lefevre @ 2008-10-13 16:00 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Kaveh R. Ghazi, gcc, gcc-patches, fortran
On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> gcc ran into?
FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs
listed on <http://www.mpfr.org/mpfr-2.3.0/#fixed>. I think that the
bugs in question are:
* The mpfr_gamma function applied on a huge integer fails on 64-bit
machines. But I don't know what the failure was (Paul Zimmermann
fixed this bug, so that he should know more than me).
Note: any double-precision number >= 2^52 is an integer.
* The mpfr_erfc function is very inefficient on large negative
numbers.
* The mpfr_j0 function applied on a large negative number and the
mpfr_jn function applied on (even integer, large negative number)
return a result with a wrong sign.
* The mpfr_asin function applied on ±0 does not set the sign of the
null result.
* The mpfr_gamma function can return a result with a wrong sign
(negative instead of positive) in case of underflow with a
positive value, e.g. on -1000000001.5 in the default exponent
range.
and perhaps bugs in mpfr_pow on particular values.
All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
not make any difference for GCC. The fixed bugs are listed here:
<http://www.mpfr.org/mpfr-2.3.1/#fixed>. They mainly concern
underflow/overflow exceptions, which should not occur on
double-precision numbers. And according to my tests, it is very
unlikely that the first mpfr_exp bug can have an influence on
double-precision numbers.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 36+ messages in thread
* Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-13 16:00 ` Vincent Lefevre
@ 2008-10-13 16:42 ` Markus Milleder
2008-10-13 17:15 ` Adrian Bunk
0 siblings, 1 reply; 36+ messages in thread
From: Markus Milleder @ 2008-10-13 16:42 UTC (permalink / raw)
To: vincent+gcc; +Cc: Adrian Bunk, fortran, gcc, gcc-patches, Kaveh R. Ghazi
Vincent Lefevre schrieb am 13.10.2008 16:16:38:
> On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> > But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> > gcc ran into?
>
> FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs
<snip bug list>
> All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
> not make any difference for GCC. The fixed bugs are listed here:
<snip again>
This seems to call for MPFR 2.3.1 as a minimum version for GCC 4.4
However, let me ask the reverse question:
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) ?
Markus Milleder
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-13 16:42 ` Antwort: " Markus Milleder
@ 2008-10-13 17:15 ` Adrian Bunk
2008-10-14 12:59 ` Antwort: " Markus Milleder
0 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2008-10-13 17:15 UTC (permalink / raw)
To: Markus Milleder; +Cc: vincent+gcc, fortran, gcc, gcc-patches, Kaveh R. Ghazi
On Mon, Oct 13, 2008 at 04:42:08PM +0200, Markus Milleder wrote:
> Vincent Lefevre schrieb am 13.10.2008 16:16:38:
>
> > On 2008-10-07 21:42:30 +0300, Adrian Bunk wrote:
> > > But is there any "need to upgrade" to 2.3.2 since it would fix a bug
> > > gcc ran into?
> >
> > FYI, GCC can be affected by some bugs in MPFR 2.3.0, amongst the bugs
>
> <snip bug list>
>
> > All these bugs were fixed in MPFR 2.3.1. AFAIK, MPFR 2.3.2 should
> > not make any difference for GCC. The fixed bugs are listed here:
>
> <snip again>
>
> This seems to call for MPFR 2.3.1 as a minimum version for GCC 4.4
>
> However, let me ask the reverse question:
>
> 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 .
And upgrading from 2.3.1 to let's say 3.0.0 might be a bad choice if
the new version contains regressions.
> Markus Milleder
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-13 17:15 ` Adrian Bunk
@ 2008-10-14 12:59 ` Markus Milleder
2008-10-14 13:10 ` Jakub Jelinek
` (3 more replies)
0 siblings, 4 replies; 36+ messages in thread
From: Markus Milleder @ 2008-10-14 12:59 UTC (permalink / raw)
To: bunk; +Cc: fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
Adrian Bunk schrieb am 13.10.2008 17:41:15:
> On Mon, Oct 13, 2008 at 04:42:08PM +0200, Markus Milleder wrote:
<snip>
> > 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
revision.
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.
Markus Milleder
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 12:59 ` Antwort: " Markus Milleder
@ 2008-10-14 13:10 ` Jakub Jelinek
2008-10-14 13:21 ` Tobias Schlüter
` (2 subsequent siblings)
3 siblings, 0 replies; 36+ messages in thread
From: Jakub Jelinek @ 2008-10-14 13:10 UTC (permalink / raw)
To: Markus Milleder
Cc: bunk, fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
On Tue, Oct 14, 2008 at 02:23:48PM +0200, Markus Milleder wrote:
> Much harder ?
>
> I don't think anybody who tries to build GCC from source will have any
> problem building MPFR first.
It is certainly an awkward annoyance, especially when you occassionally
need to build gcc on many different boxes, with various distro versions.
Obviously on your primary devel box you'll have a fresh mpfr installed (I
still have 2.3.1 though), but if you need from time to time test on less
often tested arches, strict version requirements just eat people's valuable
time for no big benefit.
Jakub
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 12:59 ` Antwort: " Markus Milleder
2008-10-14 13:10 ` Jakub Jelinek
@ 2008-10-14 13:21 ` Tobias Schlüter
2008-10-14 14:52 ` Adrian Bunk
2008-10-14 13:30 ` Antwort: Re: Antwort: " Adrian Bunk
2008-10-14 22:29 ` Nils Pipenbrinck
3 siblings, 1 reply; 36+ messages in thread
From: Tobias Schlüter @ 2008-10-14 13:21 UTC (permalink / raw)
To: Markus Milleder
Cc: bunk, fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
Markus Milleder wrote:
> Adrian Bunk schrieb am 13.10.2008 17:41:15:
>> 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.
They don't even need to do this, as mpfr can be built in-tree. It then
also won't interfere with a system-wide mpfr.
> 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.
This is moot because for the reason given above, these hypothetical
regressions are restricted to gcc if the person building gcc is careful.
Cheers,
- Tobi
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 12:59 ` Antwort: " Markus Milleder
2008-10-14 13:10 ` Jakub Jelinek
2008-10-14 13:21 ` Tobias Schlüter
@ 2008-10-14 13:30 ` Adrian Bunk
2008-10-14 22:29 ` Nils Pipenbrinck
3 siblings, 0 replies; 36+ messages in thread
From: Adrian Bunk @ 2008-10-14 13:30 UTC (permalink / raw)
To: Markus Milleder; +Cc: fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
On Tue, Oct 14, 2008 at 02:23:48PM +0200, Markus Milleder wrote:
> Adrian Bunk schrieb am 13.10.2008 17:41:15:
>...
> > 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
> revision.
>
> 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.
You seem to wrongly assume gcc was bound to one specific MPFR version?
If you force someone to upgrade from 2.3.1 to >= 2.3.2 he will usually
install the then-latest version, and that might be 3.0.0 .
> Markus Milleder
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 13:21 ` Tobias Schlüter
@ 2008-10-14 14:52 ` Adrian Bunk
2008-10-14 15:39 ` Tobias Schlüter
0 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2008-10-14 14:52 UTC (permalink / raw)
To: Tobias Schlüter
Cc: Markus Milleder, fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
On Tue, Oct 14, 2008 at 02:37:13PM +0200, Tobias Schlüter wrote:
> Markus Milleder wrote:
>> Adrian Bunk schrieb am 13.10.2008 17:41:15:
>>> 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.
>
> They don't even need to do this, as mpfr can be built in-tree. It then
> also won't interfere with a system-wide mpfr.
>
>> 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.
>
> This is moot because for the reason given above, these hypothetical
> regressions are restricted to gcc if the person building gcc is careful.
"careful" = uses an undocumented trick ?
Or where at http://gcc.gnu.org/install/ is this documented?
> Cheers,
> - Tobi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 14:52 ` Adrian Bunk
@ 2008-10-14 15:39 ` Tobias Schlüter
0 siblings, 0 replies; 36+ messages in thread
From: Tobias Schlüter @ 2008-10-14 15:39 UTC (permalink / raw)
To: Adrian Bunk
Cc: Markus Milleder, fortran, gcc, gcc-patches, Kaveh R. Ghazi, vincent+gcc
Adrian Bunk wrote:
> On Tue, Oct 14, 2008 at 02:37:13PM +0200, Tobias Schlüter wrote:
>> Markus Milleder wrote:
>>> Adrian Bunk schrieb am 13.10.2008 17:41:15:
>>>> 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.
>> They don't even need to do this, as mpfr can be built in-tree. It then
>> also won't interfere with a system-wide mpfr.
...
>> This is moot because for the reason given above, these hypothetical
>> regressions are restricted to gcc if the person building gcc is careful.
>
> "careful" = uses an undocumented trick ?
>
> Or where at http://gcc.gnu.org/install/ is this documented?
Hm, maybe it's not. I'm too lazy to search through all the
documentation of the GNU build system. While this may be written
someplace, it would certainly be a good thing to generalize the
paragraph about binutils in <http://gcc.gnu.org/install/download.html>.
Anyway, if you're afraid of regressions nothing prevents you from
building another mpfr out-of-tree (which is documented), and use that,
so the point is still moot. If you use a static library there is no
chance it will interfere with anything.
Greetings,
- Tobi
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 12:59 ` Antwort: " Markus Milleder
` (2 preceding siblings ...)
2008-10-14 13:30 ` Antwort: Re: Antwort: " Adrian Bunk
@ 2008-10-14 22:29 ` Nils Pipenbrinck
2008-10-14 22:31 ` Andrew Pinski
2008-10-15 1:09 ` Dave Korn
3 siblings, 2 replies; 36+ messages in thread
From: Nils Pipenbrinck @ 2008-10-14 22:29 UTC (permalink / raw)
Cc: gcc, gcc-patches
Markus Milleder wrote:
> I don't think anybody who tries to build GCC from source will have any
> problem building MPFR first.
>
Not entirely true:
Those of us who use cygwin and want to use the latest GCC have to first
compile a non MPFR GCC (e.g. 4.1.x) before they can compile the latest
GPFR and link GCC to it.
This is not a big deal if you know that you have to do that, but if you
don't know why the MPFR fails and wich snapshot you have to use as an
immediate step it can be very frustrating.
I would welcome a configuration option that disables all the MPFR
related things. That would make compiling GCC on a naked cygwin
installation *much* easier.
Cheers,
Nils Pipenbrinck
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 22:29 ` Nils Pipenbrinck
@ 2008-10-14 22:31 ` Andrew Pinski
2008-10-15 0:59 ` Nils Pipenbrinck
2008-10-15 1:09 ` Dave Korn
1 sibling, 1 reply; 36+ messages in thread
From: Andrew Pinski @ 2008-10-14 22:31 UTC (permalink / raw)
To: Nils Pipenbrinck; +Cc: gcc, gcc-patches
On Tue, Oct 14, 2008 at 1:28 PM, Nils Pipenbrinck
<n.pipenbrinck@cubic.org> wrote:
> Not entirely true:
>
> Those of us who use cygwin and want to use the latest GCC have to first
> compile a non MPFR GCC (e.g. 4.1.x) before they can compile the latest GPFR
> and link GCC to it.
I don't really see any issue here. Because to compile GCC you need a
compiler to begin with so compiling MPFR to start is easy, now if MPFR
does not support older GCCs, we might need to rethink this.
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 22:31 ` Andrew Pinski
@ 2008-10-15 0:59 ` Nils Pipenbrinck
2008-10-15 1:01 ` Andrew Pinski
2008-10-15 10:56 ` Brian Dessent
0 siblings, 2 replies; 36+ messages in thread
From: Nils Pipenbrinck @ 2008-10-15 0:59 UTC (permalink / raw)
Cc: gcc, gcc-patches
Andrew Pinski wrote:
> On Tue, Oct 14, 2008 at 1:28 PM, Nils Pipenbrinck
> <n.pipenbrinck@cubic.org> wrote:
>
>> Not entirely true:
>>
>> Those of us who use cygwin and want to use the latest GCC have to first
>> compile a non MPFR GCC (e.g. 4.1.x) before they can compile the latest GPFR
>> and link GCC to it.
>>
>
> I don't really see any issue here. Because to compile GCC you need a
> compiler to begin with so compiling MPFR to start is easy, now if MPFR
> does not support older GCCs, we might need to rethink this.
>
Cygwin comes with a GCC 3.4.somewhat out of the box. To compile MPFR you
need a 4.1 compiler. So you have to double compiling everything. And
worse: You have to know that you have to do this. There is no
information about that issue.
Besides that: compiling GCC under cygwin takes *much* longer than under
linux for example The config script alone (and there are more than one)
need around 20 minutes.
Nils
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-15 0:59 ` Nils Pipenbrinck
@ 2008-10-15 1:01 ` Andrew Pinski
2008-10-15 10:56 ` Brian Dessent
1 sibling, 0 replies; 36+ messages in thread
From: Andrew Pinski @ 2008-10-15 1:01 UTC (permalink / raw)
To: Nils Pipenbrinck; +Cc: gcc, gcc-patches
On Tue, Oct 14, 2008 at 2:14 PM, Nils Pipenbrinck
<n.pipenbrinck@cubic.org> wrote:
> Cygwin comes with a GCC 3.4.somewhat out of the box. To compile MPFR you
> need a 4.1 compiler. So you have to double compiling everything. And worse:
> You have to know that you have to do this. There is no information about
> that issue.
Why does MPFR requires 4.1.1? I have used GCC 3.3 and GCC 4.0.2 to
compile it before.
> Besides that: compiling GCC under cygwin takes *much* longer than under
> linux for example The config script alone (and there are more than one) need
> around 20 minutes.
That is a different issue, it comes down to Windows is not tuned for
launching small programs over and over again.
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-14 22:29 ` Nils Pipenbrinck
2008-10-14 22:31 ` Andrew Pinski
@ 2008-10-15 1:09 ` Dave Korn
1 sibling, 0 replies; 36+ messages in thread
From: Dave Korn @ 2008-10-15 1:09 UTC (permalink / raw)
To: 'Nils Pipenbrinck'; +Cc: gcc, gcc-patches
Nils Pipenbrinck wrote on 14 October 2008 21:29:
> Markus Milleder wrote:
>> I don't think anybody who tries to build GCC from source will have any
>> problem building MPFR first.
>>
> Not entirely true:
>
> Those of us who use cygwin and want to use the latest GCC have to first
> compile a non MPFR GCC (e.g. 4.1.x) before they can compile the latest
> GPFR and link GCC to it.
Err... I don't. I build 4.3.x using 3.4.4. That's what the whole
bootstrapping thing is about: it insulates you from your starting compiler
version.
> I would welcome a configuration option that disables all the MPFR
> related things. That would make compiling GCC on a naked cygwin
> installation *much* easier.
Why are you even building it at all, rather than just using the standard
package in the distro? WJFFM.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
2008-10-15 0:59 ` Nils Pipenbrinck
2008-10-15 1:01 ` Andrew Pinski
@ 2008-10-15 10:56 ` Brian Dessent
1 sibling, 0 replies; 36+ messages in thread
From: Brian Dessent @ 2008-10-15 10:56 UTC (permalink / raw)
To: Nils Pipenbrinck; +Cc: gcc, gcc-patches
Nils Pipenbrinck wrote:
> Cygwin comes with a GCC 3.4.somewhat out of the box. To compile MPFR you
> need a 4.1 compiler. So you have to double compiling everything. And
I don't know where you get that assertion but it's not true. mpfr built
with gcc 3.4 works just fine and passes all tests in its testsuite.
Besides, Cygwin has a binary package of mpfr 2.3.1 that you can just
install, so you don't have to compile mpfr yourself at all.
Brian
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-05 5:56 [PATCH]: bump minimum MPFR version, (includes some fortran bits) Kaveh R. GHAZI
2008-10-05 13:52 ` Richard Guenther
2008-10-06 13:56 ` Adrian Bunk
@ 2008-10-26 12:59 ` Geoff Keating
2008-10-26 14:42 ` Jakub Jelinek
2008-10-27 2:50 ` Kaveh R. Ghazi
2 siblings, 2 replies; 36+ messages in thread
From: Geoff Keating @ 2008-10-26 12:59 UTC (permalink / raw)
To: Kaveh R. GHAZI; +Cc: gcc, gcc-patches, fortran, angela
"Kaveh R. GHAZI" <ghazi@caip.rutgers.edu> writes:
> Since we're in stage3, I'm raising the issue of the MPFR version we
> require for GCC, just as in last year's stage3 for gcc-4.3:
> http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
>
> I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been
> released since Aug 2007). The "recommended" version of MPFR can be bumped
> to the latest which is 2.3.2.
I note that the configure script, and
<http://gcc.gnu.org/install/prerequisites.html>, says
error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
not "MPFR 2.3.0+".
I found this gave me significant trouble attempting to build GCC from
SVN sources on the regression tester, <http://glutton.geoffk.org/HEAD/>.
The regression tester is now running CentOS 5.2, basically the same as
RHEL 5.2; this is the latest available CentOS. On that distribution,
an older version of mpfr is included with the system. It is provided
as a static library but in the same RPM as gmp, which is a dynamic
library and used by at least gfortran (of course) and php.
There appears to be no Red Hat-based distribution that comes with
2.3.2 or later. Even Fedora 10, which is not yet released, does not
appear to include it.
I found that simply building MPFR in a non-default location (configure
--prefix && make) and then pointing GCC at it with --with-mpfr, as in
the installation instructions, causes the bootstrap to fail when first
running xgcc, because xgcc can't find the built MPFR dynamic library.
I eventually resolved this by uninstalling php, gfortran, and gmp, and
installing gmp, gmp-devel, and mpfr packages built (by my lovely
assistant) by taking the Fedora (10, I think) packaging and upgrading
the contained upstream sources to the latest versions.
If this is what users (or even developers) of GCC are supposed to be
doing, I'd suggest more documentation on what to do and how to do it.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-26 12:59 ` [PATCH]: bump minimum MPFR version, (includes some fortran bits) Geoff Keating
@ 2008-10-26 14:42 ` Jakub Jelinek
2008-10-27 2:50 ` Kaveh R. Ghazi
1 sibling, 0 replies; 36+ messages in thread
From: Jakub Jelinek @ 2008-10-26 14:42 UTC (permalink / raw)
To: Geoff Keating; +Cc: Kaveh R. GHAZI, gcc, gcc-patches, fortran, angela
On Sun, Oct 26, 2008 at 12:34:37AM -0700, Geoff Keating wrote:
> "Kaveh R. GHAZI" <ghazi@caip.rutgers.edu> writes:
> There appears to be no Red Hat-based distribution that comes with
> 2.3.2 or later. Even Fedora 10, which is not yet released, does not
> appear to include it.
FYI, Fedora 10 has 2.3.2 since Oct, 15th.
Jakub
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-26 12:59 ` [PATCH]: bump minimum MPFR version, (includes some fortran bits) Geoff Keating
2008-10-26 14:42 ` Jakub Jelinek
@ 2008-10-27 2:50 ` Kaveh R. Ghazi
2008-10-27 7:03 ` David Edelsohn
1 sibling, 1 reply; 36+ messages in thread
From: Kaveh R. Ghazi @ 2008-10-27 2:50 UTC (permalink / raw)
To: Geoff Keating; +Cc: gcc, gcc-patches, fortran, angela
From: "Geoff Keating" <geoffk@geoffk.org>
> I found that simply building MPFR in a non-default location (configure
> --prefix && make) and then pointing GCC at it with --with-mpfr, as in
> the installation instructions, causes the bootstrap to fail when first
> running xgcc, because xgcc can't find the built MPFR dynamic library.
First I'd like to thank you for running your regression tester, and I'm
sorry this upgrade cause you so much difficulty.
The issue you describe is PR 21547.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
It's important IMHO to point out that this issue is not confined to MPFR.
While MPFR's more stringent version requirements expose the problem more
often, you'll find the same issue with GMP as well if you compile and
install your own copy of that library in a non-default location.
Basically, the problem is that the bootstrap process doesn't encode
the -rpath during the link process of cc1. Doing this in a portable fashion
and resolving the PR requires linking cc1 et al. with libtool. I don't have
any experience with libtool myself. However since we use it elsewhere in
GCC, it may be easy to incorporate.
(Any libtool experts available to help out, or at least talk us through the
process?)
> If this is what users (or even developers) of GCC are supposed to be
> doing, I'd suggest more documentation on what to do and how to do it.
I think the steps you (or your assistant) went through was unfortunately
unnecessarily complicated. The solution I use is to build MPFR and/or GMP
using --disable-shared. Then you can install them anywhere you like, pass
the location with --with-{mpfr,gmp} to GCC and since only the static library
is available everything links and runs fine.
Do you think putting this recommendation in the docs somewhere would have
been useful to you in this situation? If so, I would be happy to prepare a
patch.
Regards,
--Kaveh
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 2:50 ` Kaveh R. Ghazi
@ 2008-10-27 7:03 ` David Edelsohn
2008-10-27 15:03 ` Joseph S. Myers
0 siblings, 1 reply; 36+ messages in thread
From: David Edelsohn @ 2008-10-27 7:03 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: Geoff Keating, gcc, gcc-patches, fortran, angela
On Sun, Oct 26, 2008 at 3:25 PM, Kaveh R. Ghazi <ghazi@caip.rutgers.edu> wrote:
> I think the steps you (or your assistant) went through was unfortunately
> unnecessarily complicated. The solution I use is to build MPFR and/or GMP
> using --disable-shared. Then you can install them anywhere you like, pass
> the location with --with-{mpfr,gmp} to GCC and since only the static library
> is available everything links and runs fine.
>
> Do you think putting this recommendation in the docs somewhere would have
> been useful to you in this situation? If so, I would be happy to prepare a
> patch.
Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
by g++, this effectively requires that libgmpxx must be a shared
library. libgmp
does not have to be a shared library, but it makes things simpler. MPFR is
a static library in my current configuration.
I configure using --with-mpfr=
David
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 7:03 ` David Edelsohn
@ 2008-10-27 15:03 ` Joseph S. Myers
2008-10-27 15:14 ` Richard Guenther
2008-10-27 16:17 ` David Edelsohn
0 siblings, 2 replies; 36+ messages in thread
From: Joseph S. Myers @ 2008-10-27 15:03 UTC (permalink / raw)
To: David Edelsohn
Cc: Kaveh R. Ghazi, Geoff Keating, gcc, gcc-patches, fortran, angela,
sebastian.pop
On Sun, 26 Oct 2008, David Edelsohn wrote:
> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
> by g++, this effectively requires that libgmpxx must be a shared
> library. libgmp
I hope the Graphite people are working on fixing this for 4.4. As I said
in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following
Ian's slides), libstdc++ should be statically linked into cc1 by default -
which probably means that if static libgmpxx is available then it should
be used. I'm also concerned that we still don't have any documentation in
install.texi concerning these libraries and pointing to suitable release
tarballs of them in the infrastructure directory - we're nearly two months
into Stage 3 and these libraries should be subject to much the same
development stage rules as in-tree optimizers with the versions documented
to be used and associated configure checks changing only to update to new
bug-fix minor releases, not major feature releases, while in Stage 3.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 15:03 ` Joseph S. Myers
@ 2008-10-27 15:14 ` Richard Guenther
2008-10-27 16:53 ` Joseph S. Myers
2008-10-27 20:34 ` Roberto Bagnara
2008-10-27 16:17 ` David Edelsohn
1 sibling, 2 replies; 36+ messages in thread
From: Richard Guenther @ 2008-10-27 15:14 UTC (permalink / raw)
To: Joseph S. Myers
Cc: David Edelsohn, Kaveh R. Ghazi, Geoff Keating, gcc, gcc-patches,
fortran, angela, sebastian.pop
On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 26 Oct 2008, David Edelsohn wrote:
>
>> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
>> by g++, this effectively requires that libgmpxx must be a shared
>> library. libgmp
>
> I hope the Graphite people are working on fixing this for 4.4. As I said
> in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following
> Ian's slides), libstdc++ should be statically linked into cc1 by default -
> which probably means that if static libgmpxx is available then it should
> be used. I'm also concerned that we still don't have any documentation in
> install.texi concerning these libraries and pointing to suitable release
> tarballs of them in the infrastructure directory - we're nearly two months
> into Stage 3 and these libraries should be subject to much the same
> development stage rules as in-tree optimizers with the versions documented
> to be used and associated configure checks changing only to update to new
> bug-fix minor releases, not major feature releases, while in Stage 3.
I think we are still waiting for the final ppl release, but otherwise
I agree that
instructions and tarballs should be provided rather yesterday than tomorrow.
I don't necessarily agree with statically linking libstdc++ into cc1 - do you
expect problems with linking dynamically? Static libraries for libgmpxx or
ppl or cloog are usually not available due to size and their libstdc++
requirement.
Richard.
> --
> Joseph S. Myers
> joseph@codesourcery.com
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 15:03 ` Joseph S. Myers
2008-10-27 15:14 ` Richard Guenther
@ 2008-10-27 16:17 ` David Edelsohn
1 sibling, 0 replies; 36+ messages in thread
From: David Edelsohn @ 2008-10-27 16:17 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Kaveh R. Ghazi, Geoff Keating, gcc, gcc-patches, fortran, angela,
sebastian.pop
On Mon, Oct 27, 2008 at 8:22 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 26 Oct 2008, David Edelsohn wrote:
>
>> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
>> by g++, this effectively requires that libgmpxx must be a shared
>> library. libgmp
>
> I hope the Graphite people are working on fixing this for 4.4. As I said
> in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following
> Ian's slides), libstdc++ should be statically linked into cc1 by default -
> which probably means that if static libgmpxx is available then it should
> be used.
I disagree; this is a very bad suggestion and will introduce more breakage.
Statically linking libstdc++ breaks some architectures.
If and when GCC itself is C++, it can be linked with libstdc++. Until then,
there is no reason the dependencies of libraries should be propagated
to cc1 itself.
Graphite will be a technology preview in GCC 4.4, with the associated
volatility.
David
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 15:14 ` Richard Guenther
@ 2008-10-27 16:53 ` Joseph S. Myers
2008-10-27 20:34 ` Roberto Bagnara
1 sibling, 0 replies; 36+ messages in thread
From: Joseph S. Myers @ 2008-10-27 16:53 UTC (permalink / raw)
To: Richard Guenther
Cc: David Edelsohn, Kaveh R. Ghazi, Geoff Keating, gcc, gcc-patches,
fortran, angela, sebastian.pop
On Mon, 27 Oct 2008, Richard Guenther wrote:
> On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > On Sun, 26 Oct 2008, David Edelsohn wrote:
> >
> >> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
> >> by g++, this effectively requires that libgmpxx must be a shared
> >> library. libgmp
> >
> > I hope the Graphite people are working on fixing this for 4.4. As I said
> > in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following
> > Ian's slides), libstdc++ should be statically linked into cc1 by default -
> > which probably means that if static libgmpxx is available then it should
> > be used. I'm also concerned that we still don't have any documentation in
> > install.texi concerning these libraries and pointing to suitable release
> > tarballs of them in the infrastructure directory - we're nearly two months
> > into Stage 3 and these libraries should be subject to much the same
> > development stage rules as in-tree optimizers with the versions documented
> > to be used and associated configure checks changing only to update to new
> > bug-fix minor releases, not major feature releases, while in Stage 3.
>
> I think we are still waiting for the final ppl release, but otherwise
> I agree that
> instructions and tarballs should be provided rather yesterday than tomorrow.
> I don't necessarily agree with statically linking libstdc++ into cc1 - do you
> expect problems with linking dynamically? Static libraries for libgmpxx or
> ppl or cloog are usually not available due to size and their libstdc++
> requirement.
The first and most important step is to support linking with static
versions of ppl, cloog, gmp, gmpxx, mpfr. Linking with separately built
static versions of GMP and MPFR is clearly something widely done as where
OS versions are available at all they may often be too old and this should
work just as well for the other libraries, and using static versions
avoids all problems with the compiler binaries depending on shared
libraries in nonstandard paths.
The comments above suggest this is broken for the new libraries used by
Graphite - presumably because of not linking with -lstdc++ so it can only
be found through shared library dependencies, though they don't specify
this. If that is the case then the configure support needs to know to add
-lstdc++ when linking with these libraries using GCC.
Next is the static libstdc++ - my suggest was that *if static Cloog/PPL
are being used* then so should static libstdc++, though this could be
controlled with a configure option. (One might note that the Ada
compilers are linked with static versions of the Ada libraries by default;
I'm sure there are cases where linking with the shared libraries would be
safe, but the default is for the binaries not to depend on the shared
libraries.) Linking with static libstdc++ avoids the binaries depending
on a shared library that again may not be a system library (especially if
you follow the procedure some people have suggested of building cross
compilers always with a native compiler of the same version, which may
avoid some problems with bootstrap compiler bugs - the context in which
it's been suggested - but would also potentially introduce dependence of
one compiler installation on shared libraries in another).
Following that is the problem gcc-in-cxx will need to solve, of
bootstrapping libstdc++ so each stage's compiler binaries can be linked
with the previous stage's libstdc++ and a compiler using libstdc++.so.6
can bootstrap one using libstdc++.so.7 (which may also require the ability
to build PPL in-tree in order to bootstrap it across incompatible C++
library ABIs). Linking the compiler binaries with static libstdc++
certainly simplifies some of the bootstrap issues there.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
2008-10-27 15:14 ` Richard Guenther
2008-10-27 16:53 ` Joseph S. Myers
@ 2008-10-27 20:34 ` Roberto Bagnara
1 sibling, 0 replies; 36+ messages in thread
From: Roberto Bagnara @ 2008-10-27 20:34 UTC (permalink / raw)
To: Richard Guenther
Cc: Joseph S dot Myers, David Edelsohn, Kaveh R dot Ghazi,
Geoff Keating, gcc, GCC Patches, fortran, angela, Pop, Sebastian,
The Parma Polyhedra Library developers' list
Richard Guenther wrote:
> On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Sun, 26 Oct 2008, David Edelsohn wrote:
>>
>>> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
>>> by g++, this effectively requires that libgmpxx must be a shared
>>> library. libgmp
>> I hope the Graphite people are working on fixing this for 4.4. As I said
>> in <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (following
>> Ian's slides), libstdc++ should be statically linked into cc1 by default -
>> which probably means that if static libgmpxx is available then it should
>> be used. I'm also concerned that we still don't have any documentation in
>> install.texi concerning these libraries and pointing to suitable release
>> tarballs of them in the infrastructure directory - we're nearly two months
>> into Stage 3 and these libraries should be subject to much the same
>> development stage rules as in-tree optimizers with the versions documented
>> to be used and associated configure checks changing only to update to new
>> bug-fix minor releases, not major feature releases, while in Stage 3.
>
> I think we are still waiting for the final ppl release, but otherwise
> I agree that
> instructions and tarballs should be provided rather yesterday than tomorrow.
The first release candidate of the PPL has just been published:
http://www.cs.unipr.it/pipermail/ppl-announce/2008/000020.html
If you want, I can draft a patch for install.texi during next weekend.
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2008-10-27 19:41 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-05 5:56 [PATCH]: bump minimum MPFR version, (includes some fortran bits) Kaveh R. GHAZI
2008-10-05 13:52 ` Richard Guenther
2008-10-05 14:10 ` Gerald Pfeifer
2008-10-05 14:43 ` Richard Guenther
2008-10-05 16:34 ` Manuel López-Ibáñez
2008-10-06 23:37 ` Kaveh R. Ghazi
2008-10-07 7:55 ` Janne Blomqvist
2008-10-06 13:56 ` Adrian Bunk
2008-10-06 23:16 ` [PATCH]: bump minimum MPFR version, (includes some fortranbits) Kaveh R. Ghazi
2008-10-06 23:40 ` Ben Elliston
2008-10-07 0:35 ` Andrew Pinski
2008-10-07 18:52 ` Adrian Bunk
2008-10-13 16:00 ` Vincent Lefevre
2008-10-13 16:42 ` Antwort: " Markus Milleder
2008-10-13 17:15 ` Adrian Bunk
2008-10-14 12:59 ` Antwort: " Markus Milleder
2008-10-14 13:10 ` Jakub Jelinek
2008-10-14 13:21 ` Tobias Schlüter
2008-10-14 14:52 ` Adrian Bunk
2008-10-14 15:39 ` Tobias Schlüter
2008-10-14 13:30 ` Antwort: Re: Antwort: " Adrian Bunk
2008-10-14 22:29 ` Nils Pipenbrinck
2008-10-14 22:31 ` Andrew Pinski
2008-10-15 0:59 ` Nils Pipenbrinck
2008-10-15 1:01 ` Andrew Pinski
2008-10-15 10:56 ` Brian Dessent
2008-10-15 1:09 ` Dave Korn
2008-10-26 12:59 ` [PATCH]: bump minimum MPFR version, (includes some fortran bits) Geoff Keating
2008-10-26 14:42 ` Jakub Jelinek
2008-10-27 2:50 ` Kaveh R. Ghazi
2008-10-27 7:03 ` David Edelsohn
2008-10-27 15:03 ` Joseph S. Myers
2008-10-27 15:14 ` Richard Guenther
2008-10-27 16:53 ` Joseph S. Myers
2008-10-27 20:34 ` Roberto Bagnara
2008-10-27 16:17 ` David Edelsohn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).