Re: [PATCH] PR fortran/84346 -- Keywords invalid in statement functions

[Thomas Koenig]

Hi Steve,


The attached patch fixes PR fortran/84346.  A statement
function always has an implicit interface.  The use of
keywords in a function with an implicit interface is
invalid.  Regression tested on x86_64-*-freebsd.  OK
to commit?


OK.

Thanks for the patch!

Regards

Thomas

[PATCH] Fix bogus function cast warning for functions with common arg subset

[Siddhesh Poyarekar]

Libraries like gtk/glib[1] and python[2] use functions with common
argument subsets to register callbacks.  The working idea behind it is
to have a flag in the structure (or some other pre-determined method)
that specifies how the callback is cast and called.

Fix this by not throwing a warning when functions with different
argument list lengths (of M and N where M < N) have compatible
argument types for the first M arguments.

Tested and bootstrapped on x86_64.

Siddhesh

[1] I haven't checked gtk/glib lately, but I remember the G_CALLBACK
interface does similar things

[2] python has the PyCFunction type member ml_meth in PyMethodDef
which is designed to accept a PyCFunctionWithKeywords (3 void *
arguments instead of 2 in PyCFunction) and ml_meth is then cast
internally to either based on flags in the ml_flags member in
PyMethodDef.

gcc/c:
* c-typcheck.c (c_safe_function_type_cast_p): Don't warn on
unequal number of arguments as long as the common argument
types match.

gcc/cp:
* c-typcheck.c (c_safe_function_type_cast_p): Don't warn on
unequal number of arguments as long as the common argument
types match.

gcc/testsuite:
* c-c++-common/Wcast-function-type.c: New test cases.
---
 gcc/c/c-typeck.c |  9 +++-
 gcc/cp/typeck.c  |  9 +++-
 gcc/testsuite/c-c++-common/Wcast-function-type.c | 29 
 3 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 1eae4ea849c..16887cd3ac4 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -5520,7 +5520,14 @@ c_safe_function_type_cast_p (tree t1, tree t2)
t1 && t2;
t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2))
 if (!c_safe_arg_type_equiv_p (TREE_VALUE (t1), TREE_VALUE (t2)))
-  return false;
+  {
+   /* Don't warn on unequal number of arguments as long as the common
+  argument types match.  This is a common idiom for callbacks.  */
+   if (t1 == void_list_node || t2 == void_list_node)
+ return true;
+
+   return false;
+  }
 
   return true;
 }
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 0e7c63dd197..f35dca3a05e 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1221,7 +1221,14 @@ cxx_safe_function_type_cast_p (tree t1, tree t2)
t1 && t2;
t1 = TREE_CHAIN (t1), t2 = TREE_CHAIN (t2))
 if (!cxx_safe_arg_type_equiv_p (TREE_VALUE (t1), TREE_VALUE (t2)))
-  return false;
+  {
+   /* Don't warn on unequal number of arguments as long as the common
+  argument types match.  This is a common idiom for callbacks.  */
+   if (t1 == void_list_node || t2 == void_list_node)
+ return true;
+
+   return false;
+  }
 
   return true;
 }
diff --git a/gcc/testsuite/c-c++-common/Wcast-function-type.c 
b/gcc/testsuite/c-c++-common/Wcast-function-type.c
index 81105762ef7..f38ad3fe73d 100644
--- a/gcc/testsuite/c-c++-common/Wcast-function-type.c
+++ b/gcc/testsuite/c-c++-common/Wcast-function-type.c
@@ -2,6 +2,8 @@
 /* { dg-options "-Wcast-function-type" } */
 
 int f(long);
+int g(long, double);
+int h(long, double, double, int);
 
 typedef int (f1)(long);
 typedef int (f2)(void*);
@@ -14,11 +16,26 @@ typedef void (f4)();
 #endif
 typedef void (f5)(void);
 
+typedef int (f6)(long, void *);
+typedef int (f7)(long, double, double);
+typedef int (f8)(long, void *, double);
+
 f1 *a;
 f2 *b;
 f3 *c;
 f4 *d;
 f5 *e;
+f6 *i;
+f7 *j;
+f8 *k;
+
+f6 *l;
+f7 *m;
+f8 *n;
+
+f6 *o;
+f7 *p;
+f8 *q;
 
 void
 foo (void)
@@ -28,4 +45,16 @@ foo (void)
   c = (f3 *) f; /* { dg-bogus   "incompatible function types" } */
   d = (f4 *) f; /* { dg-warning "incompatible function types" } */
   e = (f5 *) f; /* { dg-bogus   "incompatible function types" } */
+
+  i = (f6 *) f; /* { dg-bogus   "incompatible function types" } */
+  j = (f7 *) f; /* { dg-bogus   "incompatible function types" } */
+  k = (f8 *) f; /* { dg-bogus   "incompatible function types" } */
+
+  l = (f6 *) g; /* { dg-warning "incompatible function types" } */
+  m = (f7 *) g; /* { dg-bogus   "incompatible function types" } */
+  n = (f8 *) g; /* { dg-warning "incompatible function types" } */
+
+  o = (f6 *) h; /* { dg-warning "incompatible function types" } */
+  p = (f7 *) h; /* { dg-bogus   "incompatible function types" } */
+  q = (f8 *) h; /* { dg-warning "incompatible function types" } */
 }
-- 
2.14.3

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

[Siddhesh Poyarekar]

On Friday 02 February 2018 05:15 AM, Martin Sebor wrote:
> PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within 
> array
> 
> gcc/ChangeLog:
> 
>   PR middle-end/84095
>   * gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range): New.
>   (builtin_memref::set_base_and_offset): Same.  Handle inner references.
>   (builtin_memref::builtin_memref): Factor out parts into
>   set_base_and_offset and call it.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/84095
>   * c-c++-common/Warray-bounds-3.c: Adjust text of expected warnings.
>   * c-c++-common/Wrestrict.c: Same.
>   * gcc.dg/Wrestrict-6.c: Same.
>   * gcc.dg/Warray-bounds-27.c: New test.
>   * gcc.dg/Wrestrict-8.c: New test.
>   * gcc.dg/Wrestrict-9.c: New test.
>   * gcc.dg/pr84095.c: New test.

This is causing failures in Warray-bounds-2.c in the testsuite:

FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat   (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat   (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98  (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11  (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14  (test for warnings,
line 183)

Siddhesh

C++ PATCH for c++/84424, ICE with constexpr and __builtin_shuffle.

[Jason Merrill]

We were crashing when checking whether the value being created for v
is constant, because TYPE_FIELDS is invalid for VECTOR_TYPE.  But it's
easy enough to just return false for a partially-initialized vector.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0a07b4d11d758ccbfe11012fcbc7ee6e94f2b3d0
Author: Jason Merrill 
Date:   Thu Feb 22 17:29:54 2018 -0500

PR c++/84424 - ICE with constexpr and __builtin_shuffle.

* constexpr.c (reduced_constant_expression_p): Handle CONSTRUCTOR of
VECTOR_TYPE.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index f095b038d32..47ff90cb055 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1763,7 +1763,13 @@ reduced_constant_expression_p (tree t)
   /* And we need to handle PTRMEM_CST wrapped in a CONSTRUCTOR.  */
   tree idx, val, field; unsigned HOST_WIDE_INT i;
   if (CONSTRUCTOR_NO_IMPLICIT_ZERO (t))
-   field = next_initializable_field (TYPE_FIELDS (TREE_TYPE (t)));
+   {
+ if (TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
+   /* An initialized vector would have a VECTOR_CST.  */
+   return false;
+ else
+   field = next_initializable_field (TYPE_FIELDS (TREE_TYPE (t)));
+   }
   else
field = NULL_TREE;
   FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), i, idx, val)
diff --git a/gcc/testsuite/g++.dg/ext/vector34.C 
b/gcc/testsuite/g++.dg/ext/vector34.C
new file mode 100644
index 000..5cca53070b2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/vector34.C
@@ -0,0 +1,8 @@
+// PR c++/84424
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+typedef int vec __attribute__ ((vector_size (2 * sizeof (int;
+
+constexpr vec u = { 1, 2 };
+constexpr vec v = __builtin_shuffle (v, u); // { dg-error "" }

[PATCH] PR fortran/84346 -- Keywords invalid in statement functions

[Steve Kargl]

The attached patch fixes PR fortran/84346.  A statement
function always has an implicit interface.  The use of
keywords in a function with an implicit interface is 
invalid.  Regression tested on x86_64-*-freebsd.  OK
to commit?

2018-02-22  Steven G. Kargl  

PR fortran/84346
* interface.c (compare_actual_formal): Issue error if keyword is
used in a statement function.

2018-02-22  Steven G. Kargl  

PR fortran/84346
* gfortran.dg/statement_function_1.f90: Update test.

-- 
Steve
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c	(revision 257695)
+++ gcc/fortran/interface.c	(working copy)
@@ -2865,6 +2865,13 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_fo
 
   for (a = actual; a; a = a->next, f = f->next)
 {
+  if (a->name != NULL && in_statement_function)
+	{
+	  gfc_error ("Keyword argument %qs at %L is invalid in "
+		 "a statement function", a->name, >expr->where);
+	  return false;
+	}
+
   /* Look for keywords but ignore g77 extensions like %VAL.  */
   if (a->name != NULL && a->name[0] != '%')
 	{
Index: gcc/testsuite/gfortran.dg/statement_function_1.f90
===
--- gcc/testsuite/gfortran.dg/statement_function_1.f90	(revision 257695)
+++ gcc/testsuite/gfortran.dg/statement_function_1.f90	(working copy)
@@ -19,10 +19,6 @@
   qofs(s, i) = i * s
   i = 42
   w = qofs(hh, i)
-!
-! The following line should cause an error, because keywords are not
-! allowed in a function with an implicit interface.
-!
-  w = qofs(i = i, s = hh)
+  w = qofs(i = i, s = hh) ! { dg-error "invalid in a statement function" }
   end subroutine step
 ! { dg-prune-output " Obsolescent feature" }

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Jason Merrill]

On 02/21/2018 06:03 PM, Martin Sebor wrote:

On 02/13/2018 11:33 AM, Jason Merrill wrote:

On Tue, Feb 13, 2018 at 1:00 PM, Martin Sebor  wrote:

On 02/13/2018 07:47 AM, Jason Merrill wrote:


On Mon, Feb 12, 2018 at 6:39 PM, Martin Sebor  wrote:


I really don't think it's helpful to try to force noreturn
to match between the primary and its specializations.


I continue to disagree.


Can you explain what use case you are concerned about that isn't
already handled by the warning about noreturn function returning?


A specialization that forgot [[noreturn]] and therefore doesn't get
the desired warning.


For reference, the cases I consider important are:

1) "Unimplemented" primary template declared noreturn that throws
   or exits but whose specializations return a useful value and
   make use of attribute malloc (or one of the other blacklisted
   attributes).

2) The converse of (1).  A primary that returns a useful malloc
   like value and some of whose specializations are not/cannot
   be meaningfully implemented and are declared noreturn.


Right, but I still disagree with this use of noreturn, and therefore
don't consider these cases important.


Defining template specializations that differ from the primary
template in their implementation is idiomatic (analogous to
defining overloads or overridden virtual functions).



In any event, I am mainly interested in fixing the two bugs
(one a P1 regression).   If you consider changing the warning
aspect of the patch a condition of accepting the fix please let
me know.  Removing the noreturn keyword from the whitelist is
trivial.


Please do.


Attached is an updated patch with this change and with
the TREE_HAS_VOLATILE bit split up between types and functions.
I've also removed warn_unused_result from the blacklist (see
below).

Bootstrapped on x864_64, regression test is in progress.

Martin

While reviewing other related bugs I noticed 83502.  This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline).  Somehow those are still copied from
the primary to the specialization and can cause conflicts.


Hmm, that's odd.  Why is that?


It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below.  Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.

   template 
   int __attribute__ ((warn_unused_result)) f (T) { return 0; }

   template <>
   int __attribute__ ((noreturn)) f (int) { throw 0; }

   void fi () { f (0); }


I continue to disagree with this use of attribute noreturn.


+ /* Merge the function-has-side-effects bit.  */
+ if (TREE_THIS_VOLATILE (newdecl))
+   TREE_THIS_VOLATILE (olddecl) = 1;
+
+ if (merge_attr)


TREE_THIS_VOLATILE means attribute noreturn, not whether the function 
has side-effects; it should be handled in the blocks controlled by 
merge_attr.


Jason

patch to fix PR81572

[Vladimir Makarov]

  The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81572

  The patch was successfully bootstrapped and tested on ppc64.

  Committed as rev. 257915.

Index: ChangeLog
===
--- ChangeLog	(revision 257901)
+++ ChangeLog	(working copy)
@@ -1,3 +1,19 @@
+2018-02-22  Vladimir Makarov  
+
+	PR target/81572
+	* lra-int.h (LRA_UNKNOWN_ALT, LRA_NON_CLOBBERED_ALT): New macros.
+	* lra.c (lra_set_insn_recog_data, lra_update_insn_recog_data): Use
+	LRA_UNKNOWN_ALT.
+	* lra-constraints.c (curr_insn_transform): Set up
+	LRA_NON_CLOBBERED_ALT for moves processed on the fast path.  Use
+	LRA_UNKNOWN_ALT.
+	(remove_inheritance_pseudos): Use LRA_UNKNOWN_ALT.
+	* lra-eliminations.c (spill_pseudos): Ditto.
+	(process_insn_for_elimination): Ditto.
+	* lra-lives.c (reg_early_clobber_p): Use the new macros.
+	* lra-spills.c (spill_pseudos): Use LRA_UNKNOWN_ALT and
+	LRA_NON_CLOBBERED_ALT.
+
 2018-02-22  Martin Liska  
 
 	PR driver/83193
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 257901)
+++ lra-constraints.c	(working copy)
@@ -3730,7 +3730,13 @@ curr_insn_transform (bool check_only_p)
 
   curr_insn_set = single_set (curr_insn);
   if (curr_insn_set != NULL_RTX && simple_move_p ())
-return false;
+{
+  /* We assume that the corresponding insn alternative has no
+	 earlier clobbers.  If it is not the case, don't define move
+	 cost equal to 2 for the corresponding register classes.  */
+  lra_set_used_insn_alternative (curr_insn, LRA_NON_CLOBBERED_ALT);
+  return false;
+}
 
   no_input_reloads_p = no_output_reloads_p = false;
   goal_alt_number = -1;
@@ -3838,7 +3844,7 @@ curr_insn_transform (bool check_only_p)
   if (change_p)
 /* If we've changed the instruction then any alternative that
we chose previously may no longer be valid.  */
-lra_set_used_insn_alternative (curr_insn, -1);
+lra_set_used_insn_alternative (curr_insn, LRA_UNKNOWN_ALT);
 
   if (! check_only_p && curr_insn_set != NULL_RTX
   && check_and_process_move (_p, _mem_p))
@@ -3846,7 +3852,7 @@ curr_insn_transform (bool check_only_p)
 
  try_swapped:
 
-  reused_alternative_num = check_only_p ? -1 : curr_id->used_insn_alternative;
+  reused_alternative_num = check_only_p ? LRA_UNKNOWN_ALT : curr_id->used_insn_alternative;
   if (lra_dump_file != NULL && reused_alternative_num >= 0)
 fprintf (lra_dump_file, "Reusing alternative %d for insn #%u\n",
 	 reused_alternative_num, INSN_UID (curr_insn));
@@ -6752,7 +6758,7 @@ remove_inheritance_pseudos (bitmap remov
 			}
 		  lra_push_insn_and_update_insn_regno_info (curr_insn);
 		  lra_set_used_insn_alternative_by_uid
-			(INSN_UID (curr_insn), -1);
+			(INSN_UID (curr_insn), LRA_UNKNOWN_ALT);
 		  done_p = true;
 		  if (lra_dump_file != NULL)
 			{
@@ -6791,7 +6797,7 @@ remove_inheritance_pseudos (bitmap remov
 		 constraints pass.  */
 		  lra_push_insn_and_update_insn_regno_info (curr_insn);
 		  lra_set_used_insn_alternative_by_uid
-		(INSN_UID (curr_insn), -1);
+		(INSN_UID (curr_insn), LRA_UNKNOWN_ALT);
 		}
 	  else if (restored_regs_p)
 		/* The instruction has been restored to the form that
Index: lra-eliminations.c
===
--- lra-eliminations.c	(revision 257901)
+++ lra-eliminations.c	(working copy)
@@ -1175,7 +1175,7 @@ spill_pseudos (HARD_REG_SET set)
 if (bitmap_bit_p (_process, INSN_UID (insn)))
   {
 	lra_push_insn (insn);
-	lra_set_used_insn_alternative (insn, -1);
+	lra_set_used_insn_alternative (insn, LRA_UNKNOWN_ALT);
   }
   bitmap_clear (_process);
 }
@@ -1408,7 +1408,7 @@ process_insn_for_elimination (rtx_insn *
 	}
   lra_update_insn_regno_info (insn);
   lra_push_insn (insn);
-  lra_set_used_insn_alternative (insn, -1);
+  lra_set_used_insn_alternative (insn, LRA_UNKNOWN_ALT);
 }
 }
 
Index: lra-int.h
===
--- lra-int.h	(revision 257901)
+++ lra-int.h	(working copy)
@@ -202,15 +202,20 @@ struct lra_static_insn_data
   const struct operand_alternative *operand_alternative;
 };
 
+/* Negative insn alternative numbers used for special cases.  */
+#define LRA_UNKNOWN_ALT -1
+#define LRA_NON_CLOBBERED_ALT -2
+
 /* LRA internal info about an insn (LRA internal insn
representation).  */
 struct lra_insn_recog_data
 {
   /* The insn code.  */
   int icode;
-  /* The alternative should be used for the insn, -1 if invalid, or we
- should try to use any alternative, or the insn is a debug
- insn.  */
+  /* The alternative should be used for the insn, LRA_UNKNOWN_ALT if
+ unknown, or we should assume any alternative, or the insn is a
+ debug insn.  LRA_NON_CLOBBERED_ALT means ignoring any earlier
+ clobbers for the insn.  */
   int 

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

[Joseph Myers]

On Thu, 22 Feb 2018, Martin Sebor wrote:

> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00858.html
> 
> This is just a tweak to fix a translation bug introduced by
> one of my warnings (calling warning() where warning_n() is
> more appropriate), and to enhance warning_n() et al. to do
> the n % 100 + 100 computation so callers don't have
> to worry about it.

OK in the absence of diagnostic maintainer objections within 48 hours, 
with the comment saying "ngettext()" changed to remove the "()" (see the 
GNU Coding Standards: "Please do not write @samp{()} after a function name 
just to indicate it is a function.  @code{foo ()} is not a function, it is 
a function call with no arguments.").

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] PR 84519 Handle optional QUIET specifier for STOP and ERROR STOP

[Steve Kargl]

On Thu, Feb 22, 2018 at 09:42:02PM +0200, Janne Blomqvist wrote:
> Fortran 2018 adds a new QUIET specifier for the STOP and ERROR STOP
> statements, in order to suppress the printing of signaling FP
> exceptions and the stop code. This patch adds the necessary library
> changes, but for now the new specifier is not parsed and the frontend
> unconditionally adds a false value for the new argument.
> 
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
> 

OK.

-- 
steve

[PATCH] PR fortran/84511 -- Fix C_LOC in a transfer statement

[Steve Kargl]

All,

The attached patch handles C_LOC in a transfer statement
such as "print *, c_loc(xxx)".  The bug report contains
two files that must be compiled separately to exhibit 
the bug.  I have no idea how to write a testcase for this
situation.  If someone can write a testcase, I'm fine
with that.  If someone can tell me how to write a testcase,
I'm fine with that, too. 

Regression tested on x86_64-*-freebsd.  OK to commit?

2018-02-22  Steven G. Kargl  

PR fortran/84511
* trans-io.c (transfer_expr): Deal with C_LOC in transfer statement.

-- 
Steve
Index: trans-io.c
===
--- trans-io.c	(revision 257695)
+++ trans-io.c	(working copy)
@@ -2289,6 +2289,16 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree ad
   ts->kind = gfc_index_integer_kind;
 }
 
+  /* gfortran reaches here for "print *, c_loc(xxx)".  */
+  if (ts->type == BT_VOID
+  && code->expr1 && code->expr1->ts.type == BT_VOID
+  && code->expr1->symtree
+  && strcmp (code->expr1->symtree->name, "c_loc") == 0)
+{
+  ts->type = BT_INTEGER;
+  ts->kind = gfc_index_integer_kind;
+}
+
   kind = ts->kind;
   function = NULL;
   arg2 = NULL;

libgo patch committed: Add 64-bit RISC-V support

[Ian Lance Taylor]

This patch by Andreas Schwab adds 64-bit RISC-V support to libgo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian


2018-02-22  Andreas Schwab  

* go.test/go-test.exp (go-set-goarch): Recognize riscv64-*-*.
Index: gcc-8.0.1+r257516/libgo/configure.ac
===
--- gcc-8.0.1+r257516.orig/libgo/configure.ac
+++ gcc-8.0.1+r257516/libgo/configure.ac
@@ -224,10 +224,10 @@ AC_SUBST(USE_DEJAGNU)
 #   - libgo/go/syscall/endian_XX.go
 #   - possibly others
 # - possibly update files in libgo/go/internal/syscall/unix
-ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips 
mipsle mips64 mips64le mips64p32 mips64p32le ppc ppc64 ppc64le s390 s390x sh 
shbe sparc sparc64"
+ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mips 
mipsle mips64 mips64le mips64p32 mips64p32le ppc ppc64 ppc64le riscv64 s390 
s390x sh shbe sparc sparc64"
 
 # All known GOARCH family values.
-ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 PPC PPC64 
S390 S390X SH SPARC SPARC64"
+ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 PPC PPC64 
RISCV64 S390 S390X SH SPARC SPARC64"
 
 GOARCH=unknown
 case ${host} in
@@ -304,6 +304,9 @@ AC_COMPILE_IFELSE([
 [GOARCH=ppc64le],
 [GOARCH=ppc64])])
 ;;
+  riscv64-*-*)
+GOARCH=riscv64
+;;
   s390*-*-*)
 AC_COMPILE_IFELSE([
 #if defined(__s390x__)
@@ -500,7 +503,8 @@ AC_COMPILE_IFELSE([[int i;]],
 CFLAGS=$CFLAGS_hold])
 PTHREAD_CFLAGS=
 if test "$libgo_cv_lib_pthread" = yes; then
-  PTHREAD_CFLAGS=-pthread
+  # RISC-V apparently adds -latomic when using -pthread.
+  PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
 fi
 AC_SUBST(PTHREAD_CFLAGS)
 
Index: gcc-8.0.1+r257516/libgo/go/cmd/cgo/main.go
===
--- gcc-8.0.1+r257516.orig/libgo/go/cmd/cgo/main.go
+++ gcc-8.0.1+r257516/libgo/go/cmd/cgo/main.go
@@ -168,6 +168,7 @@ var ptrSizeMap = map[string]int64{
"ppc": 4,
"ppc64":   8,
"ppc64le": 8,
+   "riscv64": 8,
"s390":4,
"s390x":   8,
"sh":  4,
@@ -192,6 +193,7 @@ var intSizeMap = map[string]int64{
"ppc": 4,
"ppc64":   8,
"ppc64le": 8,
+   "riscv64": 8,
"s390":4,
"s390x":   8,
"sh":  4,
Index: gcc-8.0.1+r257516/libgo/go/go/build/syslist.go
===
--- gcc-8.0.1+r257516.orig/libgo/go/go/build/syslist.go
+++ gcc-8.0.1+r257516/libgo/go/go/build/syslist.go
@@ -5,4 +5,4 @@
 package build
 
 const goosList = "aix android darwin dragonfly freebsd linux nacl netbsd 
openbsd plan9 solaris windows zos "
-const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m68k 
ppc64 ppc64le mips mipsle mips64 mips64le mips64p32 mips64p32le ppc s390 s390x 
sh shbe sparc sparc64"
+const goarchList = "386 amd64 amd64p32 arm armbe arm64 arm64be alpha m68k 
ppc64 ppc64le mips mipsle mips64 mips64le mips64p32 mips64p32le ppc riscv64 
s390 s390x sh shbe sparc sparc64"
Index: 
gcc-8.0.1+r257516/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
===
--- 
gcc-8.0.1+r257516.orig/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
+++ gcc-8.0.1+r257516/libgo/go/internal/syscall/unix/getrandom_linux_generic.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build arm64
+// +build arm64 riscv64
 
 package unix
 
Index: gcc-8.0.1+r257516/libgo/go/runtime/hash64.go
===
--- gcc-8.0.1+r257516.orig/libgo/go/runtime/hash64.go
+++ gcc-8.0.1+r257516/libgo/go/runtime/hash64.go
@@ -6,7 +6,7 @@
 //   xxhash: https://code.google.com/p/xxhash/
 // cityhash: https://code.google.com/p/cityhash/
 
-// +build amd64 amd64p32 arm64 mips64 mips64le ppc64 ppc64le s390x alpha 
arm64be ia64 mips64p32 mips64p32le sparc64
+// +build amd64 amd64p32 arm64 mips64 mips64le ppc64 ppc64le s390x alpha 
arm64be ia64 mips64p32 mips64p32le sparc64 riscv64
 
 package runtime
 
Index: gcc-8.0.1+r257516/libgo/go/runtime/lfstack_64bit.go
===
--- gcc-8.0.1+r257516.orig/libgo/go/runtime/lfstack_64bit.go
+++ gcc-8.0.1+r257516/libgo/go/runtime/lfstack_64bit.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build amd64 arm64 mips64 mips64le ppc64 ppc64le s390x arm64be alpha 
sparc64 ia64
+// +build amd64 arm64 mips64 mips64le ppc64 ppc64le s390x arm64be alpha 
sparc64 ia64 riscv64
 
 package runtime
 
Index: gcc-8.0.1+r257516/libgo/go/runtime/unaligned1.go

[PATCH] PR 84519 Handle optional QUIET specifier for STOP and ERROR STOP

[Janne Blomqvist]

Fortran 2018 adds a new QUIET specifier for the STOP and ERROR STOP
statements, in order to suppress the printing of signaling FP
exceptions and the stop code. This patch adds the necessary library
changes, but for now the new specifier is not parsed and the frontend
unconditionally adds a false value for the new argument.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?

(If accepted, I will handle the necessary changes to OpenCoarrays as
well).

gcc/fortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR fortran/84519
* trans-decl.c (gfc_build_builtin_function_decls): Add bool
argument to stop and error stop decls.
* trans-stmt.c (gfc_trans_stop): Add false value to argument
lists.

libgfortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR fortran/84519
* caf/libcaf.h (_gfortran_caf_stop_numeric): Add bool argument.
(_gfortran_caf_stop_str): Likewise.
(_gfortran_caf_error_stop_str): Likewise.
(_gfortran_caf_error_stop): Likewise.
* caf/mpi.c (_gfortran_caf_error_stop_str): Handle new argument.
(_gfortran_caf_error_stop): Likewise.
* caf/single.c (_gfortran_caf_stop_numeric): Likewise.
(_gfortran_caf_stop_str): Likewise.
(_gfortran_caf_error_stop_str): Likewise.
(_gfortran_caf_error_stop): Likewise.
(_gfortran_caf_lock): Likewise.
(_gfortran_caf_unlock): Likewise.
* libgfortran.h (stop_string): Add bool argument.
* runtime/pause.c (do_pause): Add false argument.
* runtime/stop.c (stop_numeric): Handle new argument.
(stop_string): Likewise.
(error_stop_string): Likewise.
(error_stop_numeric): Likewise.
---
 gcc/fortran/trans-decl.c| 10 +
 gcc/fortran/trans-stmt.c| 13 ++-
 libgfortran/caf/libcaf.h|  8 +++
 libgfortran/caf/mpi.c   | 19 +---
 libgfortran/caf/single.c| 42 ---
 libgfortran/libgfortran.h   |  2 +-
 libgfortran/runtime/pause.c |  2 +-
 libgfortran/runtime/stop.c  | 53 +++--
 8 files changed, 87 insertions(+), 62 deletions(-)

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index e8c10d4..c233a0e 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3503,25 +3503,27 @@ gfc_build_builtin_function_decls (void)
 
   gfor_fndecl_stop_numeric = gfc_build_library_function_decl (
get_identifier (PREFIX("stop_numeric")),
-   void_type_node, 1, integer_type_node);
+   void_type_node, 2, integer_type_node, boolean_type_node);
   /* STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_stop_numeric) = 1;
 
   gfor_fndecl_stop_string = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("stop_string")), ".R.",
-   void_type_node, 2, pchar_type_node, size_type_node);
+   void_type_node, 3, pchar_type_node, size_type_node,
+   boolean_type_node);
   /* STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_stop_string) = 1;
 
   gfor_fndecl_error_stop_numeric = gfc_build_library_function_decl (
 get_identifier (PREFIX("error_stop_numeric")),
-void_type_node, 1, integer_type_node);
+void_type_node, 2, integer_type_node, boolean_type_node);
   /* ERROR STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_error_stop_numeric) = 1;
 
   gfor_fndecl_error_stop_string = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("error_stop_string")), ".R.",
-   void_type_node, 2, pchar_type_node, size_type_node);
+   void_type_node, 3, pchar_type_node, size_type_node,
+   boolean_type_node);
   /* ERROR STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1;
 
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index f1fe8a0..cf76fd0 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -642,7 +642,8 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
 : (flag_coarray == GFC_FCOARRAY_LIB
? gfor_fndecl_caf_stop_str
: gfor_fndecl_stop_string),
-2, build_int_cst (pchar_type_node, 0), tmp);
+3, build_int_cst (pchar_type_node, 0), tmp,
+boolean_false_node);
 }
   else if (code->expr1->ts.type == BT_INTEGER)
 {
@@ -654,8 +655,9 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
: gfor_fndecl_error_stop_numeric)
 : (flag_coarray == GFC_FCOARRAY_LIB
? gfor_fndecl_caf_stop_numeric
-   : gfor_fndecl_stop_numeric), 1,
-fold_convert (integer_type_node, se.expr));
+   : 

Re: [PATCH] Tweak gcc.target/i386/avx2-vp{add,sub}q-3.c (PR target/82851)

[Uros Bizjak]

On Thu, Feb 22, 2018 at 7:16 PM, Jakub Jelinek  wrote:
> Hi!
>
> These tests FAIL the vp.*q.*ymm insn scan with some tunings, e.g.
> -mtune=silvermont or -mtune=atom, because vectorizing it using AVX2
> is based on costs considered too expensive.
> E.g. for -mtune=silvermont I see for VF 4:
>
> avx2-vpop-check.h:16:3: note: Cost model analysis:
>   Vector inside of loop cost: 330
>   Vector prologue cost: 0
>   Vector epilogue cost: 0
>   Scalar iteration cost: 48
>   Scalar outside cost: 0
>   Vector outside cost: 0
>   prologue iterations: 0
>   epilogue iterations: 0
> avx2-vpop-check.h:16:3: note: cost model: the vector iteration cost = 330 
> divided by the scalar iteration cost = 48 is greater or equal to the vect
> orization factor = 4.
> avx2-vpop-check.h:16:3: note: not vectorized: vectorization not profitable.
> avx2-vpop-check.h:16:3: note: not vectorized: vector version will never be 
> profitable.
> avx2-vpop-check.h:16:3: note: * Re-trying analysis with vector size 16
>
> while with -mtune=generic I see:
>
> avx2-vpop-check.h:16:3: note: Cost model analysis:
>   Vector inside of loop cost: 64
>   Vector prologue cost: 0
>   Vector epilogue cost: 0
>   Scalar iteration cost: 40
>   Scalar outside cost: 0
>   Vector outside cost: 0
>   prologue iterations: 0
>   epilogue iterations: 0
>   Calculated minimum iters for profitability: 0
>
> I think we can either use -mtune=generic as in the patch below,
> or add -fno-vect-cost-model.
>
> Tested on x86_64-linux with:
> make check-gcc 
> RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mtune=silvermont,-m32/-mtune=atom,-m64,-m64/-mtune=silvermont,-m64/-mtune=atom\}
>  i386.exp=avx2-vp*q-3.c'
> Ok for trunk?
>
> 2018-02-22  Jakub Jelinek  
>
> PR target/82851
> * gcc.target/i386/avx2-vpaddq-3.c: Add -mtune=generic to dg-options.
> * gcc.target/i386/avx2-vpsubq-3.c: Likewise.

OK.

Thanks,
Uros.

> --- gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c.jj2015-05-29 
> 15:02:59.475249515 +0200
> +++ gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c   2018-02-22 
> 18:44:45.353178253 +0100
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps" 
> } */
> +/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize 
> -mtune=generic -save-temps" } */
>  /* { dg-require-effective-target avx2 } */
>
>
> --- gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c.jj2015-05-29 
> 15:03:00.572232560 +0200
> +++ gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c   2018-02-22 
> 18:45:02.131168864 +0100
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps" 
> } */
> +/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize 
> -mtune=generic -save-temps" } */
>  /* { dg-require-effective-target avx2 } */
>
>
>
> Jakub

libgo patch committed: Get missing function name from symbol table in funcfileline

[Ian Lance Taylor]

This patch to libgo changes funcfileline to get missing a function
name from the symbol table if possible.  This copies the idea of
https://golang.org/cl/92756 to funcfileline, which is used by
runtime.FuncForPC, runtime.(*Frames).Next, and others.  Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257911)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-b4d61f028dd1623142df4130b6c660bb77474b7b
+ed8647cc99652db2d689215c05f31ad038438a7e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/go-caller.c
===
--- libgo/runtime/go-caller.c   (revision 257527)
+++ libgo/runtime/go-caller.c   (working copy)
@@ -129,18 +129,26 @@ __go_get_backtrace_state ()
is the entry on the stack of inlined functions; -1 means the last
one.  */
 
-_Bool
+static _Bool
 __go_file_line (uintptr pc, int index, String *fn, String *file, intgo *line)
 {
   struct caller c;
+  struct backtrace_state *state;
 
   runtime_memclr (, sizeof c);
   c.index = index;
-  backtrace_pcinfo (__go_get_backtrace_state (), pc, callback,
-   error_callback, );
+  state = __go_get_backtrace_state ();
+  backtrace_pcinfo (state, pc, callback, error_callback, );
   *fn = c.fn;
   *file = c.file;
   *line = c.line;
+
+  // If backtrace_pcinfo didn't get the function name from the debug
+  // info, try to get it from the symbol table.
+  if (fn->len == 0)
+backtrace_syminfo (state, pc, __go_syminfo_fnname_callback,
+  error_callback, fn);
+
   return c.file.len > 0;
 }
 
Index: libgo/runtime/go-callers.c
===
--- libgo/runtime/go-callers.c  (revision 257527)
+++ libgo/runtime/go-callers.c  (working copy)
@@ -145,16 +145,17 @@ callback (void *data, uintptr_t pc, cons
 
 /* Syminfo callback.  */
 
-static void
-syminfo_fnname_callback (void *data, uintptr_t pc __attribute__ ((unused)),
-const char *symname,
-uintptr_t address __attribute__ ((unused)),
-uintptr_t size __attribute__ ((unused)))
+void
+__go_syminfo_fnname_callback (void *data,
+ uintptr_t pc __attribute__ ((unused)),
+ const char *symname,
+ uintptr_t address __attribute__ ((unused)),
+ uintptr_t size __attribute__ ((unused)))
 {
-  Location* locptr = (Location*) data;
+  String* strptr = (String*) data;
 
   if (symname != NULL)
-locptr->function = runtime_gostringnocopy ((const byte *) symname);
+*strptr = runtime_gostringnocopy ((const byte *) symname);
 }
 
 /* Error callback.  */
@@ -228,8 +229,8 @@ runtime_callers (int32 skip, Location *l
   for (i = 0; i < data.index; ++i)
 {
   if (locbuf[i].function.len == 0 && locbuf[i].pc != 0)
-   backtrace_syminfo (state, locbuf[i].pc, syminfo_fnname_callback,
-  error_callback, [i]);
+   backtrace_syminfo (state, locbuf[i].pc, __go_syminfo_fnname_callback,
+  error_callback, [i].function);
 }
 
   return data.index;
Index: libgo/runtime/runtime.h
===
--- libgo/runtime/runtime.h (revision 257527)
+++ libgo/runtime/runtime.h (working copy)
@@ -456,7 +456,8 @@ extern uintptr runtime_stacks_sys;
 
 struct backtrace_state;
 extern struct backtrace_state *__go_get_backtrace_state(void);
-extern _Bool __go_file_line(uintptr, int, String*, String*, intgo *);
+extern void __go_syminfo_fnname_callback(void*, uintptr_t, const char*,
+uintptr_t, uintptr_t);
 extern void runtime_main(void*)
   __asm__(GOSYM_PREFIX "runtime.main");
 

libgo patch committed: Add -L option for libatomic when using -pthread

[Ian Lance Taylor]

This patch to libgo adds a -L option for libatomic when using
-pthread.  This fixes configure checks for riscv, for which -pthread
implies -latomic.  This fixes GCC PR 84484.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257848)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c6e0970f75508e209a10a7db5164d6ea3f9b28bf
+b4d61f028dd1623142df4130b6c660bb77474b7b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 257527)
+++ libgo/configure.ac  (working copy)
@@ -493,14 +493,15 @@ dnl Test whether the compiler supports t
 AC_CACHE_CHECK([whether -pthread is supported],
 [libgo_cv_lib_pthread],
 [CFLAGS_hold=$CFLAGS
-CFLAGS="$CFLAGS -pthread"
+CFLAGS="$CFLAGS -pthread -L../libatomic/.libs"
 AC_COMPILE_IFELSE([[int i;]],
 [libgo_cv_lib_pthread=yes],
 [libgo_cv_lib_pthread=no])
 CFLAGS=$CFLAGS_hold])
 PTHREAD_CFLAGS=
 if test "$libgo_cv_lib_pthread" = yes; then
-  PTHREAD_CFLAGS=-pthread
+  # RISC-V apparently adds -latomic when using -pthread.
+  PTHREAD_CFLAGS="-pthread -L../libatomic/.libs"
 fi
 AC_SUBST(PTHREAD_CFLAGS)
 

[PATCH] Tweak gcc.target/i386/avx2-vp{add,sub}q-3.c (PR target/82851)

[Jakub Jelinek]

Hi!

These tests FAIL the vp.*q.*ymm insn scan with some tunings, e.g.
-mtune=silvermont or -mtune=atom, because vectorizing it using AVX2
is based on costs considered too expensive.
E.g. for -mtune=silvermont I see for VF 4:

avx2-vpop-check.h:16:3: note: Cost model analysis:
  Vector inside of loop cost: 330
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar iteration cost: 48
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
avx2-vpop-check.h:16:3: note: cost model: the vector iteration cost = 330 
divided by the scalar iteration cost = 48 is greater or equal to the vect
orization factor = 4.
avx2-vpop-check.h:16:3: note: not vectorized: vectorization not profitable.
avx2-vpop-check.h:16:3: note: not vectorized: vector version will never be 
profitable.
avx2-vpop-check.h:16:3: note: * Re-trying analysis with vector size 16

while with -mtune=generic I see:

avx2-vpop-check.h:16:3: note: Cost model analysis:
  Vector inside of loop cost: 64
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar iteration cost: 40
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 0

I think we can either use -mtune=generic as in the patch below,
or add -fno-vect-cost-model.

Tested on x86_64-linux with:
make check-gcc 
RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mtune=silvermont,-m32/-mtune=atom,-m64,-m64/-mtune=silvermont,-m64/-mtune=atom\}
 i386.exp=avx2-vp*q-3.c'
