public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
@ 2022-03-20 15:30 FX
  2022-04-13 14:56 ` Piotr Kubaj
  0 siblings, 1 reply; 10+ messages in thread
From: FX @ 2022-03-20 15:30 UTC (permalink / raw)
  To: gcc-patches, Fortran List; +Cc: pkubaj, segher

Hi,

(Please send all Fortran (front-end and libgfortran) patches in CC to the Fortran list.)

Please hold from pushing the patch as is, I have some questions:

- If FreeBSD has feenableexcept() and related functions, it should already use the fpu-glibc code, because of this:

if test "x${have_feenableexcept}" = "xyes"; then
  fpu_host='fpu-glibc'
  ieee_support='yes'
fi

So before the patch, what was configure.host returning, and what is the value of have_feenableexcept?

- Why restrict the patch to powerpc*? Don’t other FreeBSD targets have that function?
- How does the patch affect the results of “make check-gfortran”?


Thanks,
FX

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-03-20 15:30 [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd FX
@ 2022-04-13 14:56 ` Piotr Kubaj
  2022-04-13 15:27   ` FX
  0 siblings, 1 reply; 10+ messages in thread
From: Piotr Kubaj @ 2022-04-13 14:56 UTC (permalink / raw)
  To: FX; +Cc: gcc-patches, Fortran List, segher

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On 22-03-20 16:30:08, FX wrote:
> Hi,
> 
> (Please send all Fortran (front-end and libgfortran) patches in CC to the Fortran list.)
> 
> Please hold from pushing the patch as is, I have some questions:
> 
> - If FreeBSD has feenableexcept() and related functions, it should already use the fpu-glibc code, because of this:
> 
> if test "x${have_feenableexcept}" = "xyes"; then
>   fpu_host='fpu-glibc'
>   ieee_support='yes'
> fi
> 
> So before the patch, what was configure.host returning, and what is the value of have_feenableexcept?
> 
> - Why restrict the patch to powerpc*? Don’t other FreeBSD targets have that function?
> - How does the patch affect the results of “make check-gfortran”?
> 
> 
> Thanks,
> FX

Hello,

the problem is that configure checks for feenableexcept() in libm:
AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])

FreeBSD doesn't have this function in libm, it's implemented in /usr/include/fenv.h.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-13 14:56 ` Piotr Kubaj
@ 2022-04-13 15:27   ` FX
  2022-04-14  0:49     ` Piotr Kubaj
  0 siblings, 1 reply; 10+ messages in thread
From: FX @ 2022-04-13 15:27 UTC (permalink / raw)
  To: Piotr Kubaj; +Cc: gcc-patches, Fortran List, segher

Hi,

> the problem is that configure checks for feenableexcept() in libm:
> AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> 
> FreeBSD doesn't have this function in libm, it's implemented in /usr/include/fenv.h.

I see. Then we probably can use AC_CHECK_FUNCS, or design a specific check, so that it gives the right value on both glibc and FreeBSD targets.

Could you test something on your end?

