[PATCH] libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]
Hi!
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
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.m42022-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)
{
-
_Complex _Float128 z1, z2;
z1 = x;
@@ -290,11 +289,18 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
{
return x * __builtin_huge_valf128 ();
}
+
+__float128 baz (__float128 x)
+{
+ return x * __builtin_huge_valf128 ();
+}
],[
foo (1.2F128);
bar (1.2F128);
+baz (1.2F128);
foo (1.2Q);
bar (1.2Q);
+baz (1.2Q);
],[
libgfor_cv_have_float128=yes
],[
--- libgfortran/configure.jj2022-06-28 13:14:45.331799215 +0200
+++ libgfortran/configure 2022-06-29 11:45:49.951148846 +0200
@@ -30130,7 +30130,6 @@ else
_Float128 foo (_Float128 x)
{
-
_Complex _Float128 z1, z2;
z1 = x;
@@ -30145,14 +30144,21 @@ else
return x * __builtin_huge_valf128 ();
}
+__float128 baz (__float128 x)
+{
+ return x * __builtin_huge_valf128 ();
+}
+
int
main ()
{
foo (1.2F128);
bar (1.2F128);
+baz (1.2F128);
foo (1.2Q);
bar (1.2Q);
+baz (1.2Q);
;
return 0;
@@ -30177,7 +30183,6 @@ cat confdefs.h - <<_ACEOF >conftest.$ac_
_Float128 foo (_Float128 x)
{
-
_Complex _Float128 z1, z2;
z1 = x;
@@ -30192,14 +30197,21 @@ cat confdefs.h - <<_ACEOF >conftest.$ac_
return x * __builtin_huge_valf128 ();
}
+__float128 baz (__float128 x)
+{
+ return x * __builtin_huge_valf128 ();
+}
+
int
main ()
{
foo (1.2F128);
bar (1.2F128);
+baz (1.2F128);
foo (1.2Q);
bar (1.2Q);
+baz (1.2Q);
;
return 0;
Jakub
[PATCH] libgfortran: Switch some more __float128 uses to _Float128
Hi! My patch apparently left some __float128 uses in libgfortran that could use _Float128 instead, the following patch changes that. Ok for trunk? 2022-06-29 Jakub Jelinek * mk-kinds-h.sh: Change __float128 to _Float128 in a comment. * acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Adjust comment. (LIBGFOR_CHECK_MATH_IEEE128): Use _Float128 instead of __float128. * libgfortran.h (isnan): Change __float128 to _Float128 in a comment. (__acoshieee128, __acosieee128, __asinhieee128, __asinieee128, __atan2ieee128, __atanhieee128, __atanieee128, __copysignieee128, __coshieee128, __cosieee128, __erfcieee128, __erfieee128, __expieee128, __fabsieee128, __fmaieee128, __fmodieee128, __jnieee128, __log10ieee128, __logieee128, __powieee128, __sinhieee128, __sinieee128, __sqrtieee128, __tanhieee128, __tanieee128, __ynieee128, __strtoieee128): Use _Float128 instead of __float128. * configure: Regenerated. --- libgfortran/mk-kinds-h.sh.jj2022-06-28 13:14:45.334799175 +0200 +++ libgfortran/mk-kinds-h.sh 2022-06-29 14:01:32.935361103 +0200 @@ -67,7 +67,7 @@ for k in $possible_real_kinds; do 8) ctype="double" ; cplxtype="complex double" ; suffix="" ;; # If we have a REAL(KIND=10), it is always long double 10) ctype="long double" ; cplxtype="complex long double" ; suffix="l" ;; - # If we have a REAL(KIND=16), it is either long double or __float128 + # If we have a REAL(KIND=16), it is either long double or _Float128 16) if [ $long_double_kind -ne 16 ]; then ctype="_Float128" cplxtype="_Complex _Float128" --- libgfortran/acinclude.m4.jj 2022-06-29 11:45:19.286551469 +0200 +++ libgfortran/acinclude.m42022-06-29 14:00:22.964279364 +0200 @@ -261,7 +261,7 @@ __mingw_snprintf (NULL, 0, "%d\n", 1); fi ]) -dnl Check whether we have a __float128 type +dnl Check whether we have a __float128 and _Float128 type AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [ LIBQUADSPEC= LIBQUADLIB= @@ -537,8 +537,8 @@ AC_DEFUN([LIBGFOR_CHECK_MATH_IEEE128], AC_REQUIRE([GCC_CHECK_MATH_HEADERS]) AC_CACHE_CHECK([for $1], [gcc_cv_math_func_$1], [AC_LINK_IFELSE([AC_LANG_SOURCE([ -__float128 $1 (__float128); -__float128 (*ptr)(__float128) = $1; +_Float128 $1 (_Float128); +_Float128 (*ptr)(_Float128) = $1; int main () --- libgfortran/libgfortran.h.jj2022-06-28 13:14:45.333799188 +0200 +++ libgfortran/libgfortran.h 2022-06-29 14:01:14.364604813 +0200 @@ -247,7 +247,7 @@ extern int __mingw_snprintf (char *, siz Another advantage for GCC's builtins for these type-generic macros is that it handles floating-point types that the system headers - may not support (like __float128). */ + may not support (like _Float128). */ #undef isnan #define isnan(x) __builtin_isnan(x) @@ -1960,59 +1960,59 @@ internal_proto(cshift1_16_c17); /* Prototypes for the POWER __ieee128 functions. */ #ifdef POWER_IEEE128 -extern __float128 __acoshieee128 (__float128) +extern _Float128 __acoshieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __acosieee128 (__float128) +extern _Float128 __acosieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinhieee128 (__float128) +extern _Float128 __asinhieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinieee128 (__float128) +extern _Float128 __asinieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atan2ieee128 (__float128) +extern _Float128 __atan2ieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanhieee128 (__float128) +extern _Float128 __atanhieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanieee128 (__float128) +extern _Float128 __atanieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __copysignieee128 (__float128, __float128) +extern _Float128 __copysignieee128 (_Float128, _Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __coshieee128 (__float128) +extern _Float128 __coshieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __cosieee128 (__float128) +extern _Float128 __cosieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __erfcieee128 (__float128) +extern _Float128 __erfcieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __erfieee128 (__float128) +extern _Float128 __erfieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __expieee128 (__float128) +extern _Float128 __expieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __fabsieee128 (__float128) +extern _Float128 __fabsieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __fmaieee128 (__float128, __float128, __float128)
Re: [PATCH] libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]
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 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
Re: [PATCH] libgfortran: Switch some more __float128 uses to _Float128
On 29.06.22 14:15, Jakub Jelinek via Fortran wrote: My patch apparently left some __float128 uses in libgfortran that could use _Float128 instead, the following patch changes that. Ok for trunk? LGTM. Thanks! Tobias 2022-06-29 Jakub Jelinek * mk-kinds-h.sh: Change __float128 to _Float128 in a comment. * acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Adjust comment. (LIBGFOR_CHECK_MATH_IEEE128): Use _Float128 instead of __float128. * libgfortran.h (isnan): Change __float128 to _Float128 in a comment. (__acoshieee128, __acosieee128, __asinhieee128, __asinieee128, __atan2ieee128, __atanhieee128, __atanieee128, __copysignieee128, __coshieee128, __cosieee128, __erfcieee128, __erfieee128, __expieee128, __fabsieee128, __fmaieee128, __fmodieee128, __jnieee128, __log10ieee128, __logieee128, __powieee128, __sinhieee128, __sinieee128, __sqrtieee128, __tanhieee128, __tanieee128, __ynieee128, __strtoieee128): Use _Float128 instead of __float128. * configure: Regenerated. --- libgfortran/mk-kinds-h.sh.jj 2022-06-28 13:14:45.334799175 +0200 +++ libgfortran/mk-kinds-h.sh 2022-06-29 14:01:32.935361103 +0200 @@ -67,7 +67,7 @@ for k in $possible_real_kinds; do 8) ctype="double" ; cplxtype="complex double" ; suffix="" ;; # If we have a REAL(KIND=10), it is always long double 10) ctype="long double" ; cplxtype="complex long double" ; suffix="l" ;; - # If we have a REAL(KIND=16), it is either long double or __float128 + # If we have a REAL(KIND=16), it is either long double or _Float128 16) if [ $long_double_kind -ne 16 ]; then ctype="_Float128" cplxtype="_Complex _Float128" --- libgfortran/acinclude.m4.jj 2022-06-29 11:45:19.286551469 +0200 +++ libgfortran/acinclude.m4 2022-06-29 14:00:22.964279364 +0200 @@ -261,7 +261,7 @@ __mingw_snprintf (NULL, 0, "%d\n", 1); fi ]) -dnl Check whether we have a __float128 type +dnl Check whether we have a __float128 and _Float128 type AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [ LIBQUADSPEC= LIBQUADLIB= @@ -537,8 +537,8 @@ AC_DEFUN([LIBGFOR_CHECK_MATH_IEEE128], AC_REQUIRE([GCC_CHECK_MATH_HEADERS]) AC_CACHE_CHECK([for $1], [gcc_cv_math_func_$1], [AC_LINK_IFELSE([AC_LANG_SOURCE([ -__float128 $1 (__float128); -__float128 (*ptr)(__float128) = $1; +_Float128 $1 (_Float128); +_Float128 (*ptr)(_Float128) = $1; int main () --- libgfortran/libgfortran.h.jj 2022-06-28 13:14:45.333799188 +0200 +++ libgfortran/libgfortran.h 2022-06-29 14:01:14.364604813 +0200 @@ -247,7 +247,7 @@ extern int __mingw_snprintf (char *, siz Another advantage for GCC's builtins for these type-generic macros is that it handles floating-point types that the system headers - may not support (like __float128). */ + may not support (like _Float128). */ #undef isnan #define isnan(x) __builtin_isnan(x) @@ -1960,59 +1960,59 @@ internal_proto(cshift1_16_c17); /* Prototypes for the POWER __ieee128 functions. */ #ifdef POWER_IEEE128 -extern __float128 __acoshieee128 (__float128) +extern _Float128 __acoshieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __acosieee128 (__float128) +extern _Float128 __acosieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinhieee128 (__float128) +extern _Float128 __asinhieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinieee128 (__float128) +extern _Float128 __asinieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atan2ieee128 (__float128) +extern _Float128 __atan2ieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanhieee128 (__float128) +extern _Float128 __atanhieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanieee128 (__float128) +extern _Float128 __atanieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __copysignieee128 (__float128, __float128) +extern _Float128 __copysignieee128 (_Float128, _Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __coshieee128 (__float128) +extern _Float128 __coshieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __cosieee128 (__float128) +extern _Float128 __cosieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __erfcieee128 (__float128) +extern _Float128 __erfcieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __erfieee128 (__float128) +extern _Float128 __erfieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __expieee128 (__float128) +extern _Float128 __expieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __fabsieee128 (__float128) +extern _Float128 __fabsieee128 (_Float128) __attribute__ ((__nothrow__, __leaf__)); -
Re: [PATCH] Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121]
On 28.06.22 22:36, Harald Anlauf via Gcc-patches wrote: the simplification of EXTENDS_TYPE_OF() did not handle the situation that one of its arguments were a CLASS variable that was improperly declared. NULL pointer dereference. The fix is obvious. Steve found a similar solution, which is why I added him as co-author. Regtested on x86_64-pc-linux-gnu. LGTM – and I do note that Steven also okayed it in the PR. 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
[PATCH] Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243]
Dear all,
a CLASS entity cannot have the PARAMETER attribute.
This is detected in some situations, but in others
we ICE because we never reach the existing check.
Adding a similar check when handling the declaration
improves error recovery.
The initial patch is by Steve. I adjusted and moved
it slightly so that it also handles CLASS(*)
(unlimited polymorphic) at the same time.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This patch actually addresses multiple PRs, some of
which are marked as regressions. As I consider the
patch safe, I would like to backport to open branches
as far as it seems appropriate.
Thanks,
Harald
From e0d5aeadd218f21e450db6601956691293210156 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 29 Jun 2022 21:36:17 +0200
Subject: [PATCH] Fortran: error recovery on invalid CLASS(), PARAMETER
declarations [PR105243]
gcc/fortran/ChangeLog:
PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.
gcc/testsuite/ChangeLog:
PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.
---
gcc/fortran/decl.cc| 8
gcc/testsuite/gfortran.dg/class_58.f90 | 2 +-
gcc/testsuite/gfortran.dg/class_73.f90 | 17 +
3 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/class_73.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 26ff54d4684..339f8b15035 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -6262,6 +6262,14 @@ gfc_match_data_decl (void)
goto cleanup;
}
+ /* F2018:C708. */
+ if (current_ts.type == BT_CLASS && current_attr.flavor == FL_PARAMETER)
+{
+ gfc_error ("CLASS entity at %C cannot have the PARAMETER attribute");
+ m = MATCH_ERROR;
+ goto cleanup;
+}
+
if (current_ts.type == BT_CLASS
&& current_ts.u.derived->attr.unlimited_polymorphic)
goto ok;
diff --git a/gcc/testsuite/gfortran.dg/class_58.f90 b/gcc/testsuite/gfortran.dg/class_58.f90
index 20b601a2f51..fceb575432d 100644
--- a/gcc/testsuite/gfortran.dg/class_58.f90
+++ b/gcc/testsuite/gfortran.dg/class_58.f90
@@ -9,5 +9,5 @@ subroutine s
end type
class(t), parameter :: x = t() ! { dg-error "cannot have the PARAMETER attribute" }
class(t), parameter :: y = x! { dg-error "cannot have the PARAMETER attribute" }
- class(t) :: z = x ! { dg-error "must be dummy, allocatable or pointer" }
+ class(t) :: z = t() ! { dg-error "must be dummy, allocatable or pointer" }
end
diff --git a/gcc/testsuite/gfortran.dg/class_73.f90 b/gcc/testsuite/gfortran.dg/class_73.f90
new file mode 100644
index 000..c11ee38c086
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_73.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+! Error recovery on invalid CLASS(), PARAMETER declarations
+! PR fortran/103137
+! PR fortran/103138
+! PR fortran/103693
+! PR fortran/105243
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ character(3) :: c = '(a)'
+ end type
+ class(t), parameter :: x = 1. ! { dg-error "PARAMETER attribute" }
+ class(*), parameter :: y = t() ! { dg-error "PARAMETER attribute" }
+ class(*), parameter :: z = 1 ! { dg-error "PARAMETER attribute" }
+ print x%c ! { dg-error "Syntax error" }
+end
--
2.35.3
