[COMMITTED] IBM Z: Fix vector intrinsics vec_double and vec_floate

[Marius Hillenbrand via Gcc-patches]

Discussed offline with Andreas Krebbel.


Fix the mapping of vec_double and vec_floate to builtins.

gcc/ChangeLog:

PR target/100871
* config/s390/vecintrin.h (vec_doublee): Fix to use
  __builtin_s390_vflls.
(vec_floate): Fix to use __builtin_s390_vflrd.

gcc/testsuite/ChangeLog:

* gcc.target/s390/zvector/vec-doublee.c: New test.
* gcc.target/s390/zvector/vec-floate.c: New test.
---
 gcc/config/s390/vecintrin.h   |  4 ++--
 .../gcc.target/s390/zvector/vec-doublee.c | 22 ++
 .../gcc.target/s390/zvector/vec-floate.c  | 23 +++
 3 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/zvector/vec-doublee.c
 create mode 100644 gcc/testsuite/gcc.target/s390/zvector/vec-floate.c

diff --git a/gcc/config/s390/vecintrin.h b/gcc/config/s390/vecintrin.h
index 6bd26f8a240..9a3f7c347ac 100644
--- a/gcc/config/s390/vecintrin.h
+++ b/gcc/config/s390/vecintrin.h
@@ -109,8 +109,8 @@ __lcbb(const void *ptr, int bndry)
 #define vec_rint(X)   __builtin_s390_vfi((X), 0, 0)
 #define vec_roundc(X) __builtin_s390_vfi((X), 4, 0)
 #define vec_round(X)  __builtin_s390_vfi((X), 4, 4)
-#define vec_doublee(X) __builtin_s390_vfll((X))
-#define vec_floate(X) __builtin_s390_vflr((X), 0, 0)
+#define vec_doublee(X) __builtin_s390_vflls((X))
+#define vec_floate(X) __builtin_s390_vflrd((X), 0, 0)
 #define vec_load_len_r(X,L)\
   (__vector unsigned char)__builtin_s390_vlrlr((L),(X))
 #define vec_store_len_r(X,Y,L) \
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-doublee.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-doublee.c
new file mode 100644
index 000..11610f225e5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-doublee.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z14 -mzarch -mzvector --save-temps" } */
+/* { dg-do run { target { s390_z14_hw } } } */
+
+/*
+ * The vector intrinsic vec_doublee(a) converts the even-indexed
+ * single-precision numbers in a vector to double precision.
+ */
+#include 
+#include 
+
+int
+main (void)
+{
+vector float in = { 1.0, 2.0, 3.0, 4.0 };
+
+vector double result = vec_doublee(in);
+/* { dg-final { scan-assembler-times {\n\tvldeb} 1 } } */
+
+assert(result[0] == (double)in[0]);
+assert(result[1] == (double)in[2]);
+}
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-floate.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-floate.c
new file mode 100644
index 000..0b9cbe3d89e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-floate.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z14 -mzarch -mzvector --save-temps" } */
+/* { dg-do run { target { s390_z14_hw } } } */
+
+/*
+ * The vector intrinsic vec_floate(a) rounds a vector of double-precision
+ * numbers to single-precision. The results are stored in the even-numbered
+ * target elements.
+ */
+#include 
+#include 
+
+int
+main (void)
+{
+vector double in = { 1.0, 2.0 };
+
+vector float result = vec_floate(in);
+/* { dg-final { scan-assembler-times {\n\tvledb} 1 } } */
+
+assert(result[0] == (float)in[0]);
+assert(result[2] == (float)in[1]);
+}
-- 
2.26.2

[PATCH] IBM Z: Avoid bash-specific substitution in configure

[Marius Hillenbrand via Gcc-patches]

Tested configure runs on NetBSD x86-64, Linux on x86-64 (with target s390x), and
on s390x.

Is the patch ok for master, and for gcc-11?

8<--8<--8<-

Fix a bootstrap error observed on NetBSD.

2021-05-12  Marius Hillenbrand  

gcc/ChangeLog:

PR bootstrap/100552
* configure.ac: Replace pattern substitution with call to sed.
* configure: Regenerate (tbd at time of commit).
---
 gcc/configure.ac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/configure.ac b/gcc/configure.ac
index e9ba2af548a..4e788019d99 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7499,7 +7499,8 @@ case $target in
   # cross build. are target headers available?
   # carefully coerce the build-system compiler to use target headers
   saved_CXXFLAGS="$CXXFLAGS"
