Re: [PATCH] Integration of parallel standard algorithms for c++17

[Thomas Rodgers]

Let's try this patch -



20190311-pstl-integration.patch.bz2
Description: pstl-integration-patch

Jonathan Wakely writes:

> On 31/01/19 21:08 -0800, Thomas Rodgers wrote:
>>Update C++17 parallel algorithms to LLVM/MIT licensed upstream sources
>
> Some lines in bits/c++config.h need to be split before 80 columns
> (with a backslash if the split is in the middle of a preprocessor
> condition obviously).
>
> There are loads of very long lines in the actual PSTL headers too, but
> I think we need to keep them similar to the upstream headers to aid
> merging, so can't gratuitously reformat them. I'm assuming that
> doesn't apply to  since that's our header and any
> changes will need to be manually applied anyway, right?
>
> We'll need to add a copy of the LICENSE.TXT file to our sources, since
> it's referred to by the comments at the top of each PSTL file.
>
> Typo in include/Makefile.am: ${pstl_srcdir}/memoy_impl.h
> (Which will require regenerating include/Makefile.in).
>
> The __cpp_lib_parallel_algorithm macro needs to be (conditionally)
> defined in  as well as  and .
>
> The namespaces par_backend and unseq_backend need to be uglified.
>
> ALL the names in the __pstl::internal namespace need to be uglified:
> brick_any_of
> pattern_any_of
> for_each_n_it_serial
> brick_walk1
> pattern_walk1
> etc.
>
> I see quite a few calls to functions that should probably be qualified
> to prevent ADL, but that can be fixed later (and upstream first):
>
>   return brick_count(...
>   return except_handler([&]() { ...
>
>
> The DejaGnu directives in the pstl tests need to be in this order:
>
> // { dg-options "-std=gnu++17 -ltbb" }
> // { dg-do run { target c++17 } }
> // { dg-require-effective-target tbb-backend }
>
> Currently the dg-require-effective-target comes before the dg-do
> line, so doesn't work. DejaGnu processes the lines in order. When it
> sees the dg-do for target c++17 it overrides the effect of any earlier
> dg-require-effective-target.
>
> I fixed that locally like so:
> find testsuite/20_util/specialized_algorithms/pstl/ 
> testsuite/25_algorithms/pstl/ testsuite/26_numerics/pstl/ -name \*.cc | xargs 
> sed -i '/dg-require-eff/{h;d};/dg-do/{p;x}'
> And now I don't get FAIL results on a system with no TBB installed
> (which is great). I also get no FAIL results on a system with TBB
> installed (also great).
>
>
> There are two copies (with slight differences) of each of the
> uninitialized_xxx tests:
>
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_construct.cc
> |  128 +++
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_copy_move.cc
> |  143 
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_fill_destroy.cc
>  |  103 ++
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc
>|  132 
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc
>|  154 +
> libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc
> |  104 ++
>
> That's all for now, but I'll keep making passes over it, going into
> more detail ...

[PATCH] PR c++/86521 - wrong overload resolution with ref-qualifiers.

[Jason Merrill]

Here we were wrongly treating binding a const lvalue ref to an xvalue as
direct binding, which is wrong under [dcl.init.ref] and [over.match.ref].

Tested x86_64-pc-linux-gnu, applying to trunk.

* call.c (build_user_type_conversion_1): Don't use a conversion to a
reference of the wrong rvalueness for direct binding.
---
 gcc/cp/call.c |  8 +++
 .../20_util/is_constructible/value-2.cc   |  6 --
 gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C  | 21 +++
 gcc/cp/ChangeLog  |  6 ++
 4 files changed, 39 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 98aa5ee89f7..bf48ae2c27a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4039,6 +4039,14 @@ build_user_type_conversion_1 (tree totype, tree expr, 
int flags,
   rettype, totype,
   EXPR_LOCATION (expr));
}
+ else if (TYPE_REF_P (totype) && !ics->rvaluedness_matches_p
+  && TREE_CODE (TREE_TYPE (totype)) != FUNCTION_TYPE)
+   {
+ /* If we are called to convert to a reference type, we are trying
+to find a direct binding per [over.match.ref], so rvaluedness
+must match for non-functions.  */
+ cand->viable = 0;
+   }
  else if (DECL_NONCONVERTING_P (cand->fn)
   && ics->rank > cr_exact)
{
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc 
b/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
index 0fdbab8e2d4..57487df500b 100644
--- a/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
@@ -806,10 +806,12 @@ static_assert(!std::is_constructible>::value, "Error");
 // Binding through reference-compatible type is required to perform
 // direct-initialization as described in [over.match.ref] p. 1 b. 1:
 static_assert(std::is_constructible>::value, "Error");
-static_assert(std::is_constructible>::value,
- "Error");
 static_assert(std::is_constructible>::value, "Error");
 
+// But an xvalue doesn't count for direct binding.
+static_assert(!std::is_constructible>::value,
+ "Error");
+
 // Binding through temporary behaves like copy-initialization,
 // see [dcl.init.ref] p. 5, very last sub-bullet:
 static_assert(!std::is_constructible>::value,
diff --git a/gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C 
b/gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C
new file mode 100644
index 000..42a135dbf44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/overload-conv-3.C
@@ -0,0 +1,21 @@
+// PR c++/86521
+// { dg-do compile { target c++11 } }
+
+template  T&& move (T&);
+
+struct Dest {
+  Dest() = default;
+  Dest( Dest && ) = default;
+  Dest( Dest const & ) = delete;
+};
+
+struct Source {
+  Dest val;
+  operator Dest () && { return move( val ); }
+  operator Dest const & () const & { return val; }
+};
+
+int main() {
+  Source x;
+  Dest d(move(x)); // { dg-error "ambiguous" }
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 8cad038fd1c..33402399886 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-11  Jason Merrill  
+
+   PR c++/86521 - wrong overload resolution with ref-qualifiers.
+   * call.c (build_user_type_conversion_1): Don't use a conversion to a
+   reference of the wrong rvalueness for direct binding.
+
 2019-03-11  Martin Liska  
 
* cvt.c (build_expr_type_conversion): Wrap apostrophes

base-commit: c860979e3e331e884e482ec46928e4113f6a6d71
-- 
2.20.1

PING #2 [PATCH] correct handling of offsets in bounds warnings (PR 89350)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html

On 3/6/19 2:40 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html

(This is marked as a P1 regression.)

On 2/26/19 6:32 PM, Martin Sebor wrote:

Please disregard the original patch and consider the attached
version instead.

On 2/26/19 5:03 PM, Martin Sebor wrote:

The false positive in PR89350 is due to -Wstringop-overflow
trusting that the sizetype offset in POINTER_PLUS_EXPR means
the offset is, in fact, unsigned.  Avoiding the false positive
in the cases when this isn't so is trivial but comes at a cost
of false negatives.  Avoiding those will, I expect, require
enhancing the compute_builtin_object_size() function and that
seems risky at this stage so I would like to defer that until
stage 1.  Except in the instance of memset, the false positives
also aren't too serious because the same problem is also
diagnosed by the -Warray-bounds warning in the wrestrict pass.
Unfortunately, the wrestrict pass only handles copy functions
and not memset.

With that as background, the attached patch avoids
the -Wstringop-overflow false positive by disabling the warning
for offsets whose lower bound is positive and upper bound negative.
To avoid the false negatives for memset the patch lets the wrestrict
pass handle the function (for the bounds checking only).  While
testing this I noticed that the wrestrict pass makes the same
assumption about offsets, so it too is susceptible to similar
false positives.  The rest of the patch corrects this problem
n the wrestrict pass.  Because the pass doesn't depend on
the compute_builtin_object_size() function as much as
-Wstringop-overflow, the fix does not cause false positives (at
least none that I came across).

Tested on x86_64-linux.

Martin

PING [wwwdocs] add gcc 9 changes

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00147.html

On 3/4/19 5:28 PM, Martin Sebor wrote:

Attached is a patch with (mostly) my changes for GCC 9.  To make
things easier to find I grouped related changes together within
the sections I changed.  I put warnings under the same bullet,
built-ins, and attributes.

Martin

[PATCH] avoid assuming strncpy arrays are nul-terminated (PR 89664)

[Martin Sebor]

The -Wstringop-truncation handling for strncpy/stpncpy neglects
to consider that character arrays tracked by the strlen pass
are not necessarily nul-terminated.  It unconditionally adds
one when computing the size of each sequence to account for
the nul.  This leads to false positive warnings when checking
the validity of indices/pointers computed by the built-ins.

The attached patch corrects this by adding one for the nul
only when the character array is known to be nul-terminated.

Since GCC 7 does not issue the warning this is a 8/9 regression
that I would like to fix in both releases.  Is the patch okay
for trunk/gcc-8-branch?

Tested on x86_64-linux.

Martin
PR tree-optimization/89644 - False-positive -Warray-bounds diagnostic on strncpy

gcc/ChangeLog:

	PR tree-optimization/89644
	* tree-ssa-strlen.c (handle_builtin_stxncpy): Consider unterminated
	arrays in determining sequence sizes in strncpy and stpncpy.

gcc/testsuite/ChangeLog:

	PR tree-optimization/89644
	* gcc.dg/Wstringop-truncation-8.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Wstringop-truncation-8.c b/gcc/testsuite/gcc.dg/Wstringop-truncation-8.c
new file mode 100644
index 000..1745da50a37
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wstringop-truncation-8.c
@@ -0,0 +1,94 @@
+/* PR tree-optimization/89644 - False-positive -Warray-bounds diagnostic
+   on strncpy
+   { dg-do compile }
+   { dg-options "-O2 -Wall -ftrack-macro-expansion=0" }  */
+
+#define NONSTR __attribute__ ((nonstring))
+
+typedef __SIZE_TYPE__ size_t;
+
+size_t strlen (const char*);
+extern char* stpncpy (char*, const char*, size_t);
+extern char* strncpy (char*, const char*, size_t);
+
+void sink (char*, ...);
+
+char f0 (char *s)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  if (*s)
+strncpy (a, s, sizeof a);   /* { dg-bogus "\\\[-Warray-bounds" } */
+  return a[0];
+}
+
+void f1 (char *s)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  if (*s)
+strncpy (a, s, sizeof a);   /* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (a);
+}
+
+char f2 (void)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  strncpy (a, b + 1, 5);/* { dg-bogus "\\\[-Warray-bounds" } */
+  return a[0];
+}
+
+void f3 (void)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  strncpy (a, b + 2, 4);/* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (a);
+}
+
+void f4 (NONSTR char *d)
+{
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  strncpy (d, b + 3, 3);/* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (d);
+}
+
+
+char g0 (char *s)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  if (*s)
+stpncpy (a, s, sizeof a);   /* { dg-bogus "\\\[-Warray-bounds" } */
+  return a[0];
+}
+
+void g1 (char *s)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  char *p = 0;
+  if (*s)
+p = stpncpy (a, s, sizeof a);   /* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (a, p);
+}
+
+char g2 (void)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  stpncpy (a, b + 1, 5);/* { dg-bogus "\\\[-Warray-bounds" } */
+  return a[0];
+}
+
+void g3 (void)
+{
+  char a[6] NONSTR = { 1, 2, 3, 4, 5, 6 };
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  char *p = stpncpy (a, b + 2, 4);  /* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (a, p);
+}
+
+void g4 (NONSTR char *d)
+{
+  char b[6] NONSTR = { 6, 5, 4, 3, 2, 1 };
+  char *p = stpncpy (d, b + 3, 3);  /* { dg-bogus "\\\[-Warray-bounds" } */
+  sink (d, p);
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 721832e3f19..1969c728dc7 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -2191,13 +2191,21 @@ handle_builtin_stxncpy (built_in_function, gimple_stmt_iterator *gsi)
   int didx = get_stridx (dst);
   if (strinfo *sidst = didx > 0 ? get_strinfo (didx) : NULL)
 {
-  /* Compute the size of the destination string including the NUL.  */
+  /* Compute the size of the destination string including the nul
+	 if it is known to be nul-terminated.  */
   if (sidst->nonzero_chars)
 	{
-	  tree type = TREE_TYPE (sidst->nonzero_chars);
-	  dstsize = fold_build2 (PLUS_EXPR, type, sidst->nonzero_chars,
- build_int_cst (type, 1));
+	  if (sidst->endptr)
+	{
+	  /* String is known to be nul-terminated.  */
+	  tree type = TREE_TYPE (sidst->nonzero_chars);
+	  dstsize = fold_build2 (PLUS_EXPR, type, sidst->nonzero_chars,
+ build_int_cst (type, 1));
+	}
+	  else
+	dstsize = sidst->nonzero_chars;
 	}
+
   dst = sidst->ptr;
 }
 
@@ -2209,12 +2217,18 @@ handle_builtin_stxncpy (built_in_function, gimple_stmt_iterator *gsi)
 	 over the terminating nul so SISRC->DONT_INVALIDATE must be left
 	 clear.  */
 
-  /* Compute the size of the source string including the NUL.  */
+  /* Compute the size of the source string including the terminating
+	 nul if its known to be nul-terminated.  */
   

[PATCH] i386: Handle REG_EH_REGION note

[H.J. Lu]

When we split:

(insn 18 17 76 2 (set (reg:SF 88 [ _19 ])
(float:SF (mem/c:SI (symbol_ref:DI ("d") [flags 0x2]  ) [1 d+0 S4 A32]))) "x.ii":4:20 170 {*floatsisf2}
 (expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))

to

(insn 94 17 18 2 (set (reg:V4SF 115)
(vec_merge:V4SF (vec_duplicate:V4SF (float:SF (mem/c:SI (symbol_ref:DI 
("d") [flags 0x2]  ) [1 d+0 S4 A32])))
(reg:V4SF 114)
(const_int 1 [0x1]))) "x.ii":4:20 -1
 (nil))
(insn 18 94 76 2 (set (reg:SF 88 [ _19 ])
(subreg:SF (reg:V4SF 115) 0)) "x.ii":4:20 112 {*movsf_internal}
 (expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))

we must copy the REG_EH_REGION note to the first insn.  The REG_EH_REGION
on the second insn will be removed later since it no longer traps.

OK for trunk?


H.J.
---
gcc/

PR target/89650
* config/i386/i386.c (remove_partial_avx_dependency): Handle
REG_EH_REGION note.

gcc/testsuite/

PR target/89650
* g++.target/i386/pr89650.C: New test.
---
 gcc/config/i386/i386.c  |  6 ++
 gcc/testsuite/g++.target/i386/pr89650.C | 19 +++
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/i386/pr89650.C

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 896c6f33d40..b702703074c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2873,6 +2873,12 @@ remove_partial_avx_dependency (void)
  /* Generate an XMM vector SET.  */
  set = gen_rtx_SET (vec, src);
  set_insn = emit_insn_before (set, insn);
+
+ /* Handle REG_EH_REGION note.  */
+ rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
+ if (note)
+   add_reg_note (insn, REG_EH_REGION, XEXP (note, 0));
+
  df_insn_rescan (set_insn);
 
  src = gen_rtx_SUBREG (dest_mode, vec, 0);
diff --git a/gcc/testsuite/g++.target/i386/pr89650.C 
b/gcc/testsuite/g++.target/i386/pr89650.C
new file mode 100644
index 000..4b253cbf467
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr89650.C
@@ -0,0 +1,19 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2 -flive-range-shrinkage -fno-tree-dce -fno-dce 
-fnon-call-exceptions -mavx" }
+
+int d, e;
+struct g {
+  float f;
+  g(float h) : f(h + d) {}
+  ~g() {}
+};
+struct i {
+  int a;
+  int b : 4;
+  int 
+  i(int h) : a(), b(), c(h) {}
+};
+int main() {
+  i j(e);
+  g k[]{1, 2};
+}
-- 
2.20.1

C++ PATCH for c++/89660 - bogus error with -Wredundant-move

[Marek Polacek]

My recent patch caused us to call convert_for_initialization for a std:move's
argument to see if it would have succeeded had the returned expression been
just that argument.

That caused a bogus error in this test, because convert_for_initialization
might cause additional instantiations, and they might fail.  My first
version of the patch fixed this by adding "cp_unevaluated e;", preventing
add_pending_template from adding further instantiations, but I no longer think
that's the best fix, because in this case the argument isn't an id-expression,
and the implicit move wouldn't be performed, so we shouldn't warn.  Thus fixed
by making the maybe_warn_pessimizing_move condition more strict -- that fixes
both the bogus error and the bogus warning.  Specifically, make sure that the
argument is of form "(T &) " and not "(T &) (T *) " or similar.

Also add a test with template-ids.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2019-03-11  Marek Polacek  

PR c++/89660 - bogus error with -Wredundant-move.
* typeck.c (maybe_warn_pessimizing_move): Only accept (T &) 
as the std::move's argument.  Don't call convert_for_initialization
when warn_redundant_move isn't on.

* g++.dg/cpp0x/Wredundant-move8.C: New test.
* g++.dg/cpp0x/Wredundant-move9.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 51f47814acd..f77e9c6180d 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -9409,7 +9409,7 @@ maybe_warn_pessimizing_move (tree retval, tree functype)
   if (!CLASS_TYPE_P (functype))
 return;
 
-  /* We're looking for *std::move ().  */
+  /* We're looking for *std::move ((T &) ).  */
   if (REFERENCE_REF_P (retval)
   && TREE_CODE (TREE_OPERAND (retval, 0)) == CALL_EXPR)
 {
@@ -9417,7 +9417,9 @@ maybe_warn_pessimizing_move (tree retval, tree functype)
   if (is_std_move_p (fn))
{
  tree arg = CALL_EXPR_ARG (fn, 0);
- STRIP_NOPS (arg);
+ if (TREE_CODE (arg) != NOP_EXPR)
+   return;
+ arg = TREE_OPERAND (arg, 0);
  if (TREE_CODE (arg) != ADDR_EXPR)
return;
  arg = TREE_OPERAND (arg, 0);
@@ -9433,7 +9435,8 @@ maybe_warn_pessimizing_move (tree retval, tree functype)
}
  /* Warn if the move is redundant.  It is redundant when we would
 do maybe-rvalue overload resolution even without std::move.  */
- else if (treat_lvalue_as_rvalue_p (arg, /*parm_ok*/true))
+ else if (warn_redundant_move
+  && treat_lvalue_as_rvalue_p (arg, /*parm_ok*/true))
{
  /* Make sure that the overload resolution would actually succeed
 if we removed the std::move call.  */
diff --git gcc/testsuite/g++.dg/cpp0x/Wredundant-move8.C 
gcc/testsuite/g++.dg/cpp0x/Wredundant-move8.C
new file mode 100644
index 000..c290585b18b
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/Wredundant-move8.C
@@ -0,0 +1,38 @@
+// PR c++/89660
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wredundant-move" }
+
+// Define std::move.
+namespace std {
+  template
+struct remove_reference
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&>
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&&>
+{ typedef _Tp   type; };
+
+  template
+constexpr typename std::remove_reference<_Tp>::type&&
+move(_Tp&& __t) noexcept
+{ return static_cast::type&&>(__t); }
+}
+
+template  struct D {
+  template  D (D x) : k( ()) {}
+  S  ();
+  int *k;
+};
+
+D bar ();
+
+struct F {
+  D baz () {
+D f = bar ();
+return std::move (*reinterpret_cast *> ()); // { dg-bogus 
"redundant move in return statement" }
+  }
+};
diff --git gcc/testsuite/g++.dg/cpp0x/Wredundant-move9.C 
gcc/testsuite/g++.dg/cpp0x/Wredundant-move9.C
new file mode 100644
index 000..fdd3ce16092
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/Wredundant-move9.C
@@ -0,0 +1,108 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wredundant-move" }
+
+// Define std::move.
+namespace std {
+  template
+struct remove_reference
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&>
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&&>
+{ typedef _Tp   type; };
+
+  template
+constexpr typename std::remove_reference<_Tp>::type&&
+move(_Tp&& __t) noexcept
+{ return static_cast::type&&>(__t); }
+}
+
+template
+struct T {
+  T() { }
+  T(const T&) { }
+  T(T&&) { }
+};
+
+template
+struct U {
+  U() { }
+  U(const U&) { }
+  U(U&&) { }
+  U(T) { }
+};
+
+T
+fn1 (T t)
+{
+  return t;
+}
+
+T
+fn2 (T t)
+{
+  // Will use move even without std::move.
+  return std::move (t); // { dg-warning "redundant move in return statement" }
+}
+
+T
+fn3 (const T t)
+{
+  // t is const: will decay into copy.
+  return t;
+}
+
+T
+fn4 (const T t)
+{
+  // t is const: will decay into copy despite std::move, so it's redundant.
+  

RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

[Steve Ellcey]

This is a proposed GCC patch that allows targets to modify the names of
the libmvec routines that get called.  Currently, if you build ToT GCC
on Aarch64 and include this glibc patch:

https://sourceware.org/ml/libc-alpha/2019-03/msg00106.html

And then compile a call to expf which gets vectorized, GCC will
generate a libmvec call to '_ZGVnN4v___expf_finite' instead of
_ZGVnN4v_expf because the limvec name is based on the assembly name
of the scalar function (__expf_finite) and not the 'real' name (expf).
This means that libmvec needs to provide both names, even though the
routines don't differ.

Rather than create both names I would like to make it possible for
GCC to generate calls to libmvec based on the real name by having
a target specific function that allows GCC to use the DECL_NAME instead
of DECL_ASSEMBLER_NAME to create the libmvec name.

The responses to my glibc patch (referenced above) has a pointer
to where this was discussed in the GCC mailing list a couple of years
ago:

https://gcc.gnu.org/ml/gcc/2015-06/msg00173.html

and which has a pointer back to an older glibc string as well:

https://sourceware.org/ml/libc-alpha/2015-06/msg00213.html

Any thoughts on this patch as a way of 'fixing' GCC to not use the
finite alias names?

Steve Ellcey
sell...@marvell.com


2018-03-11  Steve Ellcey  

* config/aarch64/aarch64.c (aarch64_simd_clone_vec_base_name):
New function.
(TARGET_SIMD_CLONE_VEC_BASE_NAME): New macro.
* doc/tm.texi.in (TARGET_SIMD_CLONE_VEC_BASE_NAME): New hook.
* doc/tm.texi: Regenerate.
* omp-simd-clone.c (simd_clone_mangle): Call vec_base_name hook.
* target.def (vec_base_name): New hook.
* targhooks.c (cgraph.h): New include.
(default_vec_base_name): New function.
* targhooks.h (default_vec_base_name): New function declaration.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 252bed7..cddab80 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18711,6 +18711,14 @@ aarch64_simd_clone_usable (struct cgraph_node *node)
 }
 }
 
+/* Implement TARGET_SIMD_CLONE_VEC_BASE_NAME */
+
+static const char *
+aarch64_simd_clone_vec_base_name (struct cgraph_node *node)
+{
+  return IDENTIFIER_POINTER (DECL_NAME (node->decl));
+}
+
 /* Implement TARGET_COMP_TYPE_ATTRIBUTES */
 
 static int
@@ -19251,6 +19259,9 @@ aarch64_libgcc_floating_mode_supported_p
 #undef TARGET_SIMD_CLONE_USABLE
 #define TARGET_SIMD_CLONE_USABLE aarch64_simd_clone_usable
 
+#undef TARGET_SIMD_CLONE_VEC_BASE_NAME
+#define TARGET_SIMD_CLONE_VEC_BASE_NAME aarch64_simd_clone_vec_base_name
+
 #undef TARGET_COMP_TYPE_ATTRIBUTES
 #define TARGET_COMP_TYPE_ATTRIBUTES aarch64_comp_type_attributes
 
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index fe1194e..de4bdb42 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4196,6 +4196,8 @@ address;  but often a machine-dependent strategy can generate better code.
 
 @hook TARGET_SIMD_CLONE_USABLE
 
+@hook TARGET_SIMD_CLONE_VEC_BASE_NAME
+
 @hook TARGET_SIMT_VF
 
 @hook TARGET_GOACC_VALIDATE_DIMS
diff --git a/gcc/omp-simd-clone.c b/gcc/omp-simd-clone.c
index 388198b..b3a57aa 100644
--- a/gcc/omp-simd-clone.c
+++ b/gcc/omp-simd-clone.c
@@ -409,7 +409,7 @@ simd_clone_mangle (struct cgraph_node *node,
 }
 
   pp_underscore ();
-  const char *str = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl));
+  const char *str = targetm.simd_clone.vec_base_name (node);
   if (*str == '*')
 ++str;
   pp_string (, str);
diff --git a/gcc/target.def b/gcc/target.def
index 66cee07..da60249 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1655,6 +1655,13 @@ usable.  In that case, the smaller the number is, the more desirable it is\n\
 to use it.",
 int, (struct cgraph_node *), NULL)
 
+DEFHOOK
+(vec_base_name,
+"This hook should return the name of the scalar function being cloned.\n\
+This defaults to DECL_ASSEMBLER_NAME, but targets could use DECL_NAME\n\
+instead or some other variation of the function name.",
+const char *, (struct cgraph_node *), default_vec_base_name)
+
 HOOK_VECTOR_END (simd_clone)
 
 /* Functions relating to OpenMP SIMT vectorization transform.  */
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 318f7e9..6792ee5 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -83,6 +83,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "real.h"
 #include "langhooks.h"
 #include "sbitmap.h"
+#include "cgraph.h"
 
 bool
 default_legitimate_address_p (machine_mode mode ATTRIBUTE_UNUSED,
@@ -2379,4 +2380,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *)
 {
 }
 
