[PATCH 5/5] Testcases using dg-options require at least -mzarch.

[PATCH 5/5] Testcases using dg-options require at least -mzarch.

[Andreas Krebbel]

Testcases which override the vect default options using dg-options
need at least -mzarch on S/390 32 bit.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* gfortran.dg/vect/fast-math-mgrid-resid.f: Use -mzarch on S/390.
	* gfortran.dg/vect/pr77848.f: Likewise.
---
 gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
 gcc/testsuite/gfortran.dg/vect/pr77848.f               | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 54f1e9e..7e2816b 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
 ! { dg-require-effective-target vect_double }
 ! { dg-options "-O3 --param vect-max-peeling-for-alignment=0 -fpredictive-commoning -fdump-tree-pcom-details" }
 ! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } } }
+! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
 
 ******* RESID COMPUTES THE RESIDUAL:  R = V - AU
 *
diff --git a/gcc/testsuite/gfortran.dg/vect/pr77848.f b/gcc/testsuite/gfortran.dg/vect/pr77848.f
index d54676e..8749275 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr77848.f
+++ b/gcc/testsuite/gfortran.dg/vect/pr77848.f
@@ -1,7 +1,8 @@
 ! PR 77848: Verify versioning is on when vectorization fails
 ! { dg-do compile }
 ! { dg-options "-O3 -ffast-math -fdump-tree-ifcvt -fdump-tree-vect-details" }
-
+! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
+      
       subroutine sub(x,a,n,m)
       implicit none
       real*8 x(*),a(*),atemp
-- 
2.9.1

[PATCH 1/5] Enable vect_float with S/390 VXE and adjust testcases

[Andreas Krebbel]

The target supports routines provide vect_double and vect_float but
these do not appear to be used consequently in the vect testcases.
With z13 we only have support for vector double but with z14 also for
vector float.  This patch adds vect_float to the testcases using the
float data type and make the vect_float target check to return 1 only
on z14.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* lib/target-supports.exp (check_effective_target_vect_float):
	Return 1 being on a S/390 with VXE.
	* gcc.dg/vect/pr31699.c: Require vec_float.
	* gcc.dg/vect/pr61194.c: Likewise.
	* gcc.dg/vect/pr65947-10.c: Likewise.
	* gcc.dg/vect/pr66142.c: Likewise.
	* gcc.dg/vect/slp-10.c: Likewise.
	* gcc.dg/vect/slp-11c.c: Likewise.
	* gcc.dg/vect/slp-12b.c: Likewise.
	* gcc.dg/vect/slp-18.c: Likewise.
	* gcc.dg/vect/slp-33.c: Likewise.
	* gcc.dg/vect/slp-cond-2-big-array.c: Likewise.
	* gcc.dg/vect/slp-cond-2.c: Likewise.
	* gcc.dg/vect/vect-cond-10.c: Likewise.
	* gcc.dg/vect/vect-cond-8.c: Likewise.
	* gcc.dg/vect/vect-cond-9.c: Likewise.
	* gcc.dg/vect/vect-float-extend-1.c: Likewise.
	* gcc.dg/vect/vect-float-truncate-1.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/pr31699.c               | 2 +-
 gcc/testsuite/gcc.dg/vect/pr61194.c               | 1 +
 gcc/testsuite/gcc.dg/vect/pr65947-10.c            | 1 +
 gcc/testsuite/gcc.dg/vect/pr66142.c               | 2 +-
 gcc/testsuite/gcc.dg/vect/slp-10.c                | 1 +
 gcc/testsuite/gcc.dg/vect/slp-11c.c               | 1 +
 gcc/testsuite/gcc.dg/vect/slp-12b.c               | 1 +
 gcc/testsuite/gcc.dg/vect/slp-18.c                | 1 +
 gcc/testsuite/gcc.dg/vect/slp-33.c                | 1 +
 gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c  | 2 ++
 gcc/testsuite/gcc.dg/vect/slp-cond-2.c            | 2 ++
 gcc/testsuite/gcc.dg/vect/vect-cond-10.c          | 1 +
 gcc/testsuite/gcc.dg/vect/vect-cond-8.c           | 1 +
 gcc/testsuite/gcc.dg/vect/vect-cond-9.c           | 1 +
 gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c   | 1 +
 gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c | 1 +
 gcc/testsuite/lib/target-supports.exp             | 4 +++-
 17 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/pr31699.c b/gcc/testsuite/gcc.dg/vect/pr31699.c
index 59b8daa..7ec4dfe 100644
--- a/gcc/testsuite/gcc.dg/vect/pr31699.c
+++ b/gcc/testsuite/gcc.dg/vect/pr31699.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_double } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdlib.h>
 #include <stdarg.h>