FX

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-13 15:27   ` FX
@ 2022-04-14  0:49     ` Piotr Kubaj
  2022-04-14  7:05       ` FX
  0 siblings, 1 reply; 10+ messages in thread
From: Piotr Kubaj @ 2022-04-14  0:49 UTC (permalink / raw)
  To: FX; +Cc: gcc-patches, Fortran List, segher


[-- Attachment #1.1: Type: text/plain, Size: 607 bytes --]

Hello,

can you check the following patch?

On 22-04-13 17:27:11, FX wrote:
> Hi,
> 
> > the problem is that configure checks for feenableexcept() in libm:
> > AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> > 
> > FreeBSD doesn't have this function in libm, it's implemented in /usr/include/fenv.h.
> 
> I see. Then we probably can use AC_CHECK_FUNCS, or design a specific check, so that it gives the right value on both glibc and FreeBSD targets.
> 
> Could you test something on your end?
> 
> FX

-- 

[-- Attachment #1.2: 0001-powerpc-properly-detect-feenableexcept-on-FreeBSD.patch --]
[-- Type: text/x-diff, Size: 3874 bytes --]

From d5e255f09b4cfd2cb3688d0e2d5feba85d1f5dc8 Mon Sep 17 00:00:00 2001
From: Piotr Kubaj <pkubaj@FreeBSD.org>
Date: Thu, 14 Apr 2022 02:35:26 +0200
Subject: [PATCH] powerpc: properly detect feenableexcept on FreeBSD

FreeBSD doesn't have feenableexcept in libm, but in fenv.h.

Signed-off-by: Piotr Kubaj <pkubaj@FreeBSD.org>
---
 libgfortran/configure    | 48 +++++++++++++++++++++++++++++++++++++++-
 libgfortran/configure.ac | 18 ++++++++++++++-
 2 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/libgfortran/configure b/libgfortran/configure
index ae64dca3114..2f1011d7fdc 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -27338,8 +27338,52 @@ fi
 
 
 
+case x$target in
+  xpowerpc*-freebsd*)
+    # Check for the existence of <fenv.h> functions.
+    for ac_header in fenv.h
+do :
+  ac_fn_c_check_header_mongrel "$LINENO" "fenv.h" "ac_cv_header_fenv_h" "$ac_includes_default"
+if test "x$ac_cv_header_fenv_h" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_FENV_H 1
+_ACEOF
+ ac_has_fenv_h=yes
+else
+  ac_has_fenv_h=no
+fi
+
+done
+
+    if test x"$ac_has_fenv_h" = x"yes"; then
+      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for feenableexcept in <fenv.h>" >&5
+$as_echo_n "checking for feenableexcept in <fenv.h>... " >&6; }
+      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <fenv.h>
+int
+main ()
+{
+int except, ret;
+                      ret = feenableexcept(except);
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  have_feenableexcept=yes
+$as_echo "#define HAVE_FEENABLEEXCEPT 1" >>confdefs.h
+
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+      { $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_feenableexcept" >&5
+$as_echo "$have_feenableexcept" >&6; }
+    fi
+    ;;
+  *)
 # Check for GNU libc feenableexcept
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for feenableexcept in -lm" >&5
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for feenableexcept in -lm" >&5
 $as_echo_n "checking for feenableexcept in -lm... " >&6; }
 if ${ac_cv_lib_m_feenableexcept+:} false; then :
   $as_echo_n "(cached) " >&6
@@ -27384,6 +27428,8 @@ $as_echo "#define HAVE_FEENABLEEXCEPT 1" >>confdefs.h
 
 fi
 
+    ;;
+esac
 
 # At least for glibc, clock_gettime is in librt.  But don't
 # pull that in if it still doesn't give us the function we want.  This
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 97cc490cb5e..7c285aaf79c 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -602,8 +602,24 @@ fi
 # Check whether we have a __float128 type, depends on enable_libquadmath_support
 LIBGFOR_CHECK_FLOAT128
 
+case x$target in
+  xpowerpc*-freebsd*)
+    # Check for the existence of <fenv.h> functions.
+    AC_CHECK_HEADERS(fenv.h, ac_has_fenv_h=yes, ac_has_fenv_h=no)
+    if test x"$ac_has_fenv_h" = x"yes"; then
+      AC_MSG_CHECKING([for feenableexcept in <fenv.h>])
+      AC_TRY_COMPILE([#include <fenv.h>],
+                     [int except, ret;
+                      ret = feenableexcept(except);
+                     ],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[fenv.h includes feenableexcept])])
+      AC_MSG_RESULT($have_feenableexcept)
+    fi
+    ;;
+  *)
 # Check for GNU libc feenableexcept
-AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
+    AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
+    ;;
+esac
 
 # At least for glibc, clock_gettime is in librt.  But don't
 # pull that in if it still doesn't give us the function we want.  This
-- 
2.35.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-14  0:49     ` Piotr Kubaj
@ 2022-04-14  7:05       ` FX
  2022-04-14 14:09         ` Piotr Kubaj
  0 siblings, 1 reply; 10+ messages in thread
From: FX @ 2022-04-14  7:05 UTC (permalink / raw)
  To: Piotr Kubaj; +Cc: gcc-patches, Fortran List, segher

Hi,

> can you check the following patch?

Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
Otherwise it looks ok to me, but probably should be tested on a glibc non-x86 target.

In any case, this will be for the new branch, when stage 1 reopens.

FX

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-14  7:05       ` FX
@ 2022-04-14 14:09         ` Piotr Kubaj
  2022-04-28 17:09           ` Piotr Kubaj
  0 siblings, 1 reply; 10+ messages in thread
From: Piotr Kubaj @ 2022-04-14 14:09 UTC (permalink / raw)
  To: FX; +Cc: gcc-patches, Fortran List, segher

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On 22-04-14 09:05:17, FX wrote:
> Hi,
> 
> > can you check the following patch?
> 
> Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
amd64 and i386 on all systems use a different setting and are not affected.
For FreeBSD-supported architectures that are not amd64, i386 or powerpc*, there are also armv6, armv7, aarch64, riscv64 and riscv64sf.

However, GCC is currently not ported to riscv64 and riscv64sf (but it's likely affected as well).
aarch64 is confirmed to be affected (so armv6 and armv7 are probably also affected), but I don't have any way to test whether it works on aarch64 that way.

So currently limiting to powerpc*, but it will probably be extended to armv*, aarch64 and riscv64* in the future.

> Otherwise it looks ok to me, but probably should be tested on a glibc non-x86 target.
> 
> In any case, this will be for the new branch, when stage 1 reopens.
> 
> FX

-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-14 14:09         ` Piotr Kubaj
@ 2022-04-28 17:09           ` Piotr Kubaj
  2022-04-28 18:55             ` FX
  0 siblings, 1 reply; 10+ messages in thread
