RE: [PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for powerpc for altivec-4.c

[Kaushik Phatak]

Hi,
Just to update from my side,
this patch fixes the issues I had reported in PR83789 and there are no new 
regression in my testing.

Best Regards,
Kaushik M. Phatak

-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] 
Sent: Tuesday, March 13, 2018 12:25 AM
To: Peter Bergner 
Cc: GCC Patches ; Kaushik Phatak 
; Bill Schmidt 
Subject: Re: [PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for 
powerpc for altivec-4.c

Hi!

On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
> PR83789 shows a problem in the builtin expansion code not calling the 

There is no hurry I think?  And some changes are needed, so I'll leave it to 
you.


The patch is fine with those trivialities fixed.  Okay for trunk.  Thanks!

Enjoy your vacation!


Segher

Re: [PATCH] PR c/30552 gcc crashes when compiling examples with GNU statement expressions in VLAs

[Jeff Law]

On 03/13/2018 03:56 PM, dave.pa...@oracle.com wrote:
> This patch fixes ICE when statement expression used in old-style
> function declaration parameter list. See
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552
> 
> In c_parser_postfix_expression (), after seeing a left paren followed by
> a left curly brace, in addition to checking for existing statement list,
> also check to see if we're in the parameter scope an old-style function
> declaration. In either case, generate a "braced-group within expression
> allowed only inside a function" error.
> 
> Patch successfully bootstrapped and tested on x86_64-linux.
Just a note.  We're in regression fixes only (stage4) of our development
cycle.  I've put this (and other patches) into the queue of things to
review once stage1 re-opens.

jeff

Re: [PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

[Mike Stump]

On Mar 13, 2018, at 10:12 AM, Thomas Preudhomme 
 wrote:
> 
> scan-assembler-times and scan-tree-dump-times dejagnu directives show a
> different output in the summary files depending on whether they PASS or
> FAIL. This means that dg-cmp-results would not show a regression because
> it would not see a connection between the two output.

> 2018-03-13  Thomas Preud'homme  
> 
>   * lib/scanasm.exp (scan-assembler-times): Move FAIL debug info into a
>   separate verbose message.
>   * lib/scandump.exp (scan-dump-times): Likewise.

> Is this ok for stage 4?

Yes, please.  If broken on release branches, should be safe (if you regression 
test it of course) to move back, if you want.

C++ PATCH for c++/82336, ICE with init-list default arg

[Jason Merrill]

As analyzed by Nathan and Paolo, the problem here is that the test
conversion in check_default_arg is changing the expression, but then
we discard the result.  Excessive sharing of CONSTRUCTORs is an
ongoing issue, due to past decisions motivated by memory savings.  For
the time being, we can specifically unshare the default argument if it
is an initializer-list, since that's the problematic case.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f905470ca5ccda134972fdab07f7ed9a0380bf25
Author: Jason Merrill 
Date:   Tue Mar 13 19:34:54 2018 -0400

PR c++/82336 - link error with list-init default argument.

* decl.c (check_default_argument): Unshare an initializer list.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index afd04cea630..6c113f25a3d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12661,7 +12661,9 @@ check_default_argument (tree decl, tree arg, tsubst_flags_t complain)
  A default argument expression is implicitly converted to the
  parameter type.  */
   ++cp_unevaluated_operand;
-  perform_implicit_conversion_flags (decl_type, arg, complain,
+  /* Avoid digest_init clobbering the initializer.  */
+  tree carg = BRACE_ENCLOSED_INITIALIZER_P (arg) ? unshare_expr (arg): arg;
+  perform_implicit_conversion_flags (decl_type, carg, complain,
  LOOKUP_IMPLICIT);
   --cp_unevaluated_operand;
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-defarg2.C b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg2.C
new file mode 100644
index 000..65240355fc3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg2.C
@@ -0,0 +1,8 @@
+// PR c++/82336
+// { dg-do link { target c++11 } }
+
+struct foo { int x = 5; };
+struct bar : foo { bar() = default; };
+struct baz { bar x; };
+void qux(baz = {}){}
+int main() { qux(); }

Re: [PATCH] Fortran -- clean up KILL

[Steve Kargl]

On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote:
> 
> int val = kill (pid, signal);
> return (val == 0): 0 ? errno;
> 
> like it already does for the optional status argument for kill_sub.
> 

Committed as r258511 with your suggested change.

-- 
Steve

[Committed] PR fortran/61775 -- testcase from PR

[Steve Kargl]

The issue raised in PR fortran/61775 seemed to be fixed.
I've read the tree dump for -fdump-tree-optimized, and
gfortran seems to be generating the expected code.
Valgrind also finishes without errors.  I committed to
code as a testcase.

2018-03-13  Steven G. Kargl  

PR fortran/61775
* gfortran.dg/pr61775.f90: New test.

-- 
Steve

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

[Jason Merrill]

OK.

On Tue, Mar 13, 2018 at 6:18 PM, Marek Polacek  wrote:
> On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote:
>> On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek  wrote:
>> > Here's another case of a template code leaking into cxx_constant_value.
>> > While I recently added the require_rvalue_constant_expression check, it
>> > doesn't help here, because the problem is that we have a MODOP_EXPR (a
>> > template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's
>> > considered dependent, so fold_non_dependent_expr doesn't do its job.
>>
>> If it's dependent, we should have taken the dependent path earlier in
>> the function.  Should that test use
>> instantiation_dependent_expression_p rather than the existing type or
>> value dependent check?
>
> I guess so.  It fixes the ICE, though the error disappears unless we call
> a.b().  But that's probably expected.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-13  Marek Polacek  
>
> PR c++/84596
> * semantics.c (finish_static_assert): Check
> instantiation_dependent_expression_p instead of
> {type,value}_dependent_expression_p.
>
> * g++.dg/cpp0x/static_assert15.C: New test.
>
> diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> index bb8b5953539..fdf37bea770 100644
> --- gcc/cp/semantics.c
> +++ gcc/cp/semantics.c
> @@ -8630,8 +8630,7 @@ finish_static_assert (tree condition, tree message, 
> location_t location,
>if (check_for_bare_parameter_packs (condition))
>  condition = error_mark_node;
>
> -  if (type_dependent_expression_p (condition)
> -  || value_dependent_expression_p (condition))
> +  if (instantiation_dependent_expression_p (condition))
>  {
>/* We're in a template; build a STATIC_ASSERT and put it in
>   the right place. */
> diff --git gcc/testsuite/g++.dg/cpp0x/static_assert15.C 
> gcc/testsuite/g++.dg/cpp0x/static_assert15.C
> index e69de29bb2d..a740f73fd4a 100644
> --- gcc/testsuite/g++.dg/cpp0x/static_assert15.C
> +++ gcc/testsuite/g++.dg/cpp0x/static_assert15.C
> @@ -0,0 +1,10 @@
> +// PR c++/84596
> +// { dg-do compile { target c++11 } }
> +
> +template
> +struct a {
> +  constexpr void b() {
> +int c;
> +static_assert(c %= 1, "");
> +  }
> +};
>
> Marek

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

[Marek Polacek]

On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote:
> On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek  wrote:
> > Here's another case of a template code leaking into cxx_constant_value.
> > While I recently added the require_rvalue_constant_expression check, it
> > doesn't help here, because the problem is that we have a MODOP_EXPR (a
> > template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's
> > considered dependent, so fold_non_dependent_expr doesn't do its job.
> 
> If it's dependent, we should have taken the dependent path earlier in
> the function.  Should that test use
> instantiation_dependent_expression_p rather than the existing type or
> value dependent check?

I guess so.  It fixes the ICE, though the error disappears unless we call
a.b().  But that's probably expected.

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

2018-03-13  Marek Polacek  

PR c++/84596
* semantics.c (finish_static_assert): Check
instantiation_dependent_expression_p instead of
{type,value}_dependent_expression_p.

* g++.dg/cpp0x/static_assert15.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index bb8b5953539..fdf37bea770 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -8630,8 +8630,7 @@ finish_static_assert (tree condition, tree message, 
location_t location,
   if (check_for_bare_parameter_packs (condition))
 condition = error_mark_node;
 
-  if (type_dependent_expression_p (condition) 
-  || value_dependent_expression_p (condition))
+  if (instantiation_dependent_expression_p (condition))
 {
   /* We're in a template; build a STATIC_ASSERT and put it in
  the right place. */
diff --git gcc/testsuite/g++.dg/cpp0x/static_assert15.C 
gcc/testsuite/g++.dg/cpp0x/static_assert15.C
index e69de29bb2d..a740f73fd4a 100644
--- gcc/testsuite/g++.dg/cpp0x/static_assert15.C
+++ gcc/testsuite/g++.dg/cpp0x/static_assert15.C
@@ -0,0 +1,10 @@
+// PR c++/84596
+// { dg-do compile { target c++11 } }
+
+template
+struct a {
+  constexpr void b() {
+int c;
+static_assert(c %= 1, "");
+  }
+};

Marek

[PATCH] PR c/30552 gcc crashes when compiling examples with GNU statement expressions in VLAs

[dave . pagan]

This patch fixes ICE when statement expression used in old-style 
function declaration parameter list. See


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

In c_parser_postfix_expression (), after seeing a left paren followed by 
a left curly brace, in addition to checking for existing statement list, 
also check to see if we're in the parameter scope an old-style function 
declaration. In either case, generate a "braced-group within expression 
allowed only inside a function" error.


Patch successfully bootstrapped and tested on x86_64-linux.

--Dave

/c
2018-03-13  David Pagan  

PR c/30552
* c-decl.c (old_style_parameter_scope): New function.
* c-parser.c (c_parser_postfix_expression): Check for statement
expressions in old-style function parameter list declarations.

/c-family
2018-03-13  David Pagan  

PR c/30552
* c-common.h (old_style_parameter_scope): New extern declaration.

/testsuite
2018-03-13  David Pagan  

PR c/30552
* gcc.dg/noncompile/pr30552-1.c: New test.
* gcc.dg/noncompile/pr30552-2.c: New test.
* gcc.dg/noncompile/pr30552-3.c: New test.
* gcc.dg/noncompile/pr30552-4.c: New test.
Index: c/c-decl.c
===
--- c/c-decl.c  (revision 258257)
+++ c/c-decl.c  (working copy)
@@ -952,6 +952,17 @@ global_bindings_p (void)
   return current_scope == file_scope;
 }
 
+/* Return true if we're declaring parameters in an old-style function
+   declaration.  */
+
+bool
+old_style_parameter_scope (void)
+{
+  /* If processing parameters and there is no function statement list, we
+   * have an old-style function declaration.  */
+  return (current_scope->parm_flag && !DECL_SAVED_TREE(current_function_decl));
+}
+
 void
 keep_next_level (void)
 {
Index: c/c-parser.c
===
--- c/c-parser.c(revision 258257)
+++ c/c-parser.c(working copy)
@@ -7929,7 +7929,10 @@ c_parser_postfix_expression (c_parser *parser)
  c_parser_consume_token (parser);
  brace_loc = c_parser_peek_token (parser)->location;
  c_parser_consume_token (parser);
- if (!building_stmt_list_p ())
+ /* If we've not yet started the current function's statement list, 
+or we're in the parameter scope of an old-style function
+declaration, statement expressions are not allowed.  */
+ if (!building_stmt_list_p () || old_style_parameter_scope ())
{
  error_at (loc, "braced-group within expression allowed "
"only inside a function");
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 258257)
+++ c-family/c-common.h (working copy)
@@ -581,6 +581,7 @@ extern tree push_stmt_list (void);
 extern tree pop_stmt_list (tree);
 extern tree add_stmt (tree);
 extern void push_cleanup (tree, tree, bool);
+extern bool old_style_parameter_scope (void);
 
 extern tree build_modify_expr (location_t, tree, tree, enum tree_code,
   location_t, tree, tree);
Index: testsuite/gcc.dg/noncompile/pr30552-1.c
===
--- testsuite/gcc.dg/noncompile/pr30552-1.c (revision 0)
+++ testsuite/gcc.dg/noncompile/pr30552-1.c (working copy)
@@ -0,0 +1,17 @@
+/* PR c/30552 */
+
+/* Statement expression as formal array argument size in nested old-style 
+   function declaration should generate user error, not internal compiler 
+   error.  */
+
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int main()
+{
+  void fun(int a) /* { dg-error "old-style parameter declarations in 
prototyped function definition" } */
+int a[({void h(){}2;})]; /* { dg-error "braced-group within expression 
allowed only inside a function" } */
+  {
+  }
+  return 0;
+}
Index: testsuite/gcc.dg/noncompile/pr30552-2.c
===
--- testsuite/gcc.dg/noncompile/pr30552-2.c (revision 0)
+++ testsuite/gcc.dg/noncompile/pr30552-2.c (working copy)
@@ -0,0 +1,17 @@
+/* PR c/30552 */
+
+/* Another example of a statement expression as formal array argument size in
+ * nested old-style function declaration should generate user error, not 
+ * internal compiler error.  */
+
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int main()
+{
+  void fun(a)
+int a[({int b=2; b;})]; /* { dg-error "braced-group within expression 
allowed only inside a function" } */
+  {
+  }
+  return 0;
+}
Index: testsuite/gcc.dg/noncompile/pr30552-3.c
===
--- testsuite/gcc.dg/noncompile/pr30552-3.c (revision 0)
+++ testsuite/gcc.dg/noncompile/pr30552-3.c (working copy)
@@ -0,0 +1,15 @@
+/* PR c/30552 */
+

Patch to fix PR83712

[Vladimir Makarov]

  This is one more try to fix PR83712:

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

  The patch was successfully bootstrapped and tested on x86-64, i686, 
and ppc64.


  Committed as rev. 258504.

Index: ChangeLog
===
--- ChangeLog	(revision 258503)
+++ ChangeLog	(working copy)
@@ -1,3 +1,25 @@
+2018-03-13  Vladimir Makarov  
+
+	PR target/83712
+	* lra-assigns.c (find_all_spills_for): Ignore uninteresting
+	pseudos.
+	(assign_by_spills): Return a flag of reload assignment failure.
+	Do not process the reload assignment failures.  Do not spill other
+	reload pseudos if they has the same reg class.  Update n if
+	necessary.
+	(lra_assign): Add a return arg.  Set up from the result of
+	assign_by_spills call.
+	(find_reload_regno_insns, lra_split_hard_reg_for): New functions.
+	* lra-constraints.c (split_reg): Add a new arg.  Use it instead of
+	usage_insns if it is not NULL.
+	(spill_hard_reg_in_range): New function.
+	(split_if_necessary, inherit_in_ebb): Pass a new arg to split_reg.
+	* lra-int.h (spill_hard_reg_in_range, lra_split_hard_reg_for): New
+	function prototypes.
+	(lra_assign): Change prototype.
+	* lra.c (lra): Add code to deal with fails by splitting hard reg
+	live ranges.
+
 2018-03-01  Palmer Dabbelt  
 
 	* config/riscv/riscv.opt (mrelax): New option.
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 258482)
+++ lra-assigns.c	(working copy)
@@ -1339,24 +1339,33 @@ find_all_spills_for (int regno)
 	   r2 = r2->start_next)
 	{
 	  if (live_pseudos_reg_renumber[r2->regno] >= 0
-		  && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
+		  && ! sparseset_bit_p (live_range_hard_reg_pseudos, r2->regno)
+		  && rclass_intersect_p[regno_allocno_class_array[r2->regno]]
+		  && ((int) r2->regno < lra_constraint_new_regno_start
+		  || bitmap_bit_p (_inheritance_pseudos, r2->regno)
+		  || bitmap_bit_p (_split_regs, r2->regno)
+		  || bitmap_bit_p (_optional_reload_pseudos, r2->regno)
+		  /* There is no sense to consider another reload
+			 pseudo if it has the same class.  */
+		  || regno_allocno_class_array[r2->regno] != rclass))
 		sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
 	}
 	}
 }
 }
 
-/* Assign hard registers to reload pseudos and other pseudos.  */
-static void
+/* Assign hard registers to reload pseudos and other pseudos.  Return
+   true if we was not able to assign hard registers to all reload
+   pseudos.  */
+static bool
 assign_by_spills (void)
 {
-  int i, n, nfails, iter, regno, hard_regno, cost;
+  int i, n, nfails, iter, regno, regno2, hard_regno, cost;
   rtx restore_rtx;
-  rtx_insn *insn;
   bitmap_head changed_insns, do_not_assign_nonreload_pseudos;
   unsigned int u, conflict_regno;
   bitmap_iterator bi;
-  bool reload_p;
+  bool reload_p, fails_p = false;
   int max_regno = max_reg_num ();
 
   for (n = 0, i = lra_constraint_new_regno_start; i < max_regno; i++)
@@ -1399,8 +1408,13 @@ assign_by_spills (void)
 	hard_regno = spill_for (regno, _spilled_pseudos, iter == 1);
 	  if (hard_regno < 0)
 	{
-	  if (reload_p)
+	  if (reload_p) {
+		/* Put unassigned reload pseudo first in the
+		   array.  */
+		regno2 = sorted_pseudos[nfails];
 		sorted_pseudos[nfails++] = regno;
+		sorted_pseudos[i] = regno2;
+	  }
 	}
 	  else
 	{
@@ -1415,61 +1429,9 @@ assign_by_spills (void)
 		bitmap_set_bit (_pseudo_bitmap, regno);
 	}
 	}
-  if (nfails == 0)
-	break;
-  if (iter > 0)
+  if (nfails == 0 || iter > 0)
 	{
-	  /* We did not assign hard regs to reload pseudos after two iterations.
-	 Either it's an asm and something is wrong with the constraints, or
-	 we have run out of spill registers; error out in either case.  */
-	  bool asm_p = false;
-	  bitmap_head failed_reload_insns;
-
-	  bitmap_initialize (_reload_insns, _obstack);
-	  for (i = 0; i < nfails; i++)
-	{
-	  regno = sorted_pseudos[i];
-	  bitmap_ior_into (_reload_insns,
-			   _reg_info[regno].insn_bitmap);
-	  /* Assign an arbitrary hard register of regno class to
-		 avoid further trouble with this insn.  */
-	  bitmap_clear_bit (_spilled_pseudos, regno);
-	  assign_hard_regno
-		(ira_class_hard_regs[regno_allocno_class_array[regno]][0],
-		 regno);
-	}
-	  EXECUTE_IF_SET_IN_BITMAP (_reload_insns, 0, u, bi)
-	{
-	  insn = lra_insn_recog_data[u]->insn;
-	  if (asm_noperands (PATTERN (insn)) >= 0)
-		{
-		  asm_p = true;
-		  error_for_asm (insn,
- "% operand has impossible constraints");
-		  /* Avoid further trouble with this insn.
-		 For asm goto, instead of fixing up all the edges
-		 just clear the template and clear input operands
-		 (asm goto doesn't have any output operands).  */
-		  if (JUMP_P (insn))
-		{
-		  rtx asm_op = extract_asm_operands 

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 03/13/18 00:56, Andrew Sadek wrote:
Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test 
case ?
If all is Ok, execution and compilation shall ideally pass for the test 
cases.


Correct.

I want to make sure of two things:
  -- Your patch doesn't break anything (i.e., cause a regression) when
 you don't use the options.  This seems complete.
  -- Your patch works as intended when you do use the options.

But I have noticed that there are some output pattern checks done in 
some test cases and this may fail since the output assembly is different,

anyway I shall give it a try and send you the results with the new options.


There should be no target dependencies in the generic GCC tests.
Different instruction patterns which generate the correct results should
not be a problem.

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Jakub Jelinek]

On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote:
> > Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
> > where in particular linux_libc_has_function deals with various C libraries.
> > Of course, in this case you need another target hook, that is dependent both
> > on the target backend and C library.
> > 
> > It would be nice to make the target hook a little bit more generic as well,
> > e.g. pass it enum builtin_function and query if it is fast, slow or
> > unknown, or even some kind of cost, where the caller could ask for cost of
> > BUILT_IN_MEMCPY and BUILT_IN_MEMPCPY and decide based on the relative costs.
> 
> Let me start with simple return enum value of FAST,SLOW,UNKNOWN. I've added 
> new hook
> definition to gcc/config/gnu-user.h that will point to 
> gnu_libc_function_implementation.
> I would like to implement the function in gcc/targhooks.c, but I don't know 
> how to
> make ifdef according to target?

Put there just the default implementation (everything is UNKNOWN?).

> One another issue is that built_in_function is enum defined in tree.h. Thus 
> I'll replace the
> callback argument with int, that will be casted. One last issue: am I right 
> that I'll have to define
> TARGET_LIBC_FUNCTION_IMPLEMENTATION in each config file (similar to 
> no_c99_libc_has_function)?

And define the i386/x86_64 glibc one in config/i386/*.h, check there
OPTION_GLIBC and only in that case return something other than UNKNOWN.

And redefine TARGET_LIBC_FUNCTION_IMPLEMENTATION only in that case.

Jakub

[PATCH] Fix -march=bdver1 ICE on int to float conversion (PR target/84844)

[Jakub Jelinek]

Hi!

As mentioned in bugzilla, when e.g. sel-sched queries (indirectly) before reload
some attributes like get_attr_type that depend on alternatives, GCC attempts
to constrain the operands in non-strict mode, which implies that if
reg_class_for_constraint doesn't return NO_REGS, it is ok, otherwise the
constraint needs to match (the actual code is more complex of course).
The *float2_mixed pattern has different type
attributes between different alternatives, uses nonimmediate_operand for the
input and uses "m" constraint for it in all but one alternative; in that
alternative it has "r" constraint for the input and "Yc" for output, which
depending on tuning is either same as "v" or NO_REGS.  So, on those tunings
even in non-strict mode, if the input is a REG we fail to constrain the insn
and ICE.

The following patch fixes it by reverting the offending patch (as asked in
the PR), even with the patch reverted the reported issue doesn't reproduce
and in theory there is nothing wrong on emitting direct conversions even in
these tunings in cold blocks, the hw supports it, just it is slow, but also
smaller.

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

As mentioned in the PR, another alternative that works is adding another
alternative next to that Yc <- r, e.g. !???*v <- r, which will allow the
pre-reload attribute queries, but will very likely not be used otherwise.

2018-03-13  Jakub Jelinek  

PR target/84844
Revert
2017-04-20  Uros Bizjak  

PR target/78090
* config/i386/constraints.md (Yc): New register constraint.
* config/i386/i386.md (*float2_mixed):
Use Yc constraint for alternative 2 of operand 0.  Remove
preferred_for_speed attribute.

* gcc.target/i386/pr84844.c: New test.

--- gcc/config/i386/constraints.md.jj   2018-02-26 20:49:57.299331387 +0100
+++ gcc/config/i386/constraints.md  2018-03-13 13:47:22.285093035 +0100
@@ -99,7 +99,6 @@ (define_register_constraint "w" "TARGET_
 
 ;; We use the Y prefix to denote any number of conditional register sets:
 ;;  z  First SSE register.
-;;  c  SSE inter-unit conversions enabled
 ;;  i  SSE2 inter-unit moves to SSE register enabled
 ;;  j  SSE2 inter-unit moves from SSE register enabled
 ;;  d  any EVEX encodable SSE register for AVX512BW target or any SSE register
@@ -124,10 +123,6 @@ (define_register_constraint "w" "TARGET_
 (define_register_constraint "Yz" "TARGET_SSE ? SSE_FIRST_REG : NO_REGS"
  "First SSE register (@code{%xmm0}).")
 
-(define_register_constraint "Yc"
- "TARGET_SSE && TARGET_INTER_UNIT_CONVERSIONS ? ALL_SSE_REGS : NO_REGS"
- "@internal Any SSE register, when SSE and inter-unit conversions are 
enabled.")
-
 (define_register_constraint "Yi"
  "TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_TO_VEC ? ALL_SSE_REGS : NO_REGS"
  "@internal Any SSE register, when SSE2 and inter-unit moves to vector 
registers are enabled.")
--- gcc/config/i386/i386.md.jj  2018-03-13 13:40:44.082903460 +0100
+++ gcc/config/i386/i386.md 2018-03-13 13:47:22.284093034 +0100
@@ -5325,7 +5325,7 @@ (define_expand "float2_mixed"
-  [(set (match_operand:MODEF 0 "register_operand" "=f,Yc,v")
+  [(set (match_operand:MODEF 0 "register_operand" "=f,v,v")
(float:MODEF
  (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
   "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
@@ -5354,6 +5354,10 @@ (define_insn "*floatmode,
 mode)")
]
+   (symbol_ref "true")))
+   (set (attr "preferred_for_speed")
+ (cond [(eq_attr "alternative" "1")
+  (symbol_ref "TARGET_INTER_UNIT_CONVERSIONS")]
(symbol_ref "true")))])
 
 (define_insn "*float2_i387"
--- gcc/testsuite/gcc.target/i386/pr84844.c.jj  2018-03-13 13:12:50.569130703 
+0100
+++ gcc/testsuite/gcc.target/i386/pr84844.c 2018-03-13 12:21:04.553643164 
+0100
@@ -0,0 +1,10 @@
+/* PR target/84844 */
+/* { dg-do compile } */
+/* { dg-options "-march=bdver1 -O2 -fschedule-insns -fselective-scheduling" } 
*/
+
+double
+foo (int *x, int y, int z)
+{
+  *x = y;
+  return z;
+}

Jakub

[C++ PATCH] Fix ICE with builtin redefinition (PR c++/84843)

[Jakub Jelinek]

Hi!

If we return olddecl on an (invalid) builtin function redefinition rather
than redeclaration, we ICE shortly afterwards, because we assume we have
non-NULL DECL_INITIAL on whatever is returned (except for error_mark_node).

The following patch errors unconditionally for definitions of builtin
functions, and also makes sure to return error_mark_node if we've emitted
an error from the permerror.

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

2018-03-13  Jakub Jelinek  

PR c++/84843
* decl.c (duplicate_decls): For redefinition of built-in, use error
and return error_mark_node.  For redeclaration, return error_mark_node
rather than olddecl if !flag_permissive.

* g++.dg/ext/pr84843-1.C: New test.
* g++.dg/ext/pr84843-2.C: New test.

--- gcc/cp/decl.c.jj2018-03-09 19:00:44.350969146 +0100
+++ gcc/cp/decl.c   2018-03-13 14:56:45.244872506 +0100
@@ -1583,13 +1583,20 @@ next_arg:;
  || memcmp (name + len - strlen ("_chk"),
 "_chk", strlen ("_chk") + 1) != 0))
{
+ if (DECL_INITIAL (newdecl))
+   {
+ error_at (DECL_SOURCE_LOCATION (newdecl),
+   "definition of %q#D ambiguates built-in "
+   "declaration %q#D", newdecl, olddecl);
+ return error_mark_node;
+   }
  if (permerror (DECL_SOURCE_LOCATION (newdecl),
 "new declaration %q#D ambiguates built-in"
 " declaration %q#D", newdecl, olddecl)
  && flag_permissive)
inform (DECL_SOURCE_LOCATION (newdecl),
"ignoring the %q#D declaration", newdecl);
- return olddecl;
+ return flag_permissive ? olddecl : error_mark_node;
}
}
 
--- gcc/testsuite/g++.dg/ext/pr84843-1.C.jj 2018-03-13 14:55:15.927831678 
+0100
+++ gcc/testsuite/g++.dg/ext/pr84843-1.C2018-03-13 14:57:51.652902862 
+0100
@@ -0,0 +1,9 @@
+// PR c++/84843
+// { dg-do compile }
+// { dg-options "-fpermissive" }
+
+extern "C" int
+__atomic_compare_exchange (int x, int y)   // { dg-error "ambiguates 
built-in declaration" }
+{
+  return x + y;
+}
--- gcc/testsuite/g++.dg/ext/pr84843-2.C.jj 2018-03-13 14:55:19.349833246 
+0100
+++ gcc/testsuite/g++.dg/ext/pr84843-2.C2018-03-13 14:57:58.205905859 
+0100
@@ -0,0 +1,9 @@
+// PR c++/84843
+// { dg-do compile }
+// { dg-options "" }
+
+extern "C" int
+__atomic_compare_exchange (int x, int y)   // { dg-error "ambiguates 
built-in declaration" }
+{
+  return x + y;
+}

Jakub

Re: [C++ PATCH] Fix ICE with builtin redefinition (PR c++/84843)

[Jason Merrill]

OK.

On Tue, Mar 13, 2018 at 4:17 PM, Jakub Jelinek  wrote:
> Hi!
>
> If we return olddecl on an (invalid) builtin function redefinition rather
> than redeclaration, we ICE shortly afterwards, because we assume we have
> non-NULL DECL_INITIAL on whatever is returned (except for error_mark_node).
>
> The following patch errors unconditionally for definitions of builtin
> functions, and also makes sure to return error_mark_node if we've emitted
> an error from the permerror.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-03-13  Jakub Jelinek  
>
> PR c++/84843
> * decl.c (duplicate_decls): For redefinition of built-in, use error
> and return error_mark_node.  For redeclaration, return error_mark_node
> rather than olddecl if !flag_permissive.
>
> * g++.dg/ext/pr84843-1.C: New test.
> * g++.dg/ext/pr84843-2.C: New test.
>
> --- gcc/cp/decl.c.jj2018-03-09 19:00:44.350969146 +0100
> +++ gcc/cp/decl.c   2018-03-13 14:56:45.244872506 +0100
> @@ -1583,13 +1583,20 @@ next_arg:;
>   || memcmp (name + len - strlen ("_chk"),
>  "_chk", strlen ("_chk") + 1) != 0))
> {
> + if (DECL_INITIAL (newdecl))
> +   {
> + error_at (DECL_SOURCE_LOCATION (newdecl),
> +   "definition of %q#D ambiguates built-in "
> +   "declaration %q#D", newdecl, olddecl);
> + return error_mark_node;
> +   }
>   if (permerror (DECL_SOURCE_LOCATION (newdecl),
>  "new declaration %q#D ambiguates 
> built-in"
>  " declaration %q#D", newdecl, olddecl)
>   && flag_permissive)
> inform (DECL_SOURCE_LOCATION (newdecl),
> "ignoring the %q#D declaration", newdecl);
> - return olddecl;
> + return flag_permissive ? olddecl : error_mark_node;
> }
> }
>
> --- gcc/testsuite/g++.dg/ext/pr84843-1.C.jj 2018-03-13 14:55:15.927831678 
> +0100
> +++ gcc/testsuite/g++.dg/ext/pr84843-1.C2018-03-13 14:57:51.652902862 
> +0100
> @@ -0,0 +1,9 @@
> +// PR c++/84843
> +// { dg-do compile }
> +// { dg-options "-fpermissive" }
> +
> +extern "C" int
> +__atomic_compare_exchange (int x, int y)   // { dg-error "ambiguates 
> built-in declaration" }
> +{
> +  return x + y;
> +}
> --- gcc/testsuite/g++.dg/ext/pr84843-2.C.jj 2018-03-13 14:55:19.349833246 
> +0100
> +++ gcc/testsuite/g++.dg/ext/pr84843-2.C2018-03-13 14:57:58.205905859 
> +0100
> @@ -0,0 +1,9 @@
> +// PR c++/84843
> +// { dg-do compile }
> +// { dg-options "" }
> +
> +extern "C" int
> +__atomic_compare_exchange (int x, int y)   // { dg-error "ambiguates 
> built-in declaration" }
> +{
> +  return x + y;
> +}
>
> Jakub