diff --git a/gcc/testsuite/gcc.dg/vect/pr61194.c b/gcc/testsuite/gcc.dg/vect/pr61194.c
index f7c71b9..8421367 100644
--- a/gcc/testsuite/gcc.dg/vect/pr61194.c
+++ b/gcc/testsuite/gcc.dg/vect/pr61194.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
 
 #include "tree-vect.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/pr65947-10.c b/gcc/testsuite/gcc.dg/vect/pr65947-10.c
index a8a674f..321cb8c 100644
--- a/gcc/testsuite/gcc.dg/vect/pr65947-10.c
+++ b/gcc/testsuite/gcc.dg/vect/pr65947-10.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_condition } */
+/* { dg-require-effective-target vect_float } */
 
 #include "tree-vect.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/pr66142.c b/gcc/testsuite/gcc.dg/vect/pr66142.c
index 94854ea..8c79f29 100644
--- a/gcc/testsuite/gcc.dg/vect/pr66142.c
+++ b/gcc/testsuite/gcc.dg/vect/pr66142.c
@@ -41,4 +41,4 @@ foo (float *a, float *b, float *c)
   *a = z;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" { target vect_condition } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 1 "vect" { target { vect_condition && vect_float } } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/slp-10.c b/gcc/testsuite/gcc.dg/vect/slp-10.c
index 3395d22..61c5d3c 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-10.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-10.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-11c.c b/gcc/testsuite/gcc.dg/vect/slp-11c.c
index 8edd663..bdcf434 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-11c.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-11c.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-12b.c b/gcc/testsuite/gcc.dg/vect/slp-12b.c
index d6fe4e4..48e7865 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-12b.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-12b.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_uintfloat_cvt } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-18.c b/gcc/testsuite/gcc.dg/vect/slp-18.c
index 0752363..ed426a3 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-18.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-18.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_float } */
 /* { dg-require-effective-target vect_intfloat_cvt } */
 
 #include <stdarg.h>
diff --git a/gcc/testsuite/gcc.dg/vect/slp-33.c b/gcc/testsuite/gcc.dg/vect/slp-33.c
index 30220d4..ad74daf 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-33.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-33.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c b/gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c
index f171208..57cc67e 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c
@@ -1,4 +1,6 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
+
 #include "tree-vect.h"
 
 #define N 128
diff --git a/gcc/testsuite/gcc.dg/vect/slp-cond-2.c b/gcc/testsuite/gcc.dg/vect/slp-cond-2.c
index 68085d4..7350695 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-cond-2.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-cond-2.c
@@ -1,4 +1,6 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
+
 #include "tree-vect.h"
 
 #define N 32
diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-10.c b/gcc/testsuite/gcc.dg/vect/vect-cond-10.c
index a75ac26..1a18800 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-cond-10.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-cond-10.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
 /* { dg-additional-options "-fno-ipa-icf" } */
 
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-8.c b/gcc/testsuite/gcc.dg/vect/vect-cond-8.c
index 1b31d7d..224251d 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-cond-8.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-cond-8.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
 
 #include "tree-vect.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/vect-cond-9.c b/gcc/testsuite/gcc.dg/vect/vect-cond-9.c
index 6259ab6..c03ed96 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-cond-9.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-cond-9.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_cond_mixed } */
+/* { dg-require-effective-target vect_float } */
 /* { dg-additional-options "-fno-ipa-icf" } */
 
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c b/gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c
index 85a7ad1..867fe20 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_double } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c b/gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c
index 81c23cf..30d3a83 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_double } */
+/* { dg-require-effective-target vect_float } */
 
 #include <stdarg.h>
 #include "tree-vect.h"
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7834c30..b45a19e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5187,7 +5187,9 @@ proc check_effective_target_vect_float { } {
 	     || [istarget aarch64*-*-*]
 	     || ([istarget mips*-*-*]
 		 && [et-is-effective-target mips_msa])
-	     || [is-effective-target arm_neon] } {
+	     || [is-effective-target arm_neon]
+	     || ([istarget s390*-*-*]
+		 && [check_effective_target_s390_vxe]) } {
 	    set et_vect_float_saved($et_index) 1
 	}
     }
-- 
2.9.1

[PATCH 2/5] pr60656.c: New target check: vect_mult_long

[Andreas Krebbel]

We don't have a 64 bit vector integer multiply on z.  Add a specific
check for that.

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* gcc.dg/vect/pr60656.c: Check vect_mult_long.
	* lib/target-supports.exp (check_effective_target_vect_mult_long):
	New proc.
---
 gcc/testsuite/gcc.dg/vect/pr60656.c   |  3 ++-
 gcc/testsuite/lib/target-supports.exp | 24 ++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/pr60656.c b/gcc/testsuite/gcc.dg/vect/pr60656.c