Ok for trunk?

2018-02-22  Jakub Jelinek  

PR target/82851
* gcc.target/i386/avx2-vpaddq-3.c: Add -mtune=generic to dg-options.
* gcc.target/i386/avx2-vpsubq-3.c: Likewise.

--- gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c.jj2015-05-29 
15:02:59.475249515 +0200
+++ gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c   2018-02-22 
18:44:45.353178253 +0100
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps" } 
*/
+/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -mtune=generic 
-save-temps" } */
 /* { dg-require-effective-target avx2 } */
 
 
--- gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c.jj2015-05-29 
15:03:00.572232560 +0200
+++ gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c   2018-02-22 
18:45:02.131168864 +0100
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps" } 
*/
+/* { dg-options "-mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -mtune=generic 
-save-temps" } */
 /* { dg-require-effective-target avx2 } */
 
 

Jakub

Re: [PATCH v2] RISC-V: Support for FreeBSD

[Jim Wilson]

On Wed, Feb 21, 2018 at 10:34 PM, Kito Cheng  wrote:
> I don't family with copyright matters, so we can't commit this patch yet
> until Ruslan send the signed copy and FSF signed it? right?

Yes, I'd prefer that the FSF sign it and add it to the copyright list
before we commit the patch.

Jim

Re: [PATCH rs6000], Move Power 8 tests, fix ICE for vec_unsigned2, vec_signed2

[Segher Boessenkool]

Hi!

On Wed, Feb 21, 2018 at 11:10:25AM -0800, Carl Love wrote:
> Per discussions with Segher, we felt it would be best to move the
> vec_float2 test to a Power 8 test as it is only defined for Power 8 and
> beyond. In doing this, I found that compiling builtins-3-runnable.c
> with -mcpu=power7 then generated an ICE for vec_signed2 and
> vec_unsigned2.  It seems that once gcc saw the unsupported vec_float2
> it exited with -mcpu=power7 it exited before seeing the vec_signed2 and
> vec_unsigned2 builtins.  The vec_signed2 and vec_unsigned2 are also
> only defined for Power 8 and beyond.
> 
> This patch moves the three power 8 builtins to a new test file
> builtins-3-runnable-p8.c.  It also fixed the ICE by restricting the
> vec_signed2 and vec_unsigned2 builtins to Power 8.  The builtins-3-
> runnable.c dg settings are then set to enable the test to run on Power
> 7.

> --- a/gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c
> @@ -1,7 +1,6 @@
>  /* { dg-do run { target { p8vector_hw } } } */
>  /* { dg-require-effective-target vsx_hw } */
> -/* { dg-options "-O2 -mvsx -mcpu=power8" } */
> -/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-maltivec -mvsx" } */

I think you should change the p8vector_hw here?  To vsx_hw?

Okay for trunk with that change (please retest this test, of course).
Thanks!


Segher

Re: [PATCH, rs6000] tighten target statements for a p8 and p9 specific tests

[Segher Boessenkool]

On Wed, Feb 21, 2018 at 11:33:31AM -0600, Will Schmidt wrote:
>   Update the dg-requires statements for these tests to specify the target.
> These tests may otherwise fail on a system missing p9 assembler support.
> (Seen in a p6 environment).
> 
> OK for trunk?

Okay, thanks!


Segher


> 2018-02-21  Will Schmidt  
> 
>   * gcc.target/powerpc/pr80695-p8.c: Update dg-requires stanza.
>   * gcc.target/powerpc/pr80695-p9.c: Update dg-requires stanza.

Re: [PATCH, rs6000] Update altivec-7 testcase(s).

[Segher Boessenkool]

Hi Will,

On Wed, Feb 21, 2018 at 11:33:14AM -0600, Will Schmidt wrote:
>   This patch moves the vsx related content from the altivec-7-be test into
> a new vsx-7-be test.
> This fixes up some test failures as seen on older power systems.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> @@ -0,0 +1,42 @@
> +/* { dg-do compile { target powerpc64-*-* } } */

powerpc*-*-* please, and if you need 64-bit use lp64.

Otherwise fine.  Okay for trunk with that fixed.  Thanks!

(Is it useful to copy the altivec stuff here though?  The altivec-7-be
test will be run as well).


Segher

Re: [PATCH, rs6000] fold-vec-mult* testcase updates for power9

[Segher Boessenkool]

Hi!

On Wed, Feb 21, 2018 at 11:32:36AM -0600, Will Schmidt wrote:
> An update for the fold-vec-mult-int128-p9.c test to include more of
> the instructions generated for a vec_mul() with a power9 target.
> 
> [testsuite]
> 
> 2018-02-21  Will Schmidt  
> 
>   * fold-vec-mult-int128-p9.c: Add maddld insn to expected output.

This is fine for trunk.  Thanks!


Segher


> diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c 
> b/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c
> index 6571884..5d3d4aa 100644
> --- a/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mult-int128-p9.c
> @@ -20,7 +20,7 @@ vector unsigned __int128
>  test2 (vector unsigned __int128 x, vector unsigned __int128 y)
>  {
>return vec_mul (x, y);
>  }
>  
> -/* { dg-final { scan-assembler-times {\mmulld\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mmulld\M|\mmaddld\M} 6 } } */
>  /* { dg-final { scan-assembler-times {\mmulhdu\M} 2 } } */
> 

Re: [PATCH] avoid bogus -Wstringop-truncation when inlining (PR 84480)

[Martin Sebor]

On 02/21/2018 07:53 PM, Jeff Law wrote:

On 02/21/2018 02:19 PM, Martin Sebor wrote:

The attached patch eliminates -Wstringop-truncation false
positives reported in bug 84480 - bogus -Wstringop-truncation
despite assignment with an inlined string literal.  It does
that by delegating early strncpy checks during folding to
the same machinery in tree-ssa-strlen that looks for a NUL
assignment to the destination the next statement.

The patch also adds inlining context to the warnings via
the %G directive.

Tested on x86_64-linux with no regressions.

Martin

gcc-84480.diff


PR tree-optimization/84480 - bogus -Wstringop-truncation despite assignment 
with an inlined string literal

gcc/ChangeLog:

PR tree-optimization/84480
* gimple-fold.c (gimple_fold_builtin_strcpy): Move warnings
to maybe_diag_stxncpy_trunc.  Call it.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Integrate warnings
from gimple_fold_builtin_strcpy.  Print inlining stack.
(handle_builtin_stxncpy): Print inlining stack.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Declare.