[PATCH] Fix ptr-overflow sanopt optimization (PR sanitizer/83392)

[Jakub Jelinek]

Hi!

The sanopt maybe_optimize_ubsan_ptr_ifn optimization behaves differently
on 32-bit and on 64-bit targets when using similar arguments maximum or
minimum of ptrdiff_t or values close to it.

The problem is that UHWI is 64-bit, regardless of whether addresses are
64-bit or 32-bit, so for 32-bit targets get_inner_reference returns
NULL offset and all the offset is in pbitpos, while on 64-bit targets
where such large offsets in bytes would fit into shwi, but in bits won't
fit, we return INTEGER_CST offset and often 0 pbitpos.

The following patch handles such offset, so that the sanopt behaves the
same way, and adjusts the testcase (which really should have just 14
matches, the 3 lines with comment changes are already covered by the
overflow check on p = b - SMAX;).

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

2018-03-13  Jakub Jelinek  

PR sanitizer/83392
* sanopt.c (maybe_optimize_ubsan_ptr_ifn): Handle also
INTEGER_CST offset, add it together with bitpos / 8 and
sign extend based on POINTER_SIZE.

* c-c++-common/ubsan/ptr-overflow-sanitization-1.c: Adjust expected
check count from 17 to 14.

--- gcc/sanopt.c.jj 2018-03-02 00:15:54.670780980 +0100
+++ gcc/sanopt.c2018-03-13 16:54:49.905621373 +0100
@@ -486,12 +486,17 @@ maybe_optimize_ubsan_ptr_ifn (sanopt_ctx
   HOST_WIDE_INT bitpos;
   base = get_inner_reference (base, , , , ,
  , , );
-  if (offset == NULL_TREE
+  if ((offset == NULL_TREE || TREE_CODE (offset) == INTEGER_CST)
  && DECL_P (base)
  && pbitpos.is_constant ())
{
  gcc_assert (!DECL_REGISTER (base));
- offset_int expr_offset = bitpos / BITS_PER_UNIT;
+ offset_int expr_offset;
+ if (offset)
+   expr_offset = wi::to_offset (offset) + bitpos / BITS_PER_UNIT;
+ else
+   expr_offset = bitpos / BITS_PER_UNIT;
+ expr_offset = wi::sext (expr_offset, POINTER_SIZE);
  offset_int total_offset = expr_offset + cur_offset;
  if (total_offset != wi::sext (total_offset, POINTER_SIZE))
{
@@ -511,7 +516,7 @@ maybe_optimize_ubsan_ptr_ifn (sanopt_ctx
  && (!is_global_var (base) || decl_binds_to_current_def_p (base)))
{
  offset_int base_size = wi::to_offset (DECL_SIZE_UNIT (base));
- if (bitpos >= 0
+ if (!wi::neg_p (expr_offset)
  && wi::les_p (total_offset, base_size))
{
  if (!wi::neg_p (total_offset)
@@ -532,7 +537,7 @@ maybe_optimize_ubsan_ptr_ifn (sanopt_ctx
 */
 
  bool sign_cur_offset = !wi::neg_p (cur_offset);
- bool sign_expr_offset = bitpos >= 0;
+ bool sign_expr_offset = !wi::neg_p (expr_offset);
 
  tree base_addr
= build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (base)), base);
--- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-sanitization-1.c.jj   
2017-10-11 22:37:52.798901780 +0200
+++ gcc/testsuite/c-c++-common/ubsan/ptr-overflow-sanitization-1.c  
2018-03-13 17:00:18.947808006 +0100
@@ -25,9 +25,9 @@ void foo(void)
   p2 = p + 2;
 
   p = b - SMAX; /* pointer overflow check is needed */
-  p2 = p + (SMAX - 2); /* b - 2: pointer overflow check is needed */
-  p2 = p + (SMAX - 1); /* b - 1: pointer overflow check is needed */
-  p2 = p + SMAX; /* b: pointer overflow check is needed */
+  p2 = p + (SMAX - 2); /* b - 2: no need to check this  */
+  p2 = p + (SMAX - 1); /* b - 1: no need to check this */
+  p2 = p + SMAX; /* b: no need to check this */
   p2++; /* b + 1 */
 
   p = c;
@@ -75,4 +75,4 @@ void negative_to_negative (char *ptr)
   p2 += 5;
 }
 
-/* { dg-final { scan-tree-dump-times "__ubsan_handle_pointer_overflow" 17 
"optimized" } } */
+/* { dg-final { scan-tree-dump-times "__ubsan_handle_pointer_overflow" 14 
"optimized" } } */

Jakub

C++ PATCH for c++/82565, ICE with concepts and generic lambda

[Jason Merrill]

Here, trying to evaluate the constraints of the test::visit template
led us to instantiating the generic lambda function; this ends up with
us trying to instantiate it with processing_template_decl still set.

A simple way to fix this case in GCC 8 is to not treat the lambda as a
nested function, because we've already resolved any references to
outer functions in tsubst_lambda_expr.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8b9654e9d4a6db1d42a47a77b0636c1a05a9d60d
Author: Jason Merrill 
Date:   Tue Mar 13 15:13:12 2018 -0400

PR c++/82565 - ICE with concepts and generic lambda.

* pt.c (instantiate_decl): Clear fn_context for lambdas.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a16aef6bf58..d720c33cf0a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23460,6 +23460,9 @@ instantiate_decl (tree d, bool defer_ok, bool expl_inst_class_mem_p)
   bool push_to_top, nested;
   tree fn_context;
   fn_context = decl_function_context (d);
+  if (LAMBDA_FUNCTION_P (d))
+/* tsubst_lambda_expr resolved any references to enclosing functions.  */
+fn_context = NULL_TREE;
   nested = current_function_decl != NULL_TREE;
   push_to_top = !(nested && fn_context == current_function_decl);
 
diff --git a/gcc/testsuite/g++.dg/concepts/lambda1.C b/gcc/testsuite/g++.dg/concepts/lambda1.C
new file mode 100644
index 000..a77e65459b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/lambda1.C
@@ -0,0 +1,32 @@
+// PR c++/82565
+// { dg-do compile { target c++14 } }
+// { dg-additional-options -fconcepts }
+
+struct string
+{
+  string();
+  string(const char *);
+  bool empty() const;
+};
+
+template
+concept bool Concept() {
+  return requires(T t, const string& s) {
+{ t(s) } -> ReturnType;
+  };
+}
+
+struct test {
+  string _str;
+
+  template
+requires Concept()
+  decltype(auto) visit(Visitor&& visitor) const {
+return visitor(_str);
+  }
+
+};
+
+int main() {
+  test().visit([] (auto& x) { return x.empty(); });
+}

Re: [PATCH] Fortran -- clean up KILL

[Janne Blomqvist]

On Tue, Mar 13, 2018 at 6:08 AM, Steve Kargl
 wrote:
> On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote:
>>
>> Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
>> option was called on g77) is the original motivation. Like I said, I
>> don't have any particular opinion on whether we should keep that
>> restriction or not. On one hand, more recent versions of the standard
>> has lifted restrictions that integer intrinsic arguments have to be of
>> default kind in many cases, OTOH KILL is not a standard intrinsic but
>> something inherited from g77. So, meh.
>
> The Fortran standard specifically permits a Fortran processor to
> supply additional subprograms not contained in the Fortran standard.
> I personally can't any person person using INTEGER(1) or even
> INTEGER(2) with KILL as pid_t on typical modern OS's exceeds HUGE()
> in those types.  My original patch simply fixed KILL to actually
> conform to its documentation.  But is this what you want

Yes, very much so! Thanks!

One little nit, I think in libgfortran/intrinsics/kill.c

+kill (GFC_INTEGER_4 pid, GFC_INTEGER_4 signal)
 {
-  GFC_INTEGER_4 val;
-  kill_i4_sub (pid, signal, );
-  return val;
+  return (int)kill (pid, signal);
 }

the implementation should be something like

int val = kill (pid, signal);
return (val == 0): 0 ? errno;

like it already does for the optional status argument for kill_sub.

-- 
Janne Blomqvist

C++ PATCH for c++/84839, ICE with decltype of parameter pack

[Jason Merrill]

The comment says that the parameter pack is being used in an
unevaluated context, but at the point where we're substituting the
pack, we aren't necessarily actually in that unevaluated context, so
let's set the flag here.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0999f196019abd26f2409f351a443b45eafc234b
Author: Jason Merrill 
Date:   Tue Mar 13 14:08:17 2018 -0400

PR c++/84839 - ICE with decltype of parameter pack.

* pt.c (tsubst_pack_expansion): Set cp_unevaluated_operand while
instantiating dummy parms.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4640ca08ce0..fdc1c9a7a75 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11717,7 +11717,9 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
 	{
 	  /* This parameter pack was used in an unevaluated context.  Just
 		 make a dummy decl, since it's only used for its type.  */
+	  ++cp_unevaluated_operand;
 	  arg_pack = tsubst_decl (parm_pack, args, complain);
+	  --cp_unevaluated_operand;
 	  if (arg_pack && DECL_PACK_P (arg_pack))
 		/* Partial instantiation of the parm_pack, we can't build
 		   up an argument pack yet.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-nested2.C b/gcc/testsuite/g++.dg/cpp0x/variadic-nested2.C
new file mode 100644
index 000..ce18f99ea50
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-nested2.C
@@ -0,0 +1,9 @@
+// PR c++/84839
+// { dg-do compile { target c++11 } }
+
+template
+struct S {
+using fptr = void(*)(T... x, decltype(x)... y);
+};
+
+using F = S::fptr;

C++ PATCH for c++/84720, ICE with rvalue ref template parameter

[Jason Merrill]

In this testcase, we were crashing because we decided that the int&&
template parameter wasn't a valid argument for itself, which is wrong.
It's unclear to me that it is ever possible to instantiate a template
taking an rvalue ref parameter, but I guess we might as well handle it
properly.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 78c6cbb0e9fb5796825dc49891c7921e9270c09e
Author: Jason Merrill 
Date:   Tue Mar 13 14:25:00 2018 -0400

PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (convert_nontype_argument): Handle rvalue references.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index fdc1c9a7a75..a16aef6bf58 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6932,11 +6932,18 @@ convert_nontype_argument (tree type, tree expr, tsubst_flags_t complain)
 	  return NULL_TREE;
 	}
 
-  if (!lvalue_p (expr))
+  if (!glvalue_p (expr)
+	  || TYPE_REF_IS_RVALUE (type) != xvalue_p (expr))
 	{
 	  if (complain & tf_error)
-	error ("%qE is not a valid template argument for type %qT "
-		   "because it is not an lvalue", expr, type);
+	{
+	  if (TYPE_REF_IS_RVALUE (type))
+		error ("%qE is not a valid template argument for type %qT "
+		   "because it is not an xvalue", expr, type);
+	  else
+		error ("%qE is not a valid template argument for type %qT "
+		   "because it is not an lvalue", expr, type);
+	}
 	  return NULL_TREE;
 	}
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
new file mode 100644
index 000..b8e0daba0f7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
@@ -0,0 +1,10 @@
+// PR c++/84720
+// { dg-do compile { target c++11 } }
+
+template
+struct a {
+  template
+  static void b() {
+b();
+  }
+};

[PATCH v2] Fix bogus strncpy source length warning on source bound by constant

[Siddhesh Poyarekar]

Avoid issuing a bogus warning when the source of strncpy is bound by a
constant known to be less than the minimum size of the destination.

Changes from v1:

- Use range-info instead of the MIN_EXPR hack
- Get the minimum size of dst and check for NULL_TREE return

The patch bootstraps successfully and introduces no new regressions in
the testsuite.

gcc/

* tree-ssa-strlen.c (handle_builtin_stxncpy): Check bounds of
source length if available.

gcc/testsuite/

* gcc.dg/builtin-stringop-chk-10.c: New test case.
---
 gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c | 17 +
 gcc/tree-ssa-strlen.c  | 15 +++
 2 files changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c

diff --git a/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c 
b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
new file mode 100644
index 000..13e4bd2f049
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
@@ -0,0 +1,17 @@
+/* Bogus -Wstringop-overflow on strncpy when size is based on strlen but is
+   bound by a constant.
+   { dg-do compile }
+   { dg-options "-O2 -Wstringop-overflow" } */
+
+char dst[1024];
+
+void
+f1 (const char *src)
+{
+  unsigned long limit = 512;
+  unsigned long len = __builtin_strlen (src);  /* { dg-bogus "length computed 
here" } */
+  if (len > limit)
+len = limit;
+
+  __builtin_strncpy (dst, src, len);   /* { dg-bogus "specified bound depends 
on the length of the source argument" } */
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 72f6a17cd32..265f351ea85 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -2125,6 +2125,21 @@ handle_builtin_stxncpy (built_in_function, 
gimple_stmt_iterator *gsi)
   return;
 }
 
+  /* Don't bother about the strlen (SRC) in the LEN computation if the range of
+ values for LEN ends up within dstsize.  */
+  if (TREE_CODE (len) == SSA_NAME)
+{
+  wide_int min, max;
+  enum value_range_type vr = get_range_info (len, , );
+  tree dstsize = compute_objsize (dst, 3);
+  if (vr == VR_RANGE && dstsize)
+   {
+ tree len_max = wide_int_to_tree (TREE_TYPE (dstsize), max);
+ if (tree_int_cst_lt (len_max, dstsize))
+   return;
+   }
+}
+
   /* Retrieve the strinfo data for the string S that LEN was computed
  from as some function F of strlen (S) (i.e., LEN need not be equal
  to strlen(S)).  */
-- 
2.14.3

Re: [PATCH] PR c/46921 Lost side effect when struct initializer expression uses comma operator

[Joseph Myers]

Thanks, committed.

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

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

[Jason Merrill]

On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek  wrote:
> Here's another case of a template code leaking into cxx_constant_value.
> While I recently added the require_rvalue_constant_expression check, it
> doesn't help here, because the problem is that we have a MODOP_EXPR (a
> template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's
> considered dependent, so fold_non_dependent_expr doesn't do its job.

If it's dependent, we should have taken the dependent path earlier in
the function.  Should that test use
instantiation_dependent_expression_p rather than the existing type or
value dependent check?

Jason

[PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

[Thomas Preudhomme]

Hi,

scan-assembler-times and scan-tree-dump-times dejagnu directives show a
different output in the summary files depending on whether they PASS or
FAIL. This means that dg-cmp-results would not show a regression because
it would not see a connection between the two output.

The difference comes from the FAIL showing the number of actual times
the pattern was match, presumably to help debugging. This patch moves
the info regarding the actual number of times the pattern match in a
separate verbose message. This keeps the message unchanged but let
developers have the required debug message with -v.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2018-03-13  Thomas Preud'homme  

* lib/scanasm.exp (scan-assembler-times): Move FAIL debug info into a
separate verbose message.
* lib/scandump.exp (scan-dump-times): Likewise.

Testing: Made a modified version of gcc.dg/nand.c and
gcc.dg/torture/pr61772.c to FAIL their scan-assembler-times and
scan-tree-dump-times respective directives. Without the patch
dg-cmp-results does not flag any regression but does with the patch.

Is this ok for stage 4?

Best regards,

Thomas
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 3a775b0a812775193cf1181337a5b890cde74133..61e0f3f48aeea5785689c5df7a15dc2ccbc71029 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -266,7 +266,8 @@ proc scan-assembler-times { args } {
 if {$result_count == $times} {
 	pass "$testcase scan-assembler-times $pp_pattern $times"
 } else {
-	fail "$testcase scan-assembler-times $pp_pattern $times (found $result_count times)"
+	verbose -log "$testcase: $pp_pattern found $result_count times"
+	fail "$testcase scan-assembler-times $pp_pattern $times"
 }
 }
 
diff --git a/gcc/testsuite/lib/scandump.exp b/gcc/testsuite/lib/scandump.exp
index 4e3da972ae4ed09c9874eb384daf825e6e2dcde3..be8fbe8b461dc81d5683fe323c0913f678daa1e0 100644
--- a/gcc/testsuite/lib/scandump.exp
+++ b/gcc/testsuite/lib/scandump.exp
@@ -110,7 +110,8 @@ proc scan-dump-times { args } {
 if {$result_count == $times} {
 pass "$testname"
 } else {
-fail "$testname (found $result_count times)"
+	verbose -log "$testcase: pattern found $result_count times"
+fail "$testname"
 }
 }
 

Re: [PATCH] PR libstdc++/70664 Set failbit and read zero on stream reading negative value into unsigned type

[Jonathan Wakely]

On 13 March 2018 at 15:55, Jean-Baptiste Daval wrote:
> Hi,
>
> Currently when a value is extracted from a stream into a unsigned type,
> there is no test to check if the value is negative, in which case there
> is an overflow and failbit is not set (the correct behavior would be to
> read a zero and set failbit). This patch add a condition to check when
> we are in this particular case, read a zero and set failbit accordingly.

Thank you for the patch. It looks small enough that we don't need a
copyright assignment. The GCC trunk is currently only open for
regression fixes (and we also allow changes to C++17 library features
while our C++17 support is considered experimental). As soon as the
trunk re-opens for normal changes I'll apply your patch. For now I've
updated the bug report with a link to your patch, so we won't forget
about it.

Re: PR libstdc++/78420 Make std::less etc. yield total order for pointers

[Jonathan Wakely]

On 9 March 2018 at 00:41, Jonathan Wakely wrote:
> In order to meet the total order requirements of [comparisons] p2 we
> need to cast unrelated pointers to uintptr_t before comparing them.
> Those casts aren't allowed in constant expressions, so only cast
> when __builtin_constant_p says the result of the comparison is not a
> compile-time constant (because the arguments are not constants, or the
> result of the comparison is unspecified). When the result is constant
> just compare the pointers directly without casting.
>
> This ensures that the function can be called in constant expressions
> with suitable arguments, but still yields a total order even for
> otherwise unspecified pointer comparisons.
>
> PR libstdc++/78420
> * include/bits/stl_function.h (__ptr_rel_ops): New struct providing
> relational operators defining total order on pointers.
> (greater<_Tp*>, less<_Tp*>, greater_equal<_Tp*>, less_equal<_Tp>*):
> New partial specializations for pointers, using __ptr_rel_ops.
> (greater, less, greater_equal, less_equal Dispatch to __ptr_rel_ops when both arguments are pointers.
> * testsuite/20_util/function_objects/comparisons_pointer.cc: New.
>
> Tested powerpc64le-linux. I intend to commit this to trunk and
> backport to the active branches, unless anybody sees a problem with
> this solution, or has any suggestions for improvement.

I intentionally used "_Tp* const&" for the parameter types of the new
partial specializations like greater<_Tp*>, because that's what the
standard says for the primary templates. But it would be more
efficient to pass pointers by value, and 20.5.5.5 [member.functions]
p2 allows us to do that. Here's a new patch with that change.
commit e783a8e1c3cc0d41221796a9cadea796269a95a0
Author: Jonathan Wakely 
Date:   Thu Mar 8 20:27:04 2018 +

PR libstdc++/78420 Make std::less etc. yield total order for pointers

In order to meet the total order requirements of [comparisons] p2 we
need to cast unrelated pointers to uintptr_t before comparing them.
Those casts aren't allowed in constant expressions, so only cast
when __builtin_constant_p says the result of the comparison is not a
compile-time constant (because the arguments are not constants, or the
result of the comparison is unspecified). When the result is constant
just compare the pointers directly without casting.

This ensures that the function can be called in constant expressions
with suitable arguments, but still yields a total order even for
otherwise unspecified pointer comparisons.

PR libstdc++/78420
* include/bits/stl_function.h (__ptr_rel_ops): New struct providing
relational operators defining total order on pointers.
(greater<_Tp*>, less<_Tp*>, greater_equal<_Tp*>, less_equal<_Tp>*):
New partial specializations for pointers, using __ptr_rel_ops.
(greater, less, greater_equal, less_equal 201103L
+  struct __ptr_rel_ops
+  {
+__ptr_rel_ops() = delete;
+~__ptr_rel_ops() = delete;
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_greater(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x > __y))
+ return __x > __y;
+   return (__UINTPTR_TYPE__)__x > (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_less(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x < __y))
+ return __x < __y;
+   return (__UINTPTR_TYPE__)__x < (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_greater_equal(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x >= __y))
+ return __x >= __y;
+   return (__UINTPTR_TYPE__)__x >= (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_less_equal(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x <= __y))
+ return __x <= __y;
+   return (__UINTPTR_TYPE__)__x <= (__UINTPTR_TYPE__)__y;
+  }
+  };
+
+  // Partial specialization of std::greater for pointers.
+  template
+struct greater<_Tp*> : public binary_function<_Tp*, _Tp*, bool>
+{
+  _GLIBCXX14_CONSTEXPR bool
+  operator()(_Tp* __x, _Tp* __y) const _GLIBCXX_NOTHROW
+  { return __ptr_rel_ops::_S_greater(__x, __y); }
+};
+
+  // Partial 

Re: PR target/84743 adjust reassociation widths for power8/power9

[Segher Boessenkool]

On Mon, Mar 12, 2018 at 08:02:39PM -0500, Aaron Sawdey wrote:
> Looking at CPU2017 results for different reassociation widths, things
> have shifted since I last looked at this with CPU2006 in early gcc7
> timeframe. Best thing to do seems to be to set reassociation width to 1
> for all integer modes, which is what the attached patch does.
> 
> I also tried setting width to 1 for float modes PLUS_EXPR as this patch
> did for aarch64 but this does not seem to be helpful for power8.
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01271.html
> 
> 
> Results below are % performance improvement on power8 comparing trunk
> with the attached patch vs trunk with --param tree-reassoc-width=1 to
> disable parallel reassociation for everything (first column of results)
> and trunk unmodified (second column of results). 
> 
> CPU2017 componentvs width=1   vs trunk
> 500.perlbench_r-0.36% -0.15%
> 502.gcc_r   0.06%  0.04%
> 505.mcf_r   0.32%  0.24%
> 520.omnetpp_r   0.57% -0.95%
> 523.xalancbmk_r 1.45%  1.04%
> 525.x264_r -0.05%  0.09%
> 531.deepsjeng_r 0.04%  0.09%
> 541.leela_r 0.10%  0.72%
> 548.exchange2_r 0.08%  0.73%
> 557.xz_r0.09%  2.12%
> CPU2017 int geo mean0.23%  0.40%
> 503.bwaves_r0.00%  0.01%
> 507.cactuBSSN_r 0.05% -0.02%
> 508.namd_r  0.00%  0.00%
> 510.parest_r   -0.01%  0.20%
> 511.povray_r0.03% -0.24%
> 519.lbm_r  -0.04% -0.16%
> 521.wrf_r  -0.01% -0.56%
> 526.blender_r  -0.82% -0.47%
> 527.cam4_r -0.18%  0.06%
> 538.imagick_r  -0.02%  0.01%
> 544.nab_r   0.00%  0.23%
> 549.fotonik3d_r 0.24%  0.54%
> 554.roms_r -0.05%  0.03%
> CPU2017 fp geo mean-0.06% -0.03%
> 
> Bottom line is net improvement for CPU2017 int compared with either
> current trunk, or disabling parallel reassociation. For CPU2017 fp,
> very small overall degradation. 
> 
> Currently doing regstrap on ppc64le, ok for trunk if results look good?

Can't argue with a 0.4% win :-)  Okay for trunk.  Thanks!


Segher


> 2018-03-12  Aaron Sawdey  
> 
>   PR target/84743
>   * config/rs6000/rs6000.c (rs6000_reassociation_width): Disable parallel
>   reassociation for int modes.

Re: PATCH: Hurd port of go to gcc-8 (gcc-8-8-20180310+) 16 patches

[Svante Signell]

On Mon, 2018-03-12 at 14:44 +0100, Svante Signell wrote:
> On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote:
> 
> 
> > The patches really changed are only four:
> > src_libgo_runtime.diff
> > src_libgo_go_go_build_syslist.go.diff
> > src_libgo_go_runtime.diff
> > src_libgo_build.diff
> 
> Correction: five:
> add-gnu-to-libgo-headers.diff

And src_libgo_go_syscall.diff, eventually more. Best to use the complete set.

Regarding test suites the go test results are the same as for e.g. amd64:
This time the problem is with the symbol __libc_start_main@@GLIBC_2.2.6.

tail build/gcc/testsuite/go/go.sum

=== go Summary ===

# of expected passes518
# of untested testcases 834

grep ^FAIL: build/gcc/testsuite/go/go.log
FAIL: checksyms x 8
checksyms: found unexpected symbol "__libc_start_main@@GLIBC_2.2.6"

These problems are reported in debian bug #892167

[PATCH] PR libstdc++/70664 Set failbit and read zero on stream reading negative value into unsigned type

[Jean-Baptiste Daval]

Hi,

Currently when a value is extracted from a stream into a unsigned type,
there is no test to check if the value is negative, in which case there
is an overflow and failbit is not set (the correct behavior would be to
read a zero and set failbit). This patch add a condition to check when
we are in this particular case, read a zero and set failbit accordingly.

Tested on x86_64-pc-linux-gnu with the program provided in the bug
report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70664)

#include 
#include 

using namespace std;

template 
void test(const char * str)
{
istringstream a(str);
T i;

a >> i;
if (a.fail())
cout << "Ok: " << i << "\n";
else
cout << "Bug: " << i << "\n";
}

int main(int argc, char *argv[])
{
test("2147483648");  // INT_MIN-1
test("-2147483649"); // INT_MAX+1
test("4294967296");  // UINT_MAX+1
test("-1");
return 0;
}

Output without the patch:
Ok: 2147483647
Ok: -2147483648
Ok: 4294967295
Bug: 4294967295

With the patch:
Ok: 2147483647
Ok: -2147483648
Ok: 4294967295
Ok: 0



libstdc++-v3/ChangeLog:

2018-03-13  Jean-Baptiste Daval  

PR libstdc++/70664
* locale_facets_fix.tcc: Test when extracting a negative value
into an unsigned type


 libstdc++-v3/include/bits/locale_facets.tcc | 5 +
 1 file changed, 5 insertions(+)

iff --git a/libstdc++-v3/include/bits/locale_facets.tcc
b/libstdc++-v3/include/bits/locale_facets.tcc
index 39da5766075..9bc06c2e558 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -571,6 +571,11 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
__v = 0;
__err = ios_base::failbit;
  }
+   else if (__negative && !__num_traits::_is_signed)
+{
+  __v = 0;
+  __err = ios_base::failbit;
+ }
else if (__testoverflow)
  {
if (__negative && __num_traits::__is_signed)

C++ PATCH for c++/84798, ICE with auto in abstract function declarator

[Jason Merrill]

It doesn't make sense to use an 'auto' parameter type outside of an
implicit template declaration; conveniently, default_arg_ok_p already
tracks whether we are in a suitable context.

As Jakub points out in the PR, this extension really shouldn't be
silently accepted, given that it still isn't part of the standard
working paper even now, after much of the Concepts TS was merged in.
So the second patch makes the pedwarn unconditional, and moves
affected testcases into the concepts directory.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2bfb31f29c5ff65d16d549a8ced8f3312b19513e
Author: Jason Merrill 
Date:   Tue Mar 13 00:37:40 2018 -0400

PR c++/84798 - ICE with auto in abstract function declarator.

* parser.c (cp_parser_parameter_declaration_clause): Check
parser->default_arg_ok_p.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index cdc62388973..8e8ebceb0d5 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21198,7 +21198,10 @@ cp_parser_parameter_declaration_clause (cp_parser* parser)
 
   if (!processing_specialization
   && !processing_template_parmlist
-  && !processing_explicit_instantiation)
+  && !processing_explicit_instantiation
+  /* default_arg_ok_p tracks whether this is a parameter-clause for an
+ actual function or a random abstract declarator.  */
+  && parser->default_arg_ok_p)
 if (!current_function_decl
 	|| (current_class_type && LAMBDA_TYPE_P (current_class_type)))
   parser->auto_is_implicit_function_template_parm_p = true;
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto51.C b/gcc/testsuite/g++.dg/cpp0x/auto51.C
new file mode 100644
index 000..dfb08336b53
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto51.C
@@ -0,0 +1,9 @@
+// PR c++/84798
+// { dg-do compile { target c++11 } }
+
+template
+struct S {
+static constexpr T value = 0;
+};
+
+constexpr auto x = S::value; // { dg-error "auto" }
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60393.C b/gcc/testsuite/g++.dg/cpp1y/pr60393.C
index 27fe2b72296..2ae21ed1147 100644
--- a/gcc/testsuite/g++.dg/cpp1y/pr60393.C
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60393.C
@@ -1,8 +1,7 @@
 // PR c++/60393
 // { dg-do compile { target c++14 } }
-// { dg-options "" }
 
-void (*f)(auto) + 0; // { dg-error "expected" }
+void (*f)(auto) + 0; // { dg-error "auto|expected" }
 
 struct A
 {
commit 9da596356fed08bbbaf190ff1d70fdf7e76bd47a
Author: Jason Merrill 
Date:   Tue Mar 13 09:57:08 2018 -0400

Pedwarn about auto parameter even without -Wpedantic.

* parser.c (cp_parser_simple_type_specifier): Pedwarn about auto
parameter even without -Wpedantic.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 8e8ebceb0d5..0a82f415196 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17049,9 +17049,9 @@ cp_parser_simple_type_specifier (cp_parser* parser,
 		 "only available with "
 		 "-std=c++14 or -std=gnu++14");
 	  else if (!flag_concepts)
-	pedwarn (token->location, OPT_Wpedantic,
-		 "ISO C++ forbids use of % in parameter "
-		 "declaration");
+	pedwarn (token->location, 0,
+		 "use of % in parameter declaration "
+		 "only available with -fconcepts");
 	}
   else
 	type = make_auto ();
diff --git a/gcc/testsuite/g++.dg/cpp1z/abbrev1.C b/gcc/testsuite/g++.dg/concepts/abbrev1.C
similarity index 70%
rename from gcc/testsuite/g++.dg/cpp1z/abbrev1.C
rename to gcc/testsuite/g++.dg/concepts/abbrev1.C
+++ b/gcc/testsuite/g++.dg/concepts/abbrev1.C
@@ -1,5 +1,6 @@
 // PR c++/64969
-// { dg-options "-std=c++17" }
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-fconcepts" }
 
 auto f1(auto x) { return *x; }
 decltype(auto) f2(auto x) { return *x; }
diff --git a/gcc/testsuite/g++.dg/cpp1z/abbrev2.C b/gcc/testsuite/g++.dg/concepts/abbrev2.C
similarity index 79%
rename from gcc/testsuite/g++.dg/cpp1z/abbrev2.C
rename to gcc/testsuite/g++.dg/concepts/abbrev2.C
+++ b/gcc/testsuite/g++.dg/concepts/abbrev2.C
@@ -1,6 +1,6 @@
 // PR c++/66197
-// { dg-do run }
-// { dg-options "-std=c++17" }
+// { dg-do run { target c++14 } }
+// { dg-additional-options "-fconcepts" }
 
 extern "C" void abort();
 
diff --git a/gcc/testsuite/g++.dg/cpp1y/fn-generic-member-ool.C b/gcc/testsuite/g++.dg/concepts/fn-generic-member-ool.C
similarity index 93%
rename from gcc/testsuite/g++.dg/cpp1y/fn-generic-member-ool.C
rename to gcc/testsuite/g++.dg/concepts/fn-generic-member-ool.C
+++ b/gcc/testsuite/g++.dg/concepts/fn-generic-member-ool.C
@@ -1,6 +1,6 @@
 // Out-of-line generic member function definitions.
 // { dg-do compile { target c++14 } }
-// { dg-options "" }
+// { dg-additional-options "-fconcepts" }
 
 struct A {
   void f(auto x);
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr58500.C b/gcc/testsuite/g++.dg/concepts/pr58500.C
similarity index 69%
rename from gcc/testsuite/g++.dg/cpp1y/pr58500.C
rename to gcc/testsuite/g++.dg/concepts/pr58500.C

Re: [PATCH] S/390: Set ABI default based on uname

[Michael Matz]

Hi,

On Tue, 13 Mar 2018, Andreas Krebbel wrote:

> Leaving history aside don't you agree that it would have been more 
> sensible to require a -m option only if you want to build for an ABI 
> different from what is currently mandated by the personality setting?

I agree with you.  But we can't leave history aside, so I'm having the 
same sentiment as Jakub.  The current situation is not good, but changing 
behaviour would be even worse.


Ciao,
Michael.

[PATCH, rs6000] Remove unused (and incorrect) code for internal store and load operations

[Kelvin Nilsen]

While working to assure rs6000 documentation of built-in functions is
consistent with the implementation of built-in functions, I discovered
some apparent typographic errors in the definitions of the
ST_INTERNAL_4sf and ST_INTERNAL_2df built-in functions.  As I endeavored
to fix these definitions and write test cases to prove that I had
properly fixed them, I discovered that these functions are no  longer in
use.

This patch removes the unnecessary definitions and related back-end
functions.  This has bootstrapped and tested without regressions on both
powerpc64le-unknown-linux (P8) and on powerpc-linux (P7 big-endian, with
both -m32 and -m64 target options).

Is this patch ok for trunk?

gcc/ChangeLog:

2018-03-09  Kelvin Nilsen  

* config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
macro expansions for definition of ST_INTERNAL_ and
LD_INTERNAL_ builtins.
* config/rs6000/rs6000.c (altivec_expand_ld_builtin): Delete this
function.
(altivec_expand_st_builtin): Likewise.
(altivec_expand_builtin): Remove calls to deleted functions.

Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 258338)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -1210,20 +1210,6 @@ BU_ALTIVEC_P (VCMPGTSB_P, "vcmpgtsb_p",  CONST,
 BU_ALTIVEC_P (VCMPGTUB_P, "vcmpgtub_p",CONST,  vector_gtu_v16qi_p)
 
 /* AltiVec builtins that are handled as special cases.  */
-BU_ALTIVEC_X (ST_INTERNAL_4si,  "st_internal_4si",  MEM)
-BU_ALTIVEC_X (LD_INTERNAL_4si,  "ld_internal_4si",  MEM)
-BU_ALTIVEC_X (ST_INTERNAL_8hi, "st_internal_8hi",  MEM)
-BU_ALTIVEC_X (LD_INTERNAL_8hi, "ld_internal_8hi",  MEM)
-BU_ALTIVEC_X (ST_INTERNAL_16qi,"st_internal_16qi", MEM)
-BU_ALTIVEC_X (LD_INTERNAL_16qi,"ld_internal_16qi", MEM)
-BU_ALTIVEC_X (ST_INTERNAL_4sf, "st_internal_16qi", MEM)
-BU_ALTIVEC_X (LD_INTERNAL_4sf, "ld_internal_4sf",  MEM)
-BU_ALTIVEC_X (ST_INTERNAL_2df, "st_internal_4sf",  MEM)
-BU_ALTIVEC_X (LD_INTERNAL_2df, "ld_internal_2df",  MEM)
-BU_ALTIVEC_X (ST_INTERNAL_2di, "st_internal_2di",  MEM)
-BU_ALTIVEC_X (LD_INTERNAL_2di, "ld_internal_2di",  MEM)
-BU_ALTIVEC_X (ST_INTERNAL_1ti, "st_internal_1ti",  MEM)
-BU_ALTIVEC_X (LD_INTERNAL_1ti, "ld_internal_1ti",  MEM)
 BU_ALTIVEC_X (MTVSCR,  "mtvscr",   MISC)
 BU_ALTIVEC_X (MFVSCR,  "mfvscr",   MISC)
 BU_ALTIVEC_X (DSSALL,  "dssall",   MISC)
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 258338)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -15183,127 +15183,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
   return target;
 }
 
-/* Expand the lvx builtins.  */
-static rtx
-altivec_expand_ld_builtin (tree exp, rtx target, bool *expandedp)
-{
-  tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
-  unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
-  tree arg0;
-  machine_mode tmode, mode0;
-  rtx pat, op0;
-  enum insn_code icode;
 
-  switch (fcode)
-{
-case ALTIVEC_BUILTIN_LD_INTERNAL_16qi:
-  icode = CODE_FOR_vector_altivec_load_v16qi;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_8hi:
-  icode = CODE_FOR_vector_altivec_load_v8hi;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_4si:
-  icode = CODE_FOR_vector_altivec_load_v4si;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_4sf:
-  icode = CODE_FOR_vector_altivec_load_v4sf;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_2df:
-  icode = CODE_FOR_vector_altivec_load_v2df;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_2di:
-  icode = CODE_FOR_vector_altivec_load_v2di;
-  break;
-case ALTIVEC_BUILTIN_LD_INTERNAL_1ti:
-  icode = CODE_FOR_vector_altivec_load_v1ti;
-  break;
-default:
-  *expandedp = false;
-  return NULL_RTX;
-}
-
-  *expandedp = true;
-
-  arg0 = CALL_EXPR_ARG (exp, 0);
-  op0 = expand_normal (arg0);
-  tmode = insn_data[icode].operand[0].mode;
-  mode0 = insn_data[icode].operand[1].mode;
-
-  if (target == 0
-  || GET_MODE (target) != tmode
-  || ! (*insn_data[icode].operand[0].predicate) (target, tmode))
-target = gen_reg_rtx (tmode);
-
-  if (! (*insn_data[icode].operand[1].predicate) (op0, mode0))
-op0 = gen_rtx_MEM (mode0, copy_to_mode_reg (Pmode, op0));
-
-  pat = GEN_FCN (icode) (target, op0);
-  if (! pat)
-return 0;
-  emit_insn (pat);
-  return target;
-}
-
-/* Expand the stvx builtins.  */
-static rtx
-altivec_expand_st_builtin (tree exp, rtx target ATTRIBUTE_UNUSED,
-  bool *expandedp)
-{
-  tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
-  unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
-  tree arg0, arg1;
-  machine_mode mode0, mode1;
-  rtx pat, op0, op1;
-  enum insn_code icode;
-
-  

Re: [PATCH] accept attribute nonstring on all narrow characters (PR 84725)

[Martin Sebor]

On 03/12/2018 05:13 PM, Jeff Law wrote:

On 03/05/2018 01:54 PM, Martin Sebor wrote:

Attribute nonstring is currently only allowed on arrays and
pointers to plain char, but -Wstringop-truncation triggers
even for strncpy calls whose arguments are arrays of signed
or unsigned char (with or without a cast to char*).

To help deal with -Wstringop-truncation in the Linux kernel
it was suggested to me that it would be useful to be able
to make use of the attribute on all three narrow char types.
Apparently, there are enough calls to strncpy in the Linux
kernel with arguments of the other char types that trigger
the new warning, and the warning is considered sufficiently
useful that making use of the attribute to suppress
the warning rather than changing it ignore the other
two char types is preferable.

The attached patch relaxes the restriction and lets GCC
accept attribute nonstring on all three narrow character
types as well as their qualified forms.

Tested on x86_64-linux.

Martin

gcc-84725.diff


PR tree-optimization/84725 - enable attribute nonstring for all narrow 
character types

gcc/c-family/ChangeLog:

PR tree-optimization/84725
* c-attribs.c (handle_nonstring_attribute): Allow attribute nonstring
with all three narrow character types, including their qualified forms.

gcc/testsuite/ChangeLog:

PR tree-optimization/84725
* c-c++-common/Wstringop-truncation-4.c: New test.
* c-c++-common/attr-nonstring-5.c: New test.

While it's not a regression, I think getting this warning to a point
where it's usable by the linux kernel is a notable win.  So I'm going to
ACK it as an exception to the regression bugfixes only policy.


Thanks.  I've committed r258492.

Martin

Re: Richard Sandiford appointed SVE maintainer in AArch64 port.

[Richard Sandiford]

Ramana Radhakrishnan  writes:
> I am pleased to announced that the GCC Steering Committee has
> appointed Richard Sandiford as SVE maintainer in the AArch64 port.
>
> Please join me in congratulating Richard on his additional role.
>
> Richard, please update your listing in the MAINTAINERS file.

Thanks!  Here's what I applied.

I also installed the SVE patches posted here:

- https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02178.html
- https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00408.html
- https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00420.html

Richard


2018-03-13  Richard Sandiford  

* MAINTAINERS: Add entry for SVE maintainership.

Index: MAINTAINERS
===
--- MAINTAINERS 2018-01-19 11:57:11.527978840 +
+++ MAINTAINERS 2018-03-13 15:08:53.817230991 +
@@ -45,6 +45,7 @@ docs, and the testsuite related to that.
 aarch64 port   Richard Earnshaw
 aarch64 port   James Greenhalgh
 aarch64 port   Marcus Shawcroft
+aarch64 SVE port   Richard Sandiford   
 alpha port Richard Henderson   
 arc port   Joern Rennecke  
 arm port   Nick Clifton

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Martin Liška]

On 03/13/2018 09:32 AM, Jakub Jelinek wrote:

On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:

On 03/12/2018 10:39 AM, Marc Glisse wrote:

On Mon, 12 Mar 2018, Martin Liška wrote:


This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also tested on x86_64-linux-gnu.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-03-08  Martin Liska  

 PR middle-end/81657
 * builtins.c (expand_builtin_memory_copy_args): Add new
 arguments.
 * config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
 New macro.


Shouldn't the macro be defined in a more specific case, for instance glibc on 
x86? Or do all known libc on x86 happen to provide a fast mempcpy?


That's Marc a very good question. Do we already have a glibc-related target 
macros/hooks?
If so, I would add this as one of these.


Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
where in particular linux_libc_has_function deals with various C libraries.
Of course, in this case you need another target hook, that is dependent both
on the target backend and C library.

It would be nice to make the target hook a little bit more generic as well,
e.g. pass it enum builtin_function and query if it is fast, slow or
unknown, or even some kind of cost, where the caller could ask for cost of
BUILT_IN_MEMCPY and BUILT_IN_MEMPCPY and decide based on the relative costs.


Let me start with simple return enum value of FAST,SLOW,UNKNOWN. I've added new 
hook
definition to gcc/config/gnu-user.h that will point to 
gnu_libc_function_implementation.
I would like to implement the function in gcc/targhooks.c, but I don't know how 
to
make ifdef according to target?

One another issue is that built_in_function is enum defined in tree.h. Thus 
I'll replace the
callback argument with int, that will be casted. One last issue: am I right 
that I'll have to define
TARGET_LIBC_FUNCTION_IMPLEMENTATION in each config file (similar to 
no_c99_libc_has_function)?

Thanks,
Martin



Jakub

C++ PATCH to fix another ICE with stray template code (PR c++/84596)

[Marek Polacek]

Here's another case of a template code leaking into cxx_constant_value.
While I recently added the require_rvalue_constant_expression check, it
doesn't help here, because the problem is that we have a MODOP_EXPR (a
template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's
considered dependent, so fold_non_dependent_expr doesn't do its job.

I thought we might skip calling cxx_constant_value when processing a template;
we've already given an error in any case.

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

2018-03-13  Marek Polacek  

PR c++/84596
* semantics.c (finish_static_assert): Don't call cxx_constant_value
when processing a template.

* g++.dg/cpp0x/static_assert15.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index bb8b5953539..8680322a76c 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -8681,7 +8681,8 @@ finish_static_assert (tree condition, tree message, 
location_t location,
   else if (condition && condition != error_mark_node)
{
  error ("non-constant condition for static assertion");
- if (require_rvalue_constant_expression (condition))
+ if (!processing_template_decl
+ && require_rvalue_constant_expression (condition))
cxx_constant_value (condition);
}
   input_location = saved_loc;
diff --git gcc/testsuite/g++.dg/cpp0x/static_assert15.C 
gcc/testsuite/g++.dg/cpp0x/static_assert15.C
index e69de29bb2d..dfb64ad5e1b 100644
--- gcc/testsuite/g++.dg/cpp0x/static_assert15.C
+++ gcc/testsuite/g++.dg/cpp0x/static_assert15.C
@@ -0,0 +1,10 @@
+// PR c++/84596
+// { dg-do compile { target c++11 } }
+
+template
+struct a {
+  constexpr void b() {
+int c;
+static_assert(c %= 1, ""); // { dg-error "non-constant" }
+  }
+};

Marek

[PATCH] Fix PR84830

[Richard Biener]

This should fix the endless PRE antic iterations for good.  OK, it's
somewhat of a hack but unless I fix another two or three parts of the
antic algorithm to not prune values that may later re-appear I see
no other way to guarantee this.  And this isn't the time to fiddle
with PRE further...

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

The assert I added previously is now defunct for CFG cycles which
makes it useless, I'll rip it out as a followup.

Richard.

2018-03-13  Richard Biener  

PR tree-optimization/84830
* tree-ssa-pre.c (compute_antic_aux): Intersect the new ANTIC_IN
with the old one to avoid oscillations.

* gcc.dg/torture/pr84830.c: New testcase.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 258480)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -2154,6 +2154,35 @@ compute_antic_aux (basic_block block, bo
   /* clean (ANTIC_IN (block)) is defered to after the iteration converged
  because it can cause non-convergence, see for example PR81181.  */
 
+  /* Intersect ANTIC_IN with the old ANTIC_IN.  This is required until
+ we properly represent the maximum expression set, thus not prune
+ values without expressions during the iteration.  */
+  if (was_visited
+  && bitmap_and_into (_IN (block)->values, >values))
+{
+  if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file, "warning: intersecting with old ANTIC_IN "
+"shrinks the set\n");
+  /* Prune expressions not in the value set.  */
+  bitmap_iterator bi;
+  unsigned int i;
+  unsigned int to_clear = -1U;
+  FOR_EACH_EXPR_ID_IN_SET (ANTIC_IN (block), i, bi)
+   {
+ if (to_clear != -1U)
+   {
+ bitmap_clear_bit (_IN (block)->expressions, to_clear);
+ to_clear = -1U;
+   }
+ pre_expr expr = expression_for_id (i);
+ unsigned int value_id = get_expr_value_id (expr);
+ if (!bitmap_bit_p (_IN (block)->values, value_id))
+   to_clear = i;
+   }
+  if (to_clear != -1U)
+   bitmap_clear_bit (_IN (block)->expressions, to_clear);
+}
+
   if (!bitmap_set_equal (old, ANTIC_IN (block)))
 {
   changed = true;
Index: gcc/testsuite/gcc.dg/torture/pr84830.c
===
--- gcc/testsuite/gcc.dg/torture/pr84830.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr84830.c  (working copy)
@@ -0,0 +1,46 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fno-tree-ch -fno-tree-vrp" } */
+
+int x0;
+
+void
+br (int yp, int oo)
+{
+  int *qi = 
+
+  if (oo == 0)
+{
+g8:
+  if (x0 != 0)
+   x0 = yp;
+  else if (oo != 0)
+   x0 = yp;
+
+  if (x0 == 0)
+   {
+ *qi = 0;
+ x0 = *qi;
+   }
+
+  if (x0 != 0)
+   {
+ ++oo;
+ goto g8;
+   }
+
+  if (yp == oo)
+   yp += !!oo;
+}
+  else
+{
+  x0 = 1;
+  while (x0 < 2)
+   {
+ qi = 
+ ++oo;
+ x0 = 1;
+   }
+}
+
+  goto g8;
+}

[Patch AArch64] Turn on -fasynchronous-unwind-tables and -funwind-tables by default.

[Ramana Radhakrishnan]

Jakub commented here that
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01325.html we don't turn
on fasynchronous-unwind-tables for AArch64. I note that x86_64 turns on
funwind-tables as well. Thus this patch turns on both.

Note that this doesn't increase code size but will likely increase
binary size because we now have a lot more eh_frame / debug_frame
information being spat out. We probably need to do get the clang /llvm
guys to do the same but I'll prod them separately.

Bootstrapped and regression tested on aarch64-none-linux-gnu.

Ok ?

regards
Ramana


config.gcc (aarch64*-*-linux*): New TARGET_DEFAULT_ASYNC_UNWIND_TABLES

common/config/aarch64/aarch64-common.c (aarch64_optimization_table[]):
Turn on fasynchronous-unwind-tables and funwind-tables.
commit ef1b5fa855a369b9996ccd7041255ff75a4b5b63
Author: Ramana Radhakrishnan 
Date:   Mon Mar 5 17:13:58 2018 +

Add unwind tables by default for AArch64

asynctables

diff --git a/gcc/common/config/aarch64/aarch64-common.c 
b/gcc/common/config/aarch64/aarch64-common.c
index 7fd9305..a9fc5f1 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -53,6 +53,10 @@ static const struct default_options 
aarch_option_optimization_table[] =
 { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
 /* Enable redundant extension instructions removal at -O2 and higher.  */
 { OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 },
+#if (TARGET_DEFAULT_ASYNC_UNWIND_TABLES == 1)
+{ OPT_LEVELS_ALL, OPT_fasynchronous_unwind_tables, NULL, 1 },
+{ OPT_LEVELS_ALL, OPT_funwind_tables, NULL, 1},
+#endif
 { OPT_LEVELS_NONE, 0, NULL, 0 }
   };
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2156c6b..3fe7c8f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -981,6 +981,7 @@ aarch64*-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-linux.h"
tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-linux"
+   tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
case $target in
aarch64_be-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"

Re: [PATCH] Fix another reg-stack recovery bug (PR target/84828)

[Jakub Jelinek]

On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote:
> >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
> >> without this patch or even before the previous patch), will handle that
> >> tomorrow.

> I got:

See the above?
Or do you get this with -m64 too, rather than -m32 only?

Jakub

[PATCH] Redirect reference in the symbol table (PR ipa/84833).

[Martin Liška]

Hi.

This fixed issue where we have an ifunc function called from another ifunc 
function.
One needs to properly make a reference redirection.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
MVC tests on x86_64 also work fine.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-03-13  Martin Liska  

PR ipa/84833
* multiple_target.c (create_dispatcher_calls): Redirect
reference in the symbol table.

gcc/testsuite/ChangeLog:

2018-03-13  Martin Liska  

PR ipa/84833
* gcc.target/i386/mvc11.c: New test.
---
 gcc/multiple_target.c |  4 
 gcc/testsuite/gcc.target/i386/mvc11.c | 28 
 2 files changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/mvc11.c


diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index a6767985774..46cf7a30733 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -144,6 +144,10 @@ create_dispatcher_calls (struct cgraph_node *node)
 		  if (ref->referring->decl != resolver_decl)
 		walk_gimple_stmt (, NULL, replace_function_decl, );
 		}
+
+	  symtab_node *source = ref->referring;
+	  ref->remove_reference ();
+	  source->create_reference (inode, IPA_REF_ADDR);
 	}
 	  else
 	gcc_unreachable ();
diff --git a/gcc/testsuite/gcc.target/i386/mvc11.c b/gcc/testsuite/gcc.target/i386/mvc11.c
new file mode 100644
index 000..5bd10f4651d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mvc11.c
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-require-ifunc "" } */
+/* { dg-options "-std=gnu99" } */
+
+__attribute__((noipa)) int 
+baz (int (*fn) (void))
+{
+  asm volatile ("" : "+g" (fn) : : "memory");
+  return fn ();
+}
+
+__attribute__((target_clones("arch=sandybridge", "default"))) static int
+bar (void)
+{
+  return 1;
+}
+
+__attribute__((target_clones("arch=sandybridge", "default"))) int
+foo (void)
+{
+  baz (bar) - 1;
+}
+
+int
+main ()
+{
+  foo ();
+}

Re: GCC 6 backports

[Martin Liška]

On 03/10/2018 07:28 PM, H.J. Lu wrote:

On Wed, Mar 7, 2018 at 1:41 AM, Martin Liška  wrote:

Hi.

Sending GCC 6 branch backports.
Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
I'm going to install the patches.

Martin


I am going to backport:


Thank you for the patch and for backport of the patch.

Martin



https://gcc.gnu.org/ml/gcc-cvs/2018-01/msg00211.html

to GCC 6 branch to fix:

FAIL: g++.dg/ipa/pr82352.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/pr82352.C  -std=gnu++98 (test for excess errors)

[PATCH] Handle -fno-guess-branch-probability properly in predict.c (PR ipa/84825).

[Martin Liška]

Hi.

This is a fix for situation where we use -fno-guess-branch-probability and 
fnsplit happens.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-03-13  Martin Liska  

PR ipa/84825
* predict.c (rebuild_frequencies): Handle case when we have
PROFILE_ABSENT, but flag_guess_branch_prob is false.

gcc/testsuite/ChangeLog:

2018-03-13  Martin Liska  

* g++.dg/ipa/pr84825.C: New test.
---
 gcc/predict.c  |  3 +++
 gcc/testsuite/g++.dg/ipa/pr84825.C | 18 ++
 2 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr84825.C


diff --git a/gcc/predict.c b/gcc/predict.c
index b40dec47822..019ff9e44cf 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -3998,6 +3998,9 @@ rebuild_frequencies (void)
 }
   else if (profile_status_for_fn (cfun) == PROFILE_READ)
 update_max_bb_count ();