index d9e30bb..f44269a 100644
--- a/gcc/testsuite/gcc.dg/vect/pr60656.c
+++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
@@ -43,4 +43,5 @@ int main()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target vect_widen_mult_si_to_di_pattern } } } */
+/* P * P * P requires a widening multiplication first as well as a longxlong->long after that.  */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { vect_widen_mult_si_to_di_pattern && vect_mult_long } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index b45a19e..7fdfbbb 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5166,6 +5166,30 @@ proc check_effective_target_vect_long { } {
     return $answer
 }
 
+# Return 1 if the target supports hardware vector multiplication of
+# long operands with a long result, 0 otherwise.
+#
+# This can change for different subtargets so do not cache the result.
+
+proc check_effective_target_vect_mult_long { } {
+    if { [istarget i?86-*-*] || [istarget x86_64-*-*]
+	 || (([istarget powerpc*-*-*]
+              && ![istarget powerpc-*-linux*paired*])
+              && [check_effective_target_ilp32])
+	 || [is-effective-target arm_neon]
+	 || ([istarget sparc*-*-*] && [check_effective_target_ilp32])
+	 || [istarget aarch64*-*-*]
+	 || ([istarget mips*-*-*]
+	      && [et-is-effective-target mips_msa]) } {
+	set answer 1
+    } else {
+	set answer 0
+    }
+
+    verbose "check_effective_target_vect_mult_long: returning $answer" 2
+    return $answer
+}
+
 # Return 1 if the target supports hardware vectors of float, 0 otherwise.
 #
 # This won't change for different subtargets so cache the result.
-- 
2.9.1

[PATCH 3/5] pr65947-9.c: Requires char to be signed by default.

[Andreas Krebbel]

Fails on S/390 with char defaulting to unsigned char.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* gcc.dg/vect/pr65947-9.c: Use signed char explicitly.
---
 gcc/testsuite/gcc.dg/vect/pr65947-9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/pr65947-9.c b/gcc/testsuite/gcc.dg/vect/pr65947-9.c
index d769af9..e8f20aa 100644
--- a/gcc/testsuite/gcc.dg/vect/pr65947-9.c
+++ b/gcc/testsuite/gcc.dg/vect/pr65947-9.c
@@ -10,7 +10,7 @@ extern void abort (void) __attribute__ ((noreturn));
    vectorize because the vectorisation requires a slot for default values.  */
 
 signed char __attribute__((noinline,noclone))
-condition_reduction (char *a, char min_v)
+condition_reduction (signed char *a, signed char min_v)
 {
   signed char last = -72;
 
-- 
2.9.1

[PATCH 4/5] New target check: vect_nopeel

[Andreas Krebbel]

Without peeling loops for vector alignment the vectorization costs are
lower and in some cases make the loop vectorizer cover optimizations
which otherwise would be handelt in slp instead.

This adds a new target check for that purpose.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* g++.dg/vect/slp-pr56812.cc: Check vect_nopeel.
	* lib/target-supports.exp (check_effective_target_vect_nopeel):
	New proc.
---
 gcc/testsuite/g++.dg/vect/slp-pr56812.cc |  4 +++-
 gcc/testsuite/lib/target-supports.exp    | 22 ++++++++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/vect/slp-pr56812.cc b/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
index 80bdcdd..955b2ef 100644
--- a/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
+++ b/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
@@ -17,4 +17,6 @@ void mydata::Set (float x)
     data[i] = x;
 }
 
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" } } */
+/* For targets without vector loop peeling the loop becomes cheap
+   enough to be vectorized.  */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" { target { ! vect_nopeel } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7fdfbbb..686465a 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3199,6 +3199,28 @@ proc check_effective_target_vect_floatuint_cvt { } {
     return $et_vect_floatuint_cvt_saved($et_index)
 }
 
+# Return 1 if peeling for alignment is never profitable on the target
+#
+
+proc check_effective_target_vect_nopeel { } {
+    global et_vect_nopeel_saved
+    global et_index
+
+    if [info exists et_vect_nopeel_saved($et_index)] {
+	verbose "check_effective_target_vect_nopeel: using cached result" 2
+    } else {
+	set et_vect_nopeel_saved($et_index) 0
+        if { ([istarget s390*-*-*]
+	      && [check_effective_target_s390_vx]) } {
+	    set et_vect_nopeel_saved($et_index) 1
+        }
+    }
+
+    verbose "check_effective_target_vect_nopeel:\
+	     returning $et_vect_nopeel_saved($et_index)" 2
+    return $et_vect_nopeel_saved($et_index)
+}
+
 # Return 1 if the target supports #pragma omp declare simd, 0 otherwise.
 #
 # This won't change for different subtargets so cache the result.
-- 
2.9.1

[PATCH 0/5] vect testsuite adjustments for S/390