gcc/testsuite/ChangeLog:

PR tree-optimization/84480
* c-c++-common/Wstringop-truncation.c: Adjust text of expected warnings.
* g++.dg/warn/Wstringop-truncation-1.C: New test.

In general our guidelines are that the users of a .h file should include
any dependencies rather than having the .h file itself include other .h
files (Now that we've detangled the header files we may want to revisit
that guideline, but that's not a gcc-8 item).

It looks like gimple-fold.c and tree-ssa-strlen.c already have the
prereqs.  So in theory you should be able to just remove the bogus
#includes from tree-ssa-strlen.h.


Done.



In general we want to avoid adding more warnings to folding code.  But I
think the argument here is that we're already trying to warn within the
folder and just doing a poor job -- so we're removing that
implementation and delegating the warning to a better implementation.
Right?


Exactly.



So I think you just need to remove the bogus #includes from
tree-ssa-strlen and this is OK.


Thanks.  Committed in r257910.

Martin

[PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Jakub Jelinek]

Hi!

On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
> Thanks.  I like the idea of commonizing the macros for consistency.

Didn't see a progress on this P3 for a while, so I've written this
version of the patch; no tests though, what I've been using in testing was:
/* { dg-do compile { target lp64 } } */
/* { dg-options "-mno-avx -msse2 -mcall-ms2sysv-xlogues -O2" } */

void __attribute__((sysv_abi, noipa))
foo (void)
{
}

static void __attribute__((sysv_abi)) (*volatile foop) () = foo;

void __attribute__((ms_abi, noipa))
bar (void)
{
  foop ();
}

int
main ()
{
  bar ();
  return 0;
}

with/without -fno-omit-frame-pointer, disas bar; b on the tail
call in there, stepi; bt (which before the patch failed, now works),
also up; p $rbp to see if %rbp has been properly declared to be saved.
There is no need to cfi_startproc/cfi_endproc for every single entrypoint in
there, it is enough if the whole range is covered.  On the other side
we need the cfi_offset for the frame pointer case, otherwise up; p/x $rbp
doesn't work properly.

Ok for trunk if it passes bootstrap/regtest on x86_64-linux and i686-linux?

2018-02-22  Jakub Jelinek  

PR debug/83917
* config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME,
PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between
inclusion of auto-target.h and auto-host.h.
(USE_GAS_CFI_DIRECTIVES): Define if not defined already based on
__GCC_HAVE_DWARF2_CFI_ASM.
(cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push,
cfi_pop): Define.
* config/i386/cygwin.S: Don't include auto-host.h here, just
define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h.
(cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove.
* config/i386/resms64fx.h: Add cfi_* directives.
* config/i386/resms64x.h: Likewise.

--- libgcc/config/i386/i386-asm.h.jj2018-01-03 10:42:56.317763517 +0100
+++ libgcc/config/i386/i386-asm.h   2018-02-22 15:33:43.812922298 +0100
@@ -27,8 +27,47 @@ see the files COPYING3 and COPYING.RUNTI
 #define I386_ASM_H
 
 #include "auto-target.h"
+#undef PACKAGE_VERSION
+#undef PACKAGE_NAME
+#undef PACKAGE_STRING
+#undef PACKAGE_TARNAME
+#undef PACKAGE_URL
 #include "auto-host.h"
 
+#ifndef USE_GAS_CFI_DIRECTIVES
+# ifdef __GCC_HAVE_DWARF2_CFI_ASM
+#  define USE_GAS_CFI_DIRECTIVES 1
+# else
+#  define USE_GAS_CFI_DIRECTIVES 0
+# endif
+#endif
+#if USE_GAS_CFI_DIRECTIVES
+# define cfi_startproc()   .cfi_startproc
+# define cfi_endproc() .cfi_endproc
+# define cfi_adjust_cfa_offset(X)  .cfi_adjust_cfa_offset X
+# define cfi_def_cfa_register(X)   .cfi_def_cfa_register X
+# define cfi_def_cfa(R,O)  .cfi_def_cfa R, O
+# define cfi_register(D,S) .cfi_register D, S
+# define cfi_offset(R,O)   .cfi_offset R, O
+# ifdef __x86_64__
+#  define cfi_push(X)  .cfi_adjust_cfa_offset 8; .cfi_rel_offset X, 0
+#  define cfi_pop(X)   .cfi_adjust_cfa_offset -8; .cfi_restore X
+# else
+#  define cfi_push(X)  .cfi_adjust_cfa_offset 4; .cfi_rel_offset X, 0
+#  define cfi_pop(X)   .cfi_adjust_cfa_offset -4; .cfi_restore X
+# endif
+#else
+# define cfi_startproc()
+# define cfi_endproc()
+# define cfi_adjust_cfa_offset(X)
+# define cfi_def_cfa_register(X)
+# define cfi_def_cfa(R,O)
+# define cfi_register(D,S)
+# define cfi_offset(R,O)
+# define cfi_push(X)
+# define cfi_pop(X)
+#endif
+
 #define PASTE2(a, b) PASTE2a(a, b)
 #define PASTE2a(a, b) a ## b
 
--- libgcc/config/i386/cygwin.S.jj  2018-01-03 10:42:56.309763515 +0100
+++ libgcc/config/i386/cygwin.S 2018-02-22 15:30:34.597925496 +0100
@@ -23,31 +23,13 @@
  * .
  */
 
-#include "auto-host.h"
-
 #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE
+# define USE_GAS_CFI_DIRECTIVES 1
.cfi_sections   .debug_frame
-# define cfi_startproc()   .cfi_startproc
-# define cfi_endproc() .cfi_endproc
-# define cfi_adjust_cfa_offset(X)  .cfi_adjust_cfa_offset X
-# define cfi_def_cfa_register(X)   .cfi_def_cfa_register X
-# define cfi_register(D,S) .cfi_register D, S
-# ifdef __x86_64__
-#  define cfi_push(X)  .cfi_adjust_cfa_offset 8; .cfi_rel_offset X, 0
-#  define cfi_pop(X)   .cfi_adjust_cfa_offset -8; .cfi_restore X
-# else
-#  define cfi_push(X)  .cfi_adjust_cfa_offset 4; .cfi_rel_offset X, 0
-#  define cfi_pop(X)   .cfi_adjust_cfa_offset -4; .cfi_restore X
-# endif
 #else
-# define cfi_startproc()
-# define cfi_endproc()
-# define cfi_adjust_cfa_offset(X)
-# define cfi_def_cfa_register(X)
-# define cfi_register(D,S)
-# define cfi_push(X)
-# define cfi_pop(X)
-#endif /* HAVE_GAS_CFI_SECTIONS_DIRECTIVE */
+# define USE_GAS_CFI_DIRECTIVES 0
+#endif
+#include 

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[H.J. Lu]

On Thu, Feb 22, 2018 at 9:10 AM, Jeff Law  wrote:
> On 02/22/2018 07:38 AM, Jan Hubicka wrote:
>
> Hi Jan,
>
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
>
> Is OK for trunk?

 I see that using register makes the problem go away and pushing address to 
 stack
 seemed bit odd anyway. However how does this work on other types of thunk?
>>>
>>> Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a 
>>> proposal
>>> to use -mindirect-branch=thunk-extern in user space to support CET in a 
>>> single
>>> binary.  So at the end of the day, only
>>> -mindirect-branch=thunk-extern will be used.
>>
>> OK, so it is about the fact that we do not really want to support all
>> -mindirect-branch options in the future? If we don't want to support the 
>> correctly,
>> I wonder why we are including them at all.  Shall we at least output 
>> warning/sorry
>> when user tries other thunk type with stack unwinding enabled?
>> (does Kernel use it?)
> A few notes.
>
> 1. It's not even clear at this time that retpolining user space binaries
> makes any sense at all.   SO before doing anything to make this easier
> I'd like to see a justification for why it's really needed.

Hi Jeff,

Which part were commenting? My patch to add TARGET_INDIRECT_BRANCH_REGISTER
or removing -mindirect-branch choices?

> 2. On the other hand, the existing thunk options do make it easier to
> test independent of hte kernel.  ie, I can turn on inline thunks by
> default and test things in user space (ie, do thunks generally work
> properly).

It sounds reasonable.


-- 
H.J.

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jeff Law]

On 02/22/2018 07:38 AM, Jan Hubicka wrote:

 Hi Jan,

 https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html

 Is OK for trunk?
>>>
>>> I see that using register makes the problem go away and pushing address to 
>>> stack
>>> seemed bit odd anyway. However how does this work on other types of thunk?
>>
>> Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a proposal
>> to use -mindirect-branch=thunk-extern in user space to support CET in a 
>> single
>> binary.  So at the end of the day, only
>> -mindirect-branch=thunk-extern will be used.
> 
> OK, so it is about the fact that we do not really want to support all
> -mindirect-branch options in the future? If we don't want to support the 
> correctly,
> I wonder why we are including them at all.  Shall we at least output 
> warning/sorry
> when user tries other thunk type with stack unwinding enabled?
> (does Kernel use it?)
A few notes.

1. It's not even clear at this time that retpolining user space binaries
makes any sense at all.   SO before doing anything to make this easier
I'd like to see a justification for why it's really needed.

2. On the other hand, the existing thunk options do make it easier to
test independent of hte kernel.  ie, I can turn on inline thunks by
default and test things in user space (ie, do thunks generally work
properly).

Jeff

Re: [PATCH] RX TARGET_RTX_COSTS function

[Oleg Endo]

On Thu, 2018-02-22 at 15:41 +, Nick Clifton wrote:


> > > gcc/ChangeLog:
> > >   * config/rx/rx.c (rx_rtx_costs): New function.
> > >   (TARGET_RTX_COSTS): Override to use rx_rtx_costs.
> Approved - please apply.
> 

Thanks.  Committed as r257905.

Cheers,
Oleg

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[H.J. Lu]

On Thu, Feb 22, 2018 at 6:38 AM, Jan Hubicka  wrote:
>> >>
>> >> Hi Jan,
>> >>
>> >> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
>> >>
>> >> Is OK for trunk?
>> >
>> > I see that using register makes the problem go away and pushing address to 
>> > stack
>> > seemed bit odd anyway. However how does this work on other types of thunk?
>>
>> Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a proposal
>> to use -mindirect-branch=thunk-extern in user space to support CET in a 
>> single
>> binary.  So at the end of the day, only
>> -mindirect-branch=thunk-extern will be used.
>
> OK, so it is about the fact that we do not really want to support all
> -mindirect-branch options in the future? If we don't want to support the 
> correctly,
> I wonder why we are including them at all.  Shall we at least output 
> warning/sorry

-mindirect-branch= implementation changed over time while
experimenting different
approaches.  I didn't remove the old ones when I added new ones.  We
should remove
others and only keep -mindirect-branch=thunk-extern with my proposal
to support CET
with -mindirect-branch=thunk-extern.

> when user tries other thunk type with stack unwinding enabled?

This is on my TODO list.

> (does Kernel use it?)

No, kernel doesn't use it.


-- 
H.J.

RE: [PATCH] RX TARGET_RTX_COSTS function

[Sebastian Perta]

Hi Oleg,

Sorry, for some reason your emails did not ended up in Inbox, I was quite 
surprized when Nick's email started with Hi Oleg.

>>Do you happen to have any other numbers on the resulting code
>>size/speed?  
The original patch from DJ was present in my local sources since 4.7 so all the 
benchmarks (CSIBE etc.) were done on that version (when the patch was initially 
applied)
Of course I re-tested the patch when I applied it to the trunk (but I didn't 
re-tested CSIBE) the only problem I spotted was the multiplication with the 
reciprocal.

Best Regards,
Sebastian

> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: 22 February 2018 15:41
> To: Oleg Endo ; gcc-patches@gcc.gnu.org
> Cc: Sebastian Perta ; 'DJ Delorie'
> 
> Subject: Re: [PATCH] RX TARGET_RTX_COSTS function
> 
> Hi Oleg,
> 
> > Ping.
> 
> Sorry - I am not very good at spotting RX bugs on the gcc-patches list. :-(
> 
> >> gcc/ChangeLog:
> >>* config/rx/rx.c (rx_rtx_costs): New function.
> >>(TARGET_RTX_COSTS): Override to use rx_rtx_costs.
> 
> Approved - please apply.
> 
> Cheers
>   Nick
> 

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00858.html

This is just a tweak to fix a translation bug introduced by
one of my warnings (calling warning() where warning_n() is
more appropriate), and to enhance warning_n() et al. to do
the n % 100 + 100 computation so callers don't have
to worry about it.

On 02/14/2018 11:02 AM, Martin Sebor wrote:

On 02/13/2018 02:05 PM, Joseph Myers wrote:

On Mon, 12 Feb 2018, Martin Sebor wrote:


Bug 84207 - Hard coded plural in gimple-fold.c points out one
of a number of warning_at() calls where warning_n() should have
been used.  The attached patch both replaces the calls and also
changes the signatures of the warning_n(), error_n(), and
inform_n() functions to take an unsigned HOST_WIDE_INT argument
instead of int.  I also changed the implementation of
diagnostic_n_impl() to deal with unsigned HOST_WIDE_INT values
in excess of ULONG_MAX (the maximum value ngettext handles) so
callers don't need to.


Saturating to ULONG_MAX is not correct for languages where the plural
form
depends on n%10 or n%100 (see the various Plural-Forms entries in the .po
files).  If n is too large you want something like n % 100 + 100
instead to get the correct plural form in all cases.


Thanks.  I've made that change in the attached patch.

I was also hoping to test it, either now if it's easy, or if
it's complicated, sometime in the future but I couldn't find
a .po file where it would make a difference.  I could have
easily missed one but none of those I've looked seems to do
much with the plural forms where such large numbers could
come up.  The strings are either all empty or all look
the same.  Do you happen to know of one where it matters
and a suggestion for how to test it?  I suppose I could
create a dummy .po file with a non-trivial Plural-Forms but
then how would I plug it into GCC to verify (in an automated
test) that the right form is used?

Martin

[PATCH] PR 78534, 84509 Fix libgfortran API for PAUSE statement

[Janne Blomqvist]

This patch changes the libgfortran API for the PAUSE statement. By
passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the
character version passing the length as a size_t.

Regtested on x86_64-pc-linux-gnu, committed as obvious.

gcc/fortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* trans-decl.c (gfc_build_builtin_function_decls): Pass
gfc_int8_type node to pause_numeric, size_type_node to
pause_string.
* trans-stmt.c (gfc_trans_pause): Likewise.

libgfortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8
argument.
(pause_string): Modify to take size_t character length argument.
---
 gcc/fortran/trans-decl.c|  6 +++---
 gcc/fortran/trans-stmt.c|  9 +
 libgfortran/runtime/pause.c | 10 +-
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 63336b3..e8c10d4 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3499,7 +3499,7 @@ gfc_build_intrinsic_function_decls (void)
 void
 gfc_build_builtin_function_decls (void)
 {
-  tree gfc_int4_type_node = gfc_get_int_type (4);
+  tree gfc_int8_type_node = gfc_get_int_type (8);
 
   gfor_fndecl_stop_numeric = gfc_build_library_function_decl (
get_identifier (PREFIX("stop_numeric")),
@@ -3527,11 +3527,11 @@ gfc_build_builtin_function_decls (void)
 
   gfor_fndecl_pause_numeric = gfc_build_library_function_decl (
get_identifier (PREFIX("pause_numeric")),
-   void_type_node, 1, gfc_int4_type_node);
+   void_type_node, 1, gfc_int8_type_node);
 
   gfor_fndecl_pause_string = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("pause_string")), ".R.",
-   void_type_node, 2, pchar_type_node, gfc_int4_type_node);
+   void_type_node, 2, pchar_type_node, size_type_node);
 
   gfor_fndecl_runtime_error = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("runtime_error")), ".R",
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index e9e8456..f1fe8a0 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -578,7 +578,7 @@ gfc_trans_return (gfc_code * code)
 tree
 gfc_trans_pause (gfc_code * code)
 {
-  tree gfc_int4_type_node = gfc_get_int_type (4);
+  tree gfc_int8_type_node = gfc_get_int_type (8);
   gfc_se se;
   tree tmp;
 
@@ -589,7 +589,7 @@ gfc_trans_pause (gfc_code * code)
 
   if (code->expr1 == NULL)
 {
-  tmp = build_int_cst (gfc_int4_type_node, 0);
+  tmp = build_int_cst (size_type_node, 0);
   tmp = build_call_expr_loc (input_location,
 gfor_fndecl_pause_string, 2,
 build_int_cst (pchar_type_node, 0), tmp);
@@ -599,14 +599,15 @@ gfc_trans_pause (gfc_code * code)
   gfc_conv_expr (, code->expr1);
   tmp = build_call_expr_loc (input_location,
 gfor_fndecl_pause_numeric, 1,
-fold_convert (gfc_int4_type_node, se.expr));
+fold_convert (gfc_int8_type_node, se.expr));
 }
   else
 {
   gfc_conv_expr_reference (, code->expr1);
   tmp = build_call_expr_loc (input_location,
 gfor_fndecl_pause_string, 2,
-se.expr, se.string_length);
+se.expr, fold_convert (size_type_node,
+   se.string_length));
 }
 
   gfc_add_expr_to_block (, tmp);