+  else if (profile_status_for_fn (cfun) == PROFILE_ABSENT
+	   && !flag_guess_branch_prob)
+;
   else
 gcc_unreachable ();
   timevar_pop (TV_REBUILD_FREQUENCIES);
diff --git a/gcc/testsuite/g++.dg/ipa/pr84825.C b/gcc/testsuite/g++.dg/ipa/pr84825.C
new file mode 100644
index 000..7ae854e7140
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr84825.C
@@ -0,0 +1,18 @@
+/* PR ipa/84658 */
+/* { dg-options "-O3 --param early-inlining-insns=0 -fno-guess-branch-probability" } */
+
+struct a;
+struct b;
+struct c {
+  virtual a *d(b *);
+};
+struct a {
+  virtual a e();
+};
+struct f {
+  virtual ~f();
+};
+struct g : f, a {};
+struct b : c, virtual g {
+  b *d(b *h) { return h; }
+} i;

Re: [PATCH] Fix another reg-stack recovery bug (PR target/84828)

[H.J. Lu]

On Tue, Mar 13, 2018 at 5:02 AM, Jakub Jelinek  wrote:
> On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote:
>> >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
>> >> without this patch or even before the previous patch), will handle that
>> >> tomorrow.
>
>> I got:
>
> See the above?
> Or do you get this with -m64 too, rather than -m32 only?
>