[Andreas Krebbel]

These patches adjust the vect testcases and target support checks in
order to make the right set of testcases to be run on S/390 (z13 and
z14).

Ok for mainline?

Andreas Krebbel (5):
  Enable vect_float with S/390 VXE and adjust testcases
  pr60656.c: New target check: vect_mult_long
  pr65947-9.c: Requires char to be signed by default.
  New target check: vect_nopeel
  Testcases using dg-options require at least -mzarch.

 gcc/testsuite/g++.dg/vect/slp-pr56812.cc           |  4 +-
 gcc/testsuite/gcc.dg/vect/pr31699.c                |  2 +-
 gcc/testsuite/gcc.dg/vect/pr60656.c                |  3 +-
 gcc/testsuite/gcc.dg/vect/pr61194.c                |  1 +
 gcc/testsuite/gcc.dg/vect/pr65947-10.c             |  1 +
 gcc/testsuite/gcc.dg/vect/pr65947-9.c              |  2 +-
 gcc/testsuite/gcc.dg/vect/pr66142.c                |  2 +-
 gcc/testsuite/gcc.dg/vect/slp-10.c                 |  1 +
 gcc/testsuite/gcc.dg/vect/slp-11c.c                |  1 +
 gcc/testsuite/gcc.dg/vect/slp-12b.c                |  1 +
 gcc/testsuite/gcc.dg/vect/slp-18.c                 |  1 +
 gcc/testsuite/gcc.dg/vect/slp-33.c                 |  1 +
 gcc/testsuite/gcc.dg/vect/slp-cond-2-big-array.c   |  2 +
 gcc/testsuite/gcc.dg/vect/slp-cond-2.c             |  2 +
 gcc/testsuite/gcc.dg/vect/vect-cond-10.c           |  1 +
 gcc/testsuite/gcc.dg/vect/vect-cond-8.c            |  1 +
 gcc/testsuite/gcc.dg/vect/vect-cond-9.c            |  1 +
 gcc/testsuite/gcc.dg/vect/vect-float-extend-1.c    |  1 +
 gcc/testsuite/gcc.dg/vect/vect-float-truncate-1.c  |  1 +
 .../gfortran.dg/vect/fast-math-mgrid-resid.f       |  1 +
 gcc/testsuite/gfortran.dg/vect/pr77848.f           |  3 +-
 gcc/testsuite/lib/target-supports.exp              | 50 +++++++++++++++++++++-
 22 files changed, 76 insertions(+), 7 deletions(-)

-- 
2.9.1

Re: [PATCH 2/5] pr60656.c: New target check: vect_mult_long

[Rainer Orth]

Hi Andreas,

> We don't have a 64 bit vector integer multiply on z.  Add a specific
> check for that.
>
> 2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>
>
> 	* gcc.dg/vect/pr60656.c: Check vect_mult_long.
> 	* lib/target-supports.exp (check_effective_target_vect_mult_long):
> 	New proc.

as usual, this and the other new effective-target keywords need
documenting in sourcebuild.texi.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 2/5] pr60656.c: New target check: vect_mult_long

[Andreas Krebbel]

On 09/26/2017 01:57 PM, Rainer Orth wrote:
> Hi Andreas,
> 
>> We don't have a 64 bit vector integer multiply on z.  Add a specific
>> check for that.
>>
>> 2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>
>>
>> 	* gcc.dg/vect/pr60656.c: Check vect_mult_long.
>> 	* lib/target-supports.exp (check_effective_target_vect_mult_long):
>> 	New proc.
> 
> as usual, this and the other new effective-target keywords need
> documenting in sourcebuild.texi.
> 
> 	Rainer
> 

Ok.

-Andreas-

pr60656.c: New target check: vect_mult_long

We don't have a 64 bit vector integer multiply on z.  Add a specific
check for that.

gcc/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* doc/sourcebuild.texi: Document vect_mult_long.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* gcc.dg/vect/pr60656.c: Check vect_mult_long.
	* lib/target-supports.exp (check_effective_target_vect_mult_long):
	New proc.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 9901c94..307c726 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1467,6 +1467,10 @@ into @code{int} results, or can promote (unpack) from @code{short} to
 Target supports a vector widening multiplication of @code{int} operands
 into @code{long} results.

+@item vect_mult_long
+Target supports a vector multiplication of @code{long} operands into
+@code{long} results.
+
 @item vect_sdot_qi
 Target supports a vector dot-product of @code{signed char}.

diff --git a/gcc/testsuite/gcc.dg/vect/pr60656.c b/gcc/testsuite/gcc.dg/vect/pr60656.c
index d9e30bb..f44269a 100644
--- a/gcc/testsuite/gcc.dg/vect/pr60656.c
+++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
@@ -43,4 +43,5 @@ int main()
   return 0;
 }