diff --git a/libgfortran/runtime/pause.c b/libgfortran/runtime/pause.c
index 25690d8..3b4c17b 100644
--- a/libgfortran/runtime/pause.c
+++ b/libgfortran/runtime/pause.c
@@ -46,23 +46,23 @@ do_pause (void)
 
 /* A numeric PAUSE statement.  */
 
-extern void pause_numeric (GFC_INTEGER_4);
+extern void pause_numeric (GFC_INTEGER_8);
 export_proto(pause_numeric);
 
 void
-pause_numeric (GFC_INTEGER_4 code)
+pause_numeric (GFC_INTEGER_8 code)
 {
-  st_printf ("PAUSE %d\n", (int) code);
+  st_printf ("PAUSE %ld\n", (long) code);
   do_pause ();
 }
 
 /* A character string or blank PAUSE statement.  */
 
-extern void pause_string (char *string, GFC_INTEGER_4 len);
+extern void pause_string (char *string, size_t len);
 export_proto(pause_string);
 
 void
-pause_string (char *string, GFC_INTEGER_4 len)
+pause_string (char *string, size_t len)
 {
   estr_write ("PAUSE ");
   ssize_t w = write (STDERR_FILENO, string, len);
-- 
2.7.4

Re: [PATCH, GCC/ARM] Multilib mapping for Armv8-R

[Kyrill Tkachov]

Hi Thomas,

On 16/02/18 10:30, Thomas Preudhomme wrote:

Hi Kyrill,

Thanks for the review. Here's my second attempt. I've fixed the typo you raised 
and added some tests (wasn't aware of those). I've also reworked the mapping 
somewhat, it's explain in the description below.


Due to there being no multilib mapping for Armv8-R, default multilib
builts for -march=armv4t with softfloat floating-point arithmetic is
being used. This patch maps it instead to the existing Armv7 multilibs.
Note that mapping for single-precision Armv8-R has been left out due to
there being no Arm implementation of that architecture variant.

Changelog entry is as follows:

*** gcc/ChangeLog ***

2018-02-12  Thomas Preud'homme  

* config/arm/t-multilib: Map Armv8-R to Armv7 multilibs.


*** gcc/testsuite/ChangeLog ***

2018-02-13  Thomas Preud'homme  

* gcc.target/arm/multilib.exp: Add tests for Armv8-R multilib mappings.



Thanks for fixing this.
This is ok for trunk,
Kyrill


Testing:

Ran -print-multi-directory for all combinations of extensions one can
pass to -march=armv8-r (including no extension but only considering a
single ordering of extension). All gave the expected result. Details in
appendix.
Running multilib.exp is also successful.

Is this ok for stage4?

Best regards,

Thomas

Appendix: output of -print-multi-directory for all extensions available
to -march=armv8-r

% for ext in "" +crc +fp.sp +simd +crypto +crc+fp.sp +crc+simd +crc+crypto +fp.sp+simd 
+fp.sp+crypto +simd+crypto +crc+fp.sp+simd +crc+fp.sp+crypto +crc+simd+crypto +fp.sp+simd+crypto 
+crc+fp.sp+simd+crypto ; do cmd="arm-none-eabi-gcc -march=armv8-r${ext} -mfloat-abi=soft 
-print-multi-directory" ; echo -n "$cmd: " ; eval $cmd ; done
arm-none-eabi-gcc -march=armv8-r -mfloat-abi=soft -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc -mfloat-abi=soft -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+fp.sp -mfloat-abi=soft -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+simd -mfloat-abi=soft -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+simd -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+fp.sp+simd -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+fp.sp+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+simd+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp+simd -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+simd+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+fp.sp+simd+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp+simd+crypto -mfloat-abi=soft 
-print-multi-directory: thumb/v7/nofp

% for ext in "" +crc +fp.sp +simd +crypto +crc+fp.sp +crc+simd +crc+crypto +fp.sp+simd 
+fp.sp+crypto +simd+crypto +crc+fp.sp+simd +crc+fp.sp+crypto +crc+simd+crypto +fp.sp+simd+crypto 
+crc+fp.sp+simd+crypto ; do cmd="arm-none-eabi-gcc -march=armv8-r${ext} -mfloat-abi=softfp 
-print-multi-directory" ; echo -n "$cmd: " ; eval $cmd ; done
arm-none-eabi-gcc -march=armv8-r -mfloat-abi=softfp -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc -mfloat-abi=softfp -print-multi-directory: 
thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+fp.sp -mfloat-abi=softfp 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+simd -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+crypto -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp -mfloat-abi=softfp 
-print-multi-directory: thumb/v7/nofp
arm-none-eabi-gcc -march=armv8-r+crc+simd -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+crc+crypto -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+fp.sp+simd -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+fp.sp+crypto -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+simd+crypto -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc -march=armv8-r+crc+fp.sp+simd -mfloat-abi=softfp 
-print-multi-directory: thumb/v7+fp/softfp
arm-none-eabi-gcc 

[PATCH,AIX] Fixincludes for vec_malloc, vec_calloc

[David Edelsohn]

AIX stdlib.h header decides to redefine malloc and calloc when __VEC__
is defined.  Hilarity ensues, such as when GCC uses
__attribute__(("malloc")).

Fixed with the appended fixincludes patch.

Thanks, David


* inclhack.def (aix_stdlib_vec_malloc): New.
(aix_stdlib_vec_calloc): New.
* fixincl.x: Regenerate.
* tests/base/stdlib.h [AIX_STDLIB_VEC_MALLOC]: New test.
[AIX_STDLIB_VEC_CALLOC]: New test.

Index: inclhack.def
===
--- inclhack.def(revision 257901)
+++ inclhack.def(working copy)
@@ -838,6 +838,26 @@
 test_text = "#define valloc __linux_valloc";
 };

+fix = {
+hackname  = aix_stdlib_vec_malloc;
+mach  = "*-*-aix*";
+files = stdlib.h;
+select= "#define[ \t]+malloc[ \t]+vec_malloc";
+c_fix = format;
+c_fix_arg = "extern void *malloc(size_t) __asm__(\"vec_malloc\");";
+test_text = "#define malloc vec_malloc";
+};
+
+fix = {
+hackname  = aix_stdlib_vec_calloc;
+mach  = "*-*-aix*";
+files = stdlib.h;
+select= "#define[ \t]+calloc[ \t]+vec_calloc";
+c_fix = format;
+c_fix_arg = "extern void *calloc(size_t, size_t) __asm__(\"vec_calloc\");";
+test_text = "#define calloc vec_calloc";
+};
+
 /*
  * stdlib.h on AIX 4.3 declares strtof() with a non-const first argument.
  */

Index: tests/base/stdlib.h
===
--- tests/base/stdlib.h (revision 257901)
+++ tests/base/stdlib.h (working copy)
@@ -29,6 +29,16 @@
 #endif  /* AIX_STDLIB_VALLOC_CHECK */


+#if defined( AIX_STDLIB_VEC_MALLOC_CHECK )
+extern void *malloc(size_t) __asm__("vec_malloc");
+#endif  /* AIX_STDLIB_VEC_MALLOC_CHECK */
+
+
+#if defined( AIX_STDLIB_VEC_CALLOC_CHECK )
+extern void *calloc(size_t, size_t) __asm__("vec_calloc");
+#endif  /* AIX_STDLIB_VEC_CALLOC_CHECK */
+
+
 #if defined( AIX_STRTOF_CONST_CHECK )
 extern floatstrtof(const char *, char **);
 #endif  /* AIX_STRTOF_CONST_CHECK */

Re: [PATCH] RX TARGET_RTX_COSTS function

[Nick Clifton]

Hi Oleg,

> Ping.

Sorry - I am not very good at spotting RX bugs on the gcc-patches list. :-(

>> gcc/ChangeLog:
>>  * config/rx/rx.c (rx_rtx_costs): New function.
>>  (TARGET_RTX_COSTS): Override to use rx_rtx_costs.

Approved - please apply.

Cheers
  Nick

[PATCH, rs6000] Tests for builtin vec_neg updated

[Carl Love]

GCC maintainers:

The following patch updates the various vec_neg tests to only run on
Power 8 and beyond.  The vec_neg builtin is only supported for Power 8
and beyond, as corrected in commit 257812.  The fold-vec-neg-{char |
floatdouble | short].c test cases did not get updated to only run on
Power 8.  Also, the vec_neg tests in builtins-3.c need to be moved to
the Power 8 test file builtins-3-p8.c.

The patch has been tested on:

 powerpc64-unknown-linux-gnu (Power 8BE)
 powerpc64le-unknown-linux-gnu (Power 8LE)
 powerpc64le-unknown-linux-gnu (Power 9LE)

and no regressions were found. Please let me know if the patch looks OK
or not. Thanks.

   Carl Love

-

gcc/testsuite/ChangeLog:

2018-02-22  Carl Love  
* gcc.target/powerpc/builtins-3.c: Move vec_neg builtin tests to
Power 8 test file.
* gcc.target/powerpc/builtins-3-p8.c: Add vec_neg builtin tests.
* gcc.target/powerpc/fold-vec-neg-char.c(dg-options): Add -mcpu=power8.
* gcc.target/powerpc/fold-vec-neg-floatdouble.c(dg-options): Add
-mcpu=power8.
* gcc.target/powerpc/fold-vec-neg-int.c(dg-options): Remove file.
* gcc.target/powerpc/fold-vec-neg-short.c(dg-options): Add
-mcpu=power8.
---
 gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c   | 43 +
 gcc/testsuite/gcc.target/powerpc/builtins-3.c  | 45 ++
 .../gcc.target/powerpc/fold-vec-neg-char.c |  5 ++-
 .../gcc.target/powerpc/fold-vec-neg-floatdouble.c  |  6 ++-
 .../gcc.target/powerpc/fold-vec-neg-int.c  | 16 
 .../gcc.target/powerpc/fold-vec-neg-short.c|  6 ++-
 6 files changed, 58 insertions(+), 63 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c

diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
index a586805..f7f3107 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
@@ -180,6 +180,37 @@ test_vull_mulo_vui_vui (vector unsigned int x, vector 
unsigned int y)
return vec_mulo (x, y);
 }
 
+vector signed char
+test_neg_char (vector signed char x)
+{
+   return vec_neg (x);
+}
+
+vector short
+test_neg_short (vector short x)
+{
+   return vec_neg (x);
+}
+
+vector int
+test_neg_int (vector int x)
+{
+   return vec_neg (x);
+}
+
+vector float
+test_neg_float (vector float x)
+{
+   return vec_neg (x);
+}
+
+vector double
+test_neg_double (vector double x)
+{
+   return vec_neg (x);
+}
+
+
 /* Expected test results:
 
  test_eq_long_long 1 vcmpequd inst
@@ -200,6 +231,11 @@ test_vull_mulo_vui_vui (vector unsigned int x, vector 
unsigned int y)
  test_vull_mulo_vui_vui1 vmulouw
  test_vsll_mule_vsi_vsi1 vmulesw
  test_vull_mule_vui_vui1 vmuleuw
+ test_neg_char 1 vspltisw, 1 vsububm
+ test_neg_short1 vspltisw, 1 vsubuhm
+ test_neg_int  1 vspltisw, 1 vsubuwm
+ test_neg_float1 xvnegsp
+ test_neg_float1 xvnegdp
  */
 
 /* { dg-final { scan-assembler-times "vcmpequd" 1 } } */
@@ -220,3 +256,10 @@ test_vull_mulo_vui_vui (vector unsigned int x, vector 
unsigned int y)
 /* { dg-final { scan-assembler-times "vmulouw"  1 } } */
 /* { dg-final { scan-assembler-times "vmulesw"  1 } } */
 /* { dg-final { scan-assembler-times "vmuleuw"  1 } } */
+/* { dg-final { scan-assembler-times "vspltisw" 3 } } */
+/* { dg-final { scan-assembler-times "vsububm"  1 } } */
+/* { dg-final { scan-assembler-times "vsubuhm"  1 } } */
+/* { dg-final { scan-assembler-times "vsubuwm"  1 } } */
+/* { dg-final { scan-assembler-times "xvnegsp"  1 } } */
+/* { dg-final { scan-assembler-times "xvnegdp"  1 } } */
+
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-3.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-3.c
index b8a6dcd..0288b80 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-3.c
@@ -60,36 +60,6 @@ test_nabs_double (vector double x)
 }
 
 vector signed char
-test_neg_char (vector signed char x)
-{
-   return vec_neg (x);
-}
-
-vector short
-test_neg_short (vector short x)
-{
-   return vec_neg (x);
-}
-
-vector int
-test_neg_int (vector int x)
-{
-   return vec_neg (x);
-}
-
-vector float
-test_neg_float (vector float x)
-{
-   return vec_neg (x);
-}
-
-vector double
-test_neg_double (vector double x)
-{
-   return vec_neg (x);
-}
-
-vector signed char
 test_sll_vsc_vsc_vsuc (vector signed char x, vector unsigned char y)
 {
return vec_sll (x, y);
@@ -340,11 +310,6 @@ test_cmpb_float (vector float x, vector float y)
  test_nabs_int 

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Szabolcs Nagy]

On 21/02/18 10:11, Alexandre Oliva wrote:

On Feb 15, 2018, Szabolcs Nagy  wrote:


i see assembler slow downs with these location view patches
i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408



[LVU] reset view at function entry, omit views at line zero

Location views might be associated with locations that lack line
number information (line number zero), but since we omit .loc
directives that would have been issued with line number zero, we also
omit the symbolic view numbers that would have been issued at such
points.