I got this for -m32, -m64 and -mx32.

-- 
H.J.

Re: [PATCH] Fix another reg-stack recovery bug (PR target/84828)

[H.J. Lu]

On Tue, Mar 13, 2018 at 12:55 AM, Uros Bizjak  wrote:
> On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek  wrote:
>> Hi!
>>
>> As Martin reported, the same testcase added recently ICEs differently
>> with different options on x86_64-linux, the problem is that we
>> sometimes emit insns before a CODE_LABEL of the next bb rather than after
>> the last insn in the previous bb, and expect we can just fix up BB_END
>> of the previous bb; fortunately that doesn't change BB_HEAD of the next
>> bb, but still we need to at least update INSN_BLOCK and make sure df knows
>> that too.
>>
>> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>> trunk?
>>
>> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
>> without this patch or even before the previous patch), will handle that
>> tomorrow.
>>
>> 2018-03-12  Jakub Jelinek  
>>
>> PR target/84828
>> * reg-stack.c (change_stack): Change update_end var from int to
>> rtx_insn *, if non-NULL don't update just BB_END (current_block), but
>> also call set_block_for_insn on the newly added insns and rescan.
>>
>> * g++.dg/ext/pr84828.C: New test.
>
> LGTM.
>
> Uros.
>

I got:

spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test/bld/gcc/testsuite/g++/../../xg++
-B/export/gnu/import/git/gcc-test/bld/gcc/testsuite/g++/../../
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/g++.dg/ext/pr84828.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test/src-trunk/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test/src-trunk/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test/src-trunk/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++98 -Og -mno-sse2 -S -o pr84828.s^M
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/g++.dg/ext/pr84828.C:
In function 'void foo(float, double)':^M
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/g++.dg/ext/pr84828.C:10:35:
error: output constraint 0 must specify a single register^M
during RTL pass: stack^M
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/g++.dg/ext/pr84828.C:13:1:
internal compiler error: in move_for_stack_reg, at reg-stack.c:1108^M
0xeaf075 move_for_stack_reg^M
../../src-trunk/gcc/reg-stack.c:1108^M
0xeb26ea subst_stack_regs^M
../../src-trunk/gcc/reg-stack.c:2438^M
0xeb2950 convert_regs_1^M
../../src-trunk/gcc/reg-stack.c:3072^M
0xeb2950 convert_regs_2^M
../../src-trunk/gcc/reg-stack.c:3207^M
0xeb4798 convert_regs^M
../../src-trunk/gcc/reg-stack.c:3242^M
0xeb4798 reg_to_stack^M
../../src-trunk/gcc/reg-stack.c:3367^M
0xeb4798 rest_of_handle_stack_regs^M
../../src-trunk/gcc/reg-stack.c:3422^M
0xeb4798 execute^M
../../src-trunk/gcc/reg-stack.c:3453^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1
FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (internal compiler error)
PASS: g++.dg/ext/pr84828.C  -std=gnu++98  (test for errors, line 10)
FAIL: g++.dg/ext/pr84828.C  -std=gnu++98 (test for excess errors)