-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
vect_widen_mult_si_to_di_pattern } } } */
+/* P * P * P requires a widening multiplication first as well as a longxlong->long after that.  */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
vect_widen_mult_si_to_di_pattern && vect_mult_long } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index b45a19e..7fdfbbb 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5166,6 +5166,30 @@ proc check_effective_target_vect_long { } {
     return $answer
 }

+# Return 1 if the target supports hardware vector multiplication of
+# long operands with a long result, 0 otherwise.
+#
+# This can change for different subtargets so do not cache the result.
+
+proc check_effective_target_vect_mult_long { } {
+    if { [istarget i?86-*-*] || [istarget x86_64-*-*]
+	 || (([istarget powerpc*-*-*]
+              && ![istarget powerpc-*-linux*paired*])
+              && [check_effective_target_ilp32])
+	 || [is-effective-target arm_neon]
+	 || ([istarget sparc*-*-*] && [check_effective_target_ilp32])
+	 || [istarget aarch64*-*-*]
+	 || ([istarget mips*-*-*]
+	      && [et-is-effective-target mips_msa]) } {
+	set answer 1
+    } else {
+	set answer 0
+    }
+
+    verbose "check_effective_target_vect_mult_long: returning $answer" 2
+    return $answer
+}
+
 # Return 1 if the target supports hardware vectors of float, 0 otherwise.
 #
 # This won't change for different subtargets so cache the result.
-- 
2.9.1

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Andreas Krebbel]

- vect_nopeel renamed to vect_no_peel
- documentation added.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* doc/sourcebuild.texi: Document vect_no_peel.

gcc/testsuite/ChangeLog:

2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

	* g++.dg/vect/slp-pr56812.cc: Check vect_nopeel.
	* lib/target-supports.exp (check_effective_target_vect_nopeel):
	New proc.
---
 gcc/doc/sourcebuild.texi                 |  3 +++
 gcc/testsuite/g++.dg/vect/slp-pr56812.cc |  4 +++-
 gcc/testsuite/lib/target-supports.exp    | 22 ++++++++++++++++++++++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 307c726..3acfd85 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
 @item vect_no_align
 Target does not support a vector alignment mechanism.

+@item vect_no_peel
+Target does not require any loop peeling for alignment purposes.
+
 @item vect_no_int_min_max
 Target does not support a vector min and max instruction on @code{int}.

diff --git a/gcc/testsuite/g++.dg/vect/slp-pr56812.cc b/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
index 80bdcdd..3dbaf76 100644
--- a/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
+++ b/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
@@ -17,4 +17,6 @@ void mydata::Set (float x)
     data[i] = x;

 }



-/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" } } */

+/* For targets without vector loop peeling the loop becomes cheap

+   enough to be vectorized.  */

+/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" { target { ! vect_no_peel }
} } } */

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7fdfbbb..31e802d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3199,6 +3199,28 @@ proc check_effective_target_vect_floatuint_cvt { } {
     return $et_vect_floatuint_cvt_saved($et_index)
 }

+# Return 1 if peeling for alignment is never profitable on the target
+#
+
+proc check_effective_target_vect_no_peel { } {
+    global et_vect_no_peel_saved
+    global et_index
+
+    if [info exists et_vect_no_peel_saved($et_index)] {
+	verbose "check_effective_target_vect_no_peel: using cached result" 2
+    } else {
+	set et_vect_no_peel_saved($et_index) 0
+        if { ([istarget s390*-*-*]
+	      && [check_effective_target_s390_vx]) } {
+	    set et_vect_no_peel_saved($et_index) 1
+        }
+    }
+
+    verbose "check_effective_target_vect_no_peel:\
+	     returning $et_vect_no_peel_saved($et_index)" 2
+    return $et_vect_no_peel_saved($et_index)
+}
+
 # Return 1 if the target supports #pragma omp declare simd, 0 otherwise.
 #
 # This won't change for different subtargets so cache the result.
-- 
2.9.1

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Rainer Orth]

Hi Andreas,

> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 307c726..3acfd85 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>  @item vect_no_align
>  Target does not support a vector alignment mechanism.
>
> +@item vect_no_peel
> +Target does not require any loop peeling for alignment purposes.
> +
>  @item vect_no_int_min_max
>  Target does not support a vector min and max instruction on @code{int}.

please keep the items sorted alphabetically.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 3/5] pr65947-9.c: Requires char to be signed by default.

[Richard Biener]

On Tue, Sep 26, 2017 at 1:39 PM, Andreas Krebbel
<krebbel@linux.vnet.ibm.com> wrote:
> Fails on S/390 with char defaulting to unsigned char.

Ok.