+const char *
+default_vec_base_name (struct cgraph_node * node)
+{
+  return IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl));
+}
+
 #include "gt-targhooks.h"
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index 5943627..85dce1a 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -286,5 +286,6 @@ extern 

Re: [patch, fortran] Fix PR 87673, rejects-valid

[Steve Kargl]

On Sun, Mar 10, 2019 at 10:36:48PM +0100, Thomas Koenig wrote:
> Am 10.03.19 um 22:12 schrieb Thomas Koenig:
> 
> > You're probably right, I will fix this.  Ugh...
> 
> OK, so here is the updated test case, without the copyright stuff.
> 
> OK for trunk now? :-)
> 

Yes.  Thanks for patch.

-- 
Steve

Re: [Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[Steve Kargl]

On Mon, Mar 11, 2019 at 10:09:02PM +0100, Janus Weil wrote:
> 
> Technically the ICE is a regression, but since it happens on invalid
> code only, backporting is not essential IMHO (but might still be
> useful). Ok for trunk? And 8-branch?

Looks good to me with a minor suggestion.  See below.
You may want to wait a bit or ping Paul to give him
a chance to peek at the patch.

>if (gfc_match_char (')') == MATCH_YES)
> -goto ok;
> +  {
> +if (typeparam)
> +  {
> + gfc_error_now ("A parameter name is required at %C");

Can you insert "type" so the error reads "A type parameter name"?
Unfortunately, the words parameter has a few too many meanings.

-- 
Steve

[PATCH] Fix ICE with invalid lround etc. builtin calls (PR middle-end/89663)

[Jakub Jelinek]

Hi!

All other expand_builtin* calls in builtins.c return NULL or return
const0_rtx or return without ICEing when arg validation fails, but these
two and as the testcases show, it can happen on invalid (at runtime)
testcases.  Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2019-03-11  Jakub Jelinek  

PR middle-end/89663
* builtins.c (expand_builtin_int_roundingfn,
expand_builtin_int_roundingfn_2): Return NULL_RTX instead of
gcc_unreachable if validate_arglist fails.

* gcc.c-torture/compile/pr89663-1.c: New test.
* gcc.c-torture/compile/pr89663-2.c: New test.

--- gcc/builtins.c.jj   2019-03-08 11:45:27.547465385 +0100
+++ gcc/builtins.c  2019-03-11 20:33:43.990536154 +0100
@@ -2692,7 +2692,7 @@ expand_builtin_int_roundingfn (tree exp,
   tree arg;
 
   if (!validate_arglist (exp, REAL_TYPE, VOID_TYPE))
-gcc_unreachable ();
+return NULL_RTX;
 
   arg = CALL_EXPR_ARG (exp, 0);
 
@@ -2828,7 +2828,7 @@ expand_builtin_int_roundingfn_2 (tree ex
   enum built_in_function fallback_fn = BUILT_IN_NONE;
 
   if (!validate_arglist (exp, REAL_TYPE, VOID_TYPE))
- gcc_unreachable ();
+return NULL_RTX;
 
   arg = CALL_EXPR_ARG (exp, 0);
 
--- gcc/testsuite/gcc.c-torture/compile/pr89663-1.c.jj  2019-03-11 
20:52:42.205972807 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr89663-1.c 2019-03-11 
20:52:11.839469897 +0100
@@ -0,0 +1,81 @@
+/* PR middle-end/89663 */
+
+int irint ();
+long lrint ();
+long long llrint ();
+int iround ();
+long lround ();
+long long llround ();
+int iceil ();
+long lceil ();
+long long llceil ();
+int ifloor ();
+long lfloor ();
+long long llfloor ();
+int irintf ();
+long lrintf ();
+long long llrintf ();
+int iroundf ();
+long lroundf ();
+long long llroundf ();
+int iceilf ();
+long lceilf ();
+long long llceilf ();
+int ifloorf ();
+long lfloorf ();
+long long llfloorf ();
+int irintl ();
+long lrintl ();
+long long llrintl ();
+int iroundl ();
+long lroundl ();
+long long llroundl ();
+int iceill ();
+long lceill ();
+long long llceill ();
+int ifloorl ();
+long lfloorl ();
+long long llfloorl ();
+
+void
+foo (long long *p)
+{
+  int n = 0;
+#define T(f) p[n++] = f (1);
+  T (irint)
+  T (lrint)
+  T (llrint)
+  T (iround)
+  T (lround)
+  T (llround)
+  T (iceil)
+  T (lceil)
+  T (llceil)
+  T (ifloor)
+  T (lfloor)
+  T (llfloor)
+  T (irintf)
+  T (lrintf)
+  T (llrintf)
+  T (iroundf)
+  T (lroundf)
+  T (llroundf)
+  T (iceilf)
+  T (lceilf)
+  T (llceilf)
+  T (ifloorf)
+  T (lfloorf)
+  T (llfloorf)
+  T (irintl)
+  T (lrintl)
+  T (llrintl)
+  T (iroundl)
+  T (lroundl)
+  T (llroundl)
+  T (iceill)
+  T (lceill)
+  T (llceill)
+  T (ifloorl)
+  T (lfloorl)
+  T (llfloorl)
+}
--- gcc/testsuite/gcc.c-torture/compile/pr89663-2.c.jj  2019-03-11 
20:52:45.262922766 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr89663-2.c 2019-03-11 
20:51:26.556211180 +0100
@@ -0,0 +1,82 @@
+/* PR middle-end/89663 */
+
+int irint (double);
+long lrint (double);
+long long llrint (double);
+int iround (double);
+long lround (double);
+long long llround (double);
+int iceil (double);
+long lceil (double);
+long long llceil (double);
+int ifloor (double);
+long lfloor (double);
+long long llfloor (double);
+int irintf (float);
+long lrintf (float);
+long long llrintf (float);
+int iroundf (float);
+long lroundf (float);
+long long llroundf (float);
+int iceilf (float);
+long lceilf (float);
+long long llceilf (float);
+int ifloorf (float);
+long lfloorf (float);
+long long llfloorf (float);
+int irintl (long double);
+long lrintl (long double);
+long long llrintl (long double);
+int iroundl (long double);
+long lroundl (long double);
+long long llroundl (long double);
+int iceill (long double);
+long lceill (long double);
+long long llceill (long double);
+int ifloorl (long double);
+long lfloorl (long double);
+long long llfloorl (long double);
+
+void
+foo (long long *p)
+{
+  int (*fn) (int);
+  int n = 0;
+#define T(f) fn = (int (*) (int)) f; p[n++] = fn (1);
+  T (irint)
+  T (lrint)
+  T (llrint)
+  T (iround)
+  T (lround)
+  T (llround)
+  T (iceil)
+  T (lceil)
+  T (llceil)
+  T (ifloor)
+  T (lfloor)
+  T (llfloor)
+  T (irintf)
+  T (lrintf)
+  T (llrintf)
+  T (iroundf)
+  T (lroundf)
+  T (llroundf)
+  T (iceilf)
+  T (lceilf)
+  T (llceilf)
+  T (ifloorf)
+  T (lfloorf)
+  T (llfloorf)
+  T (irintl)
+  T (lrintl)
+  T (llrintl)
+  T (iroundl)
+  T (lroundl)
+  T (llroundl)
+  T (iceill)
+  T (lceill)
+  T (llceill)
+  T (ifloorl)
+  T (lfloorl)
+  T (llfloorl)
+}

Jakub

[committed] Avoid -W*ununitialized warnings with OpenMP privatized allocatables (PR fortran/89651)

[Jakub Jelinek]

Hi!

As mentioned in the PR, for the case where the allocatable being privatized
is "not currently allocated", we only clear the data pointer and in code
where the user guarantees in the caller that the original variable is always
allocated, this can result in false positive -Wmaybe-uninitialized warnings.

Worked around following way, bootstrapped/regtested on x86_64-linux and
i686-linux, committed to trunk.

2019-03-11  Jakub Jelinek  

PR fortran/89651
* trans-openmp.c (gfc_omp_clause_default_ctor): Set TREE_NO_WARNING
on decl if adding COND_EXPR for allocatable.
(gfc_omp_clause_copy_ctor): Set TREE_NO_WARNING on dest.

* gfortran.dg/gomp/pr89651.f90: New test.

--- gcc/fortran/trans-openmp.c.jj   2019-01-16 09:35:08.633255760 +0100
+++ gcc/fortran/trans-openmp.c  2019-03-11 18:09:32.297245296 +0100
@@ -558,6 +558,9 @@ gfc_omp_clause_default_ctor (tree clause
 build3_loc (input_location, COND_EXPR,
 void_type_node, cond, then_b,
 else_b));
+  /* Avoid -W*uninitialized warnings.  */
+  if (DECL_P (decl))
+   TREE_NO_WARNING (decl) = 1;
 }
   else
 gfc_add_expr_to_block (, then_b);
@@ -664,6 +667,9 @@ gfc_omp_clause_copy_ctor (tree clause, t
   gfc_add_expr_to_block (,
 build3_loc (input_location, COND_EXPR,
 void_type_node, cond, then_b, else_b));
+  /* Avoid -W*uninitialized warnings.  */
+  if (DECL_P (dest))
+TREE_NO_WARNING (dest) = 1;
 
   return gfc_finish_block ();
 }
--- gcc/testsuite/gfortran.dg/gomp/pr89651.f90.jj   2019-03-11 
18:05:37.740066305 +0100
+++ gcc/testsuite/gfortran.dg/gomp/pr89651.f90  2019-03-11 18:07:06.813615269 
+0100
@@ -0,0 +1,21 @@
+! PR fortran/89651
+! { dg-do compile }
+! { dg-additional-options "-Wuninitialized" }
+
+program pr89651
+  integer :: n
+  real, allocatable :: t(:)
+  n = 10
+  allocate (t(n), source = 0.0)
+!$omp parallel firstprivate(t)
+  print *, sum (t) ! { dg-bogus "lbound' may be used uninitialized in this 
function" }
+   ! { dg-bogus "ubound' may be used uninitialized in this 
function" "" { target *-*-* } .-1 }
+   ! { dg-bogus "offset' may be used uninitialized in this 
function" "" { target *-*-* } .-2 }
+!$omp end parallel
+!$omp parallel private(t)
+  t = 0.0
+  print *, sum (t) ! { dg-bogus "lbound' may be used uninitialized in this 
function" }
+   ! { dg-bogus "ubound' may be used uninitialized in this 
function" "" { target *-*-* } .-1 }
+   ! { dg-bogus "offset' may be used uninitialized in this 
function" "" { target *-*-* } .-2 }
+!$omp end parallel
+end program pr89651

Jakub

[C++ PATCH] Fix cxx_eval_loop_expr ICE (PR c++/89652)

[Jakub Jelinek]

Hi!

The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
iteration, we can also do the loop at the end of function (which has been
added there mainly to handle cases where the main loop breaks earlier)
and new_ctx.values->remove ICEs because *iter is already not in the table.

While I could e.g. add some bool whether there is anything to be removed
after the loop or not which would fix the regression part of this PR,
I believe there is a latent issue as well.  The thing is, new_ctx.save_exprs
is a hash_set, which the cxx_eval_* calls add SAVE_EXPRs to whenever they
encounter new ones, but if we don't encounter all the previously seen
SAVE_EXPRs in every iteration (e.g. some are wrapped by IF_STMT or
similar and the condition differs between iterations), I believe we can
still ICE, trying to remove a SAVE_EXPR that has been encountered by some
earlier iteration, but not the current one.

The following patch is one possible fix, only remove from new_ctx.values
what is still in there.  Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?  Or some variant mentioned below?

Another possibility would be to save_exprs.empty (); after this
/* Forget saved values of SAVE_EXPRs.  */ loop inside of main loop (no need
to do it at the end of function when we'll just destroy it anyway), the
advantage would be that we don't really walk over SAVE_EXPRs that weren't
saved in the current iteration, disadvantage is that we need to populate the
hash_set again and again each iteration.

Yet another possibility might be to turn save_exprs into a vec, from what
I understand, we do:
case SAVE_EXPR:
  /* Avoid evaluating a SAVE_EXPR more than once.  */
  if (tree *p = ctx->values->get (t))
r = *p;
  else
{
  r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 0), false,
non_constant_p, overflow_p);
  ctx->values->put (t, r);
  if (ctx->save_exprs)
ctx->save_exprs->add (t);
}
and thus shouldn't be adding duplicates to save_expr and if we flush it
every iteration, we could just if (ctx->save_exprs) ctx->save_exprs->safe_push 
(t);
and truncate the vector after every /* Forget saved values of SAVE_EXPRs.  */
loop in the main loop's body.  Thoughts on this?

2019-03-11  Jakub Jelinek  

PR c++/89652
* constexpr.c (cxx_eval_loop_expr): Only remove SAVE_EXPRs that are
still in new_ctx.values hash_map.

* g++.dg/cpp1y/constexpr-89652.C: New test.

--- gcc/cp/constexpr.c.jj   2019-03-08 08:43:23.529496048 +0100
+++ gcc/cp/constexpr.c  2019-03-11 15:11:32.081334270 +0100
@@ -4236,7 +4236,8 @@ cxx_eval_loop_expr (const constexpr_ctx
   /* Forget saved values of SAVE_EXPRs.  */
   for (hash_set::iterator iter = save_exprs.begin();
   iter != save_exprs.end(); ++iter)
-   new_ctx.values->remove (*iter);
+   if (new_ctx.values->get (*iter))
+ new_ctx.values->remove (*iter);
 
   if (++count >= constexpr_loop_limit)
{
@@ -4258,7 +4259,8 @@ cxx_eval_loop_expr (const constexpr_ctx
   /* Forget saved values of SAVE_EXPRs.  */
   for (hash_set::iterator iter = save_exprs.begin();
iter != save_exprs.end(); ++iter)
-new_ctx.values->remove (*iter);
+if (new_ctx.values->get (*iter))
+  new_ctx.values->remove (*iter);
 
   return NULL_TREE;
 }
--- gcc/testsuite/g++.dg/cpp1y/constexpr-89652.C.jj 2019-03-11 
15:14:21.877561575 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-89652.C2019-03-11 
15:16:11.962763933 +0100
@@ -0,0 +1,36 @@
+// PR c++/89652
+// { dg-do compile { target c++14 } }
+// { dg-options "" }
+
+template  constexpr auto foo (T ) { return e.foo (); }
+template  constexpr auto bar (T ) { return foo (e); }
+template  struct A { typedef T a[N]; };
+template  struct B {
+  typedef T *b;
+  typename A::a d;
+  constexpr b foo () { return d; }
+};
+template  struct C { long m; };
+struct D { long n; };
+template  struct E {
+  B, 1>::b p;
+  constexpr D operator* () { return {p->m}; }
+  constexpr E operator++ (int) { auto a{*this}; ++p; return a; }
+};
+template 
+constexpr bool operator!= (E a, E) { return a.p; }
+template 
+constexpr auto baz (B s, B)
+{
+  B t{};
+  auto q{foo (t)};
+  using u = E;
+  auto v = u{bar (s)};
+  auto w = u{};
+  while (v != w)
+*q++ = *v++;
+  return t;
+}
+constexpr auto a = B, 5>{};
+auto b = B{};
+auto c = baz (a, b);

Jakub

[committed] Fix aarch64 profiledbootstrap (PR middle-end/89655, PR bootstrap/89656)

[Jakub Jelinek]

Hi!

As mentioned in the PR, since r269453 dom can process stmts newly added
by fold_stmt.  The problem is that at the start of the pass we construct
vr_values with the current number of SSA names and size the tables based on
that.  When we process a stmt which sets on lhs a new SSA_NAME above that
number, get_value_range returns for that address of a shared constant VR_VARYING
variable, but if we manage to find some smaller range, update_value_range
happily updates that shared range to this.

Based on IRC discussion, this is a minimal fix, approved by Richard on IRC.

Bootstrapped/regtested on {x86_64,i686,powerpc64le}-linux and bootstrapped
on {aarch64,s390x}-linux (profiledbootstrap for all; where aarch64-linux
profiledbootstrap would previously fail), committed to trunk.

2019-03-11  Jakub Jelinek  

PR middle-end/89655
PR bootstrap/89656
* vr-values.c (vr_values::update_value_range): If
old_vr->varying_p (), don't update it, make new_vr also VARYING
and return false.

* gcc.c-torture/compile/pr89655.c: New test.

--- gcc/vr-values.c.jj  2019-01-24 19:54:20.792500923 +0100
+++ gcc/vr-values.c 2019-03-11 12:46:34.526494064 +0100
@@ -189,8 +189,13 @@ vr_values::update_value_range (const_tre
 because VR_RANGE and VR_ANTI_RANGE need to be considered
 the same.  We may not have is_new when transitioning to
 UNDEFINED.  If old_vr->type is VARYING, we shouldn't be
-called.  */
-  if (new_vr->undefined_p ())
+called, if we are anyway, keep it VARYING.  */
+  if (old_vr->varying_p ())
+   {
+ new_vr->set_varying ();
+ is_new = false;
+   }
+  else if (new_vr->undefined_p ())
{
  old_vr->set_varying ();
  new_vr->set_varying ();
--- gcc/testsuite/gcc.c-torture/compile/pr89655.c.jj2019-03-11 
13:45:27.279823237 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr89655.c   2019-03-11 
13:45:10.482097642 +0100
@@ -0,0 +1,15 @@
+/* PR middle-end/89655 */
+
+int a, b, d;
+char *c;
+
+void
+foo (void)
+{
+  int f = a;
+  for (;;)
+{
+  for (f = 0; f < (a > 3 ? : a); f++)
+   b = c[f] ? c[(f + 2 > a - 1 ? a - 1 : 2) * d] : 0;
+}
+}

Jakub

[Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[Janus Weil]

Hi all,

the attached patch fixes an ICE-on-invalid problem with parametrized
derived types, more precisely a PDT without any parameters, and
regtests cleanly x86_64-linux-gnu. For the relevant standard quote,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601#c4.

Technically the ICE is a regression, but since it happens on invalid
code only, backporting is not essential IMHO (but might still be
useful). Ok for trunk? And 8-branch?

Cheers,
Janus
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 1c738baedaa..5733bf2ac82 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,10 @@
+2019-03-11  Janus Weil  
+
+	PR fortran/89601
+	* decl.c (gfc_match_formal_arglist): Reject empty type parameter lists.
+	(gfc_match_derived_decl): Mark as PDT only if type parameter list was
+	matched successfully.
+
 2019-03-11  Martin Liska  
 
 	* decl.c (match_record_decl): Wrap an option name
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index a29e2db0bd6..39ec413a953 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6275,7 +6275,16 @@ gfc_match_formal_arglist (gfc_symbol *progname, int st_flag,
 }
 
   if (gfc_match_char (')') == MATCH_YES)
-goto ok;
+  {
+if (typeparam)
+  {
+	gfc_error_now ("A parameter name is required at %C");
+	m = MATCH_ERROR;
+	goto cleanup;
+  }
+else
+  goto ok;
+  }
 
   for (;;)
 {
@@ -10217,13 +10226,14 @@ gfc_match_derived_decl (void)
   m = gfc_match_formal_arglist (sym, 0, 0, true);
   if (m != MATCH_YES)
 	gfc_error_recovery ();
+  else
+	sym->attr.pdt_template = 1;
   m = gfc_match_eos ();
   if (m != MATCH_YES)
 	{
 	  gfc_error_recovery ();
 	  gfc_error_now ("Garbage after PARAMETERIZED TYPE declaration at %C");
 	}
-  sym->attr.pdt_template = 1;
 }
 
   if (extended && !sym->components)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index aec924f27aa..a571002772c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2019-03-11  Janus Weil  
+
+	PR fortran/89601
+	* gfortran.dg/pdt_16.f03: Modified to avoid follow-up errors.
+	* gfortran.dg/pdt_30.f90: New test case.
+
 2019-03-11  Martin Liska  
 
 	* g++.dg/conversion/simd3.C (foo): Wrap option names
diff --git a/gcc/testsuite/gfortran.dg/pdt_16.f03 b/gcc/testsuite/gfortran.dg/pdt_16.f03
index 067d87d660d..22c6b83a084 100644
--- a/gcc/testsuite/gfortran.dg/pdt_16.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_16.f03
@@ -12,7 +12,6 @@ end
 program p
type t(a  ! { dg-error "Expected parameter list" }
   integer, kind :: a
-  real(a) :: x
end type
type u(a, a)  ! { dg-error "Duplicate name" }
   integer, kind :: a ! { dg-error "already declared" }
diff --git a/gcc/testsuite/gfortran.dg/pdt_30.f90 b/gcc/testsuite/gfortran.dg/pdt_30.f90
new file mode 100644
index 000..d07b52f6fab
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pdt_30.f90
@@ -0,0 +1,17 @@
+! { dg-do compile }
+!
+! PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
+!
+! Contributed by Arseny Solokha 
+
+program vw
+  interface
+ real function ul (ki)
+   real :: ki
+ end function ul
+  end interface
+  type :: q8 ()  ! { dg-error "A parameter name is required" }
+ procedure (ul), pointer, nopass :: pj
+  end type q8
+  type (q8) :: ki
+end program vw

Re: [GCC, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Ramana Radhakrishnan]

Nope, just do it after testing it and adjust with Christophes follow up

R

On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists), <
andre.simoesdiasvie...@arm.com> wrote:

> Hi,
>
> Any objections to me backporting this to GCC 8 and 7?
>
> Cheers,
> Andre
>
> On 08/03/2019 17:30, Andre Vieira (lists) wrote:
> > Hi,
> >
> > vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
> > that do not support double precision.  This patch fixes that.
> >
> > Regression tested for arm-none-eabi.
> >
> > Committed in r269499.
> >
> > Cheers,
> > Andre
> >
> > gcc/ChangeLog:
> > 2019-03-08  Andre Vieira  
> >
> >  * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add
> TARGET_VFP_DOUBLE
> >  requirement.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2019-03-08  Andre Vieira  
> >
> >  * gcc.target/arm/f16_f64_conv_no_dp.c: New test.
>

Re: [GCC, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Ramana Radhakrishnan]

Ok.

Ramana

On Mon, 11 Mar 2019, 20:24 Christophe Lyon, 
wrote:

> On Mon, 11 Mar 2019 at 12:34, Richard Biener  wrote:
> >
> > On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
> >
> > > Hi,
> > >
> > > Any objections to me backporting this to GCC 8 and 7?
> >
> > No, go ahead (after proper testing).
> >
>
> Hi,
>
> I've noticed that this new test fails on arm-none-linux-gnueabi
> --with-mode thumb
> --with-cpu cortex-a9
> --with-fpu default
>
>  and with Dejagnu flags: -march=armv5t
>
> (because the test forces float-abi=hard on a target that generates
> thumb-1 by default, which isn't supported.
>
> The attached patch fixes this by adding arm_fp16_ok effective target.
> OK?
>
>
> Christophe
>
>
> > Richard.
> >
> > > Cheers,
> > > Andre
> > >
> > > On 08/03/2019 17:30, Andre Vieira (lists) wrote:
> > > > Hi,
> > > >
> > > > vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for
> FPUs that
> > > > do not support double precision.  This patch fixes that.
> > > >
> > > > Regression tested for arm-none-eabi.
> > > >
> > > > Committed in r269499.
> > > >
> > > > Cheers,
> > > > Andre
> > > >
> > > > gcc/ChangeLog:
> > > > 2019-03-08  Andre Vieira  
> > > >
> > > >  * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add
> TARGET_VFP_DOUBLE
> > > >  requirement.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > 2019-03-08  Andre Vieira  
> > > >
> > > >  * gcc.target/arm/f16_f64_conv_no_dp.c: New test.
> > >
> >
> > --
> > Richard Biener 
> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nuernberg)
>

libbacktrace patch committed: Only run ztest if HAVE_ELF

[Ian Lance Taylor]

This libbacktrace patch only runs the two ztest tests if HAVE_ELF is
true, since we only do uncompression on ELF.  This should fix PR
89699.  Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian


2019-03-11  Ian Lance Taylor  

PR libbacktrace/89669
* Makefile.am (BUILDTESTS): Only add ztest and ztest_alloc if
HAVE_ELF.
* Makefile.in: Regenerate.
Index: Makefile.am
===
--- Makefile.am (revision 269593)
+++ Makefile.am (working copy)
@@ -272,6 +272,8 @@ stest_alloc_LDADD = libbacktrace_alloc.l
 
 BUILDTESTS += stest_alloc
 
+if HAVE_ELF
+
 ztest_SOURCES = ztest.c testlib.c
 ztest_CFLAGS = -DSRCDIR=\"$(srcdir)\"
 ztest_LDADD = libbacktrace.la
@@ -291,6 +293,8 @@ ztest_alloc_CFLAGS = $(ztest_CFLAGS)
 
 BUILDTESTS += ztest_alloc
 
+endif HAVE_ELF
+
 edtest_SOURCES = edtest.c edtest2_build.c testlib.c
 edtest_LDADD = libbacktrace.la
 

Re: [GCC, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Christophe Lyon]

On Mon, 11 Mar 2019 at 12:34, Richard Biener  wrote:
>
> On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
>
> > Hi,
> >
> > Any objections to me backporting this to GCC 8 and 7?
>
> No, go ahead (after proper testing).
>

Hi,

I've noticed that this new test fails on arm-none-linux-gnueabi
--with-mode thumb
--with-cpu cortex-a9
--with-fpu default

 and with Dejagnu flags: -march=armv5t

(because the test forces float-abi=hard on a target that generates
thumb-1 by default, which isn't supported.

The attached patch fixes this by adding arm_fp16_ok effective target.
OK?

Christophe


> Richard.
>
> > Cheers,
> > Andre
> >
> > On 08/03/2019 17:30, Andre Vieira (lists) wrote:
> > > Hi,
> > >
> > > vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs 
> > > that
> > > do not support double precision.  This patch fixes that.
> > >
> > > Regression tested for arm-none-eabi.
> > >
> > > Committed in r269499.
> > >
> > > Cheers,
> > > Andre
> > >
> > > gcc/ChangeLog:
> > > 2019-03-08  Andre Vieira  
> > >
> > >  * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add TARGET_VFP_DOUBLE
> > >  requirement.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > 2019-03-08  Andre Vieira  
> > >
> > >  * gcc.target/arm/f16_f64_conv_no_dp.c: New test.
> >
>
> --
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)
2019-03-11  Christophe Lyon  

* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.

diff --git a/gcc/testsuite/gcc.target/arm/f16_f64_conv_no_dp.c 
b/gcc/testsuite/gcc.target/arm/f16_f64_conv_no_dp.c
index 99b62a8..2620e57 100644
--- a/gcc/testsuite/gcc.target/arm/f16_f64_conv_no_dp.c
+++ b/gcc/testsuite/gcc.target/arm/f16_f64_conv_no_dp.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_fp16_ok } */
 /* { dg-skip-if "do not override fpu" { *-*-* } { "-mfpu=*" } { 
"-mfpu=fpv5-sp-d16" } } */
 /* { dg-skip-if "do not disable fpu" { *-*-* } { "-mfloat-abi=soft" } { * } } 
*/
 /* { dg-skip-if "do not override fp16-format" { *-*-* } { "-mfp16-format=*" } 
{ "-mfp16-format=ieee" } } */

[PATCH] avoid assuming every type has a size (PR 89662)

[Martin Sebor]

A -Warray-bounds enhancement committed last year into GCC 9
introduced an assumption that the MEM_REF type argument has
a size.  The test case submitted in PR89662 does pointer
addition on void*, in which the MEM_REF type is void*, which
breaks the assumption.

The attached change removes this assumption and considers such
types to have the size of 1.  (The result is used to scale
the offset in diagnostics after it has been determined to be
out of bounds.)

Martin
PR tree-optimization/89662 - -Warray-bounds ICE on void* arithmetic

gcc/ChangeLog:

	PR tree-optimization/89662
	* tree-vrp.c (vrp_prop::check_mem_ref): Avoid assuming every type
	has a size.

gcc/testsuite/ChangeLog:

	PR tree-optimization/89662
	* gcc.dg/Warray-bounds-41.c: New test.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c	(revision 269445)
+++ gcc/tree-vrp.c	(working copy)
@@ -4718,13 +4718,16 @@ vrp_prop::check_mem_ref (location_t location, tree
 	{
 	  /* Extract the element type out of MEM_REF and use its size
 	 to compute the index to print in the diagnostic; arrays
-	 in MEM_REF don't mean anything.   */
+	 in MEM_REF don't mean anything.  A type with no size like
+	 void is as good as having a size of 1.  */
 	  tree type = TREE_TYPE (ref);
 	  while (TREE_CODE (type) == ARRAY_TYPE)
 	type = TREE_TYPE (type);
-	  tree size = TYPE_SIZE_UNIT (type);
-	  offrange[0] = offrange[0] / wi::to_offset (size);
-	  offrange[1] = offrange[1] / wi::to_offset (size);
+	  if (tree size = TYPE_SIZE_UNIT (type))
+	{
+	  offrange[0] = offrange[0] / wi::to_offset (size);
+	  offrange[1] = offrange[1] / wi::to_offset (size);
+	}
 	}
   else
 	{
Index: gcc/testsuite/gcc.dg/Warray-bounds-41.c
===
--- gcc/testsuite/gcc.dg/Warray-bounds-41.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Warray-bounds-41.c	(working copy)
@@ -0,0 +1,33 @@
+/* PR tree-optimization/89662- -Warray-bounds ICE on void* arithmetic
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+void* vptr (void *c)
+{
+  return c;
+}
+
+void sink (void*);
+
+void test_vptr_arith_vla_cst (void)
+{
+  int n = 1;
+  char c[n];
+  sink (vptr (c) - 1);/* { dg-warning "\\\[-Warray-bounds" } */
+}
+
+void test_vptr_arith_vla_range (int n)
+{
+  if (n < 1 || 4 < n)
+return;
+
+  char c[n];
+  sink (vptr (c) - 1);/* { dg-warning "\\\[-Warray-bounds" "pr82608" { xfail *-*-* } } */
+}
+
+void test_vptr_arith_vla_var (int n)
+{
+  char c[n];
+  sink (vptr (c) - 1);/* { dg-warning "\\\[-Warray-bounds" "pr82608" { xfail *-*-* } } */
+}
+

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

[Harald Anlauf]

Hi Dominique,

how about the attached version?  It is quite verbose and produces
messages like

Error: Expected list of 'lower-bound-expr:' or list of
'lower-bound-expr:upper-bound-expr' at (1)

(I did check other compilers.  E.g. Intel and Oracle do print messages
using the 'legalese'.  But user-friendliness does count, too.)

OK for trunk?  Further comments?

Thanks,
Harald

On 03/11/19 10:22, Dominique d'Humières wrote:
> Hi Harald,
> 
> The patch looks good to me (although I did not test it), however I don’t like 
> the standard legalese in the error messages.
> 
> IMO
> 
> R1035 bounds-spec is lower-bound-expr :
> R1036 bounds-remapping is lower-bound-expr : upper-bound-exp
> 
> should be rephrased in plain English.
> 
> Thanks for the work.
> 
> Dominique


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 269593)
+++ gcc/fortran/expr.c  (working copy)
@@ -3703,6 +3703,7 @@
   gfc_ref *ref;
   bool is_pure, is_implicit_pure, rank_remap;
   int proc_pointer;
+  bool same_rank;
 
   lhs_attr = gfc_expr_attr (lvalue);
   if (lvalue->ts.type == BT_UNKNOWN && !lhs_attr.proc_pointer)
@@ -3724,6 +3725,7 @@
   proc_pointer = lvalue->symtree->n.sym->attr.proc_pointer;
 
   rank_remap = false;
+  same_rank = lvalue->rank == rvalue->rank;
   for (ref = lvalue->ref; ref; ref = ref->next)
 {
   if (ref->type == REF_COMPONENT)
@@ -3748,36 +3750,72 @@
   lvalue->symtree->n.sym->name, >where))
return false;
 
- /* When bounds are given, all lbounds are necessary and either all
-or none of the upper bounds; no strides are allowed.  If the
-upper bounds are present, we may do rank remapping.  */
+ /* Fortran standard (e.g. F2018, 10.2.2 Pointer assignment):
+  *
+  * (C1017) If bounds-spec-list is specified, the number of
+  * bounds-specs shall equal the rank of data-pointer-object.
+  *
+  * If bounds-spec-list appears, it specifies the lower bounds.
+  *
+  * (C1018) If bounds-remapping-list is specified, the number of
+  * bounds-remappings shall equal the rank of data-pointer-object.
+  *
+  * If bounds-remapping-list appears, it specifies the upper and
+  * lower bounds of each dimension of the pointer; the pointer target
+  * shall be simply contiguous or of rank one.
+  *
+  * (C1019) If bounds-remapping-list is not specified, the ranks of
+  * data-pointer-object and data-target shall be the same.
+  *
+  * Thus when bounds are given, all lbounds are necessary and either
+  * all or none of the upper bounds; no strides are allowed.  If the
+  * upper bounds are present, we may do rank remapping.  */
+
+#define BOUNDS_SPEC_LIST "list of %"
+#define BOUNDS_REMAPPING_LIST "list of %"
+
  for (dim = 0; dim < ref->u.ar.dimen; ++dim)
{
- if (!ref->u.ar.start[dim]
- || ref->u.ar.dimen_type[dim] != DIMEN_RANGE)
+ if (ref->u.ar.stride[dim])
{
- gfc_error ("Lower bound has to be present at %L",
+ gfc_error ("Stride must not be present at %L",
 >where);
  return false;
}
- if (ref->u.ar.stride[dim])
+ if (!same_rank && (!ref->u.ar.start[dim] ||!ref->u.ar.end[dim]))
{
- gfc_error ("Stride must not be present at %L",
+ gfc_error ("Rank remapping requires a "
+BOUNDS_SPEC_LIST " at %L",
 >where);
  return false;
}
+ if (!ref->u.ar.start[dim]
+ || ref->u.ar.dimen_type[dim] != DIMEN_RANGE)
+   {
+ gfc_error ("Expected " BOUNDS_REMAPPING_LIST " or "
+BOUNDS_SPEC_LIST " at %L",
+>where);
+ return false;
+   }
 
  if (dim == 0)
rank_remap = (ref->u.ar.end[dim] != NULL);
  else
{
- if ((rank_remap && !ref->u.ar.end[dim])
- || (!rank_remap && ref->u.ar.end[dim]))
+ if ((rank_remap && !ref->u.ar.end[dim]))
{
- gfc_error ("Either all or none of the upper bounds"
-" must be specified at %L", >where);
+ gfc_error ("Rank remapping requires a "
+BOUNDS_SPEC_LIST " at %L",
+>where);
  return false;
}
+ if (!rank_remap && ref->u.ar.end[dim])
+   {
+ gfc_error ("Expected " BOUNDS_REMAPPING_LIST " or "
+

Re: [PATCH] Fix double string quoting.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 08:54:50PM +0100, Martin Liška wrote:
> /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-recog.c 
> insn-recog.c
> /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c: In function ‘void 
> aarch64_override_options_internal(gcc_options*)’:
> /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:11457:14: warning: 
> 'q' flag used within a quoted sequence [-Wformat=]
>error ("incompatible options %<-mstack-protector-guard=global%> and"
>   ^
>"%<-mstack-protector-guard-offset=%qs%>",
>
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-03-11  Martin Liska  
> 
>   * config/aarch64/aarch64.c (aarch64_override_options_internal):
>   Fix double string quoting.

That is obvious.

> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 252bed7f0e5..b38505b0872 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -11455,7 +11455,7 @@ aarch64_override_options_internal (struct gcc_options 
> *opts)
>&& opts->x_aarch64_stack_protector_guard_offset_str)
>  {
>error ("incompatible options %<-mstack-protector-guard=global%> and"
> -  "%<-mstack-protector-guard-offset=%qs%>",
> +  "%<-mstack-protector-guard-offset=%s%>",
>aarch64_stack_protector_guard_offset_str);
>  }
>  
> @@ -11482,7 +11482,7 @@ aarch64_override_options_internal (struct gcc_options 
> *opts)
>long offs = strtol (aarch64_stack_protector_guard_offset_str, , 0);
>if (!*str || *end || errno)
>   error ("%qs is not a valid offset in %qs", str,
> -"%<-mstack-protector-guard-offset=%>");
> +"-mstack-protector-guard-offset=");
>aarch64_stack_protector_guard_offset = offs;
>  }
>  
> 


Jakub

[PATCH] Fix double string quoting.

[Martin Liška]

Hi.

This is a fix for my recent change in string messages.
It fixes:

/bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-recog.c 
insn-recog.c
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c: In function ‘void 
aarch64_override_options_internal(gcc_options*)’:
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:11457:14: warning: 
'q' flag used within a quoted sequence [-Wformat=]
   error ("incompatible options %<-mstack-protector-guard=global%> and"
  ^
   "%<-mstack-protector-guard-offset=%qs%>",
   

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2019-03-11  Martin Liska  

* config/aarch64/aarch64.c (aarch64_override_options_internal):
Fix double string quoting.
---
 gcc/config/aarch64/aarch64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 252bed7f0e5..b38505b0872 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11455,7 +11455,7 @@ aarch64_override_options_internal (struct gcc_options *opts)
   && opts->x_aarch64_stack_protector_guard_offset_str)
 {
   error ("incompatible options %<-mstack-protector-guard=global%> and"
-	 "%<-mstack-protector-guard-offset=%qs%>",
+	 "%<-mstack-protector-guard-offset=%s%>",
 	 aarch64_stack_protector_guard_offset_str);
 }
 
@@ -11482,7 +11482,7 @@ aarch64_override_options_internal (struct gcc_options *opts)
   long offs = strtol (aarch64_stack_protector_guard_offset_str, , 0);
   if (!*str || *end || errno)
 	error ("%qs is not a valid offset in %qs", str,
-	   "%<-mstack-protector-guard-offset=%>");
+	   "-mstack-protector-guard-offset=");
   aarch64_stack_protector_guard_offset = offs;
 }
 

[PATCH] Fix PR89664

[Richard Biener]

Bootstrap & regtest in progress on x86_64-unknown-linux-gnu.

Richard.

2019-03-11  Richard Biener  

PR tree-optimization/89664
* tree-ssa-math-opts.c (execute_cse_reciprocals_1): Properly
free the occurance tree after the early out.

* gfortran.dg/pr89664.f90: New testcase.

Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 269212)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -799,7 +799,7 @@ execute_cse_reciprocals_1 (gimple_stmt_i
 
   /* If it is more profitable to optimize 1 / x, don't optimize 1 / (x * x).  
*/
   if (sqrt_recip_count > square_recip_count)
-return;
+goto out;
 
   /* Do the expensive part only if we can hope to optimize something.  */
   if (count + square_recip_count >= threshold && count >= 1)
@@ -842,6 +842,7 @@ execute_cse_reciprocals_1 (gimple_stmt_i
}
 }
 
+out:
   for (occ = occ_head; occ; )
 occ = free_bb (occ);
 
Index: gcc/testsuite/gfortran.dg/pr89664.f90
===
--- gcc/testsuite/gfortran.dg/pr89664.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr89664.f90   (working copy)
@@ -0,0 +1,24 @@
+! { dg-do compile }
+! { dg-options "-Ofast" }
+
+subroutine s (x)
+   real :: x
+   call sub (x)
+end
+subroutine sub (x)
+   real :: x, y
+   logical :: a, b
+   real :: f1, f2, f3, f4
+   y = f1()
+   a = .false.
+   if ( f2() > f3() ) a = .true.
+   b = .false.
+   if ( f2() > f4() ) b = .true.
+   if ( a ) then
+  x = 1.0
+   else if ( b ) then
+  x = 1.0/y**2
+   else
+  x = 1.0/y - y**2
+   end if
+end

[PATCH] PR libstdc++/89460 Fix Networking TS test failures on HP-UX

[Jonathan Wakely]

Check for availability of POSIX sockatmark before using it.

Rename _S_ntoh overloads that are ambiguous when passed an integral type
that is neither uint16_t nor uint32_t.

PR libstdc++/89460
* configure.ac: Check for sockatmark.
* crossconfig.m4: Check for sockatmark.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/experimental/internet (address_v4::_S_hton): Rename
overloaded functions to _S_hton_16 and _S_ntoh_16.
(address_v4::_S_ntoh): Rename to _S_ntoh_16 and _S_ntoh_32.
(basic_endpoint): Adjust calls to _S_hton and _S_ntoh.
* include/experimental/socket (basic_socket::at_mark): Check
_GLIBCXX_HAVE_SOCKATMARK.

Tested powerp64le-linux, committed to trunk.

commit fc3bbdb3be7676066ad2d954859837a8376ae7ee
Author: Jonathan Wakely 
Date:   Mon Mar 11 16:03:14 2019 +

PR libstdc++/89460 Fix Networking TS test failures on HP-UX

Check for availability of POSIX sockatmark before using it.

Rename _S_ntoh overloads that are ambiguous when passed an integral type
that is neither uint16_t nor uint32_t.

PR libstdc++/89460
* configure.ac: Check for sockatmark.
* crossconfig.m4: Check for sockatmark.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/experimental/internet (address_v4::_S_hton): Rename
overloaded functions to _S_hton_16 and _S_ntoh_16.
(address_v4::_S_ntoh): Rename to _S_ntoh_16 and _S_ntoh_32.
(basic_endpoint): Adjust calls to _S_hton and _S_ntoh.
* include/experimental/socket (basic_socket::at_mark): Check
_GLIBCXX_HAVE_SOCKATMARK.

diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 39b0b90c289..dadd8827b49 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -268,6 +268,9 @@ if $GLIBCXX_IS_NATIVE; then
   # C11 functions for C++17 library
   AC_CHECK_FUNCS(timespec_get)
 
+  # For Networking TS.
+  AC_CHECK_FUNCS(sockatmark)
+
   # For iconv support.
   AM_ICONV
 
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index 4a303008053..344eec09d8e 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -136,6 +136,7 @@ case "${host}" in
 AC_CHECK_FUNCS(__cxa_thread_atexit)
 AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_CHECK_FUNCS(timespec_get)
+AC_CHECK_FUNCS(sockatmark)
 ;;
 
   *-fuchsia*)
@@ -196,6 +197,7 @@ case "${host}" in
 AC_CHECK_FUNCS(__cxa_thread_atexit_impl)
 AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_CHECK_FUNCS(timespec_get)
+AC_CHECK_FUNCS(sockatmark)
 AM_ICONV
 ;;
   *-mingw32*)
@@ -224,6 +226,7 @@ case "${host}" in
 fi
 AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_CHECK_FUNCS(timespec_get)
+AC_CHECK_FUNCS(sockatmark)
 ;;
   *-qnx6.1* | *-qnx6.2*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 80682efed53..467bdfda3ed 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -158,7 +158,7 @@ namespace ip
 { }
 
 explicit constexpr
-address_v4(uint_type __val) : _M_addr(_S_hton(__val))
+address_v4(uint_type __val) : _M_addr(_S_hton_32(__val))
 {
 #if UINT_LEAST32_MAX > 0x
   if (__val > 0x)
@@ -191,7 +191,8 @@ namespace ip
   };
 }
 
-constexpr uint_type to_uint() const noexcept { return _S_ntoh(_M_addr); }
+constexpr uint_type
+to_uint() const noexcept { return _S_ntoh_32(_M_addr); }
 
 #ifdef _GLIBCXX_HAVE_ARPA_INET_H
 template>
@@ -224,22 +225,22 @@ namespace ip
 friend address_v4 make_address_v4(const char*, error_code&) noexcept;
 
 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
-static constexpr uint16_t _S_hton(uint16_t __h) { return __h; }
-static constexpr uint16_t _S_ntoh(uint16_t __n) { return __n; }
-static constexpr uint32_t _S_hton(uint32_t __h) { return __h; }
-static constexpr uint32_t _S_ntoh(uint32_t __n) { return __n; }
+static constexpr uint16_t _S_hton_16(uint16_t __h) { return __h; }
+static constexpr uint16_t _S_ntoh_16(uint16_t __n) { return __n; }
+static constexpr uint32_t _S_hton_32(uint32_t __h) { return __h; }
+static constexpr uint32_t _S_ntoh_32(uint32_t __n) { return __n; }
 #else
 static constexpr uint16_t
-_S_hton(uint16_t __h) { return __builtin_bswap16(__h); }
+_S_hton_16(uint16_t __h) { return __builtin_bswap16(__h); }
 
 static constexpr uint16_t
-_S_ntoh(uint16_t __n) { return __builtin_bswap16(__n); }
+_S_ntoh_16(uint16_t __n) { return __builtin_bswap16(__n); }
 
 static constexpr uint32_t
-_S_hton(uint32_t __h) { return __builtin_bswap32(__h); 

Re: [Patch, aarch64] PR 89628 - fix register allocation in SIMD functions

[Steve Ellcey]

Richard,

I don't necessarily disagree with anything in your comments and long
term I think that is the right direction, but I wonder if that level of
change is appropriate for GCC Stage 4 which is where we are now.  Your
changes would require fixes in shared code, whereas setting
REG_ALLOC_ORDER only affects Aarch64 and seems like a safer change.
I am not sure how long it would take me to implement something along
the lines of what you are suggesting.

Steve Ellcey
sell...@marvell.com


On Sat, 2019-03-09 at 08:03 +, Richard Sandiford wrote:

> Steve Ellcey  writes:
> > This is a patch to fix the register allocation in SIMD functions.  In
> > normal functions registers V16 to V31 are all caller saved.  In SIMD
> > functions V16 to V23 are callee saved and V24 to V31 are caller saved.
> > This means that SIMD functions should use V24 to V31 before V16 to V23
> > in order to avoid some saves and restores.
> > 
> > My fix for this is to define REG_ALLOC_ORDER.  Right now it is not
> > defined on Aarch64, so I just defined it as all the registers in order
> > except for putting V24 to V31 before V16 to V23.  This fixes the
> > register allocation in SIMD functions.  It also changes the register
> > allocation order in regular functions but since all the registers (V16
> > to V31) are caller saved in that case, it doesn't matter.  We could use
> > ADJUST_REG_ALLOC_ORDER to only affect SIMD functions but I did not see
> > any reason to do that.
> 
> REG_ALLOC_ORDER shouldn't really be needed for testcases like the ones
> in the PR.  Like you say, we don't currently need it to handle the
> equivalent situation for the standard ABI.
> 
> I think the problem is that the RA is still using the register sets
> for the default ABI when evaluating the prologue/epilogue cost of using
> a hard register.  E.g. see calculate_saved_nregs.
> 
> Maybe one fix would be to add an equivalent of call_used_reg_set to
> rtl_data.  By default it would be the same as call_used_reg_set,
> but the target could have an opportunity to change it.  Then code like
> calculate_saved_nregs should use the new set to find out what registers
> the current function can use without spilling.
> 
> This would also be useful for targets that implement interrupt handler
> attributes.
> 
> It would be good to add the testcase in the PR to the testsuite,
> with a scan-assembler to check for spills.
> 
> > diff --git a/gcc/config/aarch64/aarch64.h
> > b/gcc/config/aarch64/aarch64.h
> > index 7bd3bf5..d3723ff 100644
> > --- a/gcc/config/aarch64/aarch64.h
> > +++ b/gcc/config/aarch64/aarch64.h
> > @@ -328,7 +328,9 @@ extern unsigned aarch64_architecture_version;
> > ZR  zero register, encoded as X/R31 elsewhere
> >  
> > 32 x 128-bit floating-point/vector registers
> > -   V16-V31 Caller-saved (temporary) registers
> > +   V24-V31 Caller-saved (temporary) registers
> > +   V16-V23 Caller-saved (temporary) registers in most functions;
> > +   Callee-saved in SIMD functions.
> > V8-V15  Callee-saved registers
> > V0-V7   Parameter/result registers
> 
> Probably better as s/SIMD/vector PCS/.  The hunk above is OK with
> that
> change, independently of the rest.
> 
> Thanks,
> Richard

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Sebor]

On 3/11/19 2:13 AM, Martin Liška wrote:

Hi.

The patch adds a lot of option name wrapping in string format messages. I added 
a new contrib
script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot file 
and reports
errors.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Apart from that I built all cross compilers and compared all warnings so that
I don't introduce a bootstrap error. It's expected that various target-specific
tests will need wrapping in scanned patterns.


This looks great to me.  One change I would consider is making
the built-in and option strings arguments to %qs rather than
parts of the format strings.  That should reduce the overall
number of format strings that need to be translated, and also
make it easier to spot inconsistencies between the phrasing
or opportunities to make the phrasing more uniform.

(I still plan to work on the warning we said we'd add to keep
the missing quoting from creeping back in.)

Martin



Is it fine for next stage1?
Thanks,
Martin

Re: [PATCH 0/7] S/390: Rework instruction scheduling.

[Andreas Krebbel]

On 11.03.19 13:53, Robin Dapp wrote:
> Hi,
> 
> this patch set adds new pipeline descriptions for z13 and z14.  Based
> on that, the scoring and some properties are handled differently in
> the scheduler hooks.
> 
> Regards
>  Robin
> 
> Robin Dapp (7):
>   S/390: Change z13 pipeline description.
>   S/390: Add z14 pipeline description.
>   S/390: Change handling of long-running instructions.
>   S/390: Change handling of group end.
>   S/390: Add side to schedule-mix calculations.
>   S/390: Add handling for group-of-two instructions.
>   S/390: Tune scheduling parameters.
> 
>  gcc/config/s390/2964.md | 373 ++--
>  gcc/config/s390/3906.md | 281 ++
>  gcc/config/s390/s390.c  | 303 +++-
>  gcc/config/s390/s390.h  |   2 +-
>  gcc/config/s390/s390.md |   3 +
>  5 files changed, 679 insertions(+), 283 deletions(-)
>  create mode 100644 gcc/config/s390/3906.md
> 

Please adjust the year and the author in gcc/config/s390/3906.md. Ok with that 
change.

Thanks!

Andreas

Re: [PATCH 2/N] Wrap apostrophes in gcc internal format with %'.

[Alexander Monakov]

On Mon, 11 Mar 2019, Jakub Jelinek wrote:

> On Mon, Mar 11, 2019 at 02:25:59PM +0100, Martin Liška wrote:
> > @@ -38375,7 +38375,7 @@ rdseed_step:
> >mode0 = insn_data[icode].operand[0].mode;
> >if (!insn_data[icode].operand[0].predicate (op0, mode0))
> > {
> > - error ("the xabort's argument must be an 8-bit immediate");
> > + error ("the xabort%'s argument must be an 8-bit immediate");
> >   return const0_rtx;
> > }
> >emit_insn (gen_xabort (op0));
> 
> I'd drop the 's here instead and maybe the as well?

If this is going to be changed anyway, can it be cleared up like this:

  "the argument to % intrinsic must be an 8-bit immediate"?

Thanks.
Alexander

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Jonathan Wakely]

On 11/03/19 13:54 +, Jonathan Wakely wrote:

On 11/03/19 09:27 -0400, John David Anglin wrote:

On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:

On 11/03/19 14:13 +0100, Andreas Schwab wrote:

On Mär 11 2019, Jonathan Wakely  wrote:


What do you think about adding the following?

--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
    return $flags
}

+# Add to FLAGS all the target-specific flags to link to libatomic, if required.
+
+proc add_options_for_libatomic { flags } {
+    if { [istarget hppa*-*-hpux*] } {
+   return "$flags -L../../libatomic/.libs -latomic"
+    }
+    return $flags
+}


That should probably also be enabled for riscv*-*-*.


So all the more reason to do it this way, so the list of targets is
only maintained in one place

Your suggestion looks good to me.  We still need hunk that sets up 
LD_LIBRARY_PATH.


Right.


This is what is done in fortran tests:
! { dg-additional-options "-latomic" { target libatomic_available } }


That adds it for every target that has a libatomic though, right? We
have tests that check certain uses of atomics work without libatomic,
which would no longer check anything if we added that to them :-)


Ah, but unless -L../../libatomic./libs has been added to the flags,
-latomic won't find anything, so it wouldn't get added.

I still think {target libatomic_available } doesn't buy us much, due
to ...


If we use { dg-add-options libatomic } it'll only be added for the
listed targets (hpux and riscv to begin with) and if somebody disables
building libatomic on those targets they probably should get test
failures to say there's something wrong.

[PATCH 3/N] Fix GCC internal format in D front-end.

[Martin Liška]

On 3/11/19 2:38 PM, Jakub Jelinek wrote:
> I think for D you need to go through Iain Buclaw, I have no idea if
> exp->error even has the gcc internal format infrastructure.  Can you split
> that part of the patch and post it independently?

The patch addresses that.

Martin

>From 2285a99c9ca1435346eac9dbc0ffd41d29b8eaec Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 11 Mar 2019 14:59:25 +0100
Subject: [PATCH] Fix GCC internal format in D front-end.

gcc/d/ChangeLog:

2019-03-11  Martin Liska  

	* dmd/expressionsem.c: Fix GCC internal format.
---
 gcc/d/dmd/expressionsem.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/d/dmd/expressionsem.c b/gcc/d/dmd/expressionsem.c
index bcc1ac9ed2f..cf09f097476 100644
--- a/gcc/d/dmd/expressionsem.c
+++ b/gcc/d/dmd/expressionsem.c
@@ -1366,7 +1366,7 @@ public:
 }
 else
 {
-exp->error("new can only create structs, dynamic arrays or class objects, not %s's", exp->type->toChars());
+exp->error("new can only create structs, dynamic arrays or class objects, not %s%'s", exp->type->toChars());
 return setError();
 }
 
@@ -2298,7 +2298,7 @@ public:
 const char *name = (char *)se->string;
 if (!global.params.fileImppath)
 {
-e->error("need -Jpath switch to import text file %s", name);
+e->error("need %<-Jpath%> switch to import text file %s", name);
 return setError();
 }
 
@@ -2310,7 +2310,7 @@ public:
 name = FileName::safeSearchPath(global.filePath, name);
 if (!name)
 {
-e->error("file %s cannot be found or not in a path specified with -J", se->toChars());
+e->error("file %s cannot be found or not in a path specified with %<-J%>", se->toChars());
 return setError();
 }
 
@@ -6444,7 +6444,7 @@ public:
 e = scaleFactor(exp, sc);
 else
 {
-exp->error("can't subtract %s from pointer", t2->toChars());
+exp->error("can%'t subtract %s from pointer", t2->toChars());
 e = new ErrorExp();
 }
 result = e;
@@ -6453,7 +6453,7 @@ public:
 if (t2->ty == Tpointer)
 {
 exp->type = exp->e2->type;
-exp->error("can't subtract pointer from %s", exp->e1->type->toChars());
+exp->error("can%'t subtract pointer from %s", exp->e1->type->toChars());
 return setError();
 }
 
@@ -8702,6 +8702,6 @@ Expression *semanticY(DotTemplateInstanceExp *exp, Scope *sc, int flag)
 return e;
 }
 Lerr:
-e->error("%s isn't a template", e->toChars());
+e->error("%s isn%'t a template", e->toChars());
 return new ErrorExp();
 }
-- 
2.21.0

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 02:52:18PM +0100, Martin Liška wrote:
> On 3/11/19 2:32 PM, Jakub Jelinek wrote:
> > On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
> >> Now I understand that, thanks.
> > 
> > %<-misr-vector-size=X%>
> > and
> > %<-mcache-block-size=X%>
> > need similar treatment.
> 
> Done.
> 
> > 
> > I still see
> > %<-mcpu%>=%s
> 
> Fixed.
> 
> > 
> > %<-mfpu=crypto-neon...%>
> > might need to be %<-mfpu=crypto-neon%>... or just drop the ... ?
> 
> I dropped the 3 dots.
> 
> > 
> > %<-std=*%> should be %<-std=%> or %<-std=%>*, and not really sure
> > if the Fortran FE diagnostics support %, have you verified that?
> 
> Yes, I verified that.

Ok, thanks.
Please be prepared to fix testsuite fallout on non-x86 targets.

Jakub

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 2:52 PM, Martin Liška wrote:
> On 3/11/19 2:32 PM, Jakub Jelinek wrote:
>> On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
>>> Now I understand that, thanks.
>>
>> %<-misr-vector-size=X%>
>> and
>> %<-mcache-block-size=X%>
>> need similar treatment.
> 
> Done.
> 
>>
>> I still see
>> %<-mcpu%>=%s
> 
> Fixed.
> 
>>
>> %<-mfpu=crypto-neon...%>
>> might need to be %<-mfpu=crypto-neon%>... or just drop the ... ?
> 
> I dropped the 3 dots.
> 
>>
>> %<-std=*%> should be %<-std=%> or %<-std=%>*, and not really sure
>> if the Fortran FE diagnostics support %, have you verified that?
> 
> Yes, I verified that.
> 
> Martin
> 
>>
>>  Jakub
>>
> 

I forgot to exclude changes in D FE.

Martin


0001-Wrap-option-names-in-gcc-internal-messages-with-and.patch.bz2
Description: application/bzip

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Jonathan Wakely]

On 11/03/19 09:27 -0400, John David Anglin wrote:

On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:

On 11/03/19 14:13 +0100, Andreas Schwab wrote:

On Mär 11 2019, Jonathan Wakely  wrote:


What do you think about adding the following?

--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
    return $flags
}

+# Add to FLAGS all the target-specific flags to link to libatomic, if required.
+
+proc add_options_for_libatomic { flags } {
+    if { [istarget hppa*-*-hpux*] } {
+   return "$flags -L../../libatomic/.libs -latomic"
+    }
+    return $flags
+}


That should probably also be enabled for riscv*-*-*.


So all the more reason to do it this way, so the list of targets is
only maintained in one place

Your suggestion looks good to me.  We still need hunk that sets up 
LD_LIBRARY_PATH.


Right.


This is what is done in fortran tests:
! { dg-additional-options "-latomic" { target libatomic_available } }


That adds it for every target that has a libatomic though, right? We
have tests that check certain uses of atomics work without libatomic,
which would no longer check anything if we added that to them :-)

If we use { dg-add-options libatomic } it'll only be added for the
listed targets (hpux and riscv to begin with) and if somebody disables
building libatomic on those targets they probably should get test
failures to say there's something wrong.

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 2:32 PM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
>> Now I understand that, thanks.
> 
> %<-misr-vector-size=X%>
> and
> %<-mcache-block-size=X%>
> need similar treatment.

Done.

> 
> I still see
> %<-mcpu%>=%s

Fixed.

> 
> %<-mfpu=crypto-neon...%>
> might need to be %<-mfpu=crypto-neon%>... or just drop the ... ?

I dropped the 3 dots.

> 
> %<-std=*%> should be %<-std=%> or %<-std=%>*, and not really sure
> if the Fortran FE diagnostics support %, have you verified that?

Yes, I verified that.

Martin

> 
>   Jakub
> 



0001-Wrap-option-names-in-gcc-internal-messages-with-and.patch.bz2
Description: application/bzip

Re: [PATCH] PR88497 - Extend reassoc for vector bit_field_ref

[Kewen.Lin]

on 2019/3/11 下午6:24, Richard Biener wrote:
> On Mon, 11 Mar 2019, Kewen.Lin wrote:
> 
>> on 2019/3/8 下午6:57, Richard Biener wrote:
>>> On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin  wrote:

 Hi,

 As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
 when we meet some code pattern like:

V1[0] + V1[1] + ... + V1[k] + V2[0] + ... + V2[k] + ... Vn[k]
// V1...Vn of VECTOR_TYPE

 We can teach reassoc to transform it to:

Vs = (V1 + V2 + ... + Vn)
Vs[0] + Vs[1] + ... + Vs[k]

 It saves addition and bit_field_ref operations and exposes more
 opportunities for downstream passes, I notice that even on one
 target doesn't support vector type and vector type gets expanded
 in veclower, it's still better to have it, since the generated
 sequence is more friendly for widening_mul.  （If one more time
 DCE after forwprop, it should be the same.  )

 Bootstrapped/regtested on powerpc64le-linux-gnu, ok for trunk?