Resetting views at function entry points address some of these issues,
and alleviate the huge chains of symbolic views that have burdened
assemblers since we disabled -ginternal-reset-location-views by
default, but other problems of undefined views remain when it's not
the whole function that lacks line number info, just parts of it.

So, when we encounter a request to output a view that may have been
referenced, but we decide to omit the .loc because the line is zero,
we will now omit the view as well, i.e., we will internally regard
that view as zero-numbered.

Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?



fixes 84408 for me, now i get

$ ./xg++ -B. -g -O -fPIC -shared -fno-rtti -time poly-int-07_plugin.ii
# cc1plus 47.39 0.60
# as 6.78 0.25
# collect2 0.27 0.04

Re: [PATCH PR81228][AARCH64][gcc-7] Backport r255625 : Fix ICE by adding LTGT

[Sudakshina Das]

On 09/01/18 15:37, Sudakshina Das wrote:

Hi

This patch is only adding the missing LTGT to plug the ICE. This is a 
backport to r255625 of trunk.


Testing done: Checked for regressions on bootstrapped 
aarch64-none-linux-gnu and added a new compile time test case that gives 
out LTGT to make sure it doesn't ICE.


Is this ok for trunk?


Backported to gcc-7 as r257901.

Sudi


Thanks
Sudi

ChangeLog Entries:

*** gcc/ChangeLog ***

2018-01-09  Sudakshina Das  
     Bin Cheng  

 Backport from mainline:
 2017-12-14  Sudakshina Das  
     Bin Cheng  

 PR target/81228
 * config/aarch64/aarch64.c (aarch64_select_cc_mode): Move LTGT to 
CCFPEmode.

 * config/aarch64/aarch64-simd.md (vec_cmp): Add
 LTGT.

*** gcc/testsuite/ChangeLog ***

2017-01-09  Sudakshina Das  

 Backport from mainline:
 2017-12-14  Sudakshina Das  

 PR target/81228
 * gcc.dg/pr81228.c: New.

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jan Hubicka]

> >>
> >> Hi Jan,
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
> >>
> >> Is OK for trunk?
> >
> > I see that using register makes the problem go away and pushing address to 
> > stack
> > seemed bit odd anyway. However how does this work on other types of thunk?
> 
> Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a proposal
> to use -mindirect-branch=thunk-extern in user space to support CET in a single
> binary.  So at the end of the day, only
> -mindirect-branch=thunk-extern will be used.

OK, so it is about the fact that we do not really want to support all
-mindirect-branch options in the future? If we don't want to support the 
correctly,
I wonder why we are including them at all.  Shall we at least output 
warning/sorry
when user tries other thunk type with stack unwinding enabled?
(does Kernel use it?)

Honza
> 
> 
> -- 
> H.J.

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[H.J. Lu]

On Thu, Feb 22, 2018 at 6:29 AM, Jan Hubicka  wrote:
>> On Sun, Jan 28, 2018 at 11:56 AM, H.J. Lu  wrote:
>> > On Sat, Jan 27, 2018 at 2:12 PM, H.J. Lu  wrote:
>> >> For
>> >>
>> >> ---
>> >> struct C {
>> >>   virtual ~C();
>> >>   virtual void f();
>> >> };
>> >>
>> >> void
>> >> f (C *p)
>> >> {
>> >>   p->f();
>> >>   p->f();
>> >> }
>> >> ---
>> >>
>> >> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
>> >>
>> >> _Z1fP1C:
>> >> .LFB0:
>> >> .cfi_startproc
>> >> pushq   %rbx
>> >> .cfi_def_cfa_offset 16
>> >> .cfi_offset 3, -16
>> >> movq(%rdi), %rax
>> >> movq%rdi, %rbx
>> >> jmp .LIND1
>> >> .LIND0:
>> >> pushq   16(%rax)
>> >> jmp __x86_indirect_thunk
>> >> .LIND1:
>> >> call.LIND0
>> >> movq(%rbx), %rax
>> >> movq%rbx, %rdi
>> >> popq%rbx
>> >> .cfi_def_cfa_offset 8
>> >> movq16(%rax), %rax
>> >> jmp __x86_indirect_thunk_rax
>> >> .cfi_endproc
>> >>
>> >> x86-64 is supposed to have asynchronous unwind tables by default, but
>> >> there is nothing that reflects the change in the (relative) frame
>> >> address after .LIND0.  That region really has to be moved outside of
>> >> the .cfi_startproc/.cfi_endproc bracket.
>> >>
>> >> This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
>> >> branch via register when -mindirect-branch=thunk-extern is used.  Now,
>> >> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
>> >>
>> >> _Z1fP1C:
>> >> .LFB0:
>> >> .cfi_startproc
>> >> pushq   %rbx
>> >> .cfi_def_cfa_offset 16
>> >> .cfi_offset 3, -16
>> >> movq(%rdi), %rax
>> >> movq%rdi, %rbx
>> >> movq16(%rax), %rax
>> >> call__x86_indirect_thunk_rax
>> >> movq(%rbx), %rax
>> >> movq%rbx, %rdi
>> >> popq%rbx
>> >> .cfi_def_cfa_offset 8
>> >> movq16(%rax), %rax
>> >> jmp __x86_indirect_thunk_rax
>> >> .cfi_endproc
>> >>
>> >> Now "-mindirect-branch=thunk-extern" is equivalent to
>> >> "-mindirect-branch=thunk-extern -mindirect-branch-register", which is
>> >> used by Linux kernel.
>> >>
>> >> Tested on i686 and x86-64.  OK for trunk?
>> >>
>> >> Thanks.
>> >>
>> >> H.J.
>> >> 
>> >> gcc/
>> >>
>> >> PR target/84039
>> >> * config/i386/constraints.md (Bs): Replace
>> >> ix86_indirect_branch_register with
>> >> TARGET_INDIRECT_BRANCH_REGISTER.
>> >> (Bw): Likewise.
>> >> * config/i386/i386.md (indirect_jump): Likewise.
>> >> (tablejump): Likewise.
>> >> (*sibcall_memory): Likewise.
>> >> (*sibcall_value_memory): Likewise.
>> >> Peepholes of indirect call and jump via memory: Likewise.
>> >> * config/i386/i386.opt: Likewise.
>> >> * config/i386/predicates.md (indirect_branch_operand): Likewise.
>> >> (GOT_memory_operand): Likewise.
>> >> (call_insn_operand): Likewise.
>> >> (sibcall_insn_operand): Likewise.
>> >> (GOT32_symbol_operand): Likewise.
>> >> * config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.
>> >>
>> >
>> > Here is the updated patch  to disallow *sibcall_GOT_32 and 
>> > *sibcall_value_GOT_32
>> > for TARGET_INDIRECT_BRANCH_REGISTER.
>> >
>> > Tested on i686 and x86-64.  OK for trunk?
>> >
>>
>> Hi Jan,
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
>>
>> Is OK for trunk?
>
> I see that using register makes the problem go away and pushing address to 
> stack
> seemed bit odd anyway. However how does this work on other types of thunk?

Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a proposal
to use -mindirect-branch=thunk-extern in user space to support CET in a single
binary.  So at the end of the day, only
-mindirect-branch=thunk-extern will be used.


-- 
H.J.

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jan Hubicka]

> On Sun, Jan 28, 2018 at 11:56 AM, H.J. Lu  wrote:
> > On Sat, Jan 27, 2018 at 2:12 PM, H.J. Lu  wrote:
> >> For
> >>
> >> ---
> >> struct C {
> >>   virtual ~C();
> >>   virtual void f();
> >> };
> >>
> >> void
> >> f (C *p)
> >> {
> >>   p->f();
> >>   p->f();
> >> }
> >> ---
> >>
> >> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
> >>
> >> _Z1fP1C:
> >> .LFB0:
> >> .cfi_startproc
> >> pushq   %rbx
> >> .cfi_def_cfa_offset 16
> >> .cfi_offset 3, -16
> >> movq(%rdi), %rax
> >> movq%rdi, %rbx
> >> jmp .LIND1
> >> .LIND0:
> >> pushq   16(%rax)
> >> jmp __x86_indirect_thunk
> >> .LIND1:
> >> call.LIND0
> >> movq(%rbx), %rax
> >> movq%rbx, %rdi
> >> popq%rbx
> >> .cfi_def_cfa_offset 8
> >> movq16(%rax), %rax
> >> jmp __x86_indirect_thunk_rax
> >> .cfi_endproc
> >>
> >> x86-64 is supposed to have asynchronous unwind tables by default, but
> >> there is nothing that reflects the change in the (relative) frame
> >> address after .LIND0.  That region really has to be moved outside of
> >> the .cfi_startproc/.cfi_endproc bracket.
> >>
> >> This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
> >> branch via register when -mindirect-branch=thunk-extern is used.  Now,
> >> -mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
> >>
> >> _Z1fP1C:
> >> .LFB0:
> >> .cfi_startproc
> >> pushq   %rbx
> >> .cfi_def_cfa_offset 16
> >> .cfi_offset 3, -16
> >> movq(%rdi), %rax
> >> movq%rdi, %rbx
> >> movq16(%rax), %rax
> >> call__x86_indirect_thunk_rax
> >> movq(%rbx), %rax
> >> movq%rbx, %rdi
> >> popq%rbx
> >> .cfi_def_cfa_offset 8
> >> movq16(%rax), %rax
> >> jmp __x86_indirect_thunk_rax
> >> .cfi_endproc
> >>
> >> Now "-mindirect-branch=thunk-extern" is equivalent to
> >> "-mindirect-branch=thunk-extern -mindirect-branch-register", which is
> >> used by Linux kernel.
> >>
> >> Tested on i686 and x86-64.  OK for trunk?
> >>
> >> Thanks.
> >>
> >> H.J.
> >> 
> >> gcc/
> >>
> >> PR target/84039
> >> * config/i386/constraints.md (Bs): Replace
> >> ix86_indirect_branch_register with
> >> TARGET_INDIRECT_BRANCH_REGISTER.
> >> (Bw): Likewise.
> >> * config/i386/i386.md (indirect_jump): Likewise.
> >> (tablejump): Likewise.
> >> (*sibcall_memory): Likewise.
> >> (*sibcall_value_memory): Likewise.
> >> Peepholes of indirect call and jump via memory: Likewise.
> >> * config/i386/i386.opt: Likewise.
> >> * config/i386/predicates.md (indirect_branch_operand): Likewise.
> >> (GOT_memory_operand): Likewise.
> >> (call_insn_operand): Likewise.
> >> (sibcall_insn_operand): Likewise.
> >> (GOT32_symbol_operand): Likewise.
> >> * config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.
> >>
> >
> > Here is the updated patch  to disallow *sibcall_GOT_32 and 
> > *sibcall_value_GOT_32
> > for TARGET_INDIRECT_BRANCH_REGISTER.
> >
> > Tested on i686 and x86-64.  OK for trunk?
> >
> 
> Hi Jan,
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
> 
> Is OK for trunk?

I see that using register makes the problem go away and pushing address to stack
seemed bit odd anyway. However how does this work on other types of thunk?

Honza

Re: PING: [PATCH] i386: Add __x86_indirect_thunk_nt_reg for -fcf-protection -mcet

[Jan Hubicka]

> On Fri, Feb 2, 2018 at 8:54 AM, H.J. Lu  wrote:
> > nocf_check attribute can be used with -fcf-protection -mcet to disable
> > control-flow check by adding NOTRACK prefix before indirect branch.
> > When -mindirect-branch=thunk-extern -mindirect-branch-register is added,
> > indirect branch via register, "notrack call/jmp reg", is converted to
> >
> > call/jmp __x86_indirect_thunk_nt_reg
> >
> > When running on machines with CET enabled, __x86_indirect_thunk_nt_reg
> > can be updated to
> >
> > notrack jmp reg
> >
> > at run-time to restore NOTRACK prefix in the original indirect branch.
> >
> > Since we don't support -mindirect-branch=thunk-extern, CET and MPX at
> > the same time, -mindirect-branch=thunk-extern is disallowed with
> > -fcf-protection=branch and -fcheck-pointer-bounds.
> >
> > Tested on i686 and x86-64.  OK for trunk?
> >
> > Thanks.
> >
> > H.J.
> > ---
> > gcc/
> >
> > PR target/84176
> > * config/i386/i386.c (ix86_set_indirect_branch_type): Issue an
> > error when -mindirect-branch=thunk-extern, -fcf-protection=branch
> > and -fcheck-pointer-bounds are used together.
> > (indirect_thunk_prefix): New enum.
> > (indirect_thunk_need_prefix): New function.
> > (indirect_thunk_name): Replace need_bnd_p with need_prefix.  Use
> > "_nt" instead of "_bnd" for NOTRACK prefix.
> > (output_indirect_thunk): Replace need_bnd_p with need_prefix.
> > (output_indirect_thunk_function): Likewise.
> > (): Likewise.
> > (ix86_code_end): Update output_indirect_thunk_function calls.
> > (ix86_output_indirect_branch_via_reg): Replace
> > ix86_bnd_prefixed_insn_p with indirect_thunk_need_prefix.
> > (ix86_output_indirect_branch_via_push): Likewise.
> > (ix86_output_function_return): Likewise.
> > * doc/invoke.texi: Document -mindirect-branch=thunk-extern is
> > incompatible with -fcf-protection=branch and
> > -fcheck-pointer-bounds.
> >
> > gcc/testsuite/
> >
> > PR target/84176
> > * gcc.target/i386/indirect-thunk-11.c: New test.
> > * gcc.target/i386/indirect-thunk-12.c: Likewise.
> > * gcc.target/i386/indirect-thunk-attr-12.c: Likewise.
> > * gcc.target/i386/indirect-thunk-attr-13.c: Likewise.
> > * gcc.target/i386/indirect-thunk-attr-14.c: Likewise.
> > * gcc.target/i386/indirect-thunk-attr-15.c: Likewise.
> > * gcc.target/i386/indirect-thunk-attr-16.c: Likewise.
> > * gcc.target/i386/indirect-thunk-extern-10.c: Likewise.
> > * gcc.target/i386/indirect-thunk-extern-8.c: Likewise.
> > * gcc.target/i386/indirect-thunk-extern-9.c: Likewise.
> 
> Hi Jan,
> 
> Can you review it:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00113.html

The patch is OK. Sorry for late reaction!

Honza
> 
> Thanks.
> 
> 
> -- 
> H.J.

[committed] Add testcase for already fixed PR (PR c++/84496)

[Jakub Jelinek]

Hi!

ICE on this testcase has been introduced in r236615 and got fixed on the trunk
with r253600.  I've committed the testcase to trunk, so that we don't
regress in it as obvious.

2018-02-22  Jakub Jelinek  

PR c++/84496
* g++.dg/cpp1y/pr84496.C: New test.

--- gcc/testsuite/g++.dg/cpp1y/pr84496.C.jj 2018-02-22 10:53:30.311132498 
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr84496.C2018-02-22 10:45:29.102352811 
+0100
@@ -0,0 +1,44 @@
+// PR c++/84496
+// { dg-do compile { target c++14 } }
+
+template  struct C { static constexpr T D = n; };
+struct E : C {};
+template  struct F : C {};
+template  T foo ();
+template  struct H { typedef int G; };
+template  class I;
+struct L;
+template  struct J;
+template  struct K;
+struct R {
+  template 
+  static J () (foo...)), L> o;
+};
+template  struct K : R {
+  typedef decltype (o) G;
+};
+template 
+struct D : K::D, P, Q...> {};
+template  struct I : D {};
+template  class function;
+template  struct function {
+  template ::G> struct C;
+  template  using U = int;
+  template , typename = U>
+  function (P);
+};
+template 
+template 
+function::function (P)
+{
+}
+void bar (function);
+
+void
+baz ()
+{
+  auto a = [] {
+static int counter;
+bar ([] (auto) { counter++; });
+  };
+}