-- 
H.J.

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Richard Biener]

On Tue, Mar 13, 2018 at 9:32 AM, Jakub Jelinek  wrote:
> On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
>> On 03/12/2018 10:39 AM, Marc Glisse wrote:
>> > On Mon, 12 Mar 2018, Martin Liška wrote:
>> >
>> > > This is fix for the PR that introduces a new target macro. Using the 
>> > > macro
>> > > one can say that a target has a fast mempcpy and thus it's preferred to 
>> > > be used
>> > > if possible.
>> > >
>> > > Patch can bootstrap on ppc64le-redhat-linux and survives regression 
>> > > tests.
>> > > I also tested on x86_64-linux-gnu.
>> > >
>> > > Ready to be installed?
>> > > Martin
>> > >
>> > > gcc/ChangeLog:
>> > >
>> > > 2018-03-08  Martin Liska  
>> > >
>> > > PR middle-end/81657
>> > > * builtins.c (expand_builtin_memory_copy_args): Add new
>> > > arguments.
>> > > * config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
>> > > New macro.
>> >
>> > Shouldn't the macro be defined in a more specific case, for instance glibc 
>> > on x86? Or do all known libc on x86 happen to provide a fast mempcpy?
>>
>> That's Marc a very good question. Do we already have a glibc-related target 
>> macros/hooks?
>> If so, I would add this as one of these.
>
> Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
> where in particular linux_libc_has_function deals with various C libraries.
> Of course, in this case you need another target hook, that is dependent both
> on the target backend and C library.
>
> It would be nice to make the target hook a little bit more generic as well,
> e.g. pass it enum builtin_function and query if it is fast, slow or
> unknown, or even some kind of cost, where the caller could ask for cost of
> BUILT_IN_MEMCPY and BUILT_IN_MEMPCPY and decide based on the relative costs.

Or maybe a hook returning the alternative to use?  Pass it BUILT_IN_X
and get back
the same or related builtin?

Richard.

> Jakub

Re: [PATCH] S/390: Set ABI default based on uname

[Andreas Krebbel]

On 03/12/2018 06:50 PM, Jakub Jelinek wrote:
> On Mon, Mar 12, 2018 at 06:42:15PM +0100, Andreas Krebbel wrote:
>> On 03/12/2018 06:31 PM, Jakub Jelinek wrote:
>>> On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote:
 Currently the default ABI option for a GCC built on a 64 bit system is
 always -m64.  This is inconvenient when e.g. building 32 bit libraries
 on a 64 bit system.  The usual way to do this is to set the personality
 to s390 (32 bit) and let the configure script do the right thing.
 Having a GCC which defaults to -m64 also requires to get a -m31 somehow
 into the option list.

 With that patch the GCC driver checks the current personality setting in
 order to figure out at runtime what the default is supposed to be.

 Bootstrapped and regtested on s390x.

 I will commit the patch after waiting a few days for comments.
>>>
>>> I don't like this, it is inconsistent with how it is handled on all other
>>> targets and how it worked for years.  Having setarch magically change the
>>> default is dangerous.
>>
>> Wow, that was quick ;)
>>
>> I didn't expect this to break things. Could you please elaborate where this 
>> might cause trouble?
> 
> It is an unexpected major behavior change for environments that are this way
> used for 1-2 decades.

Ok. I agree that changing the behavior unconditionally probably isn't a good 
idea.  The
default-default should stay as is.  I'll try to hide this behind a configure 
switch.

> When people want -m32 they just specify it, or if
> they want a compiler that defaults to -m32 they configure it that way;
> when gcc 7.x works one way and 8.x works differently, it will just mean
> people will need to use -m32 or -m64 all the time, otherwise they won't be
> sure what will happen.

The only case I see where an additional -m option would be required is when 
trying to generate 64
bit code while running in a 32 bit setarch. Should this be something to care 
about?

Leaving history aside don't you agree that it would have been more sensible to 
require a -m option
only if you want to build for an ABI different from what is currently mandated 
by the personality
setting?

> Plus as I said, it is about consistency, why should s390x work in this
> regard any differently in this regard from x86_64, powerpc64, sparc64,
> mips64, which don't change the default even when setarch changes uname.

Perhaps other platforms might want that as well?! ;)

Background of that change is that while 32 bit support is starting to fade out 
of the distros we
internally have to continue to build 32 bit stuff for a while.  Currently the 
RPM spec files from
the distros take care of supporting 32 bit builds in 64 bit environments. E.g. 
for the Glibc Fedora
spec file I recently did send a patch adding -m31 to the compile options 
depending on the
personality setting. The spec file already did that for many other biarch 
architectures. With biarch
builds probably getting less attention in the future the GCC mechanism provides 
us with a simple way
to do 32 bit builds for libs which used to support s390-32bit before but don't 
add -m31 depending on
the current personality.

It is especially annoying on S/390 with our -m31 switch (instead of -m32). This 
certainly wasn't a
great choice in the very beginning of the S/390 port. I never dared to also 
support -m32
expecting that this would make the whole thing even more messy.


Andreas

> 
>   Jakub
> 

Re: [patch] Fix PR lto/84805

[Richard Biener]

On Tue, Mar 13, 2018 at 12:06 AM, Eric Botcazou  wrote:
> Hi,
>
> this is an ICE in LTO mode on code violating the ODR rule: get_odr_type checks
> that there is a sensible internal order between base, type and derived types
> but this can be easily messed up by incomplete types.  Hence the attached
> fixlet (no testcase because the -Wodr warnings have a totally random order).
>
> Tested on x86-64/Linux, OK for the mainline?

Ok.

Richard.

>
> 2018-03-12  Eric Botcazou  
>
> PR lto/84805
> * ipa-devirt.c (odr_subtypes_equivalent_p): Do not get the ODR type of
> incomplete types.
>
> --
> Eric Botcazou

Re: [PATCH] Fix bogus strncpy source length warning on source bound by constant

[Siddhesh Poyarekar]

On Monday 12 March 2018 03:26 PM, Richard Biener wrote:
> Please use tree_int_cst_lt (rhs1, dstsize) instead.
> 
>> +   {
>> + gimple_set_no_warning (stmt, true);
> 
> Why this?  There's only a single bit -- where do we warn from if you
> don't do this here?

I incorrectly thought it was necessary to set that flag but I noticed
now that it isn't.  I'll remove it.

> I also wonder why this code doesn't use range-info given the
> INTEGER_CST constraints
> range-info should tell us more than just handling MIN_EXPR?

Right, I'll try using range-info.

Thanks,
Siddhesh

[PATCH] Fix __builtin_round{,f,l} ICE on x86 (PR target/84827)

[Jakub Jelinek]

Hi!

Since r237074 the 387 rounding insns are guarded with
(flag_fp_int_builtin_inexact || !flag_trapping_math), and the
round2 expander is enabled for 387 fancy math whenever
flag_unsafe_math_optimizations; as the testcase shows, the latter
doesn't imply the former, so this patch adds another guard.

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

2018-03-12  Jakub Jelinek  

PR target/84827
* config/i386/i386.md (round2): For 387 fancy math, disable
pattern if -ftrapping-math -fno-fp-int-builtin-inexact.

* gcc.target/i386/pr84827.c: New test.

--- gcc/config/i386/i386.md.jj  2018-03-05 16:59:42.881641832 +0100
+++ gcc/config/i386/i386.md 2018-03-12 15:54:28.925304229 +0100
@@ -16311,7 +16311,8 @@ (define_expand "round2"
   "(TARGET_USE_FANCY_MATH_387
 && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
|| TARGET_MIX_SSE_I387)
-&& flag_unsafe_math_optimizations)
+&& flag_unsafe_math_optimizations
+&& (flag_fp_int_builtin_inexact || !flag_trapping_math))
|| (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH
&& !flag_trapping_math && !flag_rounding_math)"
 {
--- gcc/testsuite/gcc.target/i386/pr84827.c.jj  2018-03-12 16:04:20.195411779 
+0100
+++ gcc/testsuite/gcc.target/i386/pr84827.c 2018-03-12 15:54:58.041309098 
+0100
@@ -0,0 +1,21 @@
+/* PR target/84827 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -fno-fp-int-builtin-inexact -ftrapping-math 
-fno-associative-math -mfpmath=387" } */
+
+double
+f1 (double a)
+{
+  return __builtin_round (a);
+}
+
+float
+f2 (float a)
+{
+  return __builtin_roundf (a);
+}
+
+long double
+f3 (long double a)
+{
+  return __builtin_roundl (a);
+}

Jakub

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Jakub Jelinek]

On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote:
> On 03/12/2018 10:39 AM, Marc Glisse wrote:
> > On Mon, 12 Mar 2018, Martin Liška wrote:
> > 
> > > This is fix for the PR that introduces a new target macro. Using the macro
> > > one can say that a target has a fast mempcpy and thus it's preferred to 
> > > be used
> > > if possible.
> > > 
> > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> > > I also tested on x86_64-linux-gnu.
> > > 
> > > Ready to be installed?
> > > Martin
> > > 
> > > gcc/ChangeLog:
> > > 
> > > 2018-03-08  Martin Liska  
> > > 
> > > PR middle-end/81657
> > > * builtins.c (expand_builtin_memory_copy_args): Add new
> > > arguments.
> > > * config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
> > > New macro.
> > 
> > Shouldn't the macro be defined in a more specific case, for instance glibc 
> > on x86? Or do all known libc on x86 happen to provide a fast mempcpy?
> 
> That's Marc a very good question. Do we already have a glibc-related target 
> macros/hooks?
> If so, I would add this as one of these.

Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook,
where in particular linux_libc_has_function deals with various C libraries.
Of course, in this case you need another target hook, that is dependent both
on the target backend and C library.

It would be nice to make the target hook a little bit more generic as well,
e.g. pass it enum builtin_function and query if it is fast, slow or
unknown, or even some kind of cost, where the caller could ask for cost of
BUILT_IN_MEMCPY and BUILT_IN_MEMPCPY and decide based on the relative costs.

Jakub

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Martin Liška]

On 03/12/2018 10:39 AM, Marc Glisse wrote:

On Mon, 12 Mar 2018, Martin Liška wrote:


This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also tested on x86_64-linux-gnu.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-03-08  Martin Liska  

PR middle-end/81657
* builtins.c (expand_builtin_memory_copy_args): Add new
arguments.
* config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
New macro.


Shouldn't the macro be defined in a more specific case, for instance glibc on 
x86? Or do all known libc on x86 happen to provide a fast mempcpy?


That's Marc a very good question. Do we already have a glibc-related target 
macros/hooks?
If so, I would add this as one of these.

Thanks,
Martin




* defaults.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE): Likewise.
* doc/tm.texi: Likewise.
* doc/tm.texi.in: Likewise.
* expr.c (compare_by_pieces): Add support for bail out.
(emit_block_move_hints): Likewise.
* expr.h (emit_block_move_hints): Add new arguments.

[PATCH] Properly redirect alias for MVC (PR ipa/84722).

[Martin Liška]

Hi.

When having a weak alias that points to a multi-versioning function, one
needs to redirect the alias properly.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-03-12  Martin Liska  

PR ipa/84722
* multiple_target.c (create_dispatcher_calls): Redirect also
an alias.

gcc/testsuite/ChangeLog:

2018-03-12  Martin Liska  

PR ipa/84722
* gcc.target/i386/mvc10.c: New test.
---
 gcc/multiple_target.c |  7 +++
 gcc/testsuite/gcc.target/i386/mvc10.c | 16 
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/mvc10.c


diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index a6767985774..95297f3cd30 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -145,6 +145,13 @@ create_dispatcher_calls (struct cgraph_node *node)
 		walk_gimple_stmt (, NULL, replace_function_decl, );
 		}
 	}
+	  else if (ref->use == IPA_REF_ALIAS)
+	{
+	  symtab_node *source = ref->referring;
+	  ref->remove_reference ();
+	  source->create_reference (inode, IPA_REF_ALIAS);
+	  source->add_to_same_comdat_group (inode);
+	}
 	  else
 	gcc_unreachable ();
 	}
diff --git a/gcc/testsuite/gcc.target/i386/mvc10.c b/gcc/testsuite/gcc.target/i386/mvc10.c
new file mode 100644
index 000..9a7b609c0b3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mvc10.c
@@ -0,0 +1,16 @@
+/* PR ipa/84722.  */
+/* { dg-do run } */
+/* { dg-require-ifunc "" } */
+
+__attribute__ ((target_clones ("avx", "arch=core-avx2", "default"))) int
+foo (int i)
+{
+  return i - 1;
+}
+int weaks (int i) __attribute__ ((weak, alias ("foo")));
+
+int
+main (int argc, char **argv)
+{
+  return weaks (argc);
+}

Re: [PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

[Martin Liška]

On 03/12/2018 11:06 AM, Richard Biener wrote:

On Mon, Mar 12, 2018 at 9:42 AM, Martin Liška  wrote:

Hi.

This is what I was recommended in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?


Please do not remove the DECL_PT_UID setting (set_alias_uids).   That's required
to make followup PTA runs compute correct points-to sets.

Otherwise...

+   /* The above get's us to 99% I guess, at least catching the
+ address compares.  Below also gets us aliasing correct
+ but as said we're giving leeway to the situation with
+ readonly vars anyway, so ... */
+   basic_block bb;
+   FOR_EACH_BB_FN (bb, DECL_STRUCT_FUNCTION (cnode->decl))
+   for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+gsi_next ())

so if you want to keep this (as the comment says I think it's not
strictly necessary) then you can replace DECL_STRUCT_FUNCTION (cnode->decl)
with 'fn' you compute earlier.

Otherwise looks ok.


Good, done that. I'm attaching final version of patch I'm going to install.

Thanks for review,
Martin



Thanks,
Richard.


Martin

gcc/ChangeLog:

2018-03-12  Martin Liska  

 PR ipa/84658.
 * ipa-icf.c (set_alias_uids): Remove.
 (sem_variable::merge): Remove usage.
 (sem_item_optimizer::sem_item_optimizer): Initialize new
 vector.
 (sem_item_optimizer::~sem_item_optimizer): Release it.
 (sem_item_optimizer::merge_classes): Register variable aliases.
 (sem_item_optimizer::fixup_pt_set): New function.
 (sem_item_optimizer::fixup_points_to_sets): Likewise.
 * ipa-icf.h: Declare new variables and functions.

gcc/testsuite/ChangeLog:

2018-03-12  Martin Liska  

 PR ipa/84658.
 * g++.dg/ipa/pr84658.C: New test.
---
  gcc/ipa-icf.c  | 88 +-
  gcc/ipa-icf.h  | 10 +
  gcc/testsuite/g++.dg/ipa/pr84658.C | 30 +
  3 files changed, 108 insertions(+), 20 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/ipa/pr84658.C


>From 27acff689225028a262eec09c213be38eb323470 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 9 Mar 2018 13:23:32 +0100
Subject: [PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

gcc/ChangeLog:

2018-03-12  Martin Liska  

	PR ipa/84658.
	* (sem_item_optimizer::sem_item_optimizer): Initialize new
	vector.
	(sem_item_optimizer::~sem_item_optimizer): Release it.
	(sem_item_optimizer::merge_classes): Register variable aliases.
	(sem_item_optimizer::fixup_pt_set): New function.
	(sem_item_optimizer::fixup_points_to_sets): Likewise.
	* ipa-icf.h: Declare new variables and functions.

gcc/testsuite/ChangeLog:

2018-03-12  Martin Liska  

	PR ipa/84658.
	* g++.dg/ipa/pr84658.C: New test.
---
 gcc/ipa-icf.c  | 112 ++---
 gcc/ipa-icf.h  |  12 
 gcc/testsuite/g++.dg/ipa/pr84658.C |  30 ++
 3 files changed, 134 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr84658.C

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index b9f2bf30744..1376a54e95e 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -2133,23 +2133,6 @@ sem_variable::get_hash (void)
   return m_hash;
 }
 
-/* Set all points-to UIDs of aliases pointing to node N as UID.  */
-
-static void
-set_alias_uids (symtab_node *n, int uid)
-{
-  ipa_ref *ref;
-  FOR_EACH_ALIAS (n, ref)
-{
-  if (dump_file)
-	fprintf (dump_file, "  Setting points-to UID of [%s] as %d\n",
-		 xstrdup_for_dump (ref->referring->asm_name ()), uid);
-
-  SET_DECL_PT_UID (ref->referring->decl, uid);
-  set_alias_uids (ref->referring, uid);
-}
-}
-
 /* Merges instance with an ALIAS_ITEM, where alias, thunk or redirection can
be applied.  */
 
@@ -2276,7 +2259,6 @@ sem_variable::merge (sem_item *alias_item)
   if (dump_file)
 	fprintf (dump_file, "Unified; Variable alias has been created.\n");
 