>>>
>>> Hmm.  You are basically vectorizing the reduction partially here (note
>>> basic-block vectorization doesn't handle reductions yet).  So I'm not sure
>>> whether we should eventually just change op sort order to sort
>>> v1[1] after v2[0] to sort v1[0] and v2[0] together.  That would be also 
>>> maybe
>>> an intermediate step that makes implementing the vectorization part
>>> "easier"?  I also imagine that the "vectorization" would be profitable even
>>> if there's just two elements of the vectors summed and the real vectors are
>>> larger.
>>>
>>
>> Hi Richard,
>>
>> Sorry, I have no idea about basic-block vectorization (SLP?), did you 
>> suggest 
>> supporting this there rather than in reassoc? Changing op sort order for 
>> its expected pattern? 
> 
> I was thinking you're smashing two things together here - one part 
> suitable for reassocation and one that's on the border.  The reassoc
> pass already gathered quite some stuff that doesn't really belong there,
> we should at least think twice adding to that.
> 

Got it! Since the discussion context of the PR is mainly about reassocation, 
I started to look from it. :)

>>> Note that the code you transform contains no vector operations (just
>>> element extracts) and thus you need to check for target support before
>>> creating vector add.
>>>
>>
>> I had the same concern before.  But I thought that if this VECTOR type is 
>> valid
>> on the target, the addition operation should be fundamental on the target, 
>> then
>> it's ok; if it's invalid, then veclower will expand it into scalar type as 
>> well
>> as the addition operation. So it looks fine to guard it. Does it make sense?
> 
> But there's a reassoc phase after veclower.  Generally we avoid generating
> vector code not supported by the target.  You are not checking whether
> the vector type is valid on the target either btw.  The user might have
> written an optimal scalar sequence for a non-natively supported vector
> type (and veclower wouldn't touch the original scalar code) and veclower
> generally makes a mess of things, likely worse than the original code.
> 

Thanks for your explanation!  I'll update the code to check vector supported by 
target or not. 

>>
>>> This is for GCC 10.  Also it doesn't fix PR88497, does it?
>>>
>>
>> Yes, it's in low priority and for GCC10. I think it does. Did I miss 
>> something?
> 
> Wasn't the original testcase in the PR for _vectorized_ code?  The
> PR then got an additional testcase which you indeed fix.
> 

The original case is actually optimal with -Ofast, but additional case 
isn't. :)

>> For comment 1 and comment 7 cases, trunk gcc generates the expected code 
>> with -Ofast. There isn't any issues for the original loop. But for the 
>> expanded code in comment 1 (manually expanded case), gcc can't generate 
>> better code with multiply-add.
>>
>> From comment 9 case (same as comment 1 expanded version):
>>
>> without this patch, optimized tree and final asm:
>>
>>[local count: 1073741824]:
>>   _1 = *arg2_26(D);
>>   _2 = *arg3_27(D);
>>   _3 = _1 * _2;
>>   _4 = BIT_FIELD_REF <_3, 64, 0>;
>>   _5 = BIT_FIELD_REF <_3, 64, 64>;
>>   _18 = _4 + _5;
>>   _7 = MEM[(__vector double *)arg2_26(D) + 16B];
>>   _8 = MEM[(__vector double *)arg3_27(D) + 16B];
>>   _9 = _7 * _8;
>>   _10 = BIT_FIELD_REF <_9, 64, 0>;
>>   _11 = BIT_FIELD_REF <_9, 64, 64>;
>>   _31 = _10 + _11;
>>   _29 = _18 + _31;
>>   _13 = MEM[(__vector double *)arg2_26(D) + 32B];
>>   _14 = MEM[(__vector double *)arg3_27(D) + 32B];
>>   _15 = _13 * _14;
>>   _16 = BIT_FIELD_REF <_15, 64, 0>;
>>   _17 = BIT_FIELD_REF <_15, 64, 64>;
>>   _6 = _16 + _17;
>>   _12 = _6 + accumulator_28(D);
>>   _37 = _12 + _29;
>>   _19 = MEM[(__vector double *)arg2_26(D) + 48B];
>>   _20 = MEM[(__vector double *)arg3_27(D) + 48B];
>>   _21 = _19 * _20;
>>   _22 = BIT_FIELD_REF <_21, 64, 0>;
>>   _23 = BIT_FIELD_REF <_21, 64, 64>;
>>   _24 = _22 + _23;
>>   accumulator_32 = _24 + _37;
>>   

[PATCH] Change test to use const variables instead of macros

[Jonathan Wakely]

This is C++ so there's no reason to use macros here.

* testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc: Use
const variables instead of macros.

Tested x86_64-linux, committed to trunk.

commit 1eadaf7d34cfaaabb976e68a2fe163aab774463b
Author: Jonathan Wakely 
Date:   Mon Mar 11 13:17:41 2019 +

Change test to use const variables instead of macros

This is C++ so there's no reason to use macros here.

* testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc: Use
const variables instead of macros.

diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc
index e05b7a5fd6e..568d0d7d007 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc
@@ -25,8 +25,8 @@
 
 #include 
 
-#define ACQ memory_order_acquire | __memory_order_hle_acquire
-#define REL memory_order_release | __memory_order_hle_release
+const auto ACQ = std::memory_order_acquire | std::__memory_order_hle_acquire;
+const auto REL = std::memory_order_release | std::__memory_order_hle_release;
 
 int main()
 {

[PATCH] PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

[Jonathan Wakely]

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

Tested powerpc64le-linux, committed to trunk.

This should be backported too.

commit 7463ece3012ec59397605904387005425f11529c
Author: Jonathan Wakely 
Date:   Mon Mar 11 13:04:11 2019 +

PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

diff --git a/libstdc++-v3/libsupc++/hash_bytes.cc 
b/libstdc++-v3/libsupc++/hash_bytes.cc
index 3a555c73a52..bd12188e524 100644
--- a/libstdc++-v3/libsupc++/hash_bytes.cc
+++ b/libstdc++-v3/libsupc++/hash_bytes.cc
@@ -139,7 +139,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 // Remove the bytes not divisible by the sizeof(size_t).  This
 // allows the main loop to process the data as 64-bit integers.
-const int len_aligned = len & ~0x7;
+const size_t len_aligned = len & ~(size_t)0x7;
 const char* const end = buf + len_aligned;
 size_t hash = seed ^ (len * mul);
 for (const char* p = buf; p != end; p += 8)
diff --git a/libstdc++-v3/testsuite/20_util/hash/89629.cc 
b/libstdc++-v3/testsuite/20_util/hash/89629.cc
new file mode 100644
index 000..fd8273087fc
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/hash/89629.cc
@@ -0,0 +1,43 @@
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target { lp64 || llp64 } } }
+// { dg-require-effective-target c++11 }
+// { dg-require-effective-target run_expensive_tests }
+
+#include 
+#include 
+
+void
+test01()
+{
+  const std::size_t big = std::size_t(1) << 31;
+  std::string s;
+  try {
+s.resize(big, 'a');
+  } catch (const std::bad_alloc&) {
+return; // try to avoid a FAIL if memory allocation fails
+  }
+  // PR libstdc++/89629
+  (void) std::hash{}(s);
+}
+
+int
+main()
+{
+  test01();
+}