Jakub

Re: Add "native" as a valid option value for -march= on arm (PR driver/83193).

[Martin Liška]

On 02/22/2018 11:59 AM, Kyrill Tkachov wrote:
> Hi Martin,
> 
> On 22/02/18 08:51, Martin Liška wrote:
>> On 02/21/2018 10:23 AM, Kyrill Tkachov wrote:
>>> On arm we also support "native" as a value for -mcpu and -mtune. These are 
>>> both handled by
>>> the arm_print_hint_for_cpu_option function in the same file. Can you please 
>>> add this snippet
>>> to them as well?
>> Hi.
>>
>> Can you please test for me attached follow up patch?
> 
> I've bootstrapped and tested this patch on a native and a cross compiler and 
> confirmed
> the help string for -mcpu behaves as intended.
> 
> This patch is ok for trunk.
> Thanks,
> Kyrill

Thanks for review. May I please ask you for taking look at:
2b) point in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193#c6

We should fix it (if possible) for GCC 8 as it's regression.

Thanks,
Martin

> 
>> Thanks,
>> Martin
> 

Re: [PATCH] RX TARGET_RTX_COSTS function

[Oleg Endo]

Ping.

On Thu, 2018-02-15 at 23:07 +0900, Oleg Endo wrote:
> On Wed, 2018-02-14 at 01:06 +0900, Oleg Endo wrote:
> > 
> >  
> > Do you happen to have any other numbers on the resulting code
> > size/speed?  Looking at the new costs that the patch introduces,
> > I'd
> > expect there to be some more changes than just the 1/x...
> > 
> I've checked your proposed patch with the CSiBE set for code size
> changes.
> 
> With your patch, the code size of the whole set:
> sum:  2806044 -> 2801346-4698 / -0.167424 %
> 
> 
> Taking out this piece
> 
>     case IF_THEN_ELSE:
>   *total = COSTS_N_INSNS (3);
>   return true;
> 
> from the rx_rtx_costs results in:
> sum:  2806044 -> 2801099-4945 / -0.176227 %
> 
> 
> Taking out another piece 
> 
>       if (GET_CODE (XEXP (x, 0)) == MEM
>  || GET_CODE (XEXP (x, 1)) == MEM)
>    *total = COSTS_N_INSNS (3);
>   else
> 
> results in:
> sum:  2806044 -> 2800315-5729 / -0.204166 %
> 
> So I'd like to propose the attached patch instead, as it eliminates 1
> KByte of code more from the whole set.
> 
> Just in case, I'm testing it now with
>   "make -k check" on rx-sim for c and c++
> 
> OK for trunk if it passes?
> 
> Cheers,
> Oleg
> 
> gcc/ChangeLog:
>   * config/rx/rx.c (rx_rtx_costs): New function.
>   (TARGET_RTX_COSTS): Override to use rx_rtx_costs.

[parloops, PR83126], Use cached affine_ivs canonicalize_loop_ivs

[Tom de Vries]

Hi,

this patch fixes an ICE in the parloops pass.

The ICE (when compiling the test-case in attached patch) follows from 
the fact that here in gen_parallel_loop the call to 
canonicalize_loop_ivs fails to "base all the induction variables in LOOP 
on a single control one":

...
  /* Base all the induction variables in LOOP on a single control one.*/
  canonicalize_loop_ivs (loop, , true);
...

This is caused by the fact that for one of the induction variables, 
simple_iv no longer returns true (as was the case at the start of 
gen_parallel_loop). This seems to be triggered by the fact that during 
loop_version we call scev_reset (although I'm not sure why when 
recalculating scev info we're not reaching the same conclusion as before).


The patch fixes the ICE by caching the affine_ivs as calculated by 
simple_iv before calling loop_version, and reusing those in 
canonicalize_loop_ivs (instead of calling simple_iv again).


Bootstrapped and reg-tested on x86_64.

OK for stage1?

I'm not sure if this is minimal/low-impact enough for stage4. If not, I 
can rework the bit of the patch that adds an assert after 
canonicalize_loop_ivs into a patch that aborts the optimization instead 
of ICE-ing.


Thanks,
- Tom
[parloops] Use cached affine_ivs canonicalize_loop_ivs

2018-02-22  Tom de Vries  

	PR tree-optimization/83126
	* tree-ssa-loop-manip.c (rewrite_phi_with_iv): Add and handle piv
	parameter.
	(rewrite_all_phi_nodes_with_iv, canonicalize_loop_ivs): Add and handle
	simple_ivs parameter.
	* tree-ssa-loop-manip.h (canonicalize_loop_ivs): Declare simple_ivs
	parameter and default to NULL.
	* tree-parloops.c (num_phis): New function.
	(gen_parallel_loop): Add simple_ivs argument to canonicalize_loop_ivs
	call.

---
 gcc/testsuite/gcc.dg/graphite/pr83126.c | 19 +++
 gcc/tree-parloops.c | 43 +++--
 gcc/tree-ssa-loop-manip.c   | 41 ---
 gcc/tree-ssa-loop-manip.h   |  6 -
 4 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/graphite/pr83126.c b/gcc/testsuite/gcc.dg/graphite/pr83126.c
new file mode 100644
index 000..663d059
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/graphite/pr83126.c
@@ -0,0 +1,19 @@
+/* { dg-additional-options "-w -ftree-parallelize-loops=2 -floop-parallelize-all -O1" }  */
+
+void
+ew (unsigned short int c9, int stuff)
+{
+  int e1;
+
+  for (;;)
+{
+  unsigned int *by = 
+  int *fd = 
+
+  *fd = c9;
+  fd = *fd;
+  if (*fd != 0)
+	for (*by = 0; *by < 2; ++*by)
+	  c9 *= e1;
+}
+}
diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index e44ad5e..5971680 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -2235,6 +2235,25 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data,
   calculate_dominance_info (CDI_DOMINATORS);
 }
 