-  CROSS_TEST_CXXFLAGS="-nostdinc ${XGCC_FLAGS_FOR_TARGET//-B/-idirafter/}"
+  fixed_XGCC_FLAGS_FOR_TARGET=`echo "$XGCC_FLAGS_FOR_TARGET" | sed 
's/-B/-idirafter/g'`
+  CROSS_TEST_CXXFLAGS="-nostdinc $fixed_XGCC_FLAGS_FOR_TARGET"
   CXXFLAGS="$CROSS_TEST_CXXFLAGS"
   AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
 #include 
-- 
2.26.2

[PATCH] IBM Z: Fix error checking for builtin vec_permi

[Marius Hillenbrand via Gcc-patches]

Hi,

this patch fixes the check of immediate operands to the builtin vec_permi and
adds a new test for this built-in.

Reg-rested and bootstrapped on s390x.

Is it OK for master? Is it OK for backporting to gcc-11?

Regards,
Marius


--8<--8<-8<-

The builtin vec_permi is peculiar in that its immediate operand is
encoded differently than the immediate operand that is backing the
builtin. This fixes the check for the immediate operand, adding a
regression test in the process.

This partially reverts commit 3191c1f4488d1f7563b563d7ae2a102a26f16d82

gcc/ChangeLog:

2021-05-04  Marius Hillenbrand  

* config/s390/s390-builtins.def (O_M5, O1_M5, ...): Remove unused 
macros.
(s390_vec_permi_s64, s390_vec_permi_b64, s390_vec_permi_u64)
(s390_vec_permi_dbl, s390_vpdi): Use the O3_U2 type for the immediate
operand.
* config/s390/s390.c (s390_const_operand_ok): Remove unused
values.

gcc/testsuite/ChangeLog:

* gcc.target/s390/zvector/imm-range-error-1.c: Fix test for
__builtin_s390_vpdi.
* gcc.target/s390/zvector/vec-permi.c: New test for builtin
vec_permi.
---
 gcc/config/s390/s390-builtins.def | 44 ++-
 gcc/config/s390/s390.c|  7 ++-
 .../s390/zvector/imm-range-error-1.c  |  2 +-
 .../gcc.target/s390/zvector/vec-permi.c   | 54 +++
 4 files changed, 76 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/zvector/vec-permi.c

diff --git a/gcc/config/s390/s390-builtins.def 
b/gcc/config/s390/s390-builtins.def
index f77ab750d22..8ca002dc55a 100644
--- a/gcc/config/s390/s390-builtins.def
+++ b/gcc/config/s390/s390-builtins.def
@@ -29,7 +29,6 @@
 #undef O_U16
 #undef O_U32
 
-#undef O_M5
 #undef O_M12
 
 #undef O_S2
@@ -89,11 +88,6 @@
 #undef O3_U32
 #undef O4_U32
 
-#undef O1_M5
-#undef O2_M5
-#undef O3_M5
-#undef O4_M5
-
 #undef O1_M12
 #undef O2_M12
 #undef O3_M12
@@ -164,20 +158,19 @@
 #define O_U168 /* unsigned 16 bit literal */
 #define O_U329 /* unsigned 32 bit literal */
 
-#define O_M510 /* matches bitmask of 5 */
-#define O_M12   11 /* matches bitmask of 12 */
+#define O_M12   10 /* matches bitmask of 12 */
 
-#define O_S212 /* signed  2 bit literal */
-#define O_S313 /* signed  3 bit literal */
-#define O_S414 /* signed  4 bit literal */
-#define O_S515 /* signed  5 bit literal */
-#define O_S816 /* signed  8 bit literal */
-#define O_S12   17 /* signed 12 bit literal */
-#define O_S16   18 /* signed 16 bit literal */
-#define O_S32   19 /* signed 32 bit literal */
+#define O_S211 /* signed  2 bit literal */
+#define O_S312 /* signed  3 bit literal */
+#define O_S413 /* signed  4 bit literal */
+#define O_S514 /* signed  5 bit literal */
+#define O_S815 /* signed  8 bit literal */
+#define O_S12   16 /* signed 12 bit literal */
+#define O_S16   17 /* signed 16 bit literal */
+#define O_S32   18 /* signed 32 bit literal */
 