> gcc/testsuite/ChangeLog:
>
> 2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>
>
>         * gcc.dg/vect/pr65947-9.c: Use signed char explicitly.
> ---
>  gcc/testsuite/gcc.dg/vect/pr65947-9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/pr65947-9.c b/gcc/testsuite/gcc.dg/vect/pr65947-9.c
> index d769af9..e8f20aa 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr65947-9.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr65947-9.c
> @@ -10,7 +10,7 @@ extern void abort (void) __attribute__ ((noreturn));
>     vectorize because the vectorisation requires a slot for default values.  */
>
>  signed char __attribute__((noinline,noclone))
> -condition_reduction (char *a, char min_v)
> +condition_reduction (signed char *a, signed char min_v)
>  {
>    signed char last = -72;
>
> --
> 2.9.1
>

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Richard Sandiford]

Andreas Krebbel <krebbel@linux.vnet.ibm.com> writes:
> - vect_nopeel renamed to vect_no_peel
> - documentation added.
>
> gcc/testsuite/ChangeLog:
>
> 2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>
>
> 	* doc/sourcebuild.texi: Document vect_no_peel.
>
> gcc/testsuite/ChangeLog:
>
> 2017-09-26  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>
>
> 	* g++.dg/vect/slp-pr56812.cc: Check vect_nopeel.
> 	* lib/target-supports.exp (check_effective_target_vect_nopeel):
> 	New proc.

Sorry for the bikeshedding, but how about having a positive test
like vect_can_peel instead?  ! vect_no... can be hard to read in
complex conditions.  (There's already that problem with existing
vect_no...s.)

> -/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" } } */
>
> +/* For targets without vector loop peeling the loop becomes cheap
>
> +   enough to be vectorized.  */
>
> +/* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp1" { target { ! vect_no_peel }
> } } } */

How about an xfail instead?  Then it'll be noticeable (via an XPASS)
if we fail to vectorise the loop when we should.

Thanks,
Richard

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Andreas Krebbel]

On 09/26/2017 02:26 PM, Rainer Orth wrote:
> Hi Andreas,
> 
>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>> index 307c726..3acfd85 100644
>> --- a/gcc/doc/sourcebuild.texi
>> +++ b/gcc/doc/sourcebuild.texi
>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>  @item vect_no_align
>>  Target does not support a vector alignment mechanism.
>>
>> +@item vect_no_peel
>> +Target does not require any loop peeling for alignment purposes.
>> +
>>  @item vect_no_int_min_max
>>  Target does not support a vector min and max instruction on @code{int}.
> 
> please keep the items sorted alphabetically.

The items do not appear to be sorted alphabetically.

-Andreas-

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Rainer Orth]

Hi Andreas,

> On 09/26/2017 02:26 PM, Rainer Orth wrote:
>> Hi Andreas,
>> 
>>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>>> index 307c726..3acfd85 100644
>>> --- a/gcc/doc/sourcebuild.texi
>>> +++ b/gcc/doc/sourcebuild.texi
>>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>>  @item vect_no_align
>>>  Target does not support a vector alignment mechanism.
>>>
>>> +@item vect_no_peel
>>> +Target does not require any loop peeling for alignment purposes.
>>> +
>>>  @item vect_no_int_min_max
>>>  Target does not support a vector min and max instruction on @code{int}.
>> 
>> please keep the items sorted alphabetically.
>
> The items do not appear to be sorted alphabetically.

they should be.  Your patch makes the ordering even more random.

Patch to fix this preapproved ;-)

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Andreas Krebbel]

On 09/27/2017 10:10 AM, Rainer Orth wrote:
> Hi Andreas,
> 
>> On 09/26/2017 02:26 PM, Rainer Orth wrote:
>>> Hi Andreas,
>>>
>>>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>>>> index 307c726..3acfd85 100644
>>>> --- a/gcc/doc/sourcebuild.texi
>>>> +++ b/gcc/doc/sourcebuild.texi
>>>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>>>  @item vect_no_align
>>>>  Target does not support a vector alignment mechanism.
>>>>
>>>> +@item vect_no_peel
>>>> +Target does not require any loop peeling for alignment purposes.
>>>> +
>>>>  @item vect_no_int_min_max
>>>>  Target does not support a vector min and max instruction on @code{int}.
>>>
>>> please keep the items sorted alphabetically.
>>
>> The items do not appear to be sorted alphabetically.
> 
> they should be.  Your patch makes the ordering even more random.
> 
> Patch to fix this preapproved ;-)
The items rather appear to be arranged by subject. Does it really make sense do pull items like this
apart just to have it in alphabetical order?

@item vect_intfloat_cvt
Target supports conversion from @code{signed int} to @code{float}.

@item vect_uintfloat_cvt
Target supports conversion from @code{unsigned int} to @code{float}.

