Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
I'm abandoning this patch. It was fixed in FreeBSD instead to have feenableexcept() in libm in https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a Thanks for your insight! On 22-05-13 10:59:59, Kewen.Lin wrote: > on 2022/5/13 04:16, Segher Boessenkool wrote: > > Hi Piotr, > > > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote: > >> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header. > > > > Declared, not defined. These are required to be real functions (on all > > platforms that have these functions), not macros or inlines or whatever. > > > > Piotr's reply "FreeBSD doesn't have this function in libm, it's > implemented in /usr/include/fenv.h." from [1] made me feel like > it's a definition instead of declaration. So I thought the check > should use AC_LINK_IFELSE instead, since one fenv.h which doesn't > have the definition can still pass the proposed AC_COMPILE_IFELSE > check. > > I just did a further search, the powerpc fenv.h [2] does include > the definition of feenableexcept. By comparison, the x86 fenv.h [3] > doesn't. But I'm not sure if it's the same as what Piotr's > environments have. Hope it's similar. :-) > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593193.html > [2] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/powerpc/fenv.h > [3] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/x86/fenv.h > > BR, > Kewen > signature.asc Description: PGP signature
Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
On 22-05-13 10:59:59, Kewen.Lin wrote: > on 2022/5/13 04:16, Segher Boessenkool wrote: > > Hi Piotr, > > > > On Tue, May 03, 2022 at 12:21:12PM +0200, pku...@freebsd.org wrote: > >> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header. > > > > Declared, not defined. These are required to be real functions (on all > > platforms that have these functions), not macros or inlines or whatever. > > > > Piotr's reply "FreeBSD doesn't have this function in libm, it's > implemented in /usr/include/fenv.h." from [1] made me feel like > it's a definition instead of declaration. So I thought the check > should use AC_LINK_IFELSE instead, since one fenv.h which doesn't > have the definition can still pass the proposed AC_COMPILE_IFELSE > check. > > I just did a further search, the powerpc fenv.h [2] does include > the definition of feenableexcept. By comparison, the x86 fenv.h [3] > doesn't. But I'm not sure if it's the same as what Piotr's > environments have. Hope it's similar. :-) > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593193.html > [2] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/powerpc/fenv.h > [3] https://github.com/freebsd/freebsd-src/blob/main/lib/msun/x86/fenv.h Yes, it's a definition and thanks for confirming that. As for why it's not in libm, I asked a developer about that: 03:04 <@adalava> It shouldn't be difficulted but I moved to other thing after months looking at FPE in kernel, bugs in context switch and msun test cases failing :-P As far as I know, there are currently no plans to move it to libm on powerpc. riscv, arm and arm64 are in the same boat. I will follow with a next patch that will check for feenableexcept() in fenv.h if libm check is unsuccessful. Thanks, Piotr Kubaj. > > BR, > Kewen > signature.asc Description: PGP signature
Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
Is there anything more required?
On 22-05-03 12:33:43, Piotr Kubaj wrote:
> Here are gmake check-gfortran results requested by FX.
>
> Before patching:
> === gfortran Summary ===
>
> # of expected passes65106
> # of unexpected failures6
> # of expected failures 262
> # of unsupported tests 367
>
> After patching:
> === gfortran Summary ===
>
> # of expected passes65384
> # of unexpected failures6
> # of expected failures 262
> # of unsupported tests 373
>
> In both cases, unexpected failures are:
> FAIL: gfortran.dg/pr98076.f90 -O0 execution test
> FAIL: gfortran.dg/pr98076.f90 -O1 execution test
> FAIL: gfortran.dg/pr98076.f90 -O2 execution test
> FAIL: gfortran.dg/pr98076.f90 -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions execution test
> FAIL: gfortran.dg/pr98076.f90 -O3 -g execution test
> FAIL: gfortran.dg/pr98076.f90 -Os execution test
>
> But this seems unrelated to my patch.
>
> On 22-05-03 12:21:12, pku...@freebsd.org wrote:
> > From: Piotr Kubaj
> >
> > FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
> >
> > Signed-off-by: Piotr Kubaj
> > ---
> > libgfortran/configure| 41 +++-
> > libgfortran/configure.ac | 17 -
> > 2 files changed, 56 insertions(+), 2 deletions(-)
> >
> > diff --git a/libgfortran/configure b/libgfortran/configure
> > index ae64dca3114..ad71694ef05 100755
> > --- a/libgfortran/configure
> > +++ b/libgfortran/configure
> > @@ -27338,8 +27338,45 @@ fi
> >
> >
> >
> > +case x$target in
> > + xpowerpc*-freebsd*)
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for fenv.h and
> > feenableexcept" >&5
> > +$as_echo_n "checking for fenv.h and feenableexcept... " >&6; }
> > +if ${have_feenableexcept+:} false; then :
> > + $as_echo_n "(cached) " >&6
> > +else
> > +
> > +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> > +/* end confdefs.h. */
> > + #include
> > +int
> > +main ()
> > +{
> > + feenableexcept(FE_DIVBYZERO | FE_INVALID);
> > + ;
> > + return 0;
> > +}
> > +_ACEOF
> > +if ac_fn_c_try_compile "$LINENO"; then :
> > + have_feenableexcept="yes"
> > +else
> > + have_feenableexcept="no"
> > +fi
> > +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> > +fi
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_feenableexcept" >&5
> > +$as_echo "$have_feenableexcept" >&6; }
> > +if test "x$have_feenableexcept" = "xyes"; then
> > +
> > +cat >>confdefs.h <<_ACEOF
> > +#define HAVE_FEENABLEEXCEPT 1
> > +_ACEOF
> > +
> > +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 +27421,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..2dd6d345b22 100644
> > --- a/libgfortran/configure.ac
> > +++ b/libgfortran/configure.ac
> > @@ -602,8 +602,23 @@ fi
> > # Check whether we have a __float128 type, depends on
> > enable_libquadmath_support
> > LIBGFOR_CHECK_FLOAT128
> >
> > +case x$target in
> > + xpowerpc*-freebsd*)
> > +AC_CACHE_CHECK([for fenv.h and feenableexcept], have_feenableexcept, [
> > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
> > +[[ #include ]],
> > +[[ feenableexcept(FE_DIVBYZERO | FE_INVALID); ]])],
> > +[ have_feenableexcept="yes" ],
> > +[ have_feenableexcept="no" ])])
> > +if test "x$have_feenableexcept" = "xyes"; then
> > + AC_DEFINE(HAVE_FEENABLEEXCEPT,1,[fenv.h includes 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.36.0
> >
signature.asc
Description: PGP signature
Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD
Here are gmake check-gfortran results requested by FX.
Before patching:
=== gfortran Summary ===
# of expected passes65106
# of unexpected failures6
# of expected failures 262
# of unsupported tests 367
After patching:
=== gfortran Summary ===
# of expected passes65384
# of unexpected failures6
# of expected failures 262
# of unsupported tests 373
In both cases, unexpected failures are:
FAIL: gfortran.dg/pr98076.f90 -O0 execution test
FAIL: gfortran.dg/pr98076.f90 -O1 execution test
FAIL: gfortran.dg/pr98076.f90 -O2 execution test
FAIL: gfortran.dg/pr98076.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/pr98076.f90 -O3 -g execution test
FAIL: gfortran.dg/pr98076.f90 -Os execution test
But this seems unrelated to my patch.
On 22-05-03 12:21:12, pku...@freebsd.org wrote:
> From: Piotr Kubaj
>
> FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
>
> Signed-off-by: Piotr Kubaj
> ---
> libgfortran/configure| 41 +++-
> libgfortran/configure.ac | 17 -
> 2 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/libgfortran/configure b/libgfortran/configure
> index ae64dca3114..ad71694ef05 100755
> --- a/libgfortran/configure
> +++ b/libgfortran/configure
> @@ -27338,8 +27338,45 @@ fi
>
>
>
> +case x$target in
> + xpowerpc*-freebsd*)
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for fenv.h and
> feenableexcept" >&5
> +$as_echo_n "checking for fenv.h and feenableexcept... " >&6; }
> +if ${have_feenableexcept+:} false; then :
> + $as_echo_n "(cached) " >&6
> +else
> +
> +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h. */
> + #include
> +int
> +main ()
> +{
> + feenableexcept(FE_DIVBYZERO | FE_INVALID);
> + ;
> + return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> + have_feenableexcept="yes"
> +else
> + have_feenableexcept="no"
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_feenableexcept" >&5
> +$as_echo "$have_feenableexcept" >&6; }
> +if test "x$have_feenableexcept" = "xyes"; then
> +
> +cat >>confdefs.h <<_ACEOF
> +#define HAVE_FEENABLEEXCEPT 1
> +_ACEOF
> +
> +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 +27421,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..2dd6d345b22 100644
> --- a/libgfortran/configure.ac
> +++ b/libgfortran/configure.ac
> @@ -602,8 +602,23 @@ fi
> # Check whether we have a __float128 type, depends on
> enable_libquadmath_support
> LIBGFOR_CHECK_FLOAT128
>
> +case x$target in
> + xpowerpc*-freebsd*)
> +AC_CACHE_CHECK([for fenv.h and feenableexcept], have_feenableexcept, [
> + AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
> +[[ #include ]],
> +[[ feenableexcept(FE_DIVBYZERO | FE_INVALID); ]])],
> +[ have_feenableexcept="yes" ],
> +[ have_feenableexcept="no" ])])
> +if test "x$have_feenableexcept" = "xyes"; then
> + AC_DEFINE(HAVE_FEENABLEEXCEPT,1,[fenv.h includes 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.36.0
>
signature.asc
Description: PGP signature
Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
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 -- signature.asc Description: PGP signature
Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
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 > > -- -- signature.asc Description: PGP signature
Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
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 -- signature.asc Description: PGP signature
Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
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
--
From d5e255f09b4cfd2cb3688d0e2d5feba85d1f5dc8 Mon Sep 17 00:00:00 2001
From: Piotr Kubaj
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
---
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 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 " >&5
+$as_echo_n "checking for feenableexcept in ... " >&6; }
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+#include
+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 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 ])
+ AC_TRY_COMPILE([#include ],
+ [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
signature.asc
Description: PGP signature
Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd
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.
signature.asc
Description: PGP signature
Re: [PATCH] gcc/configure: check for powerpc64le-unknown-freebsd
On 21-10-16 18:57:39, Segher Boessenkool wrote: > On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote: > > Only powerpc64-unknown-freebsd was checked for. > > > > Signed-off-by: Piotr Kubaj > > Thanks! > > I pushed this now, with commit message (including changelog, which is > required): Thank you! Since powerpc64le-unknown-freebsd is supported also in 9, 10 and 11, can you also backport it? > > === > gcc/configure: Check for powerpc64le*-*-freebsd* > > Only powerpc64-unknown-freebsd was checked for. > > Signed-off-by: Piotr Kubaj > > gcc/ > * configure.ac: Treat powerpc64*-*-freebsd* the same as > powerpc64-*-freebsd*. > * configure: Regenerate. > === > > > Segher signature.asc Description: PGP signature
Re: rs6000: add support for powerpc64le-unknown-freebsd
Hello again, it looks like one simple patch got left out by accident. Would it be possible for you to commit it? Thank you, Piotr Kubaj. On 20-12-28 06:37:23, Segher Boessenkool wrote: > On Mon, Dec 28, 2020 at 12:44:15PM +0100, Gerald Pfeifer wrote: > > On Wed, 16 Dec 2020, Segher Boessenkool wrote: > > >> Any chance (one of you) can help and commit this? > > > Done now. > > > > > > Please remind me in a week or so to do the backports? > > > > Thank you, Segher! > > > > And thanks for pushing the backports, too, whenever you get to them, > > holiday season and such. > > Hey, if I can remember how ssh works ;-) > > Done now (10 and 9). Cheers! > > > Segher -- --- gcc/configure.orig 2021-04-29 10:19:44 UTC +++ gcc/configure @@ -29405,7 +29405,7 @@ $as_echo "#define HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE 1" esac case "$target:$tm_file" in - powerpc64-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) + powerpc64*-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) case "$target" in *le-*-linux*) emul_name="-melf64lppc" signature.asc Description: PGP signature
Re: rs6000: add support for powerpc64le-unknown-freebsd
Hello again, sorry to reopen this issue, but one part was skipped. It was just now found out, because it doesn't cause build issues, but only runtime issues (GCC fails to build binaries): /usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to `.__udivmodti4' /usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to `.__ctzdi2' /usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to `.__parityti2' /usr/local/bin/ld: /usr/local/lib/gcc10/libgcc_s.so: undefined reference to `.__enable_execute_stack' Could you commit the following patch: --- gcc/configure.orig 2021-04-29 10:19:44 UTC +++ gcc/configure @@ -29405,7 +29405,7 @@ $as_echo "#define HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE 1" esac case "$target:$tm_file" in - powerpc64-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) + powerpc64*-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) case "$target" in *le-*-linux*) emul_name="-melf64lppc" --- gcc/configure.ac.orig 2021-04-29 11:22:30 UTC +++ gcc/configure.ac @@ -5871,7 +5871,7 @@ EOF esac case "$target:$tm_file" in - powerpc64-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) + powerpc64*-*-freebsd* | powerpc64*-*-linux* | powerpc*-*-linux*rs6000/biarch64.h*) case "$target" in *le-*-linux*) emul_name="-melf64lppc" Thanks, Piotr Kubaj. On 20-12-16 16:23:09, Segher Boessenkool wrote: > On Tue, Dec 15, 2020 at 12:52:05AM +0100, Piotr Kubaj wrote: > > Yes, there is, thanks for noticing that! > > > > Fixed patch attached. > > Hi! > > Could you send this as plain text? It now is quoted-printable, which is > really hard to handle. > > Thanks! > > Hrm, this is really short, I'll just try to fix it by hand... Wish me > luck :-) > > > Segher -- signature.asc Description: PGP signature
Re: rs6000: add support for powerpc64le-unknown-freebsd
Yes, there is, thanks for noticing that!
Fixed patch attached.
On 20-12-15 00:37:02, Gerald Pfeifer wrote:
> On Mon, 14 Dec 2020, Piotr Kubaj via Gcc-patches wrote:
> > --- gcc/configure.ac.orig 2020-12-14 15:22:23 UTC
> > +++ gcc/configure.ac
> > @@ -5874,6 +5874,8 @@ case "$target:$tm_file" in
> > *-*-linux*)
> > emul_name="-melf64ppc"
> > ;;
> >+ *le-*-freebsd*)
> >+ emul_name="-melf64lppc_fbsd"
> > *-*-freebsd*)
> > emul_name="-melf64ppc_fbsd"
> > ;;
>
> Is there a ;; missing to terminate the *le-*-freebsd* entry?
>
> (Or am I missing some subtlety of /bin/sh ?)
>
> Gerald
>
--
--- gcc/config.gcc.orig 2020-12-07 03:00:29 UTC
+++ gcc/config.gcc
@@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} rs6000/t-ppccomm"
case ${target} in
+ powerpc*le-*-*)
+ tm_file="${tm_file} rs6000/sysv4le.h" ;;
+ esac
+ case ${target} in
powerpc64*)
tm_file="${tm_file} rs6000/default64.h rs6000/freebsd64.h"
tmake_file="${tmake_file} rs6000/t-freebsd64"
--- gcc/config/rs6000/freebsd64.h.orig 2020-07-23 06:35:17 UTC
+++ gcc/config/rs6000/freebsd64.h
@@ -158,8 +157,8 @@ extern int dot_symbols;
#define ASM_SPEC64 "-a64"
#define ASM_SPEC_COMMON "%(asm_cpu) \
-%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}} \
-%{mlittle} %{mlittle-endian} %{mbig} %{mbig-endian}"
+%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}}" \
+ ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
#undef SUBSUBTARGET_EXTRA_SPECS
#define SUBSUBTARGET_EXTRA_SPECS \
@@ -181,9 +180,15 @@ extern int dot_symbols;
%{static:-Bstatic}} \
%{symbolic:-Bsymbolic}"
+#undef DEFAULT_ASM_ENDIAN
#define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
-
+#if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
+#define DEFAULT_ASM_ENDIAN " -mlittle"
+#define LINK_OS_FREEBSD_SPEC64 "-melf64lppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#else
+#define DEFAULT_ASM_ENDIAN " -mbig"
#define LINK_OS_FREEBSD_SPEC64 "-melf64ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#endif
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS { "m64" }
--- gcc/configure.ac.orig 2020-12-14 15:22:23 UTC
+++ gcc/configure.ac
@@ -5874,6 +5874,9 @@ case "$target:$tm_file" in
*-*-linux*)
emul_name="-melf64ppc"
;;
+ *le-*-freebsd*)
+ emul_name="-melf64lppc_fbsd"
+ ;;
*-*-freebsd*)
emul_name="-melf64ppc_fbsd"
;;
signature.asc
Description: PGP signature
Re: rs6000: Update the processor defaults for FreeBSD
On 20-12-14 10:22:32, Segher Boessenkool wrote:
> On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > > It is both, actually (-mcpu= implies -mtune=)
> > Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the
> > generic one (ppc970 for BE)
>
> But that is not what the patch does?
OK, then can you explain to me what it does since the generated assembly still
specifies .machine power4?
This is my first attempt at improving GCC on powerpc* on FreeBSD and I'd really
prefer not to break anything, but this SEEMS to be correct.
>
> > > > Linux also does similarly in linux64.h:
> > > > 74 #undef PROCESSOR_DEFAULT
> > > > 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
> > > > 76 #undef PROCESSOR_DEFAULT64
> > > > 77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
> > >
> > > Yes, but we still default to power4 on BE Linux (and power8 on LE). I
> > > get lost in the macro maze here, not sure how that works :-)
>
> I still am baffled how this works :-/
>
> > > > Although there is hard to explain (for me) setting to tune for POWER7
> > > > on 32-bits. POWER7 is 64-bit and it should be more reasonable to
> > > > optimize for the last 32-bit machines that still may be in use (so G4).
> > >
> > > 7450 has very different optimisation than 970. Power7 and 970 have
> > > largely similar pipelines.
> > Yes, but the point is that users on 32-bit machines don't use POWER7, but
> > most likely G4.
>
> Ah, but most users using -m32 are on a 64-bit machine!
>
> > > > That said, on the 64-bit front, we will just match the Linux setting.
> > >
> > > Compile a very simple test and look at the .machine in the generated .s?
> > > Does that do what you want?
> > Yes, I just tested it (on BE).
> > pkubaj@talos:$/usr/home/pkubaj$ cat test.c
> > #include
> >
> > int main()
> > {
> > printf("Hello world!");
> > }
> >
> > I built it twice, with GCC 9.3 without my patch and with GCC 10.1 with my
> > patch. The only difference is:
> > pkubaj@talos:$/usr/home/pkubaj$ diff -u test.s.9 test.s.10
> > --- test.s.92020-12-14 15:51:43.203263000 +0100
> > +++ test.s.10 2020-12-14 15:52:01.147238000 +0100
> > @@ -43,5 +43,5 @@
> > .cfi_endproc
> > .LFE1:
> > .size main,.-main
> > - .ident "GCC: (FreeBSD Ports Collection) 9.3.0"
> > + .ident "GCC: (FreeBSD Ports Collection) 10.2.0"
> > .section.note.GNU-stack,"",@progbits
> >
> > Both have .machine power4:
> > pkubaj@talos:$/usr/home/pkubaj$ grep .machine test.s.*
> > test.s.10: .machine power4
> > test.s.9: .machine power4
> >
> > I'm not sure where GCC sets power8 for LE, but it's definitely somewhere
> > else.
>
> Yes... And I do not know where this power4 comes from. Mysteries :-)
>
> > So IMO this patch is good to go.
>
> Yes, thanks!
>
>
> Segher
--
signature.asc
Description: PGP signature
rs6000: add support for powerpc64le-unknown-freebsd
Hello,
this patch implements support for powerpc64le architecture on FreeBSD. Since we
don't have powerpcle (32-bit), I did not add support for powerpcle here. This
remains to be changed if there is powerpcle support in the future.
Patch implements similar endian detection to what linux64.h uses.
Would it be ok to backport it to at least GCC 10?
gcc/Changelog:
2020-12-14 Piotr Kubaj
* config.gcc: add support for powerpc64le-unknown-freebsd
--- gcc/config.gcc.orig 2020-12-07 03:00:29 UTC
+++ gcc/config.gcc
@@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} rs6000/t-ppccomm"
case ${target} in
+ powerpc*le-*-*)
+ tm_file="${tm_file} rs6000/sysv4le.h" ;;
+ esac
+ case ${target} in
powerpc64*)
tm_file="${tm_file} rs6000/default64.h rs6000/freebsd64.h"
tmake_file="${tmake_file} rs6000/t-freebsd64"
--- gcc/config/rs6000/freebsd64.h.orig 2020-07-23 06:35:17 UTC
+++ gcc/config/rs6000/freebsd64.h
@@ -158,8 +157,8 @@ extern int dot_symbols;
#define ASM_SPEC64 "-a64"
#define ASM_SPEC_COMMON "%(asm_cpu) \
-%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}} \
-%{mlittle} %{mlittle-endian} %{mbig} %{mbig-endian}"
+%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}}" \
+ ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
#undef SUBSUBTARGET_EXTRA_SPECS
#define SUBSUBTARGET_EXTRA_SPECS \
@@ -181,9 +180,15 @@ extern int dot_symbols;
%{static:-Bstatic}} \
%{symbolic:-Bsymbolic}"
+#undef DEFAULT_ASM_ENDIAN
#define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
-
+#if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
+#define DEFAULT_ASM_ENDIAN " -mlittle"
+#define LINK_OS_FREEBSD_SPEC64 "-melf64lppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#else
+#define DEFAULT_ASM_ENDIAN " -mbig"
#define LINK_OS_FREEBSD_SPEC64 "-melf64ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#endif
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS { "m64" }
--- gcc/configure.ac.orig 2020-12-14 15:22:23 UTC
+++ gcc/configure.ac
@@ -5874,6 +5874,8 @@ case "$target:$tm_file" in
*-*-linux*)
emul_name="-melf64ppc"
;;
+ *le-*-freebsd*)
+ emul_name="-melf64lppc_fbsd"
*-*-freebsd*)
emul_name="-melf64ppc_fbsd"
;;
signature.asc
Description: PGP signature
Re: rs6000: Update the processor defaults for FreeBSD
On 20-12-13 09:48:35, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Dec 13, 2020 at 03:34:57PM +0100, Piotr Kubaj wrote:
> > this is only default tuning (-mtune, not -mcpu).
>
> It is both, actually (-mcpu= implies -mtune=)
Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the
generic one (ppc970 for BE)
>
> > Linux also does similarly in linux64.h:
> > 74 #undef PROCESSOR_DEFAULT
> > 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
> > 76 #undef PROCESSOR_DEFAULT64
> > 77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
>
> Yes, but we still default to power4 on BE Linux (and power8 on LE). I
> get lost in the macro maze here, not sure how that works :-)
>
> > Although there is hard to explain (for me) setting to tune for POWER7 on
> > 32-bits. POWER7 is 64-bit and it should be more reasonable to optimize for
> > the last 32-bit machines that still may be in use (so G4).
>
> 7450 has very different optimisation than 970. Power7 and 970 have
> largely similar pipelines.
Yes, but the point is that users on 32-bit machines don't use POWER7, but most
likely G4.
>
> > That said, on the 64-bit front, we will just match the Linux setting.
>
> Compile a very simple test and look at the .machine in the generated .s?
> Does that do what you want?
Yes, I just tested it (on BE).
pkubaj@talos:$/usr/home/pkubaj$ cat test.c
#include
int main()
{
printf("Hello world!");
}
I built it twice, with GCC 9.3 without my patch and with GCC 10.1 with my
patch. The only difference is:
pkubaj@talos:$/usr/home/pkubaj$ diff -u test.s.9 test.s.10
--- test.s.92020-12-14 15:51:43.203263000 +0100
+++ test.s.10 2020-12-14 15:52:01.147238000 +0100
@@ -43,5 +43,5 @@
.cfi_endproc
.LFE1:
.size main,.-main
- .ident "GCC: (FreeBSD Ports Collection) 9.3.0"
+ .ident "GCC: (FreeBSD Ports Collection) 10.2.0"
.section.note.GNU-stack,"",@progbits
Both have .machine power4:
pkubaj@talos:$/usr/home/pkubaj$ grep .machine test.s.*
test.s.10: .machine power4
test.s.9: .machine power4
I'm not sure where GCC sets power8 for LE, but it's definitely somewhere else.
So IMO this patch is good to go.
Thanks,
Piotr Kubaj.
signature.asc
Description: PGP signature
Re: rs6000: Update the processor defaults for FreeBSD
Hello, this is only default tuning (-mtune, not -mcpu). Linux also does similarly in linux64.h: 74 #undef PROCESSOR_DEFAULT 75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7 76 #undef PROCESSOR_DEFAULT64 77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8 Although there is hard to explain (for me) setting to tune for POWER7 on 32-bits. POWER7 is 64-bit and it should be more reasonable to optimize for the last 32-bit machines that still may be in use (so G4). That said, on the 64-bit front, we will just match the Linux setting. On 20-12-13 08:23:53, Segher Boessenkool wrote: > On Sun, Dec 13, 2020 at 01:10:58AM +0100, Gerald Pfeifer wrote: > > Piotr is the one spending most times on ensuring FreeBSD ports work > > fine on POWER, so personally I'm happy to follow his recommendation > > on such matters. > > I have a question though: > > > -/* Until now the 970 is the only Processor where FreeBSD 64-bit runs on. > > */ > > #undef PROCESSOR_DEFAULT > > -#define PROCESSOR_DEFAULT PROCESSOR_POWER4 > > +#define PROCESSOR_DEFAULT PROCESSOR_PPC7450 > > #undef PROCESSOR_DEFAULT64 > > -#define PROCESSOR_DEFAULT64 PROCESSOR_POWER4 > > +#define PROCESSOR_DEFAULT64 PROCESSOR_POWER8 > > Is this wise? Binaries won't run on many BE systems anymore with > this. (Linux still uses Power4 by default for BE, as well). > > In either case: yes, whatever you guys decide here is fine. Also for > all backports you want. Thanks! > > > Segher signature.asc Description: PGP signature
Re: [PATCH v2] Fix use of singleton in optinfo framework
I have already bisected GCC 10 issue here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 The problem is commit 634afa05a8cbff010480088811fe1f39eca70c1d. On 20-04-14 21:11:01, Iain Sandoe wrote: Gerald Pfeifer wrote: On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote: gcc/Changelog: 2020-04-06 Gustavo Romero * dumpfile.c: (selftest::temp_dump_context::temp_dump_context): Fix ctor. If you approve (David, Jakub, or someone else) I can take care of committing this if you like. It would be helpful to get this resolved in the next days. +1 for earlier Darwin platforms. on GCC-9.x this fixes bootstrap with Apple gcc-4.2.1 (XCode 3.1.4, 3.2.6 and some earlier versions of 4.x) For master/10, we’re still broken by some other issue - but it does at least get us past the self-test. Iain signature.asc Description: PGP signature
Re: [PATCH] Fix use of singleton in optinfo framework
Hi, since there has been some misunderstanding, I will explain. There are 4 possible options here: 1. FreeBSD 12.1-RELEASE, powerpc, GCC 4.2 2. FreeBSD 13.0-CURRENT (head branch), powerpc, LLVM 10.0.0 3. FreeBSD 12.1-RELEASE, powerpc64, GCC 4.2 4. FreeBSD 13.0-CURRENT (head branch), powerpc64, LLVM 10.0.0 The patch that Gustavo provided fixes completely build issue for 1. For 2. and 4., there's another issue with namespace collision between LLVM and GCC, we use our own non-upstreamable patch. The ICE reported here doesn't happen. For 3., we currently build GCC9 using GCC8 as a bootstrap compiler and it works fine (ICE doesn't happen). However, I'd like to get rid of the bootstrap compiler and just build with base GCC 4.2. That's when the ICE happens. There are also other issues, all related to GCC persistently setting -O2, with which GCC 4.2 and stage 1 binaries compiled with -O2 just segfault. They work fine with -O0, however. So this patch helps with building on both 32 and 64 bits using old GCC 4.2. On 20-04-08 00:00:37, Gustavo Romero wrote: Hi David, On 04/06/2020 10:42 PM, David Malcolm wrote: On Mon, 2020-04-06 at 19:44 -0400, Gustavo Romero wrote: Thanks for this patch. The patch looks correct, but I'm not sure that the description of the problem is exact in every detail. I think you've run into a bug in code I wrote; sorry. Thanks a lot for your quick reply and review. which calls the singleton dtor when the class is destroyed, freeing memory that is referenced after free() is called, generating an ICE error. I introduced dump_context when adding the opt_info machinery in order to make it more amenable to unit-testing via the selftest framework. If I'm reading the code correctly, dump_context has no ctor, but instead relies on the fields being zero-initialized in the BSS segment. It has a dtor, which deletes the m_pending field. It looks like the initializer of m_context in temp_dump_context's ctor uses the implicitly-defined default constructor for dump_context, and this leaves the fields uninitialized; in particular m_pending. I *think* what's going on is that the temporary dump_context that gets created in the "m_saved" initializer is uninitialized, and when its dtor runs it deletes the m_pending, thus calling delete on uninitialized memory - whatever happens to be in the stack. I don't see a complaint about this under valgrind though. Yeah I think that's correct. On my wording in the commit message it says as if the dereference of corrupted data happens after the dtor finishes, which is wrong. Ultimately iirc even optinfo dtor can be the culprit but as you said it might depend upon what's in the uninitialized data. I'll fix it in v2. I also said base gcc used was 4.7, but it's actually 4.2.1, so I'll fix it for the records too. Finally, it seems that this patch also helps 64-bit builds, accordingly to Piotr (CC:ed). Sorry about this. IIRC I was trying to avoid having a ctor run before main. If I'm reading things right there's still a dormant bug here even with your patch. Got it. OK, I still need to spend some time on FreeBSD not building GCC9 on 64-bit (due to other reasons), so I'll keep an eye on it and report back if I find something worth. Kind regards, Gustavo signature.asc Description: PGP signature