-  set_alias_uids (original, DECL_UID (original->decl));
   return true;
 }
 }
@@ -2296,7 +2278,7 @@ unsigned int sem_item_optimizer::class_id = 0;
 
 sem_item_optimizer::sem_item_optimizer ()
 : worklist (0), m_classes (0), m_classes_count (0), m_cgraph_node_hooks (NULL),
-  m_varpool_node_hooks (NULL)
+  m_varpool_node_hooks (NULL), m_merged_variables ()
 {
   m_items.create (0);
   bitmap_obstack_initialize (_bmstack);
@@ -2321,6 +2303,7 @@ sem_item_optimizer::~sem_item_optimizer ()
   m_items.release ();
 
   bitmap_obstack_release (_bmstack);
+  m_merged_variables.release ();
 }
 
 /* Write IPA ICF summary for symbols.  */
@@ -3572,13 +3555,102 @@ sem_item_optimizer::merge_classes (unsigned int prev_class_count)
 	  }
 
 	if (dbg_cnt (merged_ipa_icf))
-	  merged_p |= source->merge 

Re: PR target/84743 adjust reassociation widths for power8/power9

[Richard Biener]

On Mon, 12 Mar 2018, Aaron Sawdey wrote:

> Looking at CPU2017 results for different reassociation widths, things
> have shifted since I last looked at this with CPU2006 in early gcc7
> timeframe. Best thing to do seems to be to set reassociation width to 1
> for all integer modes, which is what the attached patch does.
> 
> I also tried setting width to 1 for float modes PLUS_EXPR as this patch
> did for aarch64 but this does not seem to be helpful for power8.
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01271.html
> 
> 
> Results below are % performance improvement on power8 comparing trunk
> with the attached patch vs trunk with --param tree-reassoc-width=1 to
> disable parallel reassociation for everything (first column of results)
> and trunk unmodified (second column of results). 
> 
> CPU2017 componentvs width=1   vs trunk
> 500.perlbench_r-0.36% -0.15%
> 502.gcc_r   0.06%  0.04%
> 505.mcf_r   0.32%  0.24%
> 520.omnetpp_r   0.57% -0.95%
> 523.xalancbmk_r 1.45%  1.04%
> 525.x264_r -0.05%  0.09%
> 531.deepsjeng_r 0.04%  0.09%
> 541.leela_r 0.10%  0.72%
> 548.exchange2_r 0.08%  0.73%
> 557.xz_r0.09%  2.12%
> CPU2017 int geo mean0.23%  0.40%
> 503.bwaves_r0.00%  0.01%
> 507.cactuBSSN_r 0.05% -0.02%
> 508.namd_r  0.00%  0.00%
> 510.parest_r   -0.01%  0.20%
> 511.povray_r0.03% -0.24%
> 519.lbm_r  -0.04% -0.16%
> 521.wrf_r  -0.01% -0.56%
> 526.blender_r  -0.82% -0.47%
> 527.cam4_r -0.18%  0.06%
> 538.imagick_r  -0.02%  0.01%
> 544.nab_r   0.00%  0.23%
> 549.fotonik3d_r 0.24%  0.54%
> 554.roms_r -0.05%  0.03%
> CPU2017 fp geo mean-0.06% -0.03%
> 
> Bottom line is net improvement for CPU2017 int compared with either
> current trunk, or disabling parallel reassociation. For CPU2017 fp,
> very small overall degradation. 
> 
> Currently doing regstrap on ppc64le, ok for trunk if results look good?

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 258101)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -10006,7 +10006,7 @@
   if (VECTOR_MODE_P (mode))
return 4;
   if (INTEGRAL_MODE_P (mode)) 
-   return opc == MULT_EXPR ? 4 : 6;
+   return 1;
   if (FLOAT_MODE_P (mode))
return 4;
   break;

so the original widths were very large (IMHO), did you try reducing
width to, say, 2?  In your numbers I see mostly noise but
2% regression for 557.xz_r and 1% for 523.xalancbmk_r.  Maybe
POWER machines give very stable performance measurement results
but from my experience on x86_64 anything < 1% is just noise...

Richard.

> Thanks!
>Aaron
> 
> 2018-03-12  Aaron Sawdey  
> 
>   PR target/84743
>   * config/rs6000/rs6000.c (rs6000_reassociation_width): Disable parallel
>   reassociation for int modes.
> 
> 
> 

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

Re: [PATCH] Fix match.pd ICEs on COMPLEX_CSTs (PR middle-end/84834)

[Richard Biener]

On Mon, 12 Mar 2018, Jakub Jelinek wrote:

> Hi!
> 
> The following two match.pd spots assume that integer_pow2p will return
> true only for INTEGER_CSTs (it uses wi::to_wide on it), but as the testcase
> shows, that is not always the case, we can get there with COMPLEX_CSTs.
> 
> Fixed by requiring that it is both INTEGER_CST and integer_pow2p,
> bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Richard.