@item vect_floatint_cvt
Target supports conversion from @code{float} to @code{signed int}.

@item vect_floatuint_cvt
Target supports conversion from @code{float} to @code{unsigned int}.


I've added the no_peel item intentionally to the hw_misalign/no_align block.

-Andreas-

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Rainer Orth]

Hi Andreas,

> On 09/27/2017 10:10 AM, Rainer Orth wrote:
>> Hi Andreas,
>> 
>>> On 09/26/2017 02:26 PM, Rainer Orth wrote:
>>>> Hi Andreas,
>>>>
>>>>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>>>>> index 307c726..3acfd85 100644
>>>>> --- a/gcc/doc/sourcebuild.texi
>>>>> +++ b/gcc/doc/sourcebuild.texi
>>>>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>>>>  @item vect_no_align
>>>>>  Target does not support a vector alignment mechanism.
>>>>>
>>>>> +@item vect_no_peel
>>>>> +Target does not require any loop peeling for alignment purposes.
>>>>> +
>>>>>  @item vect_no_int_min_max
>>>>>  Target does not support a vector min and max instruction on @code{int}.
>>>>
>>>> please keep the items sorted alphabetically.
>>>
>>> The items do not appear to be sorted alphabetically.
>> 
>> they should be.  Your patch makes the ordering even more random.
>> 
>> Patch to fix this preapproved ;-)
> The items rather appear to be arranged by subject. Does it really make
> sense do pull items like this
> apart just to have it in alphabetical order?
>
> @item vect_intfloat_cvt
> Target supports conversion from @code{signed int} to @code{float}.
>
> @item vect_uintfloat_cvt
> Target supports conversion from @code{unsigned int} to @code{float}.
>
> @item vect_floatint_cvt
> Target supports conversion from @code{float} to @code{signed int}.
>
> @item vect_floatuint_cvt
> Target supports conversion from @code{float} to @code{unsigned int}.
>
>
> I've added the no_peel item intentionally to the hw_misalign/no_align block.

granted, there are some attempts at that, but I find it hard to make my
way through that longish list.  The way it is, you have to skip through
the whole list beginning to end.  Texinfo seems to have no subsubsection
which would allow to make the sub-grouping explicit...

Let's hear what Sandra thinks.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Sandra Loosemore]

On 09/27/2017 03:05 AM, Rainer Orth wrote:
> Hi Andreas,
>
>> On 09/27/2017 10:10 AM, Rainer Orth wrote:
>>> Hi Andreas,
>>>
>>>> On 09/26/2017 02:26 PM, Rainer Orth wrote:
>>>>> Hi Andreas,
>>>>>
>>>>>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>>>>>> index 307c726..3acfd85 100644
>>>>>> --- a/gcc/doc/sourcebuild.texi
>>>>>> +++ b/gcc/doc/sourcebuild.texi
>>>>>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>>>>>   @item vect_no_align
>>>>>>   Target does not support a vector alignment mechanism.
>>>>>>
>>>>>> +@item vect_no_peel
>>>>>> +Target does not require any loop peeling for alignment purposes.
>>>>>> +
>>>>>>   @item vect_no_int_min_max
>>>>>>   Target does not support a vector min and max instruction on @code{int}.
>>>>>
>>>>> please keep the items sorted alphabetically.
>>>>
>>>> The items do not appear to be sorted alphabetically.
>>>
>>> they should be.  Your patch makes the ordering even more random.
>>>
>>> Patch to fix this preapproved ;-)
>> The items rather appear to be arranged by subject. Does it really make
>> sense do pull items like this
>> apart just to have it in alphabetical order?
>>
>> @item vect_intfloat_cvt
>> Target supports conversion from @code{signed int} to @code{float}.
>>
>> @item vect_uintfloat_cvt
>> Target supports conversion from @code{unsigned int} to @code{float}.
>>
>> @item vect_floatint_cvt
>> Target supports conversion from @code{float} to @code{signed int}.
>>
>> @item vect_floatuint_cvt
>> Target supports conversion from @code{float} to @code{unsigned int}.
>>
>>
>> I've added the no_peel item intentionally to the hw_misalign/no_align block.
>
> granted, there are some attempts at that, but I find it hard to make my
> way through that longish list.  The way it is, you have to skip through
> the whole list beginning to end.  Texinfo seems to have no subsubsection
> which would allow to make the sub-grouping explicit...
>
> Let's hear what Sandra thinks.