From: Piotr Kubaj @ 2022-04-28 17:09 UTC (permalink / raw)
  To: FX; +Cc: gcc-patches, Fortran List, segher

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

Given that 12 has been branched off, is it OK now to commit this patch?

On 22-04-14 16:09:35, Piotr Kubaj wrote:
> On 22-04-14 09:05:17, FX wrote:
> > Hi,
> > 
> > > can you check the following patch?
> > 
> > Why restrict it to powerpc-freebsd only, and not all freebsd? Do they differ?
> amd64 and i386 on all systems use a different setting and are not affected.
> For FreeBSD-supported architectures that are not amd64, i386 or powerpc*, there are also armv6, armv7, aarch64, riscv64 and riscv64sf.
> 
> However, GCC is currently not ported to riscv64 and riscv64sf (but it's likely affected as well).
> aarch64 is confirmed to be affected (so armv6 and armv7 are probably also affected), but I don't have any way to test whether it works on aarch64 that way.
> 
> So currently limiting to powerpc*, but it will probably be extended to armv*, aarch64 and riscv64* in the future.
> 
> > Otherwise it looks ok to me, but probably should be tested on a glibc non-x86 target.
> > 
> > In any case, this will be for the new branch, when stage 1 reopens.
> > 
> > FX
> 
> -- 



-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-28 17:09           ` Piotr Kubaj
@ 2022-04-28 18:55             ` FX
  2022-04-30 18:28               ` Piotr Kubaj
  0 siblings, 1 reply; 10+ messages in thread
From: FX @ 2022-04-28 18:55 UTC (permalink / raw)
  To: Piotr Kubaj; +Cc: gcc-patches, Fortran List, segher

> Given that 12 has been branched off, is it OK now to commit this patch?

How does the patch affect the results of “make check-gfortran”? How many tests that failed or were unsupported pass?

FX

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-28 18:55             ` FX
@ 2022-04-30 18:28               ` Piotr Kubaj
  2022-04-30 19:17                 ` FX
  0 siblings, 1 reply; 10+ messages in thread
From: Piotr Kubaj @ 2022-04-30 18:28 UTC (permalink / raw)
  To: FX; +Cc: gcc-patches, Fortran List, segher

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On 22-04-28 20:55:08, FX wrote:
> > Given that 12 has been branched off, is it OK now to commit this patch?
> 
> How does the patch affect the results of “make check-gfortran”? How many tests that failed or were unsupported pass?

Actually, test results don't change at all. However, software that otherwise fails to build with "Cannot find an intrinsic module named 'ieee_arithmetic'", now builds successfully.

> 
> FX

-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
  2022-04-30 18:28               ` Piotr Kubaj
@ 2022-04-30 19:17                 ` FX
  0 siblings, 0 replies; 10+ messages in thread
From: FX @ 2022-04-30 19:17 UTC (permalink / raw)
  To: Piotr Kubaj; +Cc: gcc-patches, Fortran List, segher

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

> Actually, test results don't change at all. However, software that otherwise fails to build with "Cannot find an intrinsic module named 'ieee_arithmetic'", now builds successfully.

Test results should definitely change, we’d need to see a before/after list (same build, same revision, without and with patch applied) to know. Run “make check-gfortran”.

All tests in gcc/testsuite/gfortran.dg/ieee/ should be running and running fine (i.e., PASS). You can also grep for “ieee” in the gcc/testsuite/gfortran.sum file created after “make check-gfortran” is run, and report both here. This will help investigate.

Thanks,
FX

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-04-30 19:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-20 15:30 [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd FX
2022-04-13 14:56 ` Piotr Kubaj
2022-04-13 15:27   ` FX
2022-04-14  0:49     ` Piotr Kubaj
2022-04-14  7:05       ` FX
2022-04-14 14:09         ` Piotr Kubaj
2022-04-28 17:09           ` Piotr Kubaj
2022-04-28 18:55             ` FX
2022-04-30 18:28               ` Piotr Kubaj
2022-04-30 19:17                 ` FX

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