[Build,libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

Hi Ralf,

Ralf Wildenhues wrote:
> Is the usage of the two HAVE_* defines for optimization only?

Yes - it's just to speed up the calculation.

> But you might still consider adding a case
> statement in the gcc_no_link branch seeding the correct defines
> or the respective configure cache variables (ac_cv_lib_m_cbrtl etc)
> for targets where the functions are known to be available.

I have now use the configure cache variables; one can still add a 
version with switch, when needed.

OK?

Tobias

* Tobias Burnus wrote on Sun, Dec 19, 2010 at 05:18:50PM CET:
> Ralf Wildenhues wrote:
> >Is the usage of the two HAVE_* defines for optimization only?
> 
> Yes - it's just to speed up the calculation.

Then the original patch is ok.

> >But you might still consider adding a case
> >statement in the gcc_no_link branch seeding the correct defines
> >or the respective configure cache variables (ac_cv_lib_m_cbrtl etc)
> >for targets where the functions are known to be available.
> 
> I have now use the configure cache variables; one can still add a
> version with switch, when needed.

Well, this patch is ok as well (and a bit nicer for users willing
to pass cache variables), but what I meant was something like

  # The toplevel --target becomes the --host in target libdirs.
  case $host_os in
    linux*) ac_cv_lib_m_sqrtl=yes ;;
    ...
  esac

that already seeds the variables on systems where the answer is known.
(Kind of like another step further.)

Cheers,
Ralf

> 2010-12-19  Tobias Burnus  <burnus@net-b.de>
> 
> 	PR fortran/46520
> 	* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
> 	* configure: Regenerate
> 
> diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
> index 56b1fcb..68b5cf8 100644
> --- a/libquadmath/configure.ac
> +++ b/libquadmath/configure.ac
> @@ -109,8 +109,19 @@ esac
>  AC_SUBST(toolexecdir)
>  AC_SUBST(toolexeclibdir)
>  
> -AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> -AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +# If available, sqrtl and cbrtl speed up the calculation -
> +# but they are not required
> +if test x$gcc_no_link != xyes; then
> +  AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> +  AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +else
> +  if test "x$ac_cv_lib_m_sqrtl" = x""yes; then
> +    AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])  
> +  fi
> +  if test "x$ac_cv_lib_m_cbrtl" = x""yes; then
> +    AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])  
> +  fi
> +fi
>  
>  # Check for symbol versioning (copied from libssp).
>  AC_MSG_CHECKING([whether symbol versioning is supported])

Ralf Wildenhues wrote:
> Well, this patch is ok as well (and a bit nicer for users willing
> to pass cache variables), but what I meant was something like
>
>    # The toplevel --target becomes the --host in target libdirs.
>    case $host_os in
>      linux*) ac_cv_lib_m_sqrtl=yes ;;
>      ...
>    esac
>
> that already seeds the variables on systems where the answer is known.
> (Kind of like another step further.)

Is it obvious that all linux* support sqrtl? I wouldn't rule out that 
there are Linux systems with double-only LIBC. Admittedly, I rather 
would expect those on, e.g., ARM systems where no __float128 exists.

I have now committed the second version of the patch (Rev. 168069). 
However, if we find something better, one can still commit it as 
follow-up patch.

Tobias

* Tobias Burnus wrote on Sun, Dec 19, 2010 at 08:05:19PM CET:
> Ralf Wildenhues wrote:
> >   # The toplevel --target becomes the --host in target libdirs.
> >   case $host_os in
> >     linux*) ac_cv_lib_m_sqrtl=yes ;;
> >     ...
> >   esac

> Is it obvious that all linux* support sqrtl?

Oh, I have no idea about the actual settings; the above was only meant
as an example.

> I wouldn't rule out
> that there are Linux systems with double-only LIBC. Admittedly, I
> rather would expect those on, e.g., ARM systems where no __float128
> exists.

I would guess so, too.

> I have now committed the second version of the patch (Rev. 168069).
> However, if we find something better, one can still commit it as
> follow-up patch.

Thanks,
Ralf

On Sun, 19 Dec 2010, Tobias Burnus wrote:

> Ralf Wildenhues wrote:
> > Well, this patch is ok as well (and a bit nicer for users willing
> > to pass cache variables), but what I meant was something like
> > 
> >    # The toplevel --target becomes the --host in target libdirs.
> >    case $host_os in
> >      linux*) ac_cv_lib_m_sqrtl=yes ;;
> >      ...
> >    esac
> > 
> > that already seeds the variables on systems where the answer is known.
> > (Kind of like another step further.)
> 
> Is it obvious that all linux* support sqrtl? I wouldn't rule out that there
> are Linux systems with double-only LIBC. Admittedly, I rather would expect
> those on, e.g., ARM systems where no __float128 exists.

On systems where double and long double have the same representation, 
sqrtl is an alias for sqrt.  The function exists in libm even though there 
is no declaration in the headers with FSF glibc (Jakub's patch to add the 
declarations as required by C99 was ignored).