Re: [PATCH 2/N] Wrap apostrophes in gcc internal format with %'.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 02:25:59PM +0100, Martin Liška wrote:
> @@ -38375,7 +38375,7 @@ rdseed_step:
>mode0 = insn_data[icode].operand[0].mode;
>if (!insn_data[icode].operand[0].predicate (op0, mode0))
>   {
> -   error ("the xabort's argument must be an 8-bit immediate");
> +   error ("the xabort%'s argument must be an 8-bit immediate");
> return const0_rtx;
>   }
>emit_insn (gen_xabort (op0));

I'd drop the 's here instead and maybe the as well?

> --- a/gcc/d/dmd/expressionsem.c
> +++ b/gcc/d/dmd/expressionsem.c
> @@ -1366,7 +1366,7 @@ public:
>  }
>  else
>  {
> -exp->error("new can only create structs, dynamic arrays or class 
> objects, not %s's", exp->type->toChars());
> +exp->error("new can only create structs, dynamic arrays or class 
> objects, not %s%'s", exp->type->toChars());
>  return setError();
>  }
>  

I think for D you need to go through Iain Buclaw, I have no idea if
exp->error even has the gcc internal format infrastructure.  Can you split
that part of the patch and post it independently?

Otherwise LGTM.

Jakub

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 10:12:14AM +0100, Martin Liška wrote:
> Now I understand that, thanks.

%<-misr-vector-size=X%>
and
%<-mcache-block-size=X%>
need similar treatment.

I still see
%<-mcpu%>=%s

%<-mfpu=crypto-neon...%>
might need to be %<-mfpu=crypto-neon%>... or just drop the ... ?

%<-std=*%> should be %<-std=%> or %<-std=%>*, and not really sure
if the Fortran FE diagnostics support %, have you verified that?

Jakub

[Committed] S/390: Fix immediate vector operands for some builtins.

[Andreas Krebbel]

This fixes a problem with vec_add/sub_u128 builtins.  The
s390_expand_builtin backend function is supposed to convert the
operand to TImode *AND* load it into a vector register.  The current
implementation did only the conversion and gave up then.

Will be applied to GCC 8 branch after a while.

gcc/ChangeLog:

2019-03-11  Andreas Krebbel  

* config/s390/s390.c (s390_expand_builtin): Do the copy_to_reg not
only on the else branch.

gcc/testsuite/ChangeLog:

2019-03-11  Andreas Krebbel  

* gcc.target/s390/zvector/vec-addc-u128.c: New test.
---
 gcc/config/s390/s390.c| 14 ++
 gcc/testsuite/gcc.target/s390/zvector/vec-addc-u128.c | 10 ++
 2 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/zvector/vec-addc-u128.c

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index fce463f..b80d5e8 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -928,6 +928,8 @@ s390_expand_builtin (tree exp, rtx target, rtx subtarget 
ATTRIBUTE_UNUSED,
  continue;
}
 
+  /* A memory operand is rejected by the memory_operand predicate.
+Try making the address legal by copying it into a register.  */
   if (MEM_P (op[arity])
  && insn_op->predicate == memory_operand
  && (GET_MODE (XEXP (op[arity], 0)) == Pmode
@@ -951,10 +953,14 @@ s390_expand_builtin (tree exp, rtx target, rtx subtarget 
ATTRIBUTE_UNUSED,
{
  op[arity] = tmp_rtx;
}
-  else if (GET_MODE (op[arity]) == insn_op->mode
-  || GET_MODE (op[arity]) == VOIDmode
-  || (insn_op->predicate == address_operand
-  && GET_MODE (op[arity]) == Pmode))
+
+  /* The predicate rejects the operand although the mode is fine.
+Copy the operand to register.  */
+  if (!insn_op->predicate (op[arity], insn_op->mode)
+ && (GET_MODE (op[arity]) == insn_op->mode
+ || GET_MODE (op[arity]) == VOIDmode
+ || (insn_op->predicate == address_operand
+ && GET_MODE (op[arity]) == Pmode)))
{
  /* An address_operand usually has VOIDmode in the expander
 so we cannot use this.  */
diff --git a/gcc/testsuite/gcc.target/s390/zvector/vec-addc-u128.c 
b/gcc/testsuite/gcc.target/s390/zvector/vec-addc-u128.c
new file mode 100644
index 000..3ab0c71
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/zvector/vec-addc-u128.c
@@ -0,0 +1,10 @@
+/* { dg-do compile { target { s390*-*-* } } } */
+/* { dg-options "-O3 -mzarch -march=z13 -mzvector 
-fno-asynchronous-unwind-tables" } */
+
+#include 
+
+vector unsigned char test(void)
+{
+   vector unsigned char a = { 0 };
+   return __builtin_s390_vec_addc_u128 (a, a);
+}
-- 
2.7.4

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[John David Anglin]

On 2019-03-11 9:16 a.m., Jonathan Wakely wrote:
> On 11/03/19 14:13 +0100, Andreas Schwab wrote:
>> On Mär 11 2019, Jonathan Wakely  wrote:
>>
>>> What do you think about adding the following?
>>>
>>> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
>>> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
>>> @@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
>>>     return $flags
>>> }
>>>
>>> +# Add to FLAGS all the target-specific flags to link to libatomic, if 
>>> required.
>>> +
>>> +proc add_options_for_libatomic { flags } {
>>> +    if { [istarget hppa*-*-hpux*] } {
>>> +   return "$flags -L../../libatomic/.libs -latomic"
>>> +    }
>>> +    return $flags
>>> +}
>>
>> That should probably also be enabled for riscv*-*-*.
>
> So all the more reason to do it this way, so the list of targets is
> only maintained in one place
Your suggestion looks good to me.  We still need hunk that sets up 
LD_LIBRARY_PATH.

This is what is done in fortran tests:
! { dg-additional-options "-latomic" { target libatomic_available } }

Dave

-- 
John David Anglin  dave.ang...@bell.net

[PATCH 2/N] Wrap apostrophes in gcc internal format with %'.

[Martin Liška]

Hi.

There's second part where I wrap apostrophes.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From fb2e96c246e0dd99afafcc3ec24e766657ca2496 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 11 Mar 2019 10:13:41 +0100
Subject: [PATCH] Wrap apostrophes in gcc internal format with %'.

contrib/ChangeLog:

2019-03-11  Martin Liska  

	* check-internal-format-escaping.py: Uncomment apostrophes
	check.

gcc/ChangeLog:

2019-03-11  Martin Liska  

	* collect-utils.c (collect_wait): Wrap apostrophes
	in gcc internal format with %'.
	* collect2.c (main): Likewise.
	(scan_prog_file): Likewise.
	(scan_libraries): Likewise.
	* config/i386/i386.c (ix86_expand_call): Likewise.
	(ix86_handle_interrupt_attribute): Likewise.
	* config/nds32/nds32-intrinsic.c (nds32_expand_builtin_impl): Likewise.
	* config/nds32/nds32.c (nds32_insert_attributes): Likewise.
	* config/rl78/rl78.c (rl78_handle_saddr_attribute): Likewise.
	* lto-wrapper.c (find_crtoffloadtable): Likewise.
	* symtab.c (symtab_node::verify_base): Likewise.
	* tree-cfg.c (verify_gimple_label): Likewise.
	* tree.c (verify_type_variant): Likewise.

gcc/c-family/ChangeLog:

2019-03-11  Martin Liska  

	* c-opts.c (c_common_post_options): Wrap apostrophes
	in gcc internal format with %'.

gcc/cp/ChangeLog:

2019-03-11  Martin Liska  

	* cvt.c (build_expr_type_conversion): Wrap apostrophes
	in gcc internal format with %'.
	* decl.c (check_no_redeclaration_friend_default_args): Likewise.
	(grokfndecl): Likewise.
	* name-lookup.c (do_pushtag): Likewise.
	* pt.c (unify_parameter_deduction_failure): Likewise.
	(unify_template_deduction_failure): Likewise.

gcc/d/ChangeLog:

2019-03-11  Martin Liska  

	* dmd/expressionsem.c: Wrap apostrophes
	in gcc internal format with %'.
---
 contrib/check-internal-format-escaping.py |  4 ++--
 gcc/c-family/c-opts.c |  2 +-
 gcc/collect-utils.c   |  2 +-
 gcc/collect2.c|  6 +++---
 gcc/config/i386/i386.c|  6 +++---
 gcc/config/nds32/nds32-intrinsic.c|  8 
 gcc/config/nds32/nds32.c  |  2 +-
 gcc/config/rl78/rl78.c|  2 +-
 gcc/cp/cvt.c  |  2 +-
 gcc/cp/decl.c |  4 ++--
 gcc/cp/name-lookup.c  |  2 +-
 gcc/cp/pt.c   |  4 ++--
 gcc/d/dmd/expressionsem.c |  8 
 gcc/lto-wrapper.c |  2 +-
 gcc/symtab.c  |  8 
 gcc/tree-cfg.c|  2 +-
 gcc/tree.c| 16 
 17 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/contrib/check-internal-format-escaping.py b/contrib/check-internal-format-escaping.py
index 5513b762271..5da56b59dd6 100755
--- a/contrib/check-internal-format-escaping.py
+++ b/contrib/check-internal-format-escaping.py
@@ -56,8 +56,8 @@ for i, l in enumerate(lines):
 print('%s: %s' % (origin, text))
 elif p.startswith('__builtin_'):
 print('%s: %s' % (origin, text))
-#if re.search("[a-zA-Z]'[a-zA-Z]", p):
-#print('%s: %s' % (origin, text))
+if re.search("[a-zA-Z]'[a-zA-Z]", p):
+print('%s: %s' % (origin, text))
 j += 1
 
 origin = None
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 3233fdb9775..daa02a5e72d 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -945,7 +945,7 @@ c_common_post_options (const char **pfilename)
   if (flag_abi_version == latest_abi_version)
 	{
 	  auto_diagnostic_group d;
-	  if (warning (OPT_Wabi, "%<-Wabi%> won't warn about anything"))
+	  if (warning (OPT_Wabi, "%<-Wabi%> won%'t warn about anything"))
 	{
 	  inform (input_location, "%<-Wabi%> warns about differences "
 		  "from the most up-to-date ABI, which is also used "
diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index fba3f7496ef..1e034433b80 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -65,7 +65,7 @@ collect_wait (const char *prog, struct pex_obj *pex)
   int status;
 
   if (!pex_get_status (pex, 1, ))
-fatal_error (input_location, "can't get program status: %m");
+fatal_error (input_location, "can%'t get program status: %m");
   pex_free (pex);
 
   if (response_file && !save_temps)
diff --git a/gcc/collect2.c b/gcc/collect2.c
index da956bfd984..9d7de940ec1 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1396,7 +1396,7 @@ main (int argc, char **argv)
 
 		  stream = fopen (list_filename, "r");
 		  if (stream == NULL)
-		fatal_error (input_location, "can't open %s: %m",
+		fatal_error (input_location, "can%'t open %s: %m",
  list_filename);
 
 		  while (fgets (buf, sizeof buf, stream) != NULL)
@@ 

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Jonathan Wakely]

On 11/03/19 14:13 +0100, Andreas Schwab wrote:

On Mär 11 2019, Jonathan Wakely  wrote:


What do you think about adding the following?

--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
return $flags
}

+# Add to FLAGS all the target-specific flags to link to libatomic, if required.
+
+proc add_options_for_libatomic { flags } {
+if { [istarget hppa*-*-hpux*] } {
+   return "$flags -L../../libatomic/.libs -latomic"
+}
+return $flags
+}


That should probably also be enabled for riscv*-*-*.


So all the more reason to do it this way, so the list of targets is
only maintained in one place.

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Andreas Schwab]

On Mär 11 2019, Jonathan Wakely  wrote:

> What do you think about adding the following?
>
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
> return $flags
> }
>
> +# Add to FLAGS all the target-specific flags to link to libatomic, if 
> required.
> +
> +proc add_options_for_libatomic { flags } {
> +if { [istarget hppa*-*-hpux*] } {
> +   return "$flags -L../../libatomic/.libs -latomic"
> +}
> +return $flags
> +}

That should probably also be enabled for riscv*-*-*.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH 6/7] S/390: Add handling for group-of-two instructions.

[Robin Dapp]

This patch adds handling of group-of-two instructions.

---
 gcc/config/s390/s390.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 4dcf1be4445..78a707267e8 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -14266,14 +14266,17 @@ struct s390_sched_state
   int group_state;
   /* Execution side of the group.  */
   int side;
+  /* Group can only hold two insns.  */
+  bool group_of_two;
 } s390_sched_state;
 
-static struct s390_sched_state sched_state = {0, 1};
+static struct s390_sched_state sched_state = {0, 1, false};
 
 #define S390_SCHED_ATTR_MASK_CRACKED0x1
 #define S390_SCHED_ATTR_MASK_EXPANDED   0x2
 #define S390_SCHED_ATTR_MASK_ENDGROUP   0x4
 #define S390_SCHED_ATTR_MASK_GROUPALONE 0x8
+#define S390_SCHED_ATTR_MASK_GROUPOFTWO 0x10
 
 static unsigned int
 s390_get_sched_attrmask (rtx_insn *insn)
@@ -14301,6 +14304,8 @@ s390_get_sched_attrmask (rtx_insn *insn)
mask |= S390_SCHED_ATTR_MASK_ENDGROUP;
   if (get_attr_z13_groupalone (insn))
mask |= S390_SCHED_ATTR_MASK_GROUPALONE;
+  if (get_attr_z13_groupoftwo (insn))
+   mask |= S390_SCHED_ATTR_MASK_GROUPOFTWO;
   break;
 case PROCESSOR_3906_Z14:
   if (get_attr_z14_cracked (insn))
@@ -14311,6 +14316,8 @@ s390_get_sched_attrmask (rtx_insn *insn)
mask |= S390_SCHED_ATTR_MASK_ENDGROUP;
   if (get_attr_z14_groupalone (insn))
mask |= S390_SCHED_ATTR_MASK_GROUPALONE;
+  if (get_attr_z14_groupoftwo (insn))
+   mask |= S390_SCHED_ATTR_MASK_GROUPOFTWO;
   break;
 default:
   gcc_unreachable ();
@@ -14393,6 +14400,11 @@ s390_sched_score (rtx_insn *insn)
score += 10;
   if ((mask & S390_SCHED_ATTR_MASK_ENDGROUP) == 0)
score += 5;
+  /* If we are in a group of two already, try to schedule another
+group-of-two insn to avoid shortening another group.  */
+  if (sched_state.group_of_two
+ && (mask & S390_SCHED_ATTR_MASK_GROUPOFTWO) != 0)
+   score += 15;
   break;
 case 2:
   /* Prefer not cracked insns while trying to put together a
@@ -14404,6 +14416,10 @@ s390_sched_score (rtx_insn *insn)
   /* Prefer endgroup insns in the last slot.  */
   if ((mask & S390_SCHED_ATTR_MASK_ENDGROUP) != 0)
score += 10;
+  /* Try to avoid group-of-two insns in the last slot as they will
+shorten this group as well as the next one.  */
+  if ((mask & S390_SCHED_ATTR_MASK_GROUPOFTWO) != 0)
+   score = MAX (0, score - 15);
   break;
 }
 
@@ -14595,6 +14611,17 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
 {
   unsigned int mask = s390_get_sched_attrmask (insn);
 
+  if ((mask & S390_SCHED_ATTR_MASK_GROUPOFTWO) != 0)
+   sched_state.group_of_two = true;
+
+  /* If this is a group-of-two insn, we actually ended the last group
+and this insn is the first one of the new group.  */
+  if (sched_state.group_state == 2 && sched_state.group_of_two)
+   {
+ sched_state.side = sched_state.side ? 0 : 1;
+ sched_state.group_state = 0;
+   }
+
   /* Longrunning and side bookkeeping.  */
   for (int i = 0; i < 2; i++)
{
@@ -14645,6 +14672,11 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
  break;
case 1:
  sched_state.group_state++;
+ if (sched_state.group_of_two)
+   {
+ sched_state.group_state = 0;
+ ends_group = true;
+   }
  break;
case 2:
  sched_state.group_state++;
@@ -14700,6 +14732,7 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
{
  sched_state.group_state = 0;
  sched_state.side = sched_state.side ? 0 : 1;
+ sched_state.group_of_two = false;
}
 }
 
@@ -14733,6 +14766,7 @@ s390_sched_init (FILE *file ATTRIBUTE_UNUSED,
   memset (last_scheduled_unit_distance, 0,
  MAX_SCHED_UNITS * NUM_SIDES * sizeof (int));
   sched_state.group_state = 0;
+  sched_state.group_of_two = false;
 }
 }
 
-- 
2.17.0

[PATCH 7/7] S/390: Tune scheduling parameters.

[Robin Dapp]

This patch adapts some scheduling-related parameters.

---
 gcc/config/s390/s390.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 78a707267e8..901807e7833 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -358,12 +358,12 @@ static int fpd_longrunning[NUM_SIDES];
in use for MAX_SCHED_MIX_DISTANCE steps.  Increase this value to
give instruction mix scheduling more priority over instruction
grouping.  */
-#define MAX_SCHED_MIX_SCORE  8
+#define MAX_SCHED_MIX_SCORE  2
 
 /* The maximum distance up to which individual scores will be
calculated.  Everything beyond this gives MAX_SCHED_MIX_SCORE.
Increase this with the OOO windows size of the machine.  */
-#define MAX_SCHED_MIX_DISTANCE 100
+#define MAX_SCHED_MIX_DISTANCE 70
 
 /* Structure used to hold the components of a S/390 memory
address.  A legitimate address on S/390 is of the general
@@ -14238,7 +14238,7 @@ s390_z10_prevent_earlyload_conflicts (rtx_insn **ready, 
int *nready_p)
 }
 
 /* Returns TRUE if BB is entered via a fallthru edge and all other
-   incoming edges are less than unlikely.  */
+   incoming edges are less than likely.  */
 static bool
 s390_bb_fallthru_entry_likely (basic_block bb)
 {
@@ -14254,7 +14254,7 @@ s390_bb_fallthru_entry_likely (basic_block bb)
 
   FOR_EACH_EDGE (e, ei, bb->preds)
 if (e != fallthru_edge
-   && e->probability >= profile_probability::unlikely ())
+   && e->probability >= profile_probability::likely ())
   return false;
 
   return true;
@@ -14390,7 +14390,7 @@ s390_sched_score (rtx_insn *insn)
score += 5;
   if ((mask & S390_SCHED_ATTR_MASK_GROUPALONE) != 0)
score += 10;
-  /* fallthrough */
+  break;
 case 1:
   /* Prefer not cracked insns while trying to put together a
 group.  */
-- 
2.17.0

[PATCH 5/7] S/390: Add side to schedule-mix calculations.

[Robin Dapp]

This patch makes the scheduling score execution-side aware.

---
 gcc/config/s390/s390.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 249df00268a..4dcf1be4445 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -344,11 +344,11 @@ extern int reload_completed;
 
 /* Kept up to date using the SCHED_VARIABLE_ISSUE hook.  */
 static rtx_insn *last_scheduled_insn;
-#define MAX_SCHED_UNITS 4
-static int last_scheduled_unit_distance[MAX_SCHED_UNITS];
-
 #define NUM_SIDES 2
 
+#define MAX_SCHED_UNITS 4
+static int last_scheduled_unit_distance[MAX_SCHED_UNITS][NUM_SIDES];
+
 /* Estimate of number of cycles a long-running insn occupies an
execution unit.  */
 static int fxd_longrunning[NUM_SIDES];
@@ -14421,8 +14421,8 @@ s390_sched_score (rtx_insn *insn)
 CPU.  */
   for (i = 0; i < units; i++, m <<= 1)
if (m & unit_mask)
- score += (last_scheduled_unit_distance[i] * MAX_SCHED_MIX_SCORE /
-   MAX_SCHED_MIX_DISTANCE);
+ score += (last_scheduled_unit_distance[i][sched_state.side]
+ * MAX_SCHED_MIX_SCORE / MAX_SCHED_MIX_DISTANCE);
 
   int other_side = 1 - sched_state.side;
 
@@ -14622,9 +14622,10 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
 
  for (i = 0; i < units; i++, m <<= 1)
if (m & unit_mask)
- last_scheduled_unit_distance[i] = 0;
-   else if (last_scheduled_unit_distance[i] < MAX_SCHED_MIX_DISTANCE)
- last_scheduled_unit_distance[i]++;
+ last_scheduled_unit_distance[i][sched_state.side] = 0;
+   else if (last_scheduled_unit_distance[i][sched_state.side]
+   < MAX_SCHED_MIX_DISTANCE)
+ last_scheduled_unit_distance[i][sched_state.side]++;
}
 
   if ((mask & S390_SCHED_ATTR_MASK_CRACKED) != 0
@@ -14686,9 +14687,10 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
 
  s390_get_unit_mask (insn, );
 
- fprintf (file, ";;\t\tBACKEND: units unused for: ");
+ fprintf (file, ";;\t\tBACKEND: units on this side unused for: ");
  for (j = 0; j < units; j++)
-   fprintf (file, "%d:%d ", j, last_scheduled_unit_distance[j]);
+   fprintf (file, "%d:%d ", j,
+   last_scheduled_unit_distance[j][sched_state.side]);
  fprintf (file, "\n");
}
}
@@ -14713,9 +14715,6 @@ s390_sched_init (FILE *file ATTRIBUTE_UNUSED,
 int verbose ATTRIBUTE_UNUSED,
 int max_ready ATTRIBUTE_UNUSED)
 {
-  last_scheduled_insn = NULL;
-  memset (last_scheduled_unit_distance, 0, MAX_SCHED_UNITS * sizeof (int));
-
   /* If the next basic block is most likely entered via a fallthru edge
  we keep the last sched state.  Otherwise we start a new group.
  The scheduler traverses basic blocks in "instruction stream" ordering
@@ -14729,7 +14728,12 @@ s390_sched_init (FILE *file ATTRIBUTE_UNUSED,
 ? NEXT_INSN (current_sched_info->prev_head) : NULL;
   basic_block bb = insn ? BLOCK_FOR_INSN (insn) : NULL;
   if (s390_tune < PROCESSOR_2964_Z13 || !s390_bb_fallthru_entry_likely (bb))
-sched_state.group_state = 0;
+{
+  last_scheduled_insn = NULL;
+  memset (last_scheduled_unit_distance, 0,
+ MAX_SCHED_UNITS * NUM_SIDES * sizeof (int));
+  sched_state.group_state = 0;
+}
 }
 
 /* This target hook implementation for TARGET_LOOP_UNROLL_ADJUST calculates
-- 
2.17.0

[PATCH 2/7] S/390: Add z14 pipeline description.

[Robin Dapp]

This patch adds the z14 pipeline description.

---
 gcc/config/s390/3906.md | 282 
 gcc/config/s390/s390.c  |  23 +++-
 gcc/config/s390/s390.h  |   2 +-
 gcc/config/s390/s390.md |   3 +
 4 files changed, 307 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/s390/3906.md

diff --git a/gcc/config/s390/3906.md b/gcc/config/s390/3906.md
new file mode 100644
index 000..b2090e2dcf3
--- /dev/null
+++ b/gcc/config/s390/3906.md
@@ -0,0 +1,282 @@
+;; Scheduling description for z14.
+;;   Copyright (C) 2016-2019 Free Software Foundation, Inc.
+;;   Contributed by Andreas Krebbel (andreas.kreb...@de.ibm.com)
+
+;; This file is part of GCC.
+
+;; GCC is free software; you can redistribute it and/or modify it under
+;; the terms of the GNU General Public License as published by the Free
+;; Software Foundation; either version 3, or (at your option) any later
+;; version.
+
+;; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+;; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+;; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+;; for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+
+(define_attr "z14_unit_fpd" ""
+(cond [(eq_attr "mnemonic" "ddb,ddbr,deb,debr,dxbr,sqdb,sqdbr,sqeb,\
+sqebr,sqxbr,vfddb,vfdsb,vfsqdb,vfsqsb,wfddb,wfdsb,wfdxb,wfsqdb,wfsqxb")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z14_unit_fxa" ""
+(cond [(eq_attr "mnemonic" "a,afi,ag,agf,agfi,agfr,agh,aghi,aghik,\
+agr,agrk,ahi,ahik,al,alc,alcg,alcgr,alcr,alfi,alg,algf,algfi,algfr,\
+alghsik,algr,alhsik,alr,alrk,aly,ark,ay,bras,brasl,etnd,exrl,flogr,ic,icm,\
+icmh,icmy,icy,iihf,iilf,ipm,la,larl,lay,lb,lbr,lcgr,lcr,lgb,lgbr,lgf,lgfi,\
+lgfr,lgfrl,lgh,lghi,lghr,lghrl,lgr,lh,lhi,lhr,lhrl,lhy,llcr,llgfr,llghr,\
+llgtr,llhr,llihf,llihh,llihl,llilf,llilh,llill,lngr,lnr,loc,locg,locghi,\
+locgr,lochi,locr,lpgr,lpr,lr,lrv,lrvg,lrvgr,lrvh,lrvr,lt,ltg,ltgf,ltgfr,\
+ltgr,ltr,m,mfy,mg,mgh,mghi,mgrk,mh,mhi,mhy,ml,mlg,mlgr,mlr,mr,ms,msfi,msg,\
+msgf,msgfi,msgfr,msgr,msgrkc,msr,msrkc,msy,n,ng,ngr,ngrk,nihf,nihh,nihl,\
+nilf,nilh,nill,nr,nrk,ny,o,og,ogr,ogrk,oihf,oihh,oihl,oilf,oilh,oill,or,\
+ork,oy,pfpo,popcnt,risbg,risbgn,rll,rllg,s,sg,sgf,sgfr,sgh,sgr,sgrk,sh,\
+shy,sl,slb,slbg,slbgr,slbr,slfi,slg,slgf,slgfi,slgfr,slgr,slgrk,sll,sllg,\
+sllk,slr,slrk,sly,sr,sra,srag,srak,srl,srlg,srlk,sy,x,xg,xgr,xgrk,xihf,\
+xilf,xr,xrk,xy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z14_unit_fxb" ""
+(cond [(eq_attr "mnemonic" "agsi,algsi,alsi,asi,b,bc,bcr,bi,br,brcl,\
+c,cfi,cg,cgf,cgfi,cgfr,cgfrl,cgh,cghi,cghrl,cghsi,cgit,cgr,cgrl,cgrt,ch,\
+chi,chrl,chsi,chy,cit,cl,clfhsi,clfi,clfit,clg,clgf,clgfi,clgfr,clgfrl,\
+clghsi,clgit,clgr,clgrl,clgrt,clgt,clhhsi,clhrl,cli,cliy,clm,clmy,clr,clrl,\
+clrt,clt,cly,cr,crl,crt,cy,j,jg,laa,laag,lan,lang,lao,laog,lat,lax,laxg,\
+lcdfr,ldgr,ldr,lgat,lgdr,lndfr,lpdfr,lzdr,lzer,mvghi,mvhhi,mvhi,mvi,mviy,ni,\
+niy,nop,nopr,ntstg,oi,oiy,ppa,st,stc,stcy,std,stdy,ste,stey,stg,stgrl,sth,\
+sthrl,sthy,stoc,stocg,strl,strv,strvg,strvh,sty,tend,tm,tmh,tmhh,tmhl,tml,\
+tmlh,tmll,tmy,vlgvf,vlgvg,vlgvh,vlr,vlvgb,vlvgf,vlvgg,vlvgh,vlvgp,vst,vstl,\
+vstrl,vstrlr,xi,xiy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z14_unit_fxd" ""
+(cond [(eq_attr "mnemonic" "dlgr,dlr,dr,dsgfr,dsgr")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z14_unit_lsu" ""
+(cond [(eq_attr "mnemonic" "a,adb,aeb,ag,agf,agh,agsi,al,alc,alcg,\
+alg,algf,algsi,alsi,aly,asi,ay,c,cdb,cg,cgf,cgfrl,cgh,cghrl,cghsi,cgrl,ch,\
+chrl,chsi,chy,cl,clc,clfhsi,clg,clgf,clgfrl,clghsi,clgrl,clgt,clhhsi,clhrl,\
+cli,cliy,clm,clmy,clrl,clt,cly,crl,cy,ddb,deb,ear,ic,icm,icmh,icmy,icy,l,\
+laa,laag,lan,lang,lao,laog,lat,lax,laxg,lb,lcbb,ld,lde,ldeb,ldy,le,ley,lg,\
+lgat,lgb,lgf,lgfrl,lgh,lghrl,lgrl,lh,lhrl,lhy,llc,llgc,llgf,llgfrl,llgh,\
+llghrl,llgt,llh,llhrl,loc,locg,lrl,lrv,lrvg,lrvh,lt,ltg,ltgf,ly,m,madb,maeb,\
+meeb,mfy,mg,mgh,mh,mhy,ml,mlg,ms,msdb,mseb,msg,msgf,msy,mvghi,mvhhi,mvhi,\
+mvi,mviy,n,ng,ni,niy,ntstg,ny,o,og,oi,oiy,oy,s,sar,sdb,seb,sfpc,sg,sgf,\
+sgh,sh,shy,sl,slb,slbg,slg,slgf,sly,sqdb,sqeb,st,stc,stcy,std,stdy,ste,\
+stey,stg,stgrl,sth,sthrl,sthy,stoc,stocg,strl,strv,strvg,strvh,sty,sy,\
+tabort,tm,tmy,vl,vlbb,vleb,vlef,vleg,vleh,vll,vllezb,vllezf,vllezg,vllezh,\
+vllezlf,vlrepb,vlrepf,vlrepg,vlreph,vlrl,vlrlr,vst,vstl,vstrl,vstrlr,x,xg,xi,\
+xiy,xy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z14_unit_vfu" ""
+(cond [(eq_attr "mnemonic" "adb,adbr,adtr,aeb,aebr,axbr,axtr,cdb,\
+cdbr,cdtr,cebr,cpsdr,cxbr,cxtr,ddtr,dxtr,fidbr,fidbra,fidtr,fiebr,fiebra,\
+fixbr,fixbra,fixtr,lcdbr,lcebr,lcxbr,ldeb,ldebr,ldetr,le,ledbr,ledtr,ler,\
+ley,lndbr,lnebr,lnxbr,lpdbr,lpebr,lpxbr,ltdbr,ltebr,ltxbr,ltxtr,lxdb,\
+lxdbr,lxdtr,lxeb,lxebr,madb,madbr,maeb,maebr,mdbr,mdtr,meeb,meebr,msdb,\

[PATCH 4/7] S/390: Change handling of group end.

[Robin Dapp]

This patch adds a scheduling state struct and changes
the handling of end-group conditions.

---
 gcc/config/s390/s390.c | 158 ++---
 1 file changed, 68 insertions(+), 90 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 15926ec88cd..249df00268a 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -348,7 +348,6 @@ static rtx_insn *last_scheduled_insn;
 static int last_scheduled_unit_distance[MAX_SCHED_UNITS];
 
 #define NUM_SIDES 2
-static int current_side = 1;
 
 /* Estimate of number of cycles a long-running insn occupies an
execution unit.  */
@@ -14261,17 +14260,15 @@ s390_bb_fallthru_entry_likely (basic_block bb)
   return true;
 }
 
