On 29.06.22 14:13, Jakub Jelinek via Fortran wrote:
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which is targets that support __float128 type which we have been testing
for before - _Float128 is supported on those targets and on targets where
long double is IEEE quad precision.
So, the following patch restores check for whether __float128 is supported
into the LIBGFOR_CHECK_FLOAT128 check which determines whether
HAVE_FLOAT128 is defined or whether to use libquadmath, so that e.g. on
aarch64 where long double is IEEE quad we don't do that.
Tested by Tamar on aarch64 and by me on x86_64-linux, ok for trunk?
2022-06-29 Jakub Jelinek <ja...@redhat.com>
PR bootstrap/106137
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Also test for __float128.
* configure: Regenerated.
--- libgfortran/acinclude.m4.jj 2022-06-28 13:14:45.327799267 +0200
+++ libgfortran/acinclude.m4 2022-06-29 11:45:19.286551469 +0200
@@ -276,7 +276,6 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
GCC_TRY_COMPILE_OR_LINK([
_Float128 foo (_Float128 x)
...
+ __float128 baz (__float128 x)
As now both __float128 and _Float128 is tested, can you also update:
dnl Check whether we have a __float128 type
AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
...
AC_CACHE_CHECK([whether we have a usable _Float128 type],
libgfor_cv_have_float128, [
I note that your follow-up patch adds _Float128 to the dnl comment,
but I think __float128 should also be added to the cache output to
make clear that both _Float128/__float128 are checked.
Otherwise: LGTM.
Thanks,
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
