[PATCH]: bump minimum MPFR version, (includes some fortran bits)

[PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Kaveh R. GHAZI]

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
 }

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Richard Guenther]

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
>  }
>
>
>

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Gerald Pfeifer]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Richard Guenther]

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.

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Manuel López-Ibáñez]

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.

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Kaveh R. Ghazi]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Janne Blomqvist]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Adrian Bunk]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Kaveh R. Ghazi]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Ben Elliston]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Andrew Pinski]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Adrian Bunk]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Vincent Lefevre]

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)

Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Markus Milleder]

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

Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Adrian Bunk]

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

Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Markus Milleder]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Jakub Jelinek]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Tobias Schlüter]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Adrian Bunk]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Tobias Schlüter]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Adrian Bunk]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Nils Pipenbrinck]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Andrew Pinski]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Nils Pipenbrinck]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Andrew Pinski]

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

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Brian Dessent]

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

RE: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Dave Korn]

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....

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Geoff Keating]

"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.

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Jakub Jelinek]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Kaveh R. Ghazi]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[David Edelsohn]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Joseph S. Myers]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Richard Guenther]

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
>

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Joseph S. Myers]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Roberto Bagnara]

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

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[David Edelsohn]

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