-/* The s390_sched_state variable tracks the state of the current or
-   the last instruction group.
-
-   0,1,2 number of instructions scheduled in the current group
-   3 the last group is complete - normal insns
-   4 the last group was a cracked/expanded insn */
-
-static int s390_sched_state = 0;
+struct s390_sched_state
+{
+  /* Number of insns in the group.  */
+  int group_state;
+  /* Execution side of the group.  */
+  int side;
+} s390_sched_state;
 
-#define S390_SCHED_STATE_NORMAL  3
-#define S390_SCHED_STATE_CRACKED 4
+static struct s390_sched_state sched_state = {0, 1};
 
 #define S390_SCHED_ATTR_MASK_CRACKED0x1
 #define S390_SCHED_ATTR_MASK_EXPANDED   0x2
@@ -14369,14 +14366,14 @@ s390_is_longrunning (rtx_insn *insn)
 
 /* Return the scheduling score for INSN.  The higher the score the
better.  The score is calculated from the OOO scheduling attributes
-   of INSN and the scheduling state s390_sched_state.  */
+   of INSN and the scheduling state sched_state.  */
 static int
 s390_sched_score (rtx_insn *insn)
 {
   unsigned int mask = s390_get_sched_attrmask (insn);
   int score = 0;
 
-  switch (s390_sched_state)
+  switch (sched_state.group_state)
 {
 case 0:
   /* Try to put insns into the first slot which would otherwise
@@ -14408,21 +14405,6 @@ s390_sched_score (rtx_insn *insn)
   if ((mask & S390_SCHED_ATTR_MASK_ENDGROUP) != 0)
score += 10;
   break;
-case S390_SCHED_STATE_NORMAL:
-  /* Prefer not cracked insns if the last was not cracked.  */
-  if ((mask & S390_SCHED_ATTR_MASK_CRACKED) == 0
- && (mask & S390_SCHED_ATTR_MASK_EXPANDED) == 0)
-   score += 5;
-  if ((mask & S390_SCHED_ATTR_MASK_GROUPALONE) != 0)
-   score += 10;
-  break;
-case S390_SCHED_STATE_CRACKED:
-  /* Try to keep cracked insns together to prevent them from
-interrupting groups.  */
-  if ((mask & S390_SCHED_ATTR_MASK_CRACKED) != 0
- || (mask & S390_SCHED_ATTR_MASK_EXPANDED) != 0)
-   score += 5;
-  break;
 }
 
   if (s390_tune >= PROCESSOR_2964_Z13)
@@ -14442,46 +14424,46 @@ s390_sched_score (rtx_insn *insn)
  score += (last_scheduled_unit_distance[i] * MAX_SCHED_MIX_SCORE /
MAX_SCHED_MIX_DISTANCE);
 
-  int other_side = 1 - current_side;
+  int other_side = 1 - sched_state.side;
 
   /* Try to delay long-running insns when side is busy.  */
   if (s390_is_longrunning (insn))
{
  if (s390_tune == PROCESSOR_2964_Z13)
{
- if (get_attr_z13_unit_fxd (insn) && fxd_longrunning[current_side]
- && fxd_longrunning[other_side] <= 
fxd_longrunning[current_side])
+ if (get_attr_z13_unit_fxd (insn) && 
fxd_longrunning[sched_state.side]
+ && fxd_longrunning[other_side] <= 
fxd_longrunning[sched_state.side])
score = MAX (0, score - 10);
 
  if (get_attr_z13_unit_fxd (insn)
- && fxd_longrunning[other_side] >= 
fxd_longrunning[current_side])
+ && fxd_longrunning[other_side] >= 
fxd_longrunning[sched_state.side])
score += 10;
 
- if (get_attr_z13_unit_fpd (insn) && fpd_longrunning[current_side]
- && fpd_longrunning[other_side] <= 
fpd_longrunning[current_side])
+ if (get_attr_z13_unit_fpd (insn) && 
fpd_longrunning[sched_state.side]
+ && fpd_longrunning[other_side] <= 
fpd_longrunning[sched_state.side])
score = MAX (0, score - 10);
 
  if (get_attr_z13_unit_fpd (insn)
- && fpd_longrunning[other_side] >= 
fpd_longrunning[current_side])
+ && fpd_longrunning[other_side] >= 
fpd_longrunning[sched_state.side])
score += 10;
}
 
  if (s390_tune == PROCESSOR_3906_Z14)
{
- if (get_attr_z14_unit_fxd (insn) && fxd_longrunning[current_side]
- && fxd_longrunning[other_side] <= 
fxd_longrunning[current_side])
+ if (get_attr_z14_unit_fxd (insn) && 
fxd_longrunning[sched_state.side]
+ && fxd_longrunning[other_side] <= 
fxd_longrunning[sched_state.side])
score = MAX (0, score - 

[PATCH 1/7] S/390: Change z13 pipeline description.

[Robin Dapp]

This patch adapts the z13 pipeline description.

---
 gcc/config/s390/2964.md | 372 ++--
 gcc/config/s390/s390.c  |  39 ++---
 2 files changed, 226 insertions(+), 185 deletions(-)

diff --git a/gcc/config/s390/2964.md b/gcc/config/s390/2964.md
index 19e641bd252..a7897bcf58a 100644
--- a/gcc/config/s390/2964.md
+++ b/gcc/config/s390/2964.md
@@ -18,215 +18,257 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .
 
+(define_attr "z13_unit_fpd" ""
+(cond [(eq_attr "mnemonic" "ddb,ddbr,deb,debr,dxbr,sqdb,sqdbr,sqeb,\
+sqebr,sqxbr,vfddb,vfdsb,vfsqdb,vfsqsb,wfddb,wfdsb,wfdxb,wfsqdb,wfsqxb")
+ (const_int 1)] (const_int 0)))
 
-; generator options: vector_ecycs=12 cracked_ecycs=6 scale_ecycs=5
+(define_attr "z13_unit_fxa" ""
+(cond [(eq_attr "mnemonic" "a,afi,ag,agf,agfi,agfr,aghi,aghik,agr,\
+agrk,ahi,ahik,al,alc,alcg,alcgr,alcr,alfi,alg,algf,algfi,algfr,alghsik,\
+algr,alhsik,alr,alrk,aly,ark,ay,bras,brasl,etnd,exrl,flogr,ic,icm,icmh,\
+icmy,icy,iihf,iilf,ipm,la,larl,lay,lb,lbr,lcgr,lcr,lgb,lgbr,lgf,lgfi,lgfr,\
+lgfrl,lgh,lghi,lghr,lghrl,lgr,lh,lhi,lhr,lhrl,lhy,llcr,llgfr,llghr,llgtr,\
+llhr,llihf,llihh,llihl,llilf,llilh,llill,lngr,lnr,loc,locg,locghi,locgr,\
+lochi,locr,lpgr,lpr,lr,lrv,lrvg,lrvgr,lrvh,lrvr,lt,ltg,ltgf,ltgfr,ltgr,ltr,\
+m,mfy,mghi,mh,mhi,mhy,ml,mlg,mlgr,mlr,mr,ms,msfi,msg,msgf,msgfi,msgfr,\
+msgr,msr,msy,n,ng,ngr,ngrk,nihf,nihh,nihl,nilf,nilh,nill,nr,nrk,ny,o,og,\
+ogr,ogrk,oihf,oihh,oihl,oilf,oilh,oill,or,ork,oy,pfpo,popcnt,ppa,risbg,\
+risbgn,rll,rllg,s,sg,sgf,sgfr,sgr,sgrk,sh,shy,sl,slb,slbg,slbgr,slbr,slfi,\
+slg,slgf,slgfi,slgfr,slgr,slgrk,sll,sllg,sllk,slr,slrk,sly,sr,sra,srag,\
+srak,srl,srlg,srlk,sy,x,xg,xgr,xgrk,xihf,xilf,xr,xrk,xy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z13_unit_fxb" ""
+(cond [(eq_attr "mnemonic" "agsi,algsi,alsi,asi,b,bc,bcr,br,brcl,c,\
+cfi,cg,cgf,cgfi,cgfr,cgfrl,cgh,cghi,cghrl,cghsi,cgit,cgr,cgrl,cgrt,ch,chi,\
+chrl,chsi,chy,cit,cl,clfhsi,clfi,clfit,clg,clgf,clgfi,clgfr,clgfrl,clghsi,\
+clgit,clgr,clgrl,clgrt,clgt,clhhsi,clhrl,cli,cliy,clm,clmy,clr,clrl,clrt,\
+clt,cly,cr,crl,crt,cy,j,jg,laa,laag,lan,lang,lao,laog,lat,lax,laxg,lcdfr,\
+ldgr,ldr,lgat,lgdr,lndfr,lpdfr,lzdr,lzer,mvghi,mvhhi,mvhi,mvi,mviy,ni,niy,\
+nop,nopr,ntstg,oi,oiy,st,stc,stcy,std,stdy,ste,stey,stg,stgrl,sth,sthrl,\
+sthy,stoc,stocg,strl,strv,strvg,strvh,sty,tend,tm,tmh,tmhh,tmhl,tml,tmlh,\
+tmll,tmy,vlgvf,vlgvg,vlgvh,vlr,vlvgb,vlvgf,vlvgg,vlvgh,vlvgp,vst,vstl,xi,\
+xiy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z13_unit_fxd" ""
+(cond [(eq_attr "mnemonic" "dlgr,dlr,dr,dsgfr,dsgr")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z13_unit_lsu" ""
+(cond [(eq_attr "mnemonic" "a,adb,aeb,ag,agf,agsi,al,alc,alcg,alg,\
+algf,algsi,alsi,aly,asi,ay,c,cdb,cg,cgf,cgfrl,cgh,cghrl,cghsi,cgrl,ch,chrl,\
+chsi,chy,cl,clc,clfhsi,clg,clgf,clgfrl,clghsi,clgrl,clgt,clhhsi,clhrl,cli,\
+cliy,clm,clmy,clrl,clt,cly,crl,cy,ddb,deb,ear,ic,icm,icmh,icmy,icy,l,laa,\
+laag,lan,lang,lao,laog,lat,lax,laxg,lb,lcbb,ld,lde,ldeb,ldy,le,ley,lg,lgat,\
+lgb,lgf,lgfrl,lgh,lghrl,lgrl,lh,lhrl,lhy,llc,llgc,llgf,llgfrl,llgh,llghrl,\
+llgt,llh,llhrl,loc,locg,lrl,lrv,lrvg,lrvh,lt,ltg,ltgf,ly,m,madb,maeb,meeb,\
+mfy,mh,mhy,ml,mlg,ms,msdb,mseb,msg,msgf,msy,mvghi,mvhhi,mvhi,mvi,mviy,n,\
+ng,ni,niy,ntstg,ny,o,og,oi,oiy,oy,s,sar,sdb,seb,sfpc,sg,sgf,sh,shy,sl,\
+slb,slbg,slg,slgf,sly,sqdb,sqeb,st,stc,stcy,std,stdy,ste,stey,stg,stgrl,\
+sth,sthrl,sthy,stoc,stocg,strl,strv,strvg,strvh,sty,sy,tabort,tm,tmy,vl,\
+vlbb,vleb,vlef,vleg,vleh,vll,vllezb,vllezf,vllezg,vllezh,vllezlf,vlrepb,\
+vlrepf,vlrepg,vlreph,vst,vstl,x,xg,xi,xiy,xy")
+ (const_int 1)] (const_int 0)))
+
+(define_attr "z13_unit_vfu" ""
+(cond [(eq_attr "mnemonic" "adb,adbr,adtr,aeb,aebr,axbr,axtr,cdb,\
+cdbr,cdtr,cebr,cpsdr,cxbr,cxtr,ddtr,dxtr,fidbr,fidbra,fidtr,fiebr,fiebra,\
+fixbr,fixbra,fixtr,lcdbr,lcebr,lcxbr,ldeb,ldebr,ldetr,le,ledbr,ledtr,ler,\
+ley,lndbr,lnebr,lnxbr,lpdbr,lpebr,lpxbr,ltdbr,ltebr,ltxbr,ltxtr,lxdb,\
+lxdbr,lxdtr,lxeb,lxebr,madb,madbr,maeb,maebr,mdbr,mdtr,meeb,meebr,msdb,\
+msdbr,mseb,msebr,mxbr,mxtr,sdb,sdbr,sdtr,seb,sebr,sxbr,sxtr,tcdb,tceb,tcxb,\
+tdcdt,tdcet,tdcxt,vab,vaccb,vacccq,vaccf,vaccg,vacch,vaccq,vacq,vaf,vag,vah,\
+vaq,vavgb,vavgf,vavgg,vavgh,vavglb,vavglf,vavglg,vavglh,vcdgb,vcdlgb,\
+vceqb,vceqbs,vceqf,vceqfs,vceqg,vceqgs,vceqh,vceqhs,vcgdb,vchb,vchbs,vchf,\
+vchfs,vchg,vchgs,vchh,vchhs,vchlb,vchlbs,vchlf,vchlfs,vchlg,vchlgs,vchlh,\
+vchlhs,vcksm,vclgdb,vclzf,vctzb,vctzf,vctzg,vctzh,verimb,verimf,verimg,\
+verimh,verllb,verllf,verllg,verllh,verllvb,verllvf,verllvg,verllvh,veslb,\
+veslf,veslg,veslh,veslvb,veslvf,veslvg,veslvh,vesrab,vesraf,vesrag,vesrah,\
+vesravb,vesravf,vesravg,vesravh,vesrlb,vesrlf,vesrlg,vesrlh,vesrlvb,vesrlvf,\
+vesrlvg,vesrlvh,vfadb,vfasb,vfcedb,vfcedbs,vfcesb,vfcesbs,vfchdb,vfchdbs,\
+vfchedb,vfchedbs,vfchesb,vfchesbs,vfchsb,vfchsbs,vfeeb,vfeef,vfeeh,vfeezbs,\

[PATCH 3/7] S/390: Change handling of long-running instructions.

[Robin Dapp]

This patch makes the detection of long-running instructions
independent of their latency and checks the execution unit
instead.

---
 gcc/config/s390/s390.c | 73 +++---
 1 file changed, 55 insertions(+), 18 deletions(-)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 95a4460dcf5..15926ec88cd 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -349,12 +349,11 @@ static int last_scheduled_unit_distance[MAX_SCHED_UNITS];
 
 #define NUM_SIDES 2
 static int current_side = 1;
-#define LONGRUNNING_THRESHOLD 20
 
 /* Estimate of number of cycles a long-running insn occupies an
execution unit.  */
-static unsigned fxd_longrunning[NUM_SIDES];
-static unsigned fpd_longrunning[NUM_SIDES];
+static int fxd_longrunning[NUM_SIDES];
+static int fpd_longrunning[NUM_SIDES];
 
 /* The maximum score added for an instruction whose unit hasn't been
in use for MAX_SCHED_MIX_DISTANCE steps.  Increase this value to
@@ -14357,6 +14356,17 @@ s390_get_unit_mask (rtx_insn *insn, int *units)
   return mask;
 }
 
+/* Returns TRUE if INSN is a long-running instruction.  */
+static bool
+s390_is_longrunning (rtx_insn *insn)
+{
+  if (insn == NULL_RTX)
+return false;
+
+  return get_attr_z13_unit_fxd (insn) || get_attr_z13_unit_fpd (insn)
+|| get_attr_z14_unit_fxd (insn) || get_attr_z14_unit_fpd (insn);
+}
+
 /* Return the scheduling score for INSN.  The higher the score the
better.  The score is calculated from the OOO scheduling attributes
of INSN and the scheduling state s390_sched_state.  */
@@ -14432,20 +14442,48 @@ s390_sched_score (rtx_insn *insn)
  score += (last_scheduled_unit_distance[i] * MAX_SCHED_MIX_SCORE /
MAX_SCHED_MIX_DISTANCE);
 
-  unsigned latency = insn_default_latency (insn);
-
   int other_side = 1 - current_side;
 
   /* Try to delay long-running insns when side is busy.  */
-  if (latency > LONGRUNNING_THRESHOLD)
+  if (s390_is_longrunning (insn))
{
- if (get_attr_z13_unit_fxu (insn) && fxd_longrunning[current_side]
- && fxd_longrunning[other_side] <= fxd_longrunning[current_side])
-   score = MAX (0, score - 10);
+ if (s390_tune == PROCESSOR_2964_Z13)
+   {
+ if (get_attr_z13_unit_fxd (insn) && fxd_longrunning[current_side]
+ && fxd_longrunning[other_side] <= 
fxd_longrunning[current_side])
+   score = MAX (0, score - 10);
 
- if (get_attr_z13_unit_vfu (insn) && fpd_longrunning[current_side]
- && fpd_longrunning[other_side] <= fpd_longrunning[current_side])
-   score = MAX (0, score - 10);
+ if (get_attr_z13_unit_fxd (insn)
+ && fxd_longrunning[other_side] >= 
fxd_longrunning[current_side])
+   score += 10;
+
+ if (get_attr_z13_unit_fpd (insn) && fpd_longrunning[current_side]
+ && fpd_longrunning[other_side] <= 
fpd_longrunning[current_side])
+   score = MAX (0, score - 10);
+
+ if (get_attr_z13_unit_fpd (insn)
+ && fpd_longrunning[other_side] >= 
fpd_longrunning[current_side])
+   score += 10;
+   }
+
+ if (s390_tune == PROCESSOR_3906_Z14)
+   {
+ if (get_attr_z14_unit_fxd (insn) && fxd_longrunning[current_side]
+ && fxd_longrunning[other_side] <= 
fxd_longrunning[current_side])
+   score = MAX (0, score - 10);
+
+ if (get_attr_z14_unit_fxd (insn)
+ && fxd_longrunning[other_side] >= 
fxd_longrunning[current_side])
+   score += 10;
+
+ if (get_attr_z14_unit_fpd (insn) && fpd_longrunning[current_side]
+ && fpd_longrunning[other_side] <= 
fpd_longrunning[current_side])
+   score = MAX (0, score - 10);
+
+ if (get_attr_z14_unit_fpd (insn)
+ && fpd_longrunning[other_side] >= 
fpd_longrunning[current_side])
+   score += 10;
+   }
}
 }
 
@@ -14629,16 +14667,15 @@ s390_sched_variable_issue (FILE *file, int verbose, 
rtx_insn *insn, int more)
 
   for (int i = 0; i < 2; i++)
{
- if (fxd_longrunning[i] >= 1)
-   fxd_longrunning[i] -= 1;
- if (fpd_longrunning[i] >= 1)
-   fpd_longrunning[i] -= 1;
+ fxd_longrunning[i] = MAX (0, fxd_longrunning[i] - 1);
+ fpd_longrunning[i] = MAX (0, fpd_longrunning[i] - 1);
}
 
   unsigned latency = insn_default_latency (insn);
-  if (latency > LONGRUNNING_THRESHOLD)
+  if (s390_is_longrunning (insn))
{
- if (get_attr_z13_unit_fxu (insn))
+ if (get_attr_z13_unit_fxd (insn)
+ || get_attr_z14_unit_fxd (insn))
fxd_longrunning[current_side] = latency;
  else
fpd_longrunning[current_side] = latency;
-- 
2.17.0

[PATCH 0/7] S/390: Rework instruction scheduling.

[Robin Dapp]

Hi,

this patch set adds new pipeline descriptions for z13 and z14.  Based
on that, the scoring and some properties are handled differently in
the scheduler hooks.

Regards
 Robin

Robin Dapp (7):
  S/390: Change z13 pipeline description.
  S/390: Add z14 pipeline description.
  S/390: Change handling of long-running instructions.
  S/390: Change handling of group end.
  S/390: Add side to schedule-mix calculations.
  S/390: Add handling for group-of-two instructions.
  S/390: Tune scheduling parameters.

 gcc/config/s390/2964.md | 373 ++--
 gcc/config/s390/3906.md | 281 ++
 gcc/config/s390/s390.c  | 303 +++-
 gcc/config/s390/s390.h  |   2 +-
 gcc/config/s390/s390.md |   3 +
 5 files changed, 679 insertions(+), 283 deletions(-)
 create mode 100644 gcc/config/s390/3906.md

-- 
2.17.0

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

[Jonathan Wakely]

On 09/03/19 12:46 -0500, John David Anglin wrote:

The hppa*-*-hpux* target has no builtin atomic support, so we need to 
explicitly link
applications requiring atomic support against libatomic.

Okay?

Dave
--
John David Anglin  dave.ang...@bell.net

2019-03-09  John David Anglin  

PR libstdc++/89461
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc: Link
against libatomic on hppa*-*-hpux*.
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc: Likewise.
* testsuite/experimental/net/timer/waitable/cons.cc: Likewise.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
* testsuite/lib/libstdc++.exp: Locate libatomic.



What do you think about adding the following?

--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,6 +257,15 @@ proc add_options_for_net_ts { flags } {
return $flags
}

+# Add to FLAGS all the target-specific flags to link to libatomic, if required.
+
+proc add_options_for_libatomic { flags } {
+if { [istarget hppa*-*-hpux*] } {
+   return "$flags -L../../libatomic/.libs -latomic"
+}
+return $flags
+}
+
# Like dg-options, but adds to the default options rather than replacing them.

proc dg-additional-options { args } {





Index: testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
===
--- testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc (revision 
269442)
+++ testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc (working copy)
@@ -22,6 +22,7 @@
// { dg-require-effective-target c++11 }
// { dg-require-effective-target pthread }
// { dg-require-cstdint "" }
+// { dg-additional-options "-L../../libatomic/.libs -latomic" { target 
hppa*-*-hpux* } }


And then this would be:

--- a/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
@@ -19,6 +19,7 @@

// { dg-do run }
// { dg-options "-pthread"  }
+// { dg-add-options libatomic }
// { dg-require-effective-target c++11 }
// { dg-require-effective-target pthread }
// { dg-require-cstdint "" }

Re: [Patch, libstdc++.exp]Update the usage of cached result, rebuild nlocale wrapper for each variant.

[Jonathan Wakely]

Hi, I've just noticed this in your r266209 change from November:

On 16/11/18 10:42 +, Renlin Li wrote:

+return [check_v3_target_prop_cached et_parallel_mode {
+   global cxxflags
+   global v3-libgomp
# If 'make check-parallel' is running the test succeeds.
if { ${v3-libgomp} == 1 && [regexp "libgomp" $cxxflags] } {
-   set et_parallel_mode 1
+   return1 1


Is this a typo? It should be "return 1" not "return1 1" right?

Re: [PATCH] Improve JSON format for group functions.

[Martin Liška]

On 2/27/19 1:32 PM, Martin Liška wrote:
> Hi.
> 
> The patch adds missing information into JSON intermediate format.
> Before the patch one can't assign 'lines' to 'functions' in case
> one has a group function (e.g. a template function).
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I will install it if not objections.
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-02-27  Martin Liska  
> 
>   * gcov.c (output_intermediate_json_line): When a line
>   belongs to a group of functions, print function name
>   for each of such line entry.
>   (output_json_intermediate_file): Add new argument.
>   * doc/gcov.texi: Document the change.
> ---
>  gcc/doc/gcov.texi |  5 +
>  gcc/gcov.c| 14 ++
>  2 files changed, 15 insertions(+), 4 deletions(-)
> 
> 

This is final version of the patch I'm going to install.

Martin
>From 90a136a54501ee4f8f4da4c21b44bb1399985688 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 27 Feb 2019 09:16:40 +0100
Subject: [PATCH] Improve JSON format: add function names for lines.

gcc/ChangeLog:

2019-03-05  Martin Liska  

	* gcov.c (output_intermediate_json_line): Print function
	name of each line.
	(output_json_intermediate_file): Add new argument.
	* doc/gcov.texi: Document the change.
---
 gcc/doc/gcov.texi |  5 +
 gcc/gcov.c| 20 
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index eaac2f69409..0960e4acb26 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -276,6 +276,7 @@ Each @var{line} has the following form:
   "count": @var{count},
   "line_number": @var{line_number},
   "unexecuted_block": @var{unexecuted_block}
+  "function_name": @var{function_name},
 @}
 @end smallexample
 
@@ -294,6 +295,10 @@ Fields of the @var{line} element have following semantics:
 (not all statements on the line are executed)
 @end itemize
 
+@item
+@var{function_name}: a name of a function this @var{line} belongs to
+(for a line with an inlined statements can be not set)
+
 Each @var{branch} has the following form:
 
 @smallexample
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 9e27a826ea4..37e787a1823 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -1041,17 +1041,21 @@ process_args (int argc, char **argv)
   return optind;
 }
 
-/* Output intermediate LINE sitting on LINE_NUM to JSON OBJECT.  */
+/* Output intermediate LINE sitting on LINE_NUM to JSON OBJECT.
+   Add FUNCTION_NAME to the LINE.  */
 
 static void
 output_intermediate_json_line (json::array *object,
-			   line_info *line, unsigned line_num)
+			   line_info *line, unsigned line_num,
+			   const char *function_name)
 {
   if (!line->exists)
 return;
 
   json::object *lineo = new json::object ();
   lineo->set ("line_number", new json::number (line_num));
+  if (function_name != NULL)
+lineo->set ("function_name", new json::string (function_name));
   lineo->set ("count", new json::number (line->count));
   lineo->set ("unexecuted_block",
 	  new json::literal (line->has_unexecuted_block));
@@ -1141,6 +1145,8 @@ output_json_intermediate_file (json::array *json_files, source_info *src)
   json::array *lineso = new json::array ();
   root->set ("lines", lineso);
 
+  function_info *last_non_group_fn = NULL;
+
   for (unsigned line_num = 1; line_num <= src->lines.size (); line_num++)
 {
   vector *fns = src->get_functions_at_location (line_num);
@@ -1150,17 +1156,23 @@ output_json_intermediate_file (json::array *json_files, source_info *src)
 	for (vector::iterator it2 = fns->begin ();
 	 it2 != fns->end (); it2++)
 	  {
+	if (!(*it2)->is_group)
+	  last_non_group_fn = *it2;
+
 	vector  = (*it2)->lines;
 	for (unsigned i = 0; i < lines.size (); i++)
 	  {
 		line_info *line = [i];
-		output_intermediate_json_line (lineso, line, line_num + i);
+		output_intermediate_json_line (lineso, line, line_num + i,
+	   (*it2)->m_name);
 	  }
 	  }
 
   /* Follow with lines associated with the source file.  */
   if (line_num < src->lines.size ())
-	output_intermediate_json_line (lineso, >lines[line_num], line_num);
+	output_intermediate_json_line (lineso, >lines[line_num], line_num,
+   (last_non_group_fn != NULL
+	? last_non_group_fn->m_name : NULL));
 }
 }
 
-- 
2.21.0

[PATCH] Fix PR89653

[Richard Biener]

The following fixes a missed vectorization of std::min() when
only one argument is a temporary.  The following patch is the least
intrusive and safest one - PRE already performs the necessary
work to make this vectorizable, it's just that we end up with
a dead store and clobber of a stack-local that the vectorizer is
not happy about.  The easiest fix is to schedule an update-address-taken
phase at the right spot which rewrites it into SSA and then DCE
can get rid of it.  DSE would also do the job but is more expensive.
Since PRE/VN have the chance to expose things that can be written
into SSA doing so before loop opts sounds like a good idea in any case.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Queued for GCC 10 for which I also have a fix for phiprop which
usually deals with std::min/max if-conversion.  The one below
is quite safe but it's not a regression unfortunately.

Richard.

2019-03-11  Richard Biener  

PR tree-optimization/89653
* tree-ssa-loop.c (pass_data_tree_loop_init): Execute
update-address-taken before the pass.
* passes.def (pass_tree_loop_init): Put comment before it.

* g++.dg/vect/pr89653.cc: New testcase.

Index: gcc/tree-ssa-loop.c
===
--- gcc/tree-ssa-loop.c (revision 269569)
+++ gcc/tree-ssa-loop.c (working copy)
@@ -330,7 +330,7 @@ const pass_data pass_data_tree_loop_init
   PROP_cfg, /* properties_required */
   0, /* properties_provided */
   0, /* properties_destroyed */
-  0, /* todo_flags_start */
+  TODO_update_address_taken, /* todo_flags_start */
   0, /* todo_flags_finish */
 };
 
Index: gcc/passes.def
===
--- gcc/passes.def  (revision 269569)
+++ gcc/passes.def  (working copy)
@@ -261,6 +261,8 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_fix_loops);
   NEXT_PASS (pass_tree_loop);
   PUSH_INSERT_PASSES_WITHIN (pass_tree_loop)
+  /* Before loop_init we rewrite no longer addressed locals into SSA
+form if possible.  */
  NEXT_PASS (pass_tree_loop_init);
  NEXT_PASS (pass_tree_unswitch);
  NEXT_PASS (pass_scev_cprop);
Index: gcc/testsuite/g++.dg/vect/pr89653.cc
===
--- gcc/testsuite/g++.dg/vect/pr89653.cc(nonexistent)
+++ gcc/testsuite/g++.dg/vect/pr89653.cc(working copy)
@@ -0,0 +1,12 @@
+// { dg-do compile }
+// { dg-require-effective-target vect_double }
+
+#include 
+
+void loop1(double * const __restrict__ vec, double x, int end)
+{
+  for (int i = 0; i < end; ++i)
+vec[i] = std::min(vec[i], vec[i]/x);
+}
+
+// { dg-final { scan-tree-dump "vectorized 1 loops" "vect" } }

Re: [GCC, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Richard Biener]

On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:

> Hi,
> 
> Any objections to me backporting this to GCC 8 and 7?

No, go ahead (after proper testing).

Richard.

> Cheers,
> Andre
> 
> On 08/03/2019 17:30, Andre Vieira (lists) wrote:
> > Hi,
> > 
> > vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs that
> > do not support double precision.  This patch fixes that.
> > 
> > Regression tested for arm-none-eabi.
> > 
> > Committed in r269499.
> > 
> > Cheers,
> > Andre
> > 
> > gcc/ChangeLog:
> > 2019-03-08  Andre Vieira  
> > 
> >      * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add TARGET_VFP_DOUBLE
> >      requirement.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2019-03-08  Andre Vieira  
> > 
> >      * gcc.target/arm/f16_f64_conv_no_dp.c: New test.
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] Fix in -std=c++2a mode (PR libstdc++/89641)

[Jonathan Wakely]

On 11/03/19 08:58 +0100, Jakub Jelinek wrote:

On Sun, Mar 10, 2019 at 10:36:08PM +0100, Jakub Jelinek wrote:

Ok for trunk if normal bootstrap/regtest succeeds (i.e. including the default 
flags
testing)?


Normal bootstrap/regtest on x86_64-linux and i686-linux succeeded too.


2019-03-10  Jakub Jelinek  

PR libstdc++/89641
* include/std/atomic (atomic::store, atomic::load,
atomic::exchange, atomic::compare_exchange_weak,
atomic::compare_exchange_strong): Cast __m or __s and __f to int.
* include/bits/atomic_base.h (__atomic_base::operator++,
__atomic_base::operator--, __atomic_base::operator+=,
__atomic_base::operator-=, __atomic_base::operator&=,
__atomic_base::operator|=, __atomic_base::operator^=,
__atomic_base::operator++, __atomic_base::operator--,
__atomic_base::operator+=, __atomic_base::operator-=): Cast
memory_order_seq_cst to int.


OK for trunk, thanks.

I'll make sure we have a test that runs routinely with -std=gnu++2a.

Re: GCC 7 backport

[Martin Liška]

Hi.

Another 2 patches that I've just tested.

Thanks,
Martin
>From a4ec4d12444bc2fed3fbf559d6cae4618caab7c8 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 18 Feb 2019 09:46:19 +
Subject: [PATCH 2/2] Backport r268981

libcpp/ChangeLog:

2019-02-18  Martin Liska  

	PR c++/89383
	* line-map.c (linemap_line_start): Use 1UL in order
	to not overflow.
---
 libcpp/line-map.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 5827f303b6d..ddcb0111f4b 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -756,7 +756,8 @@ linemap_line_start (struct line_maps *set, linenum_type to_line,
 	  || ( /* We can't reuse the map if the line offset is sufficiently
 		  large to cause overflow when computing location_t values.  */
 	  (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
-	  >= (1U << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
+	  >= (((uint64_t) 1)
+		  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
 	  || range_bits < map->m_range_bits)
 	map = linemap_check_ordinary
 	(const_cast 
-- 
2.21.0

>From c4a45a0f56b8eb91295260332989382180418506 Mon Sep 17 00:00:00 2001
From: dmalcolm 
Date: Tue, 12 Feb 2019 01:09:31 +
Subject: [PATCH 1/2] Backport r268789

gcc/ChangeLog:

2019-02-11  David Malcolm  

	PR lto/88147
	* input.c (selftest::test_line_offset_overflow): New selftest.
	(selftest::input_c_tests): Call it.

libcpp/ChangeLog:

2019-02-11  Martin Liska  

	PR lto/88147
	* line-map.c (linemap_line_start): Don't reuse the existing line
	map if the line offset is sufficiently large to cause overflow
	when computing location_t values.
---
 gcc/input.c   | 30 ++
 libcpp/line-map.c |  4 
 2 files changed, 34 insertions(+)

diff --git a/gcc/input.c b/gcc/input.c
index 80718100d0c..6412d70f4e2 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -3480,6 +3480,34 @@ for_each_line_table_case (void (*testcase) (const line_table_case &))
   ASSERT_EQ (num_cases_tested, 2 * 12);
 }
 
+/* Verify that when presented with a consecutive pair of locations with
+   a very large line offset, we don't attempt to consolidate them into
+   a single ordinary linemap where the line offsets within the line map
+   would lead to overflow (PR lto/88147).  */
+
+static void
+test_line_offset_overflow ()
+{
+  line_table_test ltt (line_table_case (5, 0));
+
+  linemap_add (line_table, LC_ENTER, false, "foo.c", 0);
+  linemap_line_start (line_table, 1, 100);
+  location_t loc_a = linemap_line_start (line_table, 2578, 255);
+  assert_loceq ("foo.c", 2578, 0, loc_a);
+
+  const line_map_ordinary *ordmap_a = LINEMAPS_LAST_ORDINARY_MAP (line_table);
+  ASSERT_EQ (ordmap_a->m_column_and_range_bits, 13);
+  ASSERT_EQ (ordmap_a->m_range_bits, 5);
+
+  location_t loc_b = linemap_line_start (line_table, 404198, 512);
+  assert_loceq ("foo.c", 404198, 0, loc_b);
+
+  /* We should have started a new linemap, rather than attempting to store
+ a very large line offset.  */
+  const line_map_ordinary *ordmap_b = LINEMAPS_LAST_ORDINARY_MAP (line_table);
+  ASSERT_NE (ordmap_a, ordmap_b);
+}
+
 /* Run all of the selftests within this file.  */
 
 void
@@ -3518,6 +3546,8 @@ input_c_tests ()
   for_each_line_table_case (test_lexer_char_constants);
 
   test_reading_source_line ();
+
+  test_line_offset_overflow ();
 }
 
 } // namespace selftest
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 949489eb1a1..5827f303b6d 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -753,6 +753,10 @@ linemap_line_start (struct line_maps *set, linenum_type to_line,
   if (line_delta < 0
 	  || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
 	  || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
+	  || ( /* We can't reuse the map if the line offset is sufficiently
+		  large to cause overflow when computing location_t values.  */
+	  (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
+	  >= (1U << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
 	  || range_bits < map->m_range_bits)
 	map = linemap_check_ordinary
 	(const_cast 
-- 
2.21.0

Re: [GCC, Arm, committed] Fix availability of FP16-FP64 conversion instructions

[Andre Vieira (lists)]

Hi,

Any objections to me backporting this to GCC 8 and 7?

Cheers,
Andre

On 08/03/2019 17:30, Andre Vieira (lists) wrote:

Hi,

vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs 
that do not support double precision.  This patch fixes that.


Regression tested for arm-none-eabi.

Committed in r269499.

Cheers,
Andre

gcc/ChangeLog:
2019-03-08  Andre Vieira  

     * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add TARGET_VFP_DOUBLE
     requirement.

gcc/testsuite/ChangeLog:

2019-03-08  Andre Vieira  

     * gcc.target/arm/f16_f64_conv_no_dp.c: New test.

[patch] Fix ASAN failures on SPARC64/Linux

[Eric Botcazou]

Hi,

ASAN was enabled for the SPARC architecture during GCC 9 development but it 
doesn't really work on SPARC64/Linux because of the specific layout of the 
virtual memory address space.  Fortunately this is (easily) fixable and the 
fix has been accepted upstream, along with other fixes for SPARC (I have 
attached the asan/asan_mapping_sparc64.h file accepted upstream).

But, since GCC also hardcodes the scaling done by ASAN, this also requires a 
small adjustment to the compiler proper by means of a hook, tentatively called 
TARGET_ASAN_SHADOW_LEFT_SHIFT, which is defined to NULL except for SPARC.  It
yields a 100% clean ASAN testsuite on SPARC64/Linux (32-bit and 64-bit).

Tested on SPARC64/Linux, SPARC/Solaris and x86-64/Linux, OK for the mainline?


2019-03-11  Eric Botcazou  

PR sanitizer/80953
* target.def (asan_shadow_left_shift): New hook.
(asan_shadow_offset): Minor tweak.
* doc/tm.texi.in: Add TARGET_ASAN_SHADOW_LEFT_SHIFT.
* doc/tm.texi: Regenerate.
* asan.c (asan_emit_stack_protection): Do a preliminary left shift if
TARGET_ASAN_SHADOW_LEFT_SHIFT is positive.
(build_shadow_mem_access): Likewise.
* config/sparc/sparc.c (TARGET_ASAN_SHADOW_LEFT_SHIFT): Define to...
(sparc_asan_shadow_left_shift): ...this.  New function.

-- 
Eric BotcazouIndex: asan.c
===
--- asan.c	(revision 269546)
+++ asan.c	(working copy)
@@ -1380,6 +1380,7 @@ asan_emit_stack_protection (rtx base, rt
   unsigned char cur_shadow_byte = ASAN_STACK_MAGIC_LEFT;
   tree str_cst, decl, id;
   int use_after_return_class = -1;
+  unsigned int shift;
 
   if (shadow_ptr_types[0] == NULL_TREE)
 asan_init_shadow_ptr_types ();
@@ -1524,8 +1525,19 @@ asan_emit_stack_protection (rtx base, rt
   TREE_ASM_WRITTEN (decl) = 1;
   TREE_ASM_WRITTEN (id) = 1;
   emit_move_insn (mem, expand_normal (build_fold_addr_expr (decl)));
-  shadow_base = expand_binop (Pmode, lshr_optab, base,
-			  gen_int_shift_amount (Pmode, ASAN_SHADOW_SHIFT),
+  shadow_base = base;
+  if (targetm.asan_shadow_left_shift
+  && (shift = targetm.asan_shadow_left_shift ()) > 0)
+{
+  shadow_base = expand_binop (Pmode, ashl_optab, shadow_base,
+  gen_int_shift_amount (Pmode, shift),
+  NULL_RTX, 1, OPTAB_DIRECT);
+  shift += ASAN_SHADOW_SHIFT;
+}
+  else
+shift = ASAN_SHADOW_SHIFT;
+  shadow_base = expand_binop (Pmode, lshr_optab, shadow_base,
+			  gen_int_shift_amount (Pmode, shift),
 			  NULL_RTX, 1, OPTAB_DIRECT);
   shadow_base
 = plus_constant (Pmode, shadow_base,
@@ -2023,9 +2035,24 @@ build_shadow_mem_access (gimple_stmt_ite
 {
   tree t, uintptr_type = TREE_TYPE (base_addr);
   tree shadow_type = TREE_TYPE (shadow_ptr_type);
+  unsigned int shift;
   gimple *g;
 
-  t = build_int_cst (uintptr_type, ASAN_SHADOW_SHIFT);
+  if (targetm.asan_shadow_left_shift
+  && (shift = targetm.asan_shadow_left_shift ()) > 0)
+{
+  t = build_int_cst (uintptr_type, shift);
+  g = gimple_build_assign (make_ssa_name (uintptr_type), LSHIFT_EXPR,
+			   base_addr, t);
+  gimple_set_location (g, location);
+  gsi_insert_after (gsi, g, GSI_NEW_STMT);
+  base_addr = gimple_assign_lhs (g);
+  shift += ASAN_SHADOW_SHIFT;
+}
+  else
+shift = ASAN_SHADOW_SHIFT;
+
+  t = build_int_cst (uintptr_type, shift);
   g = gimple_build_assign (make_ssa_name (uintptr_type), RSHIFT_EXPR,
 			   base_addr, t);
   gimple_set_location (g, location);
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 269546)
+++ config/sparc/sparc.c	(working copy)
@@ -674,6 +674,7 @@ static rtx sparc_struct_value_rtx (tree,
 static rtx sparc_function_value (const_tree, const_tree, bool);
 static rtx sparc_libcall_value (machine_mode, const_rtx);
 static bool sparc_function_value_regno_p (const unsigned int);
+static unsigned int sparc_asan_shadow_left_shift (void);
 static unsigned HOST_WIDE_INT sparc_asan_shadow_offset (void);
 static void sparc_output_dwarf_dtprel (FILE *, int, rtx) ATTRIBUTE_UNUSED;
 static void sparc_file_end (void);
@@ -835,6 +836,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_EXPAND_BUILTIN_SAVEREGS
 #define TARGET_EXPAND_BUILTIN_SAVEREGS sparc_builtin_saveregs
 
+#undef TARGET_ASAN_SHADOW_LEFT_SHIFT
+#define TARGET_ASAN_SHADOW_LEFT_SHIFT sparc_asan_shadow_left_shift
+
 #undef TARGET_ASAN_SHADOW_OFFSET
 #define TARGET_ASAN_SHADOW_OFFSET sparc_asan_shadow_offset
 
@@ -12493,7 +12497,16 @@ sparc_init_machine_status (void)
 {
   return ggc_cleared_alloc ();
 }
-
+
+/* Implement the TARGET_ASAN_SHADOW_LEFT_SHIFT hook.  */
+
+static unsigned int
+sparc_asan_shadow_left_shift (void)
+{
+  /* This is tailored to the 52-bit VM layout on SPARC-T4 and later.  */
+  return TARGET_ARCH64 ? 12 : 0;
+}
+
 /* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
 
 static unsigned HOST_WIDE_INT

Re: [PATCH] PR88497 - Extend reassoc for vector bit_field_ref

[Richard Biener]

On Mon, 11 Mar 2019, Kewen.Lin wrote:

> on 2019/3/8 下午6:57, Richard Biener wrote:
> > On Fri, Mar 8, 2019 at 2:40 AM Kewen.Lin  wrote:
> >>
> >> Hi,
> >>
> >> As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
> >> when we meet some code pattern like:
> >>
> >>V1[0] + V1[1] + ... + V1[k] + V2[0] + ... + V2[k] + ... Vn[k]
> >>// V1...Vn of VECTOR_TYPE
> >>
> >> We can teach reassoc to transform it to:
> >>
> >>Vs = (V1 + V2 + ... + Vn)
> >>Vs[0] + Vs[1] + ... + Vs[k]
> >>
> >> It saves addition and bit_field_ref operations and exposes more
> >> opportunities for downstream passes, I notice that even on one
> >> target doesn't support vector type and vector type gets expanded
> >> in veclower, it's still better to have it, since the generated
> >> sequence is more friendly for widening_mul.  （If one more time
> >> DCE after forwprop, it should be the same.  )
> >>
> >> Bootstrapped/regtested on powerpc64le-linux-gnu, ok for trunk?
> > 
> > Hmm.  You are basically vectorizing the reduction partially here (note
> > basic-block vectorization doesn't handle reductions yet).  So I'm not sure
> > whether we should eventually just change op sort order to sort
> > v1[1] after v2[0] to sort v1[0] and v2[0] together.  That would be also 
> > maybe
> > an intermediate step that makes implementing the vectorization part
> > "easier"?  I also imagine that the "vectorization" would be profitable even
> > if there's just two elements of the vectors summed and the real vectors are
> > larger.
> > 
> 
> Hi Richard,
> 
> Sorry, I have no idea about basic-block vectorization (SLP?), did you suggest 
> supporting this there rather than in reassoc? Changing op sort order for 
> its expected pattern? 

I was thinking you're smashing two things together here - one part 
suitable for reassocation and one that's on the border.  The reassoc
pass already gathered quite some stuff that doesn't really belong there,
we should at least think twice adding to that.

> > Note that the code you transform contains no vector operations (just
> > element extracts) and thus you need to check for target support before
> > creating vector add.
> > 
> 
> I had the same concern before.  But I thought that if this VECTOR type is 
> valid
> on the target, the addition operation should be fundamental on the target, 
> then
> it's ok; if it's invalid, then veclower will expand it into scalar type as 
> well
> as the addition operation. So it looks fine to guard it. Does it make sense?

But there's a reassoc phase after veclower.  Generally we avoid generating
vector code not supported by the target.  You are not checking whether
the vector type is valid on the target either btw.  The user might have
written an optimal scalar sequence for a non-natively supported vector
type (and veclower wouldn't touch the original scalar code) and veclower
generally makes a mess of things, likely worse than the original code.

> 
> > This is for GCC 10.  Also it doesn't fix PR88497, does it?
> > 
> 
> Yes, it's in low priority and for GCC10. I think it does. Did I miss 
> something?

Wasn't the original testcase in the PR for _vectorized_ code?  The
PR then got an additional testcase which you indeed fix.

> For comment 1 and comment 7 cases, trunk gcc generates the expected code 
> with -Ofast. There isn't any issues for the original loop. But for the 
> expanded code in comment 1 (manually expanded case), gcc can't generate 
> better code with multiply-add.
> 
> From comment 9 case (same as comment 1 expanded version):
> 
> without this patch, optimized tree and final asm:
> 
>[local count: 1073741824]:
>   _1 = *arg2_26(D);
>   _2 = *arg3_27(D);
>   _3 = _1 * _2;
>   _4 = BIT_FIELD_REF <_3, 64, 0>;
>   _5 = BIT_FIELD_REF <_3, 64, 64>;
>   _18 = _4 + _5;
>   _7 = MEM[(__vector double *)arg2_26(D) + 16B];
>   _8 = MEM[(__vector double *)arg3_27(D) + 16B];
>   _9 = _7 * _8;
>   _10 = BIT_FIELD_REF <_9, 64, 0>;
>   _11 = BIT_FIELD_REF <_9, 64, 64>;
>   _31 = _10 + _11;
>   _29 = _18 + _31;
>   _13 = MEM[(__vector double *)arg2_26(D) + 32B];
>   _14 = MEM[(__vector double *)arg3_27(D) + 32B];
>   _15 = _13 * _14;
>   _16 = BIT_FIELD_REF <_15, 64, 0>;
>   _17 = BIT_FIELD_REF <_15, 64, 64>;
>   _6 = _16 + _17;
>   _12 = _6 + accumulator_28(D);
>   _37 = _12 + _29;
>   _19 = MEM[(__vector double *)arg2_26(D) + 48B];
>   _20 = MEM[(__vector double *)arg3_27(D) + 48B];
>   _21 = _19 * _20;
>   _22 = BIT_FIELD_REF <_21, 64, 0>;
>   _23 = BIT_FIELD_REF <_21, 64, 64>;
>   _24 = _22 + _23;
>   accumulator_32 = _24 + _37;
>   return accumulator_32;
> 
>  :
>0:   01 00 e5 f4 lxv vs7,0(r5)
>4:   11 00 05 f4 lxv vs0,16(r5)
>8:   21 00 24 f5 lxv vs9,32(r4)
>c:   21 00 c5 f4 lxv vs6,32(r5)
>   10:   01 00 44 f5 lxv vs10,0(r4)
>   14:   11 00 64 f5 lxv vs11,16(r4)
>   18:   31 00 05 f5 lxv vs8,48(r5)
>   1c:   31 00 84 f5 lxv vs12,48(r4)
>   20:   80 33 29 

Re: [patch] Fix PR rtl-optimization/89588

[Eric Botcazou]

> Hmm, this looks fragile - isn't the same effect when using
> -fdisable-tree-cunroll?

Maybe.

> That is, it looks like we could "move" the assert to decide_unrolling
> instead, deciding LPT_NONE?

We already have a guard for the assertion but it is bypassed here.

I'm going to commit this (equivalent to Jakub's fixlet) after retesting.


PR rtl-optimization/89588
* loop-unroll.c (decide_unroll_constant_iterations): Make guard for
explicit unrolling factor more robust.

-- 
Eric BotcazouIndex: loop-unroll.c
===
--- loop-unroll.c	(revision 269546)
+++ loop-unroll.c	(working copy)
@@ -400,7 +400,7 @@ decide_unroll_constant_iterations (struc
 {
   /* However we cannot unroll completely at the RTL level a loop with
 	 constant number of iterations; it should have been peeled instead.  */
-  if ((unsigned) loop->unroll - 1 > desc->niter - 2)
+  if (desc->niter < 2 || (unsigned) loop->unroll - 1 > desc->niter - 2)
 	{
 	  if (dump_file)
 	fprintf (dump_file, ";; Loop should have been peeled\n");

Re: [patch] Fix PR rtl-optimization/89588

[Richard Biener]

On Mon, Mar 11, 2019 at 10:05 AM Eric Botcazou  wrote:
>
> Hi,
>
> this is the failure of the assertion:
>
>   /* Should not get here (such loop should be peeled instead).  */
>   gcc_assert (niter > max_unroll + 1);
>
> in unroll_loop_constant_iterations on a testcase both containing #pragma GCC
> unroll and compiled with -fno-tree-loop-optimize.  The proposed fix is just to
> disable the pragma altogether when the option is passed.
>
> Tested on x86_64-suse-linux, OK for mainline and 8 branch?

Hmm, this looks fragile - isn't the same effect when using
-fdisable-tree-cunroll?

That is, it looks like we could "move" the assert to decide_unrolling
instead, deciding LPT_NONE?

Richard.

>
> 2019-03-11  Eric Botcazou  
>
> PR rtl-optimization/89588
> * tree-cfg.c (replace_loop_annotate_in_block) 
> :
> Skip annotation and warn if -fno-tree-loop-optimize is specified.
>
>
> 2019-03-11  Eric Botcazou  
>
> * c-c++-common/unroll-6.c: New test.
>
> --
> Eric Botcazou

Re: GCC 8 backports

[Martin Liška]

Hi.

I'm sending another patches that I've just tested.

Martin
>From 915af267eb22e5059737f4dbb6e9d48601bb0779 Mon Sep 17 00:00:00 2001
From: "ro@138bc75d-0d04-0410-961f-82ee72b054a4"
 
Date: Sun, 10 Mar 2019 16:43:48 +
Subject: [PATCH 4/4] Backport r269558

gcc/testsuite/ChangeLog:

2019-03-10  Rainer Orth  

	* gcc.target/i386/indirect-thunk-extern-7.c: Add -fjump-tables to
	dg-options.
---
 gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
index b7339745116..95c5cc176ae 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk-extern -fno-pic" } */
+/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk-extern -fno-pic -fjump-tables" } */
 
 void func0 (void);
 void func1 (void);
-- 
2.21.0

>From 5a433aca1d83cfc8a270b02d89be5b3ed75a503c Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 8 Mar 2019 12:55:40 +
Subject: [PATCH 3/4] Backport r269492

gcc/ChangeLog:

2019-03-08  Martin Liska  

	PR target/86952
	* config/i386/i386.c (ix86_option_override_internal): Disable
	jump tables when retpolines are used.

gcc/testsuite/ChangeLog:

2019-03-08  Martin Liska  

	PR target/86952
	* gcc.target/i386/indirect-thunk-7.c: Use jump tables to match
	scanned pattern.
	* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
---
 gcc/config/i386/i386.c  | 6 ++
 gcc/testsuite/gcc.target/i386/indirect-thunk-7.c| 2 +-
 gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a88a29b51e6..f1de97f73df 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4958,6 +4958,12 @@ ix86_option_override_internal (bool main_args_p,
 			   opts->x_param_values,
 			   opts_set->x_param_values);
 
+  /* PR86952: jump table usage with retpolines is slow.
+ The PR provides some numbers about the slowness.  */
+  if (ix86_indirect_branch != indirect_branch_keep
+  && !opts_set->x_flag_jump_tables)
+opts->x_flag_jump_tables = 0;
+
   return true;
 }
 
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
index 3c72036dbaf..53868f46558 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk -fno-pic" } */
+/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk -fno-pic -fjump-tables" } */
 
 void func0 (void);
 void func1 (void);
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c b/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c
index ea009245a58..e6f064959a1 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk-inline -fno-pic" } */
+/* { dg-options "-O2 -mno-indirect-branch-register -mfunction-return=keep -mindirect-branch=thunk-inline -fno-pic -fjump-tables" } */
 
 void func0 (void);
 void func1 (void);
-- 
2.21.0

>From 4a20f76e3887229751ebd8352cc3c77a4e7c2b10 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 18 Feb 2019 09:46:19 +
Subject: [PATCH 2/4] Backport r268981

libcpp/ChangeLog:

2019-02-18  Martin Liska  

	PR c++/89383
	* line-map.c (linemap_line_start): Use 1UL in order
	to not overflow.
---
 libcpp/line-map.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 42aecd6993f..72fe2c0dcec 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -758,7 +758,8 @@ linemap_line_start (struct line_maps *set, linenum_type to_line,
 	  || ( /* We can't reuse the map if the line offset is sufficiently
 		  large to cause overflow when computing location_t values.  */
 	  (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
-	  >= (1U << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
+	  >= (((uint64_t) 1)
+		  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
 	  || range_bits < map->m_range_bits)
 	map = linemap_check_ordinary
 	(const_cast 
-- 
2.21.0

>From fe9fa030d7ae1a4b4da4751b39bddc68395b1728 Mon Sep 17 00:00:00 2001
From: dmalcolm 
Date: Tue, 12 Feb 2019 01:09:31 +
Subject: [PATCH 1/4] Backport r268789

gcc/ChangeLog:

2019-02-11  David Malcolm  

	PR 

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

[Dominique d'Humières]

Hi Harald,

The patch looks good to me (although I did not test it), however I don’t like 
the standard legalese in the error messages.

IMO

R1035 bounds-spec is lower-bound-expr :
R1036 bounds-remapping is lower-bound-expr : upper-bound-exp

should be rephrased in plain English.

Thanks for the work.

Dominique

Re: [patch, fortran] Fix PR 66089, ICE (plus wrong code) in dependency handling

[Dominique d'Humières]

Hi Thomas,

> Anything else? …

Yes, the tests gfortran.dg/assumed_type_2.f90 and 
gfortran.dg/no_arg_check_2.f90 fail:

FAIL: gfortran.dg/assumed_type_2.f90   -O   scan-tree-dump-times original 
"sub_array_assumed (D" 3 (found 4 times)
FAIL: gfortran.dg/assumed_type_2.f90   -O   scan-tree-dump-times original 
"sub_array_assumed ((struct t1.0:. .) 
array_class_t1_ptr._data.data);" 1 (found 0 times)

FAIL: gfortran.dg/no_arg_check_2.f90   -O   scan-tree-dump-times original 
"sub_array_assumed (D" 3 (found 4 times)
FAIL: gfortran.dg/no_arg_check_2.f90   -O   scan-tree-dump-times original 
"sub_array_assumed ((struct t1.0:. .) 
array_class_t1_ptr._data.data);" 1 (found 0 times)

TIA

Dominique

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 10:05 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:57:36AM +0100, Martin Liška wrote:
>> On 3/11/19 9:30 AM, Jakub Jelinek wrote:
>>> On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
 The patch adds a lot of option name wrapping in string format messages. I 
 added a new contrib
 script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot 
 file and reports
 errors.

 Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
 Apart from that I built all cross compilers and compared all warnings so 
 that
 I don't introduce a bootstrap error. It's expected that various 
 target-specific
 tests will need wrapping in scanned patterns.

 Is it fine for next stage1?
>>>
>>> Generally looks good to me, but I'm not sure about corner cases like:
>>> %<-misr-secure=X%>, shouldn't the X be after %>?  X is not what users would
>>> type.  Or reword these to %<-misr-secure=%s%> argument not in between 0 and
>>> 23 or similar.
>>
>> Well, in order to make it consistent, I would put the closing '%>' after
>> the whole option=argument expression.
> 
> The problem is that the X is not what people should write literally on the
> command line, unlike everything else we put in between the quotes.  That is
> why I suggest to rework it like other targets do, where they actually print
> the argument the user specified (which should be in between quotes) and
> don't use any X in the wording.
> 
>   Jakub
> 

Now I understand that, thanks.

Sending updated patch.

Martin


0001-Wrap-option-names-in-gcc-internal-messages-with-and.patch.bz2
Description: application/bzip

[PATCH] Fix PR89649

[Richard Biener]

I am testing the following patch to fix the g++.dg/pr80481.C FAIL
on x86_64.  Copying of the loop force_vectorize flag caused the
epilogue loops no longer be unrolled because the vectorizer fails
to unset the force_vectorize flag after copying the loop causing
the unroller to not touch it.  This skewed the testcase enough to
cause reg-reg moves to re-appear (the testcase is for a IRA issue).

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2019-03-11  Richard Biener  

PR tree-optimization/89649
* tree-vectorizer.h (vect_loop_versioning): Adjust prototype.
* tree-vect-loop-manip.c (vect_do_peeling): Unset force_vectorize
on the prolog and epilog loops.
(vect_loop_versioning): Return copy of loop.
* tree-vect-loop.c (vect_transform_loop): Unset force_vectorize
on the non-vectorized version of the loop.

Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   (revision 269569)
+++ gcc/tree-vectorizer.h   (working copy)
@@ -1449,8 +1449,8 @@ extern void vect_set_loop_condition (str
 extern bool slpeel_can_duplicate_loop_p (const struct loop *, const_edge);
 struct loop *slpeel_tree_duplicate_loop_to_edge_cfg (struct loop *,
 struct loop *, edge);
-extern void vect_loop_versioning (loop_vec_info, unsigned int, bool,
- poly_uint64);
+struct loop *vect_loop_versioning (loop_vec_info, unsigned int, bool,
+  poly_uint64);
 extern struct loop *vect_do_peeling (loop_vec_info, tree, tree,
 tree *, tree *, tree *, int, bool, bool);
 extern void vect_prepare_for_masked_peels (loop_vec_info);
Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c  (revision 269569)
+++ gcc/tree-vect-loop-manip.c  (working copy)
@@ -2542,6 +2543,7 @@ vect_do_peeling (loop_vec_info loop_vinf
   "slpeel_tree_duplicate_loop_to_edge_cfg failed.\n");
  gcc_unreachable ();
}
+  prolog->force_vectorize = false;
   slpeel_update_phi_nodes_for_loops (loop_vinfo, prolog, loop, true);
   first_loop = prolog;
   reset_original_copy_tables ();
@@ -2612,6 +2614,7 @@ vect_do_peeling (loop_vec_info loop_vinf
   "slpeel_tree_duplicate_loop_to_edge_cfg failed.\n");
  gcc_unreachable ();
}
+  epilog->force_vectorize = false;
   slpeel_update_phi_nodes_for_loops (loop_vinfo, loop, epilog, false);
 
   /* Scalar version loop may be preferred.  In this case, add guard
@@ -2984,7 +2987,7 @@ vect_create_cond_for_alias_checks (loop_
The versioning precondition(s) are placed in *COND_EXPR and
*COND_EXPR_STMT_LIST.  */
 
-void
+struct loop *
 vect_loop_versioning (loop_vec_info loop_vinfo,
  unsigned int th, bool check_profitability,
  poly_uint64 versioning_threshold)
@@ -3154,4 +3157,6 @@ vect_loop_versioning (loop_vec_info loop
 GSI_SAME_STMT);
 }
   update_ssa (TODO_update_ssa);
+
+  return nloop;
 }
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 269569)
+++ gcc/tree-vect-loop.c(working copy)
@@ -8201,8 +8201,10 @@ vect_transform_loop (loop_vec_info loop_
  versioning_threshold);
  check_profitability = false;
}
-  vect_loop_versioning (loop_vinfo, th, check_profitability,
-   versioning_threshold);
+  struct loop *sloop
+   = vect_loop_versioning (loop_vinfo, th, check_profitability,
+   versioning_threshold);
+  sloop->force_vectorize = false;
   check_profitability = false;
 }
 

Re: [PR 85762, 87008, 85459] Relax MEM_REF check in contains_vce_or_bfcref_p

[Martin Jambor]

Hi,

after we have accidentally dropped the mailing list from our discussion
(my apologies for not spotting that in time), Richi has approved the
following patch which I have bootstrapped and tested on x86_64-linux
(all languages) and on i686-linux, aarch64-linux and ppc64-linux (C, C++
and Fortran) and so I am about to commit it to trunk.

It XFAILS three guality tests which pass at -O0, which means there are
three additional XPASSes - there already are 5 pre-existing XPASSes in
that testcase and 29 outright failures.  I will come back to this next
in April and see whether I can make the tests pass by decoupling the
roles now played by cannot_scalarize_away_bitmap (or at least massage
the testcase to go make the XPASSes go away).  But I won't have time to
do it next two weeks and this patch is important enough to have it in
trunk now.  I intend to backport it to gcc 8 in April too.

Thanks,

Martin


2019-03-08  Martin Jambor  

PR tree-optimization/85762
PR tree-optimization/87008
PR tree-optimization/85459
* tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool
it points to if there is a type changing MEM_REF.  Adjust all callers.
(build_accesses_from_assign): Disable total scalarization if
contains_vce_or_bfcref_p returns true through the new parameter, for
both rhs and lhs.

testsuite/
* g++.dg/tree-ssa/pr87008.C: New test.
* gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere.
---
 gcc/testsuite/g++.dg/tree-ssa/pr87008.C | 17 
 gcc/testsuite/gcc.dg/guality/pr54970.c  |  6 ++---
 gcc/tree-sra.c  | 36 ++---
 3 files changed, 47 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr87008.C

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr87008.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr87008.C
new file mode 100644
index 000..eef521f9ad5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr87008.C
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+extern void dontcallthis();
+
+struct A { long a, b; };
+struct B : A {};
+templatevoid cp(T,T const){a=b;}
+long f(B x){
+  B y; cp(y,x);
+  B z; cp(z,x);
+  if (y.a - z.a)
+dontcallthis ();
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "dontcallthis" "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/guality/pr54970.c 
b/gcc/testsuite/gcc.dg/guality/pr54970.c
index 5d32af07c32..2e0bc5784a9 100644
--- a/gcc/testsuite/gcc.dg/guality/pr54970.c
+++ b/gcc/testsuite/gcc.dg/guality/pr54970.c
@@ -8,17 +8,17 @@
 int
 main ()
 {
-  int a[] = { 1, 2, 3 };   /* { dg-final { gdb-test .+4 "a\[0\]" "1" } } */
+  int a[] = { 1, 2, 3 };   /* { dg-final { gdb-test .+4 "a\[0\]" "1" { 
xfail { *-*-* } } } } */
   int *p = a + 2;  /* { dg-final { gdb-test .+3 "a\[1\]" "2" } } */
   int *q = a + 1;  /* { dg-final { gdb-test .+2 "a\[2\]" "3" } } */
/* { dg-final { gdb-test .+1 "*p" "3" } } */
   asm volatile (NOP);  /* { dg-final { gdb-test . "*q" "2" } } */
-  *p += 10;/* { dg-final { gdb-test .+4 "a\[0\]" "1" } } */
+  *p += 10;/* { dg-final { gdb-test .+4 "a\[0\]" "1" { 
xfail { *-*-* } } } } */
/* { dg-final { gdb-test .+3 "a\[1\]" "2" } } */
/* { dg-final { gdb-test .+2 "a\[2\]" "13" } } 
*/
/* { dg-final { gdb-test .+1 "*p" "13" } } */
   asm volatile (NOP);  /* { dg-final { gdb-test . "*q" "2" } } */
-  *q += 10;/* { dg-final { gdb-test .+4 "a\[0\]" "1" } } */
+  *q += 10;/* { dg-final { gdb-test .+4 "a\[0\]" "1" { 
xfail { *-*-* } } } } */
/* { dg-final { gdb-test .+3 "a\[1\]" "12" } } 
*/
/* { dg-final { gdb-test .+2 "a\[2\]" "13" } } 
*/
/* { dg-final { gdb-test .+1 "*p" "13" } } */
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index eeef31ba496..ca3858d5fc7 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -1150,29 +1150,36 @@ contains_view_convert_expr_p (const_tree ref)
   return false;
 }
 
-/* Return true if REF contains a VIEW_CONVERT_EXPR or a MEM_REF that performs
-   type conversion or a COMPONENT_REF with a bit-field field declaration.  */
+/* Return true if REF contains a VIEW_CONVERT_EXPR or a COMPONENT_REF with a
+   bit-field field declaration.  If TYPE_CHANGING_P is non-NULL, set the bool
+   it points to will be set if REF contains any of the above or a MEM_REF
+   expression that effectively performs type conversion.  */
 
 static bool
-contains_vce_or_bfcref_p (const_tree ref)
+contains_vce_or_bfcref_p (const_tree ref, bool *type_changing_p = NULL)
 {
   while (handled_component_p (ref))
 {
   if (TREE_CODE (ref) == VIEW_CONVERT_EXPR
  || 

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 09:57:36AM +0100, Martin Liška wrote:
> On 3/11/19 9:30 AM, Jakub Jelinek wrote:
> > On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
> >> The patch adds a lot of option name wrapping in string format messages. I 
> >> added a new contrib
> >> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot 
> >> file and reports
> >> errors.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >> Apart from that I built all cross compilers and compared all warnings so 
> >> that
> >> I don't introduce a bootstrap error. It's expected that various 
> >> target-specific
> >> tests will need wrapping in scanned patterns.
> >>
> >> Is it fine for next stage1?
> > 
> > Generally looks good to me, but I'm not sure about corner cases like:
> > %<-misr-secure=X%>, shouldn't the X be after %>?  X is not what users would
> > type.  Or reword these to %<-misr-secure=%s%> argument not in between 0 and
> > 23 or similar.
> 
> Well, in order to make it consistent, I would put the closing '%>' after
> the whole option=argument expression.

The problem is that the X is not what people should write literally on the
command line, unlike everything else we put in between the quotes.  That is
why I suggest to rework it like other targets do, where they actually print
the argument the user specified (which should be in between quotes) and
don't use any X in the wording.

Jakub

[patch] Fix PR rtl-optimization/89588

[Eric Botcazou]

Hi,

this is the failure of the assertion:

  /* Should not get here (such loop should be peeled instead).  */
  gcc_assert (niter > max_unroll + 1);

in unroll_loop_constant_iterations on a testcase both containing #pragma GCC 
unroll and compiled with -fno-tree-loop-optimize.  The proposed fix is just to 
disable the pragma altogether when the option is passed.

Tested on x86_64-suse-linux, OK for mainline and 8 branch?


2019-03-11  Eric Botcazou  

PR rtl-optimization/89588
* tree-cfg.c (replace_loop_annotate_in_block) :
Skip annotation and warn if -fno-tree-loop-optimize is specified.


2019-03-11  Eric Botcazou  

* c-c++-common/unroll-6.c: New test.

-- 
Eric BotcazouIndex: tree-cfg.c
===
--- tree-cfg.c	(revision 269546)
+++ tree-cfg.c	(working copy)
@@ -280,9 +280,16 @@ replace_loop_annotate_in_block (basic_bl
 	  loop->safelen = INT_MAX;
 	  break;
 	case annot_expr_unroll_kind:
-	  loop->unroll
-	= (unsigned short) tree_to_shwi (gimple_call_arg (stmt, 2));
-	  cfun->has_unroll = true;
+	  if (flag_tree_loop_optimize)
+	{
+	  loop->unroll
+		= (unsigned short) tree_to_shwi (gimple_call_arg (stmt, 2));
+	  cfun->has_unroll = true;
+	}
+	  else
+	warning_at (gimple_location (stmt), 0,
+			"pragma GCC unroll disabled by "
+			"-fno-tree-loop-optimize");
 	  break;
 	case annot_expr_no_vector_kind:
 	  loop->dont_vectorize = true;
/* { dg-do compile } */
/* { dg-options "-O -fno-tree-loop-optimize" } */

void test (void)
{
  #pragma GCC unroll 2
  for (int nv = 0; nv <= 2; nv += 2) /* { dg-warning "GCC unroll disabled" } */
{}
}

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 9:33 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:30:15AM +0100, Jakub Jelinek wrote:
>> Similarly
>> %<-mstringop-strategy=rep%>_8byte
>> or
>> %<-mcpu=v8%>.30.a
>> or
>> %<-mfloat128%>-hardware
>> look wrong.
> 
> %<-mspfp%>_fast
> 
> too.  I guess just go through the whole patch and look for cases where
> %> is not followed by [" ] and verify all cases.

I've done that and I'm sending updated version of the patch.

Martin

> 
>   Jakub
> 



0001-Wrap-option-names-in-gcc-internal-messages-with-and.patch.bz2
Description: application/bzip

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

On 3/11/19 9:30 AM, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
>> The patch adds a lot of option name wrapping in string format messages. I 
>> added a new contrib
>> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot 
>> file and reports
>> errors.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> Apart from that I built all cross compilers and compared all warnings so that
>> I don't introduce a bootstrap error. It's expected that various 
>> target-specific
>> tests will need wrapping in scanned patterns.
>>
>> Is it fine for next stage1?
> 
> Generally looks good to me, but I'm not sure about corner cases like:
> %<-misr-secure=X%>, shouldn't the X be after %>?  X is not what users would
> type.  Or reword these to %<-misr-secure=%s%> argument not in between 0 and
> 23 or similar.

Well, in order to make it consistent, I would put the closing '%>' after
the whole option=argument expression.

> 
> On the other side:
> %<-mcpu%>=%s conflicts with %<-march%>=%s
> the =%s should be before %>.
> Same with %<-mrgf-banked-regs%>=%s .
> 
> Similarly
> %<-mstringop-strategy=rep%>_8byte
> or
> %<-mcpu=v8%>.30.a
> or
> %<-mfloat128%>-hardware
> look wrong.

I'm going to fix all these.

> 
> Don't we want to commit it now (after fixing above issues), rather than
> waiting for stage1?  We have changed tons of translations recently and this
> is something that the translators have been asking for a long time, we need
> to upload new gcc.pot anyway and let them adjust translations, plus your
> it will be hard to maintain your patch for another month or two.

I would be happy to get it in right now. Yes, patch conflicts would happen
during the time. I'll send updated version as a reply for the second
Jakub's email.

Martin

> 
>   Jakub
> 

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 09:30:15AM +0100, Jakub Jelinek wrote:
> Similarly
> %<-mstringop-strategy=rep%>_8byte
> or
> %<-mcpu=v8%>.30.a
> or
> %<-mfloat128%>-hardware
> look wrong.

%<-mspfp%>_fast

too.  I guess just go through the whole patch and look for cases where
%> is not followed by [" ] and verify all cases.

Jakub

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Jakub Jelinek]

On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote:
> The patch adds a lot of option name wrapping in string format messages. I 
> added a new contrib
> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot 
> file and reports
> errors.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> Apart from that I built all cross compilers and compared all warnings so that
> I don't introduce a bootstrap error. It's expected that various 
> target-specific
> tests will need wrapping in scanned patterns.
> 
> Is it fine for next stage1?

Generally looks good to me, but I'm not sure about corner cases like:
%<-misr-secure=X%>, shouldn't the X be after %>?  X is not what users would
type.  Or reword these to %<-misr-secure=%s%> argument not in between 0 and
23 or similar.

On the other side:
%<-mcpu%>=%s conflicts with %<-march%>=%s
the =%s should be before %>.
Same with %<-mrgf-banked-regs%>=%s .

Similarly
%<-mstringop-strategy=rep%>_8byte
or
%<-mcpu=v8%>.30.a
or
%<-mfloat128%>-hardware
look wrong.

Don't we want to commit it now (after fixing above issues), rather than
waiting for stage1?  We have changed tons of translations recently and this
is something that the translators have been asking for a long time, we need
to upload new gcc.pot anyway and let them adjust translations, plus your
it will be hard to maintain your patch for another month or two.

Jakub

[PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

[Martin Liška]

Hi.

The patch adds a lot of option name wrapping in string format messages. I added 
a new contrib
script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot file 
and reports
errors.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Apart from that I built all cross compilers and compared all warnings so that
I don't introduce a bootstrap error. It's expected that various target-specific
tests will need wrapping in scanned patterns.

Is it fine for next stage1?
Thanks,
Martin


0001-Wrap-option-names-in-gcc-internal-messages-with-and.patch.bz2
Description: application/bzip

Re: [PATCH] Fix in -std=c++2a mode (PR libstdc++/89641)

[Jakub Jelinek]

On Sun, Mar 10, 2019 at 10:36:08PM +0100, Jakub Jelinek wrote:
> Ok for trunk if normal bootstrap/regtest succeeds (i.e. including the default 
> flags
> testing)?

Normal bootstrap/regtest on x86_64-linux and i686-linux succeeded too.

> 2019-03-10  Jakub Jelinek  
> 
>   PR libstdc++/89641
>   * include/std/atomic (atomic::store, atomic::load,
>   atomic::exchange, atomic::compare_exchange_weak,
>   atomic::compare_exchange_strong): Cast __m or __s and __f to int.
>   * include/bits/atomic_base.h (__atomic_base::operator++,
>   __atomic_base::operator--, __atomic_base::operator+=,
>   __atomic_base::operator-=, __atomic_base::operator&=,
>   __atomic_base::operator|=, __atomic_base::operator^=,
>   __atomic_base::operator++, __atomic_base::operator--,
>   __atomic_base::operator+=, __atomic_base::operator-=): Cast
>   memory_order_seq_cst to int.

Jakub

Re: V5 [PATCH] Optimize vector constructor

[H.J. Lu]

On Fri, Mar 8, 2019 at 7:03 PM Richard Biener
 wrote:
>
> On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu  wrote:
> >
> > On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu  wrote:
> > >
> > > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > >  wrote:
> > > >
> > > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu  wrote:
> > > > >
> > > > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu  wrote:
> > > > > >
> > > > > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > > > > > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski wrote:
> > > > > > > > > )
> > > > > > > > > ,On Sun, Mar 3, 2019 at 6:32 AM H.J. Lu  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > For vector init constructor:
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > typedef float __v4sf __attribute__ ((__vector_size__ (16)));
> > > > > > > > > >
> > > > > > > > > > __v4sf
> > > > > > > > > > foo (__v4sf x, float f)
> > > > > > > > > > {
> > > > > > > > > >   __v4sf y = { f, x[1], x[2], x[3] };
> > > > > > > > > >   return y;
> > > > > > > > > > }
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > we can optimize vector init constructor with vector copy or 
> > > > > > > > > > permute
> > > > > > > > > > followed by a single scalar insert:
> > > > > >
> > > > > > > and you want to advance to the _1 = BIT_INSERT_EXPR here.  The 
> > > > > > > easiest way
> > > > > > > is to emit a new stmt for _2 = copy ...; and do the set_rhs with 
> > > > > > > the
> > > > > > > BIT_INSERT_EXPR.
> > > > > >
> > > > > > Thanks for BIT_INSERT_EXPR suggestion.  I am testing this patch.
> > > > > >
> > > > > >
> > > > > > H.J.
> > > > > > ---
> > > > > > We can optimize vector constructor with vector copy or permute 
> > > > > > followed
> > > > > > by a single scalar insert:
> > > > > >
> > > > > >   __v4sf y;
> > > > > >   __v4sf D.1930;
> > > > > >   float _1;
> > > > > >   float _2;
> > > > > >   float _3;
> > > > > >
> > > > > >:
> > > > > >   _1 = BIT_FIELD_REF ;
> > > > > >   _2 = BIT_FIELD_REF ;
> > > > > >   _3 = BIT_FIELD_REF ;
> > > > > >   y_6 = {f_5(D), _3, _2, _1};
> > > > > >   return y_6;
> > > > > >
> > > > > > with
> > > > > >
> > > > > >  __v4sf y;
> > > > > >   __v4sf D.1930;
> > > > > >   float _1;
> > > > > >   float _2;
> > > > > >   float _3;
> > > > > >   vector(4) float _8;
> > > > > >
> > > > > >:
> > > > > >   _1 = BIT_FIELD_REF ;
> > > > > >   _2 = BIT_FIELD_REF ;
> > > > > >   _3 = BIT_FIELD_REF ;
> > > > > >   _8 = x_9(D);
> > > > > >   y_6 = BIT_INSERT_EXPR ;
> > > > > >   return y_6;
> > > > > >
> > > > > > gcc/
> > > > > >
> > > > > > PR tree-optimization/88828
> > > > > > * tree-ssa-forwprop.c (simplify_vector_constructor): 
> > > > > > Optimize
> > > > > > vector init constructor with vector copy or permute followed
> > > > > > by a single scalar insert.
> > > > > >
> > > > > > gcc/testsuite/
> > > > > >
> > > > > > PR tree-optimization/88828
> > > > > > * gcc.target/i386/pr88828-1a.c: New test.
> > > > > > * gcc.target/i386/pr88828-2b.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-2.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-3a.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-3b.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-3c.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-3d.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-4a.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-4b.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-5a.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-5b.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-6a.c: Likewise.
> > > > > > * gcc.target/i386/pr88828-6b.c: Likewise.
> > > > >
> > > > > Here is the updated patch with run-time tests.
> > > >
> > > > -  if (TREE_CODE (elt->value) != SSA_NAME)
> > > > +  if (TREE_CODE (ce->value) != SSA_NAME)
> > > > return false;
> > > >
> > > > hmm, so it doesn't allow { 0, v[1], v[2], v[3] }?  I think the single
> > > > scalar value can be a constant as well.
> > >
> > > Fixed.
> > >
> > > >if (!def_stmt)
> > > > -   return false;
> > > > +   {
> > > > + if (gimple_nop_p (SSA_NAME_DEF_STMT (ce->value)))
> > > >
> > > > if (SSA_NAME_IS_DEFAULT_DEF (ce->value))
> > > >
> > > > +   {
> > > >
> > > > also you seem to disallow
> > > >
> > > >   { i + 1, v[1], v[2], v[3] }
> > >
> > > Fixed by
> > >
> > >  if (code != BIT_FIELD_REF)
> > > {
> > >   /* Only allow one scalar insert.  */
> > >   if (nscalars != 0)
> > > return false;
> > >
> > >   nscalars = 1;
> > >   insert = true;
> > >   scalar_idx = i;
> > >   sel.quick_push (i);
> > >   scalar_element = ce->value;
> > >   continue;
> > > }
> > >
> > > > because