+/* Return number of phis in bb.  If COUNT_VIRTUAL_P is false, don't count the
+   virtual phi.  */
+
+static unsigned int
+num_phis (basic_block bb, bool count_virtual_p)
+{
+  unsigned int nr_phis = 0;
+  gphi_iterator gsi;
+  for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next ())
+{
+  if (!count_virtual_p && virtual_operand_p (PHI_RESULT (gsi.phi (
+	continue;
+
+  nr_phis++;
+}
+
+  return nr_phis;
+}
+
 /* Generates code to execute the iterations of LOOP in N_THREADS
threads in parallel, which can be 0 if that number is to be determined
later.
@@ -2326,6 +2345,24 @@ gen_parallel_loop (struct loop *loop,
   if (stmts)
 gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts);
 
+  /* The loop_version call below calls gimple_duplicate_loop_to_header_edge,
+ which calls scev_reset.  So a loop header phi node that classifies as
+ simple_iv here, may not classify as such anymore after loop_version, which
+ will make canonicalize_loop_ivs fail to "base all the induction variables
+ in LOOP on a single control one".  We fix this by storing the affine_iv
+ result of the simple_iv call in a map from phi node result to affine_iv,
+ and passing that map as an argument to canonicalize_loop_ivs.  */
+  std::map simple_ivs;
+  gphi_iterator psi;
+  for (psi = gsi_start_phis (loop->header); !gsi_end_p (psi); gsi_next ())
+{
+  gphi *phi = psi.phi ();
+  affine_iv iv;
+  tree res = PHI_RESULT (phi);
+  if (simple_iv (loop, loop, res, , true))
+	simple_ivs.insert (std::pair (res, iv));
+}
+
   if (!oacc_kernels_p)
 {
   if (loop->inner)
@@ -2364,12 +2401,14 @@ gen_parallel_loop (struct loop *loop,
 		profile_probability::unlikely (),
 		profile_probability::likely (),
 		profile_probability::unlikely (), true);
-  update_ssa (TODO_update_ssa);
   free_original_copy_tables ();
 }
 
   /* Base all the induction variables in LOOP on a single control one.  */
-  canonicalize_loop_ivs (loop, , 

[PATCH][AArch64] PR84114: Avoid reassociating FMA

[Wilco Dijkstra]

As discussed in the PR, the reassociation phase runs before FMAs are formed
and so can significantly reduce FMA opportunities.  Although reassociation
could be switched off, it helps in many cases, so a better alternative is to
only avoid reassociation of floating point additions.  This fixes the testcase
and gives 1% speedup on SPECFP2017, fixing the performance regression.

OK for commit?

ChangeLog:
2018-02-23  Wilco Dijkstra  

PR tree-optimization/84114
* config/aarch64/aarch64.c (aarch64_reassociation_width)
Avoid reassociation of FLOAT_MODE addition.
--

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
b3d5fde171920e5759046a4bd61cfcf9eb78d7dd..5f9541cf700aaf18c1f1ac73054614e2932781e4
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1109,15 +1109,16 @@ aarch64_min_divisions_for_recip_mul (machine_mode mode)
   return aarch64_tune_params.min_div_recip_mul_df;
 }
 
+/* Return the reassociation width of treeop OPC with mode MODE.  */
 static int
-aarch64_reassociation_width (unsigned opc ATTRIBUTE_UNUSED,
-machine_mode mode)
+aarch64_reassociation_width (unsigned opc, machine_mode mode)
 {
   if (VECTOR_MODE_P (mode))
 return aarch64_tune_params.vec_reassoc_width;
   if (INTEGRAL_MODE_P (mode))
 return aarch64_tune_params.int_reassoc_width;
-  if (FLOAT_MODE_P (mode))
+  /* Avoid reassociating floating point addition so we emit more FMAs.  */
+  if (FLOAT_MODE_P (mode) && opc != PLUS_EXPR)
 return aarch64_tune_params.fp_reassoc_width;
   return 1;
 }

Re: plugin-api.h patch to add a new interface for linker plugins

[Nick Clifton]

Hi Cary, Hi Sriraman,

>> Ping.  Is this alright to apply now or should I wait for Stage 1?
>>
>> * plugin-api.h (ld_plugin_get_wrap_symbols): New
>>   plugin interface.
> 
> I'd say go ahead and apply the patch in binutils, and wait for Stage 1
> to sync back to GCC, unless someone there OKs it sooner.
> 
> Nick, is that OK?

Yes, that is fine with me.

Cheers
  Nick

[og7] Fix hang when running oacc exec with CUDA 9.0 nvprof

[Tom de Vries]

Hi,

when using cuda 9 nvprof with an openacc executable, the executable hangs.

The scenario resulting in the hang is as follows:
1. goacc_lazy_initialize calls gomp_mutex_lock (_device_lock)
2. goacc_lazy_initialize calls acc_init_1
3. acc_init_1 calls goacc_profiling_dispatch (_info,
   _init_event_info, _info);
4. goacc_profiling_dispatch calls the registered callback in the cuda
   profiling library
5. the registered call back calls acc_get_device_type
6. acc_get_device_type calls gomp_mutex_lock (_device_lock)
7. The lock is not recursive, so we have deadlock

The registered callback in cuda 8 does not call acc_get_device_type, so 
the hang doesn't occur there.


This patch fixes the hang by detecting in acc_get_device_type that the 
calling thread is a thread that is currently initializing the openacc 
part of the libgomp library, and returning acc_device_none, which is a 
legal value given that the openacc standard states "If the device type 
has not yet been selected, the value acc_device_none may be returned".


Committed to og7 branch.

Thanks,
- Tom
Fix hang when running oacc exec with CUDA 9.0 nvprof

2018-02-15  Tom de Vries  

	* oacc-init.c (acc_init_state_lock, acc_init_state, acc_init_thread):
	New variable.
	(acc_init_1): Set acc_init_thread to pthread_self ().  Set
	acc_init_state to initializing at the start, and to initialized at the
	end.
	(self_initializing_p): New function.
	(acc_get_device_type): Return acc_device_none if called by thread that
	is currently executing acc_init_1.

---
 libgomp/oacc-init.c   | 33 +
 2 files changed, 44 insertions(+)

diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c
index 6dada0b..d8348c0 100644
--- a/libgomp/oacc-init.c
+++ b/libgomp/oacc-init.c
@@ -40,6 +40,11 @@
 
 static gomp_mutex_t acc_device_lock;
 
+static gomp_mutex_t acc_init_state_lock;
+static enum { uninitialized, initializing, initialized } acc_init_state
+  = uninitialized;
+static pthread_t acc_init_thread;
+
 /* A cached version of the dispatcher for the global "current" accelerator type,
e.g. used as the default when creating new host threads.  This is the
device-type equivalent of goacc_device_num (which specifies which device to
@@ -220,6 +225,11 @@ acc_dev_num_out_of_range (acc_device_t d, int ord, int ndevs)
 static struct gomp_device_descr *
 acc_init_1 (acc_device_t d, acc_construct_t parent_construct, int implicit)
 {
+  gomp_mutex_lock (_init_state_lock);
+  acc_init_state = initializing;
+  acc_init_thread = pthread_self ();
+  gomp_mutex_unlock (_init_state_lock);
+
   bool check_not_nested_p;
   if (implicit)
 {
@@ -312,6 +322,9 @@ acc_init_1 (acc_device_t d, acc_construct_t parent_construct, int implicit)
 _info);
 }
 
+  gomp_mutex_lock (_init_state_lock);
+  acc_init_state = initialized;
+  gomp_mutex_unlock (_init_state_lock);
   return base_dev;
 }
 
@@ -644,6 +657,17 @@ acc_set_device_type (acc_device_t d)
 
 ialias (acc_set_device_type)
 
+static bool
+self_initializing_p (void)
+{
+  bool res;
+  gomp_mutex_lock (_init_state_lock);
+  res = (acc_init_state == initializing
+	 && pthread_equal (acc_init_thread, pthread_self ()));
+  gomp_mutex_unlock (_init_state_lock);
+  return res;
+}
+
 acc_device_t
 acc_get_device_type (void)
 {
@@ -653,6 +677,15 @@ acc_get_device_type (void)
 
   if (thr && thr->base_dev)
 res = acc_device_type (thr->base_dev->type);
+  else if (self_initializing_p ())
+/* The Cuda libaccinj64.so version 9.0+ calls acc_get_device_type during the
+   acc_ev_device_init_start event callback, which is dispatched during
+   acc_init_1.  Trying to lock acc_device_lock during such a call (as we do
+   in the else clause below), will result in deadlock, since the lock has
+   already been taken by the acc_init_1 caller.  We work around this problem
+   by using the acc_get_device_type property "If the device type has not yet
+   been selected, the value acc_device_none may be returned".  */
+;
   else
 {
   acc_prof_info prof_info;

[testsuite] Require et alloca for pr82210.c

[Tom de Vries]

Hi,

this patch requires effective target alloca in testcase pr82210.c.

Committed.

Thanks,
- Tom
[testsuite] Require et alloca for pr82210.c

2018-02-22  Tom de Vries  

	* gcc.c-torture/execute/pr82210.c: Require effective target alloca.

---
 gcc/testsuite/gcc.c-torture/execute/pr82210.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr82210.c b/gcc/testsuite/gcc.c-torture/execute/pr82210.c
index 48fb715..4caf843 100644
--- a/gcc/testsuite/gcc.c-torture/execute/pr82210.c
+++ b/gcc/testsuite/gcc.c-torture/execute/pr82210.c
@@ -1,4 +1,5 @@
 /* PR c/82210 */
+/* { dg-require-effective-target alloca } */
 
 void
 foo (int size)

Re: [PATCH][committed] Fix ICE in maybe_record_trace_start

[Tom de Vries]

On 02/12/2018 07:32 PM, Jeff Law wrote:

diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c 
b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
new file mode 100644
index 000..0ca0b9f034b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
@@ -0,0 +1,36 @@
+int foo;
+typedef long unsigned int size_t;
+typedef short unsigned int wchar_t;
+struct tm
+{
+  int tm_mday;
+  int tm_mon;
+  int tm_year;
+};
+size_t
+__strftime (wchar_t * s, size_t maxsize, const wchar_t * format, const struct 
tm *tim_p)
+{
+  size_t count = 0;
+  int len = 0;
+  size_t i, ctloclen;
+  unsigned long width;
+  {
+if (foo)
+  {
+   {
+ wchar_t *fmt = L"%s%.*d";
+ len = swprintf ([count], maxsize, fmt, "-", width, 0);
+   }
+   if ((count) >= maxsize)
+ return 0;
+  }
+else
+  {
+   len =
+ swprintf ([count], maxsize - count, L"%.2d/%.2d/%.2d", 42, 99, 0);
+   if ((count) >= maxsize)
+ return 0;
+
+  }
+  }
+}


Hi,

when compiling this test for nvptx, the missing declaration for swprintf 
results in this default declaration in the .s file based on the 
arguments of the first call:

...
.extern .func (.param.u32 %value_out) swprintf (.param.u64 
%in_ar0, .param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3, 
.param.u64 %in_ar4, .param.u32 %in_ar5);

...

and this error message when ptxas process the second call:
...
ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument 
does not match formal parameter '%in_ar3'
ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument 
does not match formal parameter '%in_ar4'

ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
...

When adding a declaration in the source like so:
...
diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c 
b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c

index 0ca0b9f034b..81943a2c459 100644
--- a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
+++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
@@ -1,6 +1,7 @@
 int foo;
 typedef long unsigned int size_t;
 typedef short unsigned int wchar_t;
+extern int swprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format, 
...);

 struct tm
 {
   int tm_mday;
...

the declaration changes to:
...
.extern .func (.param.u32 %value_out) swprintf (.param.u64 %in_ar0, 
.param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3);

...
and test test-case passes.

Is it ok to update the test-case like this, or should it require 
effective target 'untyped_assembly' (which is false for nvptx).


Thanks,
- Tom

Re: Add "native" as a valid option value for -march= on arm (PR driver/83193).

[Kyrill Tkachov]

Hi Martin,

On 22/02/18 08:51, Martin Liška wrote:

On 02/21/2018 10:23 AM, Kyrill Tkachov wrote:

On arm we also support "native" as a value for -mcpu and -mtune. These are both 
handled by
the arm_print_hint_for_cpu_option function in the same file. Can you please add 
this snippet
to them as well?

Hi.

Can you please test for me attached follow up patch?


I've bootstrapped and tested this patch on a native and a cross compiler and 
confirmed
the help string for -mcpu behaves as intended.

This patch is ok for trunk.
Thanks,
Kyrill


Thanks,
Martin

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Janne Blomqvist]

On Thu, Feb 22, 2018 at 11:46 AM, Janne Blomqvist
 wrote:
> On Thu, Feb 22, 2018 at 2:36 AM, Damian Rouson
>  wrote:
>> Hi Janne,
>>
>> To be more specific, the new OpenCoarrays test failures after applying the
>> patch are the following ones:
>>
>>  image_fail_test_1 (Timeout)
>>  image_fail_and_sync_test_2 (Timeout)
>>  image_fail_and_sync_test_3 (Timeout)
>>  image_fail_and_get_test_1 (Timeout)
>>
>> There are four.  I was mistaken when I wrote that there are three.
>>
>> Damian
>>
>> On February 21, 2018 at 12:56:05 PM, Janne Blomqvist
>> (blomqvist.ja...@gmail.com) wrote:
>>
>> On Wed, Feb 21, 2018 at 10:18 PM, Damian Rouson
>>  wrote:
>>>
>>>
>>>
>>>
>>> On February 21, 2018 at 11:35:47 AM, Janne Blomqvist
>>> (blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:
>>>
 PING

 Is anybody planning to work on this on the opencoarrays side? Or do
 you prefer that this is just committed and you can sort it out on your
 own schedule?
>>>
>>> Hi Janne,
>>>
>>> The trunk didn’t build for me the first time I tried soon after your
>>> initial email and it took me until yesterday to find time to try again. Once
>>> I succeeded, the patch created three new test failures. I’m wondering if
>>> Andre’s recent patch (r257813) helped reduce the number. All new failures
>>> involve the failed-images features developed by Alessandro and Andre, both
>>> of whom now have new employment or contracts that prevent making significant
>>> contributions to OpenCoarrays (although I hope that will change and am
>>> working with Alessandro’s organization to attempt to get some of his time
>>> allocated to gfortran/OpenCoarrays development).
>>>
>>> I think the most sustainable path forward is for me to assist any
>>> interested gfortran developer in building OpenCoarrays on your local system
>>> and running the test suite. At least that eliminates the reliance on
>>> OpenCoarrays developers to run the tests every time a patch impacts
>>> OpenCoarrays. If we can work together on building OpenCoarrays on your
>>> system, we can also look together at the requisite changes to see if we can
>>> eliminate the failures.
>>>
>>> Oxford University Ph.D. student Daniel Garza visit Sourcery Institute
>>> March 17 - June 2 to integrate the building of OpenCoarrays into the GCC
>>> build system so I hope this will all be easier sooner.
>>
>> Ok, I'll see if I find the time to get opencoarrays built.
>>
>>
>>
>> --
>> Janne Blomqvist
>
> Hi,
>
> I managed to build and test OpenCoarrays. I committed a slightly
> enlarged patch (I needed to fix STOP and ERROR STOP in libgfortran as
> well to make everything consistent) as r257894. I'll shortly send out
> the pull request with the corresponding changes needed in
> OpenCoarrays.

OpenCoarrays pull request:
https://github.com/sourceryinstitute/OpenCoarrays/pull/508



-- 
Janne Blomqvist

[PATCH] Fix store merging (PR tree-optimization/84503)

[Jakub Jelinek]

Hi!

The long comment above the new check_no_overlap function below should
hopefully explain the problem.  coalesce_immediate_stores is splitting the
stores from the same base into groups that we are going to optimize
individually; for each successfully merged group we emit new stores at the
location of the last store from that group.  And coalesce_immediate_stores
processes stores ordered primarily by increasing bit position and only
secondarily by the original ordering in the basic block.
On the following testcases, we have the unfortunate ordering of:
 MEM[(long long int *)p_28] = 0;
 MEM[(long long int *)p_28 + 8B] = 0;
 MEM[(long long int *)p_28 + 16B] = 0;
 MEM[(long long int *)p_28 + 24B] = 0;
 _129 = (int) _130;
 MEM[(int *)p_28 + 8B] = _129;
 MEM[(int *)p_28].a = -1;
We already have
 MEM[(long long int *)p_28] = 0;
 MEM[(int *)p_28].a = -1;
in the first group (which is fine) and the following 2 stores to consider
are
 MEM[(long long int *)p_28 + 8B] = 0;
and
 MEM[(int *)p_28 + 8B] = _129;
We add the first store to the group, which has the effect of emitting the
merged stores at the location of former MEM[(int *)p_28].a = -1;
store.  Then we process MEM[(int *)p_28 + 8B] = _129; (which was handled
just as potential bswap possibility and as it overlaps with previous
and can't be merged with next either, it will be its own group and thus
reuse the original stmt; the net effect is that we've reordered the
MEM[(long long int *)p_28 + 8B] = 0; store from before the
MEM[(int *)p_28 + 8B] = _129; store to after it, but those two do alias.

Instead of detecting this situation late, where we could just throw away the
whole group (which would mean we couldn't merge even the
MEM[(long long int *)p_28] = 0; and MEM[(int *)p_28].a = -1; stores)
this patch attempts to check before calling merge_into whether it will
not overlap with later stores we won't be able to emit in the same group
and if it does, it terminates the group right away.

I had to fix also the merged_store_group::merge_into width computation,
it was mistakenly just counting sum of the bits we've added to the group,
but we really need the distance between the first bit in the group and last
bit, including any gaps in between, but exclusing gaps before the start and
after the end (still within the bitregion).

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

For 7.x I think we'll need something along the lines of PR82916 instead,
while the same testcase fails there, we only handle stores with lhs being
a constant and so the problem is that we aren't terminating the chain when
we should on the variable store.

2018-02-21  Jakub Jelinek  

PR tree-optimization/84503
* gimple-ssa-store-merging.c (merged_store_group::merge_into): Compute
width as info->bitpos + info->bitsize - start.
(merged_store_group::merge_overlapping): Simplify width computation.
(check_no_overlap): New function.
(imm_store_chain_info::try_coalesce_bswap): Compute expected
start + width and last_order of the group, fail if check_no_overlap
fails.
(imm_store_chain_info::coalesce_immediate_stores): Don't merge info
to group if check_no_overlap fails.

* gcc.dg/pr84503-1.c: New test.
* gcc.dg/pr84503-2.c: New test.

--- gcc/gimple-ssa-store-merging.c.jj   2018-01-16 09:52:26.230235131 +0100
+++ gcc/gimple-ssa-store-merging.c  2018-02-21 20:13:45.239129599 +0100
@@ -1891,12 +1891,11 @@ merged_store_group::do_merge (store_imme
 void
 merged_store_group::merge_into (store_immediate_info *info)
 {
-  unsigned HOST_WIDE_INT wid = info->bitsize;
   /* Make sure we're inserting in the position we think we're inserting.  */
   gcc_assert (info->bitpos >= start + width
  && info->bitregion_start <= bitregion_end);
 
-  width += wid;
+  width = info->bitpos + info->bitsize - start;
   do_merge (info);
 }
 
@@ -1909,7 +1908,7 @@ merged_store_group::merge_overlapping (s
 {
   /* If the store extends the size of the group, extend the width.  */
   if (info->bitpos + info->bitsize > start + width)
-width += info->bitpos + info->bitsize - (start + width);
+width = info->bitpos + info->bitsize - start;
 
   do_merge (info);
 }
@@ -2304,6 +2303,55 @@ gather_bswap_load_refs (vec *refs,
 }
 }
 
+/* Check if there are any stores in M_STORE_INFO after index I
+   (where M_STORE_INFO must be sorted by sort_by_bitpos) that overlap
+   a potential group ending with END that have their order
+   smaller than LAST_ORDER.  RHS_CODE is the kind of store in the
+   group.  Return true if there are no such stores.
+   Consider:
+ MEM[(long long int *)p_28] = 0;
+ MEM[(long long int *)p_28 + 8B] = 0;
+ MEM[(long long int *)p_28 + 16B] = 0;
+ MEM[(long long int *)p_28 + 24B] = 0;
+ _129 = (int) _130;
+ MEM[(int *)p_28 + 8B] = _129;
+ MEM[(int *)p_28].a = -1;
+   We already have
+

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Janne Blomqvist]

On Thu, Feb 22, 2018 at 2:36 AM, Damian Rouson
 wrote:
> Hi Janne,
>
> To be more specific, the new OpenCoarrays test failures after applying the
> patch are the following ones:
>
>  image_fail_test_1 (Timeout)
>  image_fail_and_sync_test_2 (Timeout)
>  image_fail_and_sync_test_3 (Timeout)
>  image_fail_and_get_test_1 (Timeout)
>
> There are four.  I was mistaken when I wrote that there are three.
>
> Damian
>
> On February 21, 2018 at 12:56:05 PM, Janne Blomqvist
> (blomqvist.ja...@gmail.com) wrote:
>
> On Wed, Feb 21, 2018 at 10:18 PM, Damian Rouson
>  wrote:
>>
>>
>>
>>
>> On February 21, 2018 at 11:35:47 AM, Janne Blomqvist
>> (blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:
>>
>>> PING
>>>
>>> Is anybody planning to work on this on the opencoarrays side? Or do
>>> you prefer that this is just committed and you can sort it out on your
>>> own schedule?
>>
>> Hi Janne,
>>
>> The trunk didn’t build for me the first time I tried soon after your
>> initial email and it took me until yesterday to find time to try again. Once
>> I succeeded, the patch created three new test failures. I’m wondering if
>> Andre’s recent patch (r257813) helped reduce the number. All new failures
>> involve the failed-images features developed by Alessandro and Andre, both
>> of whom now have new employment or contracts that prevent making significant
>> contributions to OpenCoarrays (although I hope that will change and am
>> working with Alessandro’s organization to attempt to get some of his time
>> allocated to gfortran/OpenCoarrays development).
>>
>> I think the most sustainable path forward is for me to assist any
>> interested gfortran developer in building OpenCoarrays on your local system
>> and running the test suite. At least that eliminates the reliance on
>> OpenCoarrays developers to run the tests every time a patch impacts
>> OpenCoarrays. If we can work together on building OpenCoarrays on your
>> system, we can also look together at the requisite changes to see if we can
>> eliminate the failures.
>>
>> Oxford University Ph.D. student Daniel Garza visit Sourcery Institute
>> March 17 - June 2 to integrate the building of OpenCoarrays into the GCC
>> build system so I hope this will all be easier sooner.
>
> Ok, I'll see if I find the time to get opencoarrays built.
>
>
>
> --
> Janne Blomqvist

Hi,

I managed to build and test OpenCoarrays. I committed a slightly
enlarged patch (I needed to fix STOP and ERROR STOP in libgfortran as
well to make everything consistent) as r257894. I'll shortly send out
the pull request with the corresponding changes needed in
OpenCoarrays.

-- 
Janne Blomqvist

Re: Add "native" as a valid option value for -march= on arm (PR driver/83193).

[Martin Liška]

On 02/21/2018 10:23 AM, Kyrill Tkachov wrote:
> 
> On arm we also support "native" as a value for -mcpu and -mtune. These are 
> both handled by
> the arm_print_hint_for_cpu_option function in the same file. Can you please 
> add this snippet
> to them as well?

Hi.

Can you please test for me attached follow up patch?
Thanks,
Martin
>From 3a40e8a873461f9f06a18539cfb7c366dd6efafb Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 21 Feb 2018 15:38:32 +0100
Subject: [PATCH] Add "native" as a valid option value for -mcpu/-mtune= on arm
 (PR driver/83193).

gcc/ChangeLog:

2018-02-21  Martin Liska  

	PR driver/83193
	* common/config/arm/arm-common.c (arm_print_hint_for_cpu_option):
	Add "native" as a possible value.
---
 gcc/common/config/arm/arm-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/common/config/arm/arm-common.c b/gcc/common/config/arm/arm-common.c
index 50f0bad3e36..a404d4b1562 100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -309,6 +309,12 @@ arm_print_hint_for_cpu_option (const char *target,
   auto_vec candidates;
   for (; list->common.name != NULL; list++)
 candidates.safe_push (list->common.name);
+
+#ifdef HAVE_LOCAL_CPU_DETECT
+  /* Add also "native" as possible value.  */
+  candidates.safe_push ("native");
+#endif
+
   char *s;
   const char *hint = candidates_list_and_hint (target, s, candidates);
   if (hint)
-- 
2.16.1