Ummmm.  There is no common convention in the GCC documentation and other 
parts of the manual do deliberately diverge from alphabetization in 
places.  There's a perpetual tension between putting the most 
commonly-needed information first vs grouping things by related concepts 
vs alphabetize vs the tendency of people to insert new items at random 
places in an existing list regardless of how it's previously been 
organized.  :-(

Alphabetical lists are useful when you already know the name of the 
thing you are searching for, but almost everybody reads the 
documentation in a web browser or PDF viewer with a search feature 
nowadays so you can find the term no matter how the list is sorted.  So 
I'd say we shouldn't alphabetize as a matter of policy if there is some 
other organization that makes sense.

In this case, the section is already broken into multiple sublists by 
topic, most of the sublists are fairly short, and where there's some 
discernible sort order within the sublists, it seems to be grouping 
related things together rather than alphabetical.  So I wouldn't insist 
on alphabetizing this particular sublist either.

-Sandra

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Andreas Krebbel]

On 09/26/2017 06:49 PM, Richard Sandiford wrote:
> Andreas Krebbel <krebbel@linux.vnet.ibm.com> writes:
...
> Sorry for the bikeshedding, but how about having a positive test
> like vect_can_peel instead?  ! vect_no... can be hard to read in
> complex conditions.  (There's already that problem with existing
> vect_no...s.)

Done. Updated patch here: https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01867.html

Bye,

-Andreas-

Re: [PATCH 4/5] New target check: vect_nopeel - v2

[Andreas Krebbel]

On 09/27/2017 07:30 PM, Sandra Loosemore wrote:
> On 09/27/2017 03:05 AM, Rainer Orth wrote:
>> Hi Andreas,
>>
>>> On 09/27/2017 10:10 AM, Rainer Orth wrote:
>>>> Hi Andreas,
>>>>
>>>>> On 09/26/2017 02:26 PM, Rainer Orth wrote:
>>>>>> Hi Andreas,
>>>>>>
>>>>>>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>>>>>>> index 307c726..3acfd85 100644
>>>>>>> --- a/gcc/doc/sourcebuild.texi
>>>>>>> +++ b/gcc/doc/sourcebuild.texi
>>>>>>> @@ -1398,6 +1398,9 @@ Target supports a vector misalign access.
>>>>>>>   @item vect_no_align
>>>>>>>   Target does not support a vector alignment mechanism.
>>>>>>>
>>>>>>> +@item vect_no_peel
>>>>>>> +Target does not require any loop peeling for alignment purposes.
>>>>>>> +
>>>>>>>   @item vect_no_int_min_max
>>>>>>>   Target does not support a vector min and max instruction on @code{int}.
>>>>>>
>>>>>> please keep the items sorted alphabetically.
>>>>>
>>>>> The items do not appear to be sorted alphabetically.
>>>>
>>>> they should be.  Your patch makes the ordering even more random.
>>>>
>>>> Patch to fix this preapproved ;-)
>>> The items rather appear to be arranged by subject. Does it really make
>>> sense do pull items like this
>>> apart just to have it in alphabetical order?
>>>
>>> @item vect_intfloat_cvt
>>> Target supports conversion from @code{signed int} to @code{float}.
>>>
>>> @item vect_uintfloat_cvt
>>> Target supports conversion from @code{unsigned int} to @code{float}.
>>>
>>> @item vect_floatint_cvt
>>> Target supports conversion from @code{float} to @code{signed int}.
>>>
>>> @item vect_floatuint_cvt
>>> Target supports conversion from @code{float} to @code{unsigned int}.
>>>
>>>
>>> I've added the no_peel item intentionally to the hw_misalign/no_align block.
>>
>> granted, there are some attempts at that, but I find it hard to make my
>> way through that longish list.  The way it is, you have to skip through
>> the whole list beginning to end.  Texinfo seems to have no subsubsection
>> which would allow to make the sub-grouping explicit...
>>
>> Let's hear what Sandra thinks.
> 
> Ummmm.  There is no common convention in the GCC documentation and other 
> parts of the manual do deliberately diverge from alphabetization in 
> places.  There's a perpetual tension between putting the most 
> commonly-needed information first vs grouping things by related concepts 
> vs alphabetize vs the tendency of people to insert new items at random 
> places in an existing list regardless of how it's previously been 
> organized.  :-(
> 
> Alphabetical lists are useful when you already know the name of the 
> thing you are searching for, but almost everybody reads the 
> documentation in a web browser or PDF viewer with a search feature 
> nowadays so you can find the term no matter how the list is sorted.  So 
> I'd say we shouldn't alphabetize as a matter of policy if there is some 
> other organization that makes sense.
> 
> In this case, the section is already broken into multiple sublists by 
> topic, most of the sublists are fairly short, and where there's some 
> discernible sort order within the sublists, it seems to be grouping 
> related things together rather than alphabetical.  So I wouldn't insist 
> on alphabetizing this particular sublist either.
> 
> -Sandra

Ok thanks for the clarification. I'll try to fit the documentation updates into the existing
structure.  Updated patchset here: https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01862.html

Bye,

-Andreas-