> I went through other spots where integer_pow2p is used in match.pd and think
> all other spots should be safe, I don't think we e.g. allow BIT_AND_EXPR
> with COMPLEX_CST operand etc.
> 
> 2018-03-12  Jakub Jelinek  
> 
>   PR middle-end/84834
>   * match.pd ((A & C) != 0 ? D : 0): Use INTEGER_CST@2 instead of
>   integer_pow2p@2 and test integer_pow2p in condition.
>   (A < 0 ? C : 0): Similarly for @1.
> 
>   * gcc.dg/pr84834.c: New test.
> 
> --- gcc/match.pd.jj   2018-03-06 08:06:13.0 +0100
> +++ gcc/match.pd  2018-03-12 19:18:24.144577077 +0100
> @@ -3566,16 +3566,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (cond
>(ne (bit_and @0 integer_pow2p@1) integer_zerop)
> -  integer_pow2p@2 integer_zerop)
> - (with {
> -int shift = (wi::exact_log2 (wi::to_wide (@2))
> -  - wi::exact_log2 (wi::to_wide (@1)));
> -  }
> -  (if (shift > 0)
> -   (bit_and
> -(lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
> -   (bit_and
> -(convert (rshift @0 { build_int_cst (integer_type_node, -shift); })) 
> @2
> +  INTEGER_CST@2 integer_zerop)
> + (if (integer_pow2p (@2))
> +  (with {
> + int shift = (wi::exact_log2 (wi::to_wide (@2))
> +   - wi::exact_log2 (wi::to_wide (@1)));
> +   }
> +   (if (shift > 0)
> +(bit_and
> + (lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
> +(bit_and
> + (convert (rshift @0 { build_int_cst (integer_type_node, -shift); }))
> + @2)
>  
>  /* If we have (A & C) != 0 where C is the sign bit of A, convert
> this into A < 0.  Similarly for (A & C) == 0 into A >= 0.  */
> @@ -3595,8 +3597,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (cond
>(lt @0 integer_zerop)
> -  integer_pow2p@1 integer_zerop)
> - (if (!TYPE_UNSIGNED (TREE_TYPE (@0)))
> +  INTEGER_CST@1 integer_zerop)
> + (if (integer_pow2p (@1)
> +  && !TYPE_UNSIGNED (TREE_TYPE (@0)))
>(with {
>  int shift = element_precision (@0) - wi::exact_log2 (wi::to_wide (@1)) - 
> 1;
> }
> --- gcc/testsuite/gcc.dg/pr84834.c.jj 2018-03-12 19:21:15.677631881 +0100
> +++ gcc/testsuite/gcc.dg/pr84834.c2018-03-12 19:20:59.105626588 +0100
> @@ -0,0 +1,15 @@
> +/* PR middle-end/84834 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +_Complex int
> +foo (int a)
> +{
> +  return a < 0;
> +}
> +
> +_Complex int
> +bar (int a)
> +{
> +  return (a & 8) ? (_Complex int) 16 : (_Complex int) 0;
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] Fix another CONSTRAINT_LEN related bug (PR middle-end/84831)

[Richard Biener]

On Mon, 12 Mar 2018, Jakub Jelinek wrote:

> Hi!
> 
> I thought the vregs pass is the first one to analyze constraints,
> but I was wrong, already before that parse_{output,input}_constraint
> are called, already during GIMPLE passes.  They don't really fail miserably
> if , appears in the middle of multi-letter constraint (unlike e.g. the RA),
> which is what my previous patch was fixing, but care if '\0' appears
> in the middle of multi-letter constraint, because then we continue walking
> random characters after the constraint string.  parse_input_constraint
> is actually fine, because it has c_len = strlen (constraint); and uses
> j < c_len, but parse_output_constraint doesn't do that.  While doing it
> is possible, I think it is needlessly slow (needs to walk the constraint
> twice), so this patch instead makes sure there are no '\0's in the middle
> of constraints, if there are, doesn't jump over it.
> 
> The patch is larger because of reindentation, here is diff -upbd for
> easier understanding what has changed.
> 
> --- gcc/stmt.c.jj 2018-01-03 10:19:55.150533956 +0100
> +++ gcc/stmt.c2018-03-12 13:25:03.790733765 +0100
> @@ -247,7 +247,8 @@ parse_output_constraint (const char **co
>  }
>  
>/* Loop through the constraint string.  */
> -  for (p = constraint + 1; *p; p += CONSTRAINT_LEN (*p, p))
> +  for (p = constraint + 1; *p; )
> +{
>  switch (*p)
>{
>case '+':
> @@ -304,6 +305,11 @@ parse_output_constraint (const char **co
>   break;
>}
>  
> +  for (size_t len = CONSTRAINT_LEN (*p, p); len; len--, p++)
> + if (*p == '\0')
> +   break;
> +}
> +
>return true;
>  }
>  
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Richard.

> 2018-03-12  Jakub Jelinek  
> 
>   PR middle-end/84831
>   * stmt.c (parse_output_constraint): If the CONSTRAINT_LEN (*p, p)
>   characters starting at p contain '\0' character, don't look beyond
>   that.
> 
> --- gcc/stmt.c.jj 2018-01-03 10:19:55.150533956 +0100
> +++ gcc/stmt.c2018-03-12 13:25:03.790733765 +0100
> @@ -247,62 +247,68 @@ parse_output_constraint (const char **co
>  }
>  
>/* Loop through the constraint string.  */
> -  for (p = constraint + 1; *p; p += CONSTRAINT_LEN (*p, p))
> -switch (*p)
> -  {
> -  case '+':
> -  case '=':
> - error ("operand constraint contains incorrectly positioned "
> -"%<+%> or %<=%>");
> - return false;
> -
> -  case '%':
> - if (operand_num + 1 == ninputs + noutputs)
> -   {
> - error ("%<%%%> constraint used with last operand");
> - return false;
> -   }
> - break;
> -
> -  case '?':  case '!':  case '*':  case '&':  case '#':
> -  case '$':  case '^':
> -  case 'E':  case 'F':  case 'G':  case 'H':
> -  case 's':  case 'i':  case 'n':
> -  case 'I':  case 'J':  case 'K':  case 'L':  case 'M':
> -  case 'N':  case 'O':  case 'P':  case ',':
> - break;
> -
> -  case '0':  case '1':  case '2':  case '3':  case '4':
> -  case '5':  case '6':  case '7':  case '8':  case '9':
> -  case '[':
> - error ("matching constraint not valid in output operand");
> - return false;
> -
> -  case '<':  case '>':
> - /* ??? Before flow, auto inc/dec insns are not supposed to exist,
> -excepting those that expand_call created.  So match memory
> -and hope.  */
> - *allows_mem = true;
> - break;
> -
> -  case 'g':  case 'X':
> - *allows_reg = true;
> - *allows_mem = true;
> - break;
> -
> -  default:
> - if (!ISALPHA (*p))
> -   break;
> - enum constraint_num cn = lookup_constraint (p);
> - if (reg_class_for_constraint (cn) != NO_REGS
> - || insn_extra_address_constraint (cn))
> +  for (p = constraint + 1; *p; )
> +{
> +  switch (*p)
> + {
> + case '+':
> + case '=':
> +   error ("operand constraint contains incorrectly positioned "
> +  "%<+%> or %<=%>");
> +   return false;
> +
> + case '%':
> +   if (operand_num + 1 == ninputs + noutputs)
> + {
> +   error ("%<%%%> constraint used with last operand");
> +   return false;
> + }
> +   break;
> +
> + case '?':  case '!':  case '*':  case '&':  case '#':
> + case '$':  case '^':
> + case 'E':  case 'F':  case 'G':  case 'H':
> + case 's':  case 'i':  case 'n':
> + case 'I':  case 'J':  case 'K':  case 'L':  case 'M':
> + case 'N':  case 'O':  case 'P':  case ',':
> +   break;
> +
> + case '0':  case '1':  case '2':  case '3':  case '4':
> + case '5':  case '6':  case '7':  case '8':  case '9':
> + case '[':
> +   error ("matching constraint not valid in output operand");
> +   return false;
> +
> + case '<':  case '>':
> +   /* ??? Before flow, auto inc/dec insns are not supposed to exist,
> +  excepting 

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test
case ?
If all is Ok, execution and compilation shall ideally pass for the test
cases.
But I have noticed that there are some output pattern checks done in some
test cases and this may fail since the output assembly is different,
anyway I shall give it a try and send you the results with the new options.

On Tue, Mar 13, 2018 at 8:42 AM, Michael Eager  wrote:

> On 03/12/18 23:10, Andrew Sadek wrote:
>
>> _Command for running testsuite:_
>>
>> /make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu
>> CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h
>> -L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
>> -mlittle-endian' "/
>>
>> _Quick Details:_
>> 1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in
>> some test cases.
>> 2) -L . /lib: it contains libm, libc in little endian since we use
>> 'qemu-system-microblazeel', and libxil which is the libgloss + some
>> additional features (read, write, inbyte, outbyte) built with Xilinx SDK.
>>
>> _mb-gcc command example from gcc.log:_
>>
>> Testing execute/va-arg-15.c,   -O1
>> doing compile
>> Executing on host://home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-
>> elf/build/build-cc-gcc-final/gcc/xgcc -B/home/andrew/gcc_workspace/g
>> cc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/
>> /home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/
>> src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c -include
>> /home/andrew/qemu/common.h -L/home/andrew/qemu/lib
>> -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian
>> -fno-diagnostics-show-caret -fdiagnostics-color=never-O1  -w
>> -T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld  -lm  -o
>> ./va-arg-15.exe(timeout = 300)/
>>
>
> OK.  This shows that the patch does not cause regressions when the new
> options are not used.  That is good.
>
> Please run the same regression test with the new PIC options.  Ideally you
> should have the same results.
>
>
>
>>
>>
>> On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager  ea...@eagerm.com>> wrote:
>>
>> On 03/12/18 06:19, Andrew Sadek wrote:
>>
>>
>>
>> On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager >  >
>> >> wrote:
>>
>>  On 03/02/2018 08:12 AM, Andrew Sadek wrote:
>>
>>  Hello Michael,
>>
>>  I tried running the whole GCC test suite on the current
>> head
>>  (without my patch) along with 'microblaze-qemu' but I
>> have the
>>  following problems:
>>
>>  1) The test is hanging at
>> 'gcc.c-torture/string-large-1.c' , the
>>  gcc is making a 100% CPU usage and the machine stucks.
>>  I tried compiling the file alone, it generated a couple
>> of
>>  warnings than it hangs.
>> warning: '__builtin_memchr' specified size
>> 4294967295 exceeds
>>  maximum object size 2147483647 [-Wstringop-overflow=]
>>   vp1 = __builtin_memchr (a, b, SIZE1);
>>
>>  Is it a bug? Is there something wrong with my
>> configuration ?
>>  GCC configured with options :  --with-newlib
>> --enable-threads=no
>>  --disable-shared --with-pkgversion='crosstool-NG
>>  crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
>>  --disable-libgomp --disable-libmudflap --disable-libmpx
>>  --disable-libssp --disable-libquadmath
>>  --disable-libquadmath-support --enable-lto
>>  --with-host-libstdcxx='-static-libgcc
>>  -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
>> --enable-target-optspace
>>  --disable-nls --enable-multiarch --enable-languages=c,c++
>>
>>
>>  Your configuration is more complex than my hard-metal
>> target version,
>>  but it looks reasonable.
>>
>>  The problem with string-large-1.c does appear to be a bug.
>>You can
>>  add a line to the test case which will mark it as known
>> failure for MB:
>>
>> /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
>>
>>  (I have not tested this, but it should work.  Compare with
>> other
>>  xfail's.)
>>
>>
>> Problem that the whole compile package is invoked with '-w'
>> which inhibits all warnings and overrides ' -Werror' as well as
>> ' -Wfatal-errors' .
>> As a result, the warning message does not appear when running
>> compile.exp. Any suggestions ? Do I remove the '-w' ?
>>
>>
>>
>>  2) For running QEMU, I have no problem with elf
>> 

Re: [PATCH] Fix another reg-stack recovery bug (PR target/84828)

[Uros Bizjak]

On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek  wrote:
> Hi!
>
> As Martin reported, the same testcase added recently ICEs differently
> with different options on x86_64-linux, the problem is that we
> sometimes emit insns before a CODE_LABEL of the next bb rather than after
> the last insn in the previous bb, and expect we can just fix up BB_END
> of the previous bb; fortunately that doesn't change BB_HEAD of the next
> bb, but still we need to at least update INSN_BLOCK and make sure df knows
> that too.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
> without this patch or even before the previous patch), will handle that
> tomorrow.
>
> 2018-03-12  Jakub Jelinek  
>
> PR target/84828
> * reg-stack.c (change_stack): Change update_end var from int to
> rtx_insn *, if non-NULL don't update just BB_END (current_block), but
> also call set_block_for_insn on the newly added insns and rescan.
>
> * g++.dg/ext/pr84828.C: New test.

LGTM.

Uros.

> --- gcc/reg-stack.c.jj  2018-03-12 15:06:21.565800672 +0100
> +++ gcc/reg-stack.c 2018-03-12 15:06:31.167802560 +0100
> @@ -2489,7 +2489,7 @@ change_stack (rtx_insn *insn, stack_ptr
>   enum emit_where where)
>  {
>int reg;
> -  int update_end = 0;
> +  rtx_insn *update_end = NULL;
>int i;
>
>/* Stack adjustments for the first insn in a block update the
> @@ -2511,7 +2511,7 @@ change_stack (rtx_insn *insn, stack_ptr
>if (where == EMIT_AFTER)
>  {
>if (current_block && BB_END (current_block) == insn)
> -   update_end = 1;
> +   update_end = insn;
>insn = NEXT_INSN (insn);
>  }
>
> @@ -2686,7 +2686,16 @@ change_stack (rtx_insn *insn, stack_ptr
>  }
>
>if (update_end)
> -BB_END (current_block) = PREV_INSN (insn);
> +{
> +  for (update_end = NEXT_INSN (update_end); update_end != insn;
> +  update_end = NEXT_INSN (update_end))
> +   {
> + set_block_for_insn (update_end, current_block);
> + if (INSN_P (update_end))
> +   df_insn_rescan (update_end);
> +   }
> +  BB_END (current_block) = PREV_INSN (insn);
> +}
>  }
>
>  /* Print stack configuration.  */
> --- gcc/testsuite/g++.dg/ext/pr84828.C.jj   2018-03-12 15:13:50.589882983 
> +0100
> +++ gcc/testsuite/g++.dg/ext/pr84828.C  2018-03-12 15:14:06.670885916 +0100
> @@ -0,0 +1,13 @@
> +// PR target/84828
> +// { dg-do compile { target i?86-*-* x86_64-*-* } }
> +// { dg-options "-Og -mno-sse2" }
> +
> +void
> +foo (float b, double c)
> +{
> +  for (int e = 0; e < 2; e++)
> +{
> +  asm volatile ("" : "+f" (c));// { dg-error "must specify a single 
> register" }
> +  asm ("" : "+rm" (c = b));
> +}
> +}
>
> Jakub

Re: [PATCH] Fix -march=knl wrong-code (PR target/84786)

[Uros Bizjak]

On Mon, Mar 12, 2018 at 9:52 PM, Jakub Jelinek  wrote:
> Hi!
>
> For TARGET_AVX512F && !TARGET_AVX512VL, the RA ensures that
> 128-bit and 256-bit vectors aren't allocated in %xmm16+ registers,
> but not so for scalar modes.  In that case we use avx512vl isa attribute,
> or TARGET_AVX512VL guards, or Yv constraint.
>
> The following patch does the last one for sse2_loadhpd pattern where the
> last argument has DFmode and thus using v constraint for it is unsafe
> and on the testcase we emit
> vunpcklpd   %xmm18, %xmm0, %xmm0
> instruction which needs avx512vl.  Bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk?
>
> 2018-03-12  Jakub Jelinek  
>
> PR target/84786
> * config/i386/sse.md (sse2_loadhpd): Use Yv constraint rather than v
> on the last operand.
>
> * gcc.target/i386/avx512f-pr84786-1.c: New test.
> * gcc.target/i386/avx512f-pr84786-2.c: New test.

OK for trunk and backports.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2018-03-05 17:00:24.568655800 +0100
> +++ gcc/config/i386/sse.md  2018-03-12 11:05:48.917401886 +0100
> @@ -9022,14 +9022,14 @@ (define_expand "sse2_loadhpd_exp"
>  ;; see comment above inline_secondary_memory_needed function in i386.c
>  (define_insn "sse2_loadhpd"
>[(set (match_operand:V2DF 0 "nonimmediate_operand"
> - "=x,v,x,v,o,o ,o")
> + "=x,v,x,v ,o,o ,o")
> (vec_concat:V2DF
>   (vec_select:DF
> (match_operand:V2DF 1 "nonimmediate_operand"
> - " 0,v,0,v,0,0 ,0")
> + " 0,v,0,v ,0,0 ,0")
> (parallel [(const_int 0)]))
>   (match_operand:DF 2 "nonimmediate_operand"
> - " m,m,x,v,x,*f,r")))]
> + " m,m,x,Yv,x,*f,r")))]
>"TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
>"@
> movhpd\t{%2, %0|%0, %2}
> --- gcc/testsuite/gcc.target/i386/avx512f-pr84786-1.c.jj2018-03-12 
> 11:32:33.563665173 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512f-pr84786-1.c   2018-03-12 
> 11:35:33.964695384 +0100
> @@ -0,0 +1,25 @@
> +/* PR target/84786 */
> +/* { dg-do run { target { ! ia32 } } } */
> +/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
> +/* { dg-require-effective-target avx512f } */
> +
> +#include "avx512f-check.h"
> +
> +typedef double V __attribute__((vector_size (16)));
> +
> +__attribute__((noipa)) V
> +foo (V x, double y)
> +{
> +  register double z __asm ("xmm18");
> +  asm volatile ("" : "=v" (z) : "0" (y));
> +  x[1] = z;
> +  return x;
> +}
> +
> +static void
> +avx512f_test (void)
> +{
> +  V a = foo ((V) { 1.0, 2.0 }, 3.0);
> +  if (a[0] != 1.0 || a[1] != 3.0)
> +abort ();
> +}
> --- gcc/testsuite/gcc.target/i386/avx512f-pr84786-2.c.jj2018-03-12 
> 11:32:43.445666826 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512f-pr84786-2.c   2018-03-12 
> 11:35:45.260697279 +0100
> @@ -0,0 +1,16 @@
> +/* PR target/84786 */
> +/* { dg-do compile { target { ! ia32 } } } */
> +/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
> +
> +typedef double V __attribute__((vector_size (16)));
> +
> +__attribute__((noipa)) V
> +foo (V x, double y)
> +{
> +  register double z __asm ("xmm18");
> +  asm volatile ("" : "=v" (z) : "0" (y));
> +  x[1] = z;
> +  return x;
> +}
> +
> +/* { dg-final { scan-assembler-not 
> "vunpcklpd\[\^\n\r]*xmm(1\[6-9]|\[23]\[0-9])" } } */
>
> Jakub

Re: [PATCH] Fix __builtin_round{,f,l} ICE on x86 (PR target/84827)

[Uros Bizjak]

On Mon, Mar 12, 2018 at 10:14 PM, Jakub Jelinek  wrote:
> Hi!
>
> Since r237074 the 387 rounding insns are guarded with
> (flag_fp_int_builtin_inexact || !flag_trapping_math), and the
> round2 expander is enabled for 387 fancy math whenever
> flag_unsafe_math_optimizations; as the testcase shows, the latter
> doesn't imply the former, so this patch adds another guard.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-03-12  Jakub Jelinek  
>
> PR target/84827
> * config/i386/i386.md (round2): For 387 fancy math, disable
> pattern if -ftrapping-math -fno-fp-int-builtin-inexact.
>
> * gcc.target/i386/pr84827.c: New test.

OK for trunk and backports.

Thanks,
Uros.

> --- gcc/config/i386/i386.md.jj  2018-03-05 16:59:42.881641832 +0100
> +++ gcc/config/i386/i386.md 2018-03-12 15:54:28.925304229 +0100
> @@ -16311,7 +16311,8 @@ (define_expand "round2"
>"(TARGET_USE_FANCY_MATH_387
>  && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
> || TARGET_MIX_SSE_I387)
> -&& flag_unsafe_math_optimizations)
> +&& flag_unsafe_math_optimizations
> +&& (flag_fp_int_builtin_inexact || !flag_trapping_math))
> || (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH
> && !flag_trapping_math && !flag_rounding_math)"
>  {
> --- gcc/testsuite/gcc.target/i386/pr84827.c.jj  2018-03-12 16:04:20.195411779 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr84827.c 2018-03-12 15:54:58.041309098 
> +0100
> @@ -0,0 +1,21 @@
> +/* PR target/84827 */
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fno-fp-int-builtin-inexact -ftrapping-math 
> -fno-associative-math -mfpmath=387" } */
> +
> +double
> +f1 (double a)
> +{
> +  return __builtin_round (a);
> +}
> +
> +float
> +f2 (float a)
> +{
> +  return __builtin_roundf (a);
> +}
> +
> +long double
> +f3 (long double a)
> +{
> +  return __builtin_roundl (a);
> +}
>
> Jakub

RE: [patch][x86] Split-up march icelake on march=icelake-server and march=icelake-client

[Koval, Julia]

Fixed invoke.texi. Here is the new version.

gcc/
* config.gcc (icelake-client, icelake-server): New.
(icelake): Remove.
* config/i386/i386.c (initial_ix86_tune_features): Extend to 64 bit.
(initial_ix86_arch_features): Ditto.
(ix86_option_override_internal): Split up icelake on icelake client and
icelake server.
(get_builtin_code_for_version): Ditto.
(fold_builtin_cpu): Ditto.
* config/i386/driver-i386.c (config/i386/driver-i386.c): Ditto.
* config/i386/i386-c.c (ix86_target_macros_internal): Ditto
* config/i386/i386.h (processor_type) Ditto.
* doc/invoke.texi: Ditto.

gcc/testsuite/
* g++.dg/ext/mv16.C: Split up icelake on icelake client and
icelake-server.
* gcc.target/i386/funcspec-56.inc: Ditto.

libgcc/
* config/i386/cpuinfo.h (processor_subtypes): Split up icelake on 
icelake 
client and icelake-server.

Thanks,
Julia

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Monday, March 12, 2018 10:21 PM
> To: Koval, Julia 
> Cc: 'GCC Patches' ; Uros Bizjak
> 
> Subject: Re: [patch][x86] Split-up march icelake on march=icelake-server and
> march=icelake-client
> 
> On Mon, 12 Mar 2018, Koval, Julia wrote:
> 
> > Hi,
> > This patch introduces separate client and server arch options instead of
> > -march=icelake. Ok for trunk?
> 
> I don't see any invoke.texi updates here to document what these two
> options mean (including, presumably, different lists of features for
> them).
> 
> --
> Joseph S. Myers
> jos...@codesourcery.com


0001-icelake-client.patch
Description: 0001-icelake-client.patch

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 03/12/18 23:10, Andrew Sadek wrote:

_Command for running testsuite:_

/make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu 
CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h 
-L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group 
-mlittle-endian' "/


_Quick Details:_
1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in 
some test cases.
2) -L . /lib: it contains libm, libc in little endian since we use 
'qemu-system-microblazeel', and libxil which is the libgloss + some 
additional features (read, write, inbyte, outbyte) built with Xilinx SDK.


_mb-gcc command example from gcc.log:_

Testing execute/va-arg-15.c,   -O1
doing compile
Executing on 
host://home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/xgcc 
-B/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/ 
/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c  
   -include /home/andrew/qemu/common.h -L/home/andrew/qemu/lib 
-Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian 
-fno-diagnostics-show-caret -fdiagnostics-color=never    -O1  -w 
-T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld  -lm  -o 
./va-arg-15.exe    (timeout = 300)/


OK.  This shows that the patch does not cause regressions when the new 
options are not used.  That is good.


Please run the same regression test with the new PIC options.  Ideally 
you should have the same results.







On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager > wrote:


On 03/12/18 06:19, Andrew Sadek wrote:



On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager  >> wrote:

     On 03/02/2018 08:12 AM, Andrew Sadek wrote:

         Hello Michael,

         I tried running the whole GCC test suite on the current
head
         (without my patch) along with 'microblaze-qemu' but I
have the
         following problems:

         1) The test is hanging at
'gcc.c-torture/string-large-1.c' , the
         gcc is making a 100% CPU usage and the machine stucks.
         I tried compiling the file alone, it generated a couple of
         warnings than it hangs.
            warning: '__builtin_memchr' specified size
4294967295 exceeds
         maximum object size 2147483647 [-Wstringop-overflow=]
          vp1 = __builtin_memchr (a, b, SIZE1);

         Is it a bug? Is there something wrong with my
configuration ?
         GCC configured with options :  --with-newlib
--enable-threads=no
         --disable-shared --with-pkgversion='crosstool-NG
         crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
         --disable-libgomp --disable-libmudflap --disable-libmpx
         --disable-libssp --disable-libquadmath
         --disable-libquadmath-support --enable-lto
         --with-host-libstdcxx='-static-libgcc
         -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-target-optspace
         --disable-nls --enable-multiarch --enable-languages=c,c++


     Your configuration is more complex than my hard-metal
target version,
     but it looks reasonable.

     The problem with string-large-1.c does appear to be a bug. 
You can

     add a line to the test case which will mark it as known
failure for MB:

        /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */

     (I have not tested this, but it should work.  Compare with
other
     xfail's.)


Problem that the whole compile package is invoked with '-w'
which inhibits all warnings and overrides ' -Werror' as well as
' -Wfatal-errors' .
As a result, the warning message does not appear when running
compile.exp. Any suggestions ? Do I remove the '-w' ?



         2) For running QEMU, I have no problem with elf
execution. But I
         do not know how to auto terminate the QEMU itself  as
it remains
         up even after program execution.
         Is there some command to be passed to QEMU in order
make system
         shut down after program termination with its exit code ?


     Yes, this is a problem.  For other targets using QEMU I
have added dummy
     HLT instructions to terminate QEMU, or used a wrapper
around QEMU which
     sets breakpoints at exit (or _exit) and stops the simulator
when hit.

     If you are running Linux on QEMU, instead of using QEMU's
built-in gdb
     interface you might 

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

*Command for running testsuite:*

*make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu
CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h
-L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
-mlittle-endian' "*

*Quick Details:*
1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in some
test cases.
2) -L . /lib: it contains libm, libc in little endian since we use
'qemu-system-microblazeel', and libxil which is the libgloss + some
additional features (read, write, inbyte, outbyte) built with Xilinx SDK.

*mb-gcc command example from gcc.log:*

Testing execute/va-arg-15.c,   -O1
doing compile
Executing on host:*
/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/xgcc
-B/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/
/home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c
  -include /home/andrew/qemu/common.h -L/home/andrew/qemu/lib
-Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian
-fno-diagnostics-show-caret -fdiagnostics-color=never-O1  -w
-T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld  -lm  -o
./va-arg-15.exe(timeout = 300)*



On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager  wrote:

> On 03/12/18 06:19, Andrew Sadek wrote:
>
>
>>
>> On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager  ea...@eagerm.com>> wrote:
>>
>> On 03/02/2018 08:12 AM, Andrew Sadek wrote:
>>
>> Hello Michael,
>>
>> I tried running the whole GCC test suite on the current head
>> (without my patch) along with 'microblaze-qemu' but I have the
>> following problems:
>>
>> 1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the
>> gcc is making a 100% CPU usage and the machine stucks.
>> I tried compiling the file alone, it generated a couple of
>> warnings than it hangs.
>>warning: '__builtin_memchr' specified size 4294967295 exceeds
>> maximum object size 2147483647 [-Wstringop-overflow=]
>>  vp1 = __builtin_memchr (a, b, SIZE1);
>>
>> Is it a bug? Is there something wrong with my configuration ?
>> GCC configured with options :  --with-newlib --enable-threads=no
>> --disable-shared --with-pkgversion='crosstool-NG
>> crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
>> --disable-libgomp --disable-libmudflap --disable-libmpx
>> --disable-libssp --disable-libquadmath
>> --disable-libquadmath-support --enable-lto
>> --with-host-libstdcxx='-static-libgcc
>> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace
>> --disable-nls --enable-multiarch --enable-languages=c,c++
>>
>>
>> Your configuration is more complex than my hard-metal target version,
>> but it looks reasonable.
>>
>> The problem with string-large-1.c does appear to be a bug.  You can
>> add a line to the test case which will mark it as known failure for
>> MB:
>>
>>/* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
>>
>> (I have not tested this, but it should work.  Compare with other
>> xfail's.)
>>
>>
>> Problem that the whole compile package is invoked with '-w' which
>> inhibits all warnings and overrides ' -Werror' as well as ' -Wfatal-errors'
>> .
>> As a result, the warning message does not appear when running
>> compile.exp. Any suggestions ? Do I remove the '-w' ?
>>
>>
>>
>> 2) For running QEMU, I have no problem with elf execution. But I
>> do not know how to auto terminate the QEMU itself  as it remains
>> up even after program execution.
>> Is there some command to be passed to QEMU in order make system
>> shut down after program termination with its exit code ?
>>
>>
>> Yes, this is a problem.  For other targets using QEMU I have added
>> dummy
>> HLT instructions to terminate QEMU, or used a wrapper around QEMU
>> which
>> sets breakpoints at exit (or _exit) and stops the simulator when hit.
>>
>> If you are running Linux on QEMU, instead of using QEMU's built-in gdb
>> interface you might use the Linux system as the target for the test
>> suite, running gdbserver on the target.
>>
>>
>> I have finally managed to fully run QEMU with test suite but had to make
>> a local modification in the QEMU code itself.
>> In the translate function, I make a check if "bri 0" is reached which is
>> the '_exit'. Then, abort the QEMU app with the exit code stored in 'r5'.
>>
>
> I've done essentially the same for other targets.
>
> Here are the results below:
>> _Without Patch:_
>> === gcc Summary ===
>>
>> # of expected passes90776
>> # of unexpected failures1317
>> # of unexpected successes3
>> # of expected failures207
>> # of unresolved testcases115
>> # of unsupported tests2828
>>
>> _With Patch and after adding my test