-#define O_ELEM  20 /* Element selector requiring modulo arithmetic. */
-#define O_LIT   21 /* Operand must be a literal fitting the target type.  */
+#define O_ELEM  19 /* Element selector requiring modulo arithmetic. */
+#define O_LIT   20 /* Operand must be a literal fitting the target type.  */
 
 #define O_SHIFT 5
 
@@ -230,11 +223,6 @@
 #define O3_U32 (O_U32 << (2 * O_SHIFT))
 #define O4_U32 (O_U32 << (3 * O_SHIFT))
 
-#define O1_M5 O_M5
-#define O2_M5 (O_M5 << O_SHIFT)
-#define O3_M5 (O_M5 << (2 * O_SHIFT))
-#define O4_M5 (O_M5 << (3 * O_SHIFT))
-
 #define O1_M12 O_M12
 #define O2_M12 (O_M12 << O_SHIFT)
 #define O3_M12 (O_M12 << (2 * O_SHIFT))
@@ -671,12 +659,12 @@ OB_DEF_VAR (s390_vec_perm_dbl,  s390_vperm,   
  0,
 B_DEF  (s390_vperm, vec_permv16qi,  0, 
 B_VX,   0,  BT_FN_UV16QI_UV16QI_UV16QI_UV16QI)
 
 OB_DEF (s390_vec_permi, s390_vec_permi_s64, 
s390_vec_permi_dbl, B_VX,   BT_FN_OV4SI_OV4SI_OV4SI_INT)
-OB_DEF_VAR (s390_vec_permi_s64, s390_vpdi,  0, 
 O3_M5,  BT_OV_V2DI_V2DI_V2DI_INT)
-OB_DEF_VAR (s390_vec_permi_b64, s390_vpdi,  0, 
 O3_M5,  BT_OV_BV2DI_BV2DI_BV2DI_INT)
-OB_DEF_VAR (s390_vec_permi_u64, s390_vpdi,  0, 
 O3_M5,  BT_OV_UV2DI_UV2DI_UV2DI_INT)
-OB_DEF_VAR (s390_vec_permi_dbl, s390_vpdi,  0, 
 O3_M5,  BT_OV_V2DF_V2DF_V2DF_INT)
+OB_DEF_VAR (s390_vec_permi_s64, s390_vpdi,  0, 
 O3_U2,  BT_OV_V2DI_V2DI_V2DI_INT)
+OB_DEF_VAR (s390_vec_permi_b64, s390_vpdi,  0, 
 O3_U2,  BT_OV_BV2DI_BV2DI_BV2DI_INT)
+OB_DEF_VAR (s390_vec_permi_u64, s390_vpdi,  0, 
 O3_U2,  BT_OV_UV2DI_UV2DI_UV2DI_INT)
+OB_DEF_VAR 

[committed][wwwdocs] gcc-11/changes: Add cross build behavior for --enable-s390-excess-float-precision

[Marius Hillenbrand via Gcc-patches]

I pushed a minor update to the existing entry for s390-specific
--enable-s390-excess-float-precision after validating.

Marius


--->8->8-->8->8---

Reflect the changes in commit 33f925094d02 ("IBM Z: Detect libc's
float_t behavior on cross compiles").
---
 htdocs/gcc-11/changes.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 08a4c93a..13a35e09 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -466,9 +466,9 @@ a work-in-progress.
   maintain previous behavior and evaluate float expressions in double
   precision, which aligns with the definition of float_t as
   double. With the flag disabled, GCC will always evaluate
-  float expressions in single precision. In native builds, GCC will by
-  default match the definition of float_t in the installed
-  glibc.
+  float expressions in single precision. In native builds and cross 
compiles
+  that have target libc headers, GCC will by default match the definition 
of
+  float_t in the installed glibc.
   
 
 
-- 
2.26.2

[COMMITTED] IBM Z: Fix linking to libatomic in target test cases

[Marius Hillenbrand via Gcc-patches]

Regtested on s390x-linux-gnu. Approved offline by Andreas Krebbel.
Pushed.

>8--->8--->8->8--->8--->8-

One of the test cases failed to link because of missing paths to
libatomic. Reuse procedures in lib/atomic-dg.exp to gather these paths.

gcc/testsuite/ChangeLog:

2021-01-15  Marius Hillenbrand  

* gcc.target/s390/s390.exp: Call lib atomic-dg.exp to link
libatomic into testcases in gcc.target/s390/md.
* gcc.target/s390/md/atomic_exchange-1.c: Remove no unnecessary
-latomic.
---
 gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c | 2 +-
 gcc/testsuite/gcc.target/s390/s390.exp   | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c 
b/gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c
index f82b2131015..54e97d34172 100644
--- a/gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c
+++ b/gcc/testsuite/gcc.target/s390/md/atomic_exchange-1.c
@@ -1,7 +1,7 @@
 /* Machine description pattern tests.  */
 
 /* { dg-do compile } */
-/* { dg-options "-lpthread -latomic" } */
+/* { dg-options "-lpthread" } */
 /* { dg-do run { target { s390_useable_hw } } } */
 
 /**/
diff --git a/gcc/testsuite/gcc.target/s390/s390.exp 
b/gcc/testsuite/gcc.target/s390/s390.exp
index 57b2690f8ab..df460600d42 100644
--- a/gcc/testsuite/gcc.target/s390/s390.exp
+++ b/gcc/testsuite/gcc.target/s390/s390.exp
@@ -28,6 +28,7 @@ if ![istarget s390*-*-*] then {
 load_lib gcc-dg.exp
 load_lib target-supports.exp
 load_lib gfortran-dg.exp
+load_lib atomic-dg.exp
 
 # Return 1 if the the assembler understands .machine and .machinemode.  The
 # target attribute needs that feature to work.
@@ -250,6 +251,8 @@ dg-runtest [lsort [glob -nocomplain 
$srcdir/$subdir/arch13/*.{c,S}]] \
 dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/vxe/*.{c,S}]] \
"" "-O3 -march=arch12 -mzarch"
 
+# Some md tests require libatomic
+atomic_init
 dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/md/*.{c,S}]] \
"" $DEFAULT_CFLAGS
 
@@ -294,4 +297,5 @@ foreach t [list $srcdir/$subdir/pr80080-3.c] {
 }
 
 # All done.
+atomic_finish
 dg-finish
-- 
2.26.2

[COMMITTED] MAINTAINERS: Add myself for write after approval.

[Marius Hillenbrand via Gcc-patches]

ChangeLog:

2020-12-17  Marius Hillenbrand  

* MAINTAINERS (Write After Approval): Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 32f8a2b7292..48335cc7920 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -428,6 +428,7 @@ George Helffrich

 Daniel Hellstrom   
 Fergus Henderson   
 Stuart Henderson   
+Marius Hillenbrand 
 Matthew Hiller 
 Kazu Hirata
 Manfred Hollstein  
-- 
2.26.2

[PING] [PATCH] testsuite/libstdc++: Fix required locales of a testcase

[Marius Hillenbrand via Gcc-patches]

I'd like to ping the small fixup in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560100.html

Please review and merge, if OK.

Marius


 Forwarded Message 
Subject: [PATCH] testsuite/libstdc++: Fix required locales of a testcase
Date: Tue, 24 Nov 2020 17:26:26 +0100
From: Marius Hillenbrand 
To: gcc-patches@gcc.gnu.org
CC: Marius Hillenbrand 

The testsuite for libstdc++ aims to skips test cases for which not all
required locales are installed. This patch adds missing directives about
required locales to one test case to avoid false positive test failures
on systems that have a partial set of locales installed.

Verified by test suite runs that this patch changes the test case from
FAIL to UNSUPPORTED when not all required locales are available and that
the test case will run and PASS when the necessary locales have been
added.

Please review and merge this patch if you agree. While this patch is
trivial, it may safe others a few minutes of confusion ;-)

Marius


libstdc++-v3/ChangeLog:

2020-11-24  Marius Hillenbrand  

* testsuite/22_locale/locale/cons/5.cc: Add missing directives
for required locales.
---
 libstdc++-v3/testsuite/22_locale/locale/cons/5.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
index 8fd73960abb..49e863ec85c 100644
--- a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
@@ -1,5 +1,7 @@
-// { dg-require-namedlocale "en_PH" }
 // { dg-require-namedlocale "de_DE" }
+// { dg-require-namedlocale "en_PH" }
+// { dg-require-namedlocale "es_MX" }
+// { dg-require-namedlocale "fr_FR" }
 // { dg-require-namedlocale "it_IT" }
  // 2000-09-13 Benjamin Kosnik 
-- 
2.26.2

[PATCH] IBM Z: Detect libc's float_t behavior on cross compiles

[Marius Hillenbrand via Gcc-patches]

Hi,

Currently, when the option --enable-s390-excess-float-precision is
omitted, configure checks the libc's behavior only for native builds yet
defaults to the new model for cross compiles. This patch extends the
configure-time check to cross-compiles that have target headers
available (e.g., in the second stage when manually bootstrapping a cross
toolchain or in the build process for cross compilers in some
distributions).

Built cross-compilers for target s390x on x86_64 and checked configure
results and behavior wrt excess float precision (1) with target headers
with old float_t behavior, (2) with new float_t behavior, and (3)
without target headers.
Bootstrapped and checked configure results on s390x.
Tested configure and build on x86_64.

Marius

--->8>8>8>8

When cross-compiling GCC with target libc headers available and
configure option --enable-s390-excess-float-precision has been omitted,
identify whether they clamp float_t to double or respect
__FLT_EVAL_METHOD__ via a compile test that coerces the build-system
compiler to use the target headers. Then derive the setting from that.

gcc/ChangeLog:

2020-12-14  Marius Hillenbrand  

* configure.ac: Change --enable-s390-excess-float-precision
default behavior for cross compiles with target headers.
* configure: Regenerate.
* doc/install.texi: Adjust documentation.
---
 gcc/configure.ac | 52 +++-
 gcc/doc/install.texi |  7 +++---
 2 files changed, 41 insertions(+), 18 deletions(-)

diff --git a/gcc/configure.ac b/gcc/configure.ac
index 062f57fa12b..0964bab6fec 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7372,9 +7372,9 @@ AC_MSG_RESULT($ld_pushpopstate_support)
 # gcc describes its behavior via the macro __FLT_EVAL_METHOD__ and glibc 
derives
 # float_t from that, this behavior can be configured with
 # --enable-s390-excess-float-precision. When given as enabled, that flag 
selects
-# the old model. When omitted, native builds will derive the flag from the
-# behavior of glibc. When glibc clamps float_t to double, gcc follows the old
-# model. In any other case, it defaults to the new model.
+# the old model. When omitted, native builds and cross compiles that have 
target
+# libc headers will detect whether libc clamps float_t to double and in that
+# case maintain the old model. Otherwise, they will default to the new model.
 AC_ARG_ENABLE(s390-excess-float-precision,
   [AS_HELP_STRING([--enable-s390-excess-float-precision],
  [on s390 targets, evaluate float with double precision
@@ -7383,20 +7383,42 @@ AC_ARG_ENABLE(s390-excess-float-precision,
 
 case $target in
   s390*-linux*)
-  if test "$target" = "$host" -a "$host" = "$build" -a \
-  x"$enable_s390_excess_float_precision" = xauto; then
-AC_CACHE_CHECK([for glibc clamping float_t to double],
-  gcc_cv_float_t_clamped_to_double,
-  [AC_RUN_IFELSE([AC_LANG_SOURCE([
+  if test x"$enable_s390_excess_float_precision" = xauto; then
+# Can we autodetect the behavior of the target libc?
+if test "$target" = "$host" -a "$host" = "$build"; then
+  enable_s390_excess_float_precision=autodetect
+elif test "x$with_headers" != xno; then
+  # cross build. are target headers available?
+  # carefully coerce the build-system compiler to use target headers
+  saved_CXXFLAGS="$CXXFLAGS"
+  CROSS_TEST_CXXFLAGS="-nostdinc ${XGCC_FLAGS_FOR_TARGET//-B/-idirafter/}"
+  CXXFLAGS="$CROSS_TEST_CXXFLAGS"
+  AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include 
+]])], [enable_s390_excess_float_precision=autodetect], [])
+  CXXFLAGS="$saved_CXXFLAGS"
+fi
+
+if test x"$enable_s390_excess_float_precision" = xautodetect; then
+  saved_CXXFLAGS="$CXXFLAGS"
+  if ! test "$target" = "$host" -a "$host" = "$build"; then
+CXXFLAGS="$CROSS_TEST_CXXFLAGS"
+   unset CROSS_TEST_CXXFLAGS
+  fi
+  AC_CACHE_CHECK([for glibc clamping float_t to double],
+gcc_cv_float_t_clamped_to_double, [
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
 #define __FLT_EVAL_METHOD__ 0
 #include 
-int main() {
-  return !(sizeof(float_t) == sizeof(double));
-}])],
-[gcc_cv_float_t_clamped_to_double=yes],
-[gcc_cv_float_t_clamped_to_double=no])])
-if test x"$gcc_cv_float_t_clamped_to_double" = xyes; then
-  enable_s390_excess_float_precision=yes
+int dummy[sizeof(float_t) == sizeof(double) ? 1 : -1];
+]])],
+  [gcc_cv_float_t_clamped_to_double=yes],
+  [gcc_cv_float_t_clamped_to_double=no])])
+  CXXFLAGS="$saved_CXXFLAGS"
+  enable_s390_excess_float_precision="$gcc_cv_float_t_clamped_to_double"
+else
+  # no way to detect behavior of target libc, default to new model
+  enable_s390_excess_float_precision=no
 fi
   fi
 
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index a38ca3e3ce8..e30d2fc95bc 100644
--- a/gcc/doc/install.texi

[PATCH] gcc-11/changes: Document new configure flag --enable-s390-excess-float-precision

[Marius Hillenbrand via Gcc-patches]

Hi,

To document the new behavior around FLT_EVAL_METHOD and configure flag
--enable-s390-excess-float-precision on s390, I propose this update to the
Release Notes. Please commit to git-wwwdocs if you agree.

Checked against the w3c validator.

Thanks,
Marius
---
 htdocs/gcc-11/changes.html | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 46a6a372..20f29677 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -340,7 +340,20 @@ a work-in-progress.
 
 
 
-
+S/390, System z, IBM Z Systems
+
+  The behavior when compiling with -fexcess-precision=standard
+  (e.g., implied by -std=c99) on s390(x) targets can now be
+  controlled at configure time with the flag
+  --enable-s390-excess-float-precision. When enabled, gcc will
+  maintain previous behavior and evaluate float expressions in double
+  precision, which aligns with the definition of float_t as
+  double. With the flag disabled, gcc will always evaluate
+  float expressions in single precision. In native builds, gcc will by
+  default match the definition of float_t in the installed
+  glibc.
+  
+
 
 
 
-- 
2.26.2

[PATCH 2/2] gcc/testsuite/s390: Add test cases for float_t

[Marius Hillenbrand via Gcc-patches]

Add two test cases that check for acceptable combinations of float_t and
FLT_EVAL_METHOD on s390x.

Tested against an as-is glibc and one modified so that it derives
float_t from FLT_EVAL_METHOD.

gcc/testsuite/ChangeLog:

2020-11-25  Marius Hillenbrand  

* gcc.target/s390/float_t-1.c: New test.
* gcc.target/s390/float_t-2.c: New test.
---
 gcc/testsuite/gcc.target/s390/float_t-1.c | 15 +++
 gcc/testsuite/gcc.target/s390/float_t-2.c | 13 +
 2 files changed, 28 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/float_t-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/float_t-2.c

diff --git a/gcc/testsuite/gcc.target/s390/float_t-1.c 
b/gcc/testsuite/gcc.target/s390/float_t-1.c
new file mode 100644
index 000..3455694250f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/float_t-1.c
@@ -0,0 +1,15 @@
+/* { dg-do run } */
+/* { dg-options "-std=c99" } */
+#include 
+#include 
+
+int main()
+{
+  /* In standard-compliant mode, the size of float_t and FLT_EVAL_METHOD must
+ match. */
+  if (sizeof(float_t) == sizeof(double) && __FLT_EVAL_METHOD__ != 1)
+abort();
+  if (sizeof(float_t) == sizeof(float) && __FLT_EVAL_METHOD__ != 0)
+abort();
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/s390/float_t-2.c 
b/gcc/testsuite/gcc.target/s390/float_t-2.c
new file mode 100644
index 000..ebeda28b6d2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/float_t-2.c
@@ -0,0 +1,13 @@
+/* { dg-do run } */
+/* { dg-options "-std=gnu99" } */
+#include 
+#include 
+
+int main()
+{
+  /* In gnuXY mode, the size of float_t and FLT_EVAL_METHOD must
+ match, with the historic exception of permitting double and 0. */
+  if (sizeof(float_t) == sizeof(float) && __FLT_EVAL_METHOD__ == 1)
+abort();
+  return 0;
+}
-- 
2.26.2

[PATCH 1/2] IBM Z: Configure excess precision for float at compile-time

[Marius Hillenbrand via Gcc-patches]

Historically, float_t has been defined as double on s390 and gcc would
emit double precision insns for evaluating float expressions when in
standard-compliant mode. Configure that behavior at compile-time as prep
for changes in glibc: When glibc ties float_t to double, keep the old
behavior; when glibc derives float_t from FLT_EVAL_METHOD (as on most
other archs), revert to the default behavior (i.e.,
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT). Provide a configure option
--enable-s390-excess-float-precision to override the check.

gcc/ChangeLog:

2020-11-25  Marius Hillenbrand  

* configure.ac: Add configure option
--enable-s390-excess-float-precision and check to derive default
from glibc.
* config/s390/s390.c: Guard s390_excess_precision with an ifdef
for ENABLE_S390_EXCESS_FLOAT_PRECISION.
* doc/install.texi: Document --enable-s390-excess-float-precision.
* configure: Regenerate.
* config.in: Regenerate.
---
 gcc/config/s390/s390.c | 27 ++---
 gcc/configure.ac   | 45 ++
 gcc/doc/install.texi   | 10 ++
 3 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 6983e363252..02f18366aa1 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -16376,20 +16376,28 @@ s390_invalid_binary_op (int op ATTRIBUTE_UNUSED, 
const_tree type1, const_tree ty
   return NULL;
 }
 
-/* Implement TARGET_C_EXCESS_PRECISION.
+#if ENABLE_S390_EXCESS_FLOAT_PRECISION == 1
+/* Implement TARGET_C_EXCESS_PRECISION to maintain historic behavior with older
+   glibc versions
 
-   FIXME: For historical reasons, float_t and double_t are typedef'ed to
+   For historical reasons, float_t and double_t had been typedef'ed to
double on s390, causing operations on float_t to operate in a higher
precision than is necessary.  However, it is not the case that SFmode
operations have implicit excess precision, and we generate more optimal
code if we let the compiler know no implicit extra precision is added.
 
-   That means when we are compiling with -fexcess-precision=fast, the value
-   we set for FLT_EVAL_METHOD will be out of line with the actual precision of
-   float_t (though they would be correct for -fexcess-precision=standard).
+   With a glibc with that "historic" definition, configure will enable this 
hook
+   to set FLT_EVAL_METHOD to 1 for -fexcess-precision=standard (e.g., as 
implied
+   by -std=cXY).  That means when we are compiling with 
-fexcess-precision=fast,
+   the value we set for FLT_EVAL_METHOD will be out of line with the actual
+   precision of float_t.
 
-   A complete fix would modify glibc to remove the unnecessary typedef
-   of float_t to double.  */
+   Newer versions of glibc will be modified to derive the definition of float_t
+   from FLT_EVAL_METHOD on s390x, as on many other architectures.  There,
+   configure will disable this hook by default, so that we defer to the default
+   of FLT_EVAL_METHOD_PROMOTE_TO_FLOAT and a resulting typedef of float_t to
+   float.  Note that in that scenario, float_t and FLT_EVAL_METHOD will be in
+   line independent of -fexcess-precision. */
 
 static enum flt_eval_method
 s390_excess_precision (enum excess_precision_type type)
@@ -16412,6 +16420,7 @@ s390_excess_precision (enum excess_precision_type type)
 }
   return FLT_EVAL_METHOD_UNPREDICTABLE;
 }
+#endif
 
 /* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
 
@@ -16708,8 +16717,12 @@ s390_shift_truncation_mask (machine_mode mode)
 #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
 #define TARGET_ASM_CAN_OUTPUT_MI_THUNK 
hook_bool_const_tree_hwi_hwi_const_tree_true
 
+#if ENABLE_S390_EXCESS_FLOAT_PRECISION == 1
+/* This hook is only needed to maintain the historic behavior with glibc
+   versions that typedef float_t to double. */
 #undef TARGET_C_EXCESS_PRECISION
 #define TARGET_C_EXCESS_PRECISION s390_excess_precision
+#endif
 
 #undef  TARGET_SCHED_ADJUST_PRIORITY
 #define TARGET_SCHED_ADJUST_PRIORITY s390_adjust_priority
diff --git a/gcc/configure.ac b/gcc/configure.ac
index b410428b4fc..24679a540c1 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7318,6 +7318,51 @@ if test x"$ld_pushpopstate_support" = xyes; then
 fi
 AC_MSG_RESULT($ld_pushpopstate_support)
 
+# On s390, float_t has historically been statically defined as double for no
+# good reason. To comply with the C standard in the light of this definition,
+# gcc has evaluated float expressions in double precision when in
+# standards-compatible mode or when given -fexcess-precision=standard. To 
enable
+# a smooth transition towards the new model used by most architectures, where
+# gcc describes its behavior via the macro __FLT_EVAL_METHOD__ and glibc 
derives
+# float_t from that, this behavior can be configured with
+# --enable-s390-excess-float-precision. When given as enabled, that flag 
selects
+# the old model. When omitted, 

[PATCH 0/2] IBM Z: Prepare cleanup of float express precision

[Marius Hillenbrand via Gcc-patches]

Hi,

gcc has special behavior for FLT_EVAL_METHOD on s390x that causes
performance impact in some scenarios and fails to align with float_t wrt
the C standard in others. These two patches prepare gcc for a cleanup to
get rid of that special case, to improve standard compliance and avoid
the overhead.

On s390 today, float_t is defined as double while gcc by default sets
FLT_EVAL_METHOD to 0 and evaluates float expressions in
single-precision. To mitigate that mismatch, with -std=c99 gcc emits
double precision instructions for evaluating float expressions -- at the
cost of additional conversion instructions. Earlier discussions favored
this behavior to maintain ABI compatibility and compliance with the C
standard (that is, for -std=c99), see the discussion around
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-09/msg02392.html Given
the performance overhead, I have reevaluated the impact of cleaning up
the special behavior and changing float_t into float on s390, and now
think that option to be favorable.

The reason for float_t being defined as double is that the port of glibc
to s390 deferred to the generic definition, which back then defaulted to
double. Since then, that definition has not been changed to avoid
breaking ABIs that use float_t. I found only two affected packages,
clucene and ImageMagick, out of >130k Debian packages scanned, and
prepared patches to avoid impact. ImageMagick's ABI has become
independent of float_t on s390 since 7.0.10-39 (patch in
https://github.com/ImageMagick/ImageMagick/pull/2832); patch for clucene
in https://sourceforge.net/p/clucene/bugs/233/.

To smoothen the transition, the first patch makes gcc's behavior
configurable at compile-time with the flag
--enable-s390-excess-float-precision. When the flag is enabled, gcc
maintains the current behavior. By default, configure will test glibc's
behavior: if glibc ties float_t to double, configure will enable the
flag and maintain the current behavior.  Otherwise, it will disable the
flag and drop the special behavior.

Bootstrapped and regtested on s390x, both with a conventional and a
modified glibc. Bootstrapped and regtested on x86-64. Inspected the
generated headers on both targets.

Marius Hillenbrand (2):
  IBM Z: Configure excess precision for float at compile-time
  gcc/testsuite/s390: Add test cases for float_t

 gcc/config/s390/s390.c| 27 ++
 gcc/configure.ac  | 45 +++
 gcc/doc/install.texi  | 10 +
 gcc/testsuite/gcc.target/s390/float_t-1.c | 15 
 gcc/testsuite/gcc.target/s390/float_t-2.c | 13 +++
 5 files changed, 103 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/float_t-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/float_t-2.c

-- 
2.26.2

[PATCH] testsuite/libstdc++: Fix required locales of a testcase

[Marius Hillenbrand via Gcc-patches]

The testsuite for libstdc++ aims to skips test cases for which not all
required locales are installed. This patch adds missing directives about
required locales to one test case to avoid false positive test failures
on systems that have a partial set of locales installed.

Verified by test suite runs that this patch changes the test case from
FAIL to UNSUPPORTED when not all required locales are available and that
the test case will run and PASS when the necessary locales have been
added.

Please review and merge this patch if you agree. While this patch is
trivial, it may safe others a few minutes of confusion ;-)

Marius


libstdc++-v3/ChangeLog:

2020-11-24  Marius Hillenbrand  

* testsuite/22_locale/locale/cons/5.cc: Add missing directives
for required locales.
---
 libstdc++-v3/testsuite/22_locale/locale/cons/5.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc 
b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
index 8fd73960abb..49e863ec85c 100644
--- a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
@@ -1,5 +1,7 @@
-// { dg-require-namedlocale "en_PH" }
 // { dg-require-namedlocale "de_DE" }
+// { dg-require-namedlocale "en_PH" }
+// { dg-require-namedlocale "es_MX" }
+// { dg-require-namedlocale "fr_FR" }
 // { dg-require-namedlocale "it_IT" }
 
 // 2000-09-13 Benjamin Kosnik 
-- 
2.26.2