[PATCH] Suppress ssp.c unused variable warning on mingw

2017-03-31 Thread JonY
Hi,

This suppresses an unused variable warning for mingw*, patch OK?

Index: libssp/ssp.c
===
--- libssp/ssp.c(revision 246630)
+++ libssp/ssp.c(working copy)
@@ -72,7 +72,6 @@
 __guard_setup (void)
 {
   unsigned char *p;
-  int fd;
 
   if (__stack_chk_guard != 0)
 return;
@@ -91,7 +90,7 @@
   CryptReleaseContext(hprovider, 0);
 }
 #else
-  fd = open ("/dev/urandom", O_RDONLY);
+  int fd = open ("/dev/urandom", O_RDONLY);
   if (fd != -1)
 {
   ssize_t size = read (fd, &__stack_chk_guard,


Changelog:
2017-04-01  Jonathan Yong  <10wa...@gmail.com>

* ssp.c (__guard_setup): Suppress unused variable warning.




signature.asc
Description: OpenPGP digital signature


[PATCH,rs6000] PR80108: Fix ICE with cross compiler

2017-03-31 Thread Kelvin Nilsen

PR 80108 describes an ICE that occurs on an existing test program when
compiled with a particular combination of target options.  

This patch fixes the compiler to reject that particular combination of
target options since it is not meaningful and duplicates the offending
test case with a dg-options directive to exercise the problematic
command-line options.

This patch has been bootstrapped and tested with no regressions on both
powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu.  Is
this ok for the trunk?


gcc/ChangeLog:

2017-03-31  Kelvin Nilsen  

PR target/80108
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Enhance special handling given to the TARGET_P9_MINMAX option in
relation to certain other options.

gcc/testsuite/ChangeLog:

2017-03-31  Kelvin Nilsen  

PR target/80108
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: New file.
* gcc.target/powerpc/ppc-fortran/pr80108-1.f90: New test.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246573)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4273,8 +4273,30 @@ rs6000_option_override_internal (bool global_init_
   /* For the newer switches (vsx, dfp, etc.) set some of the older options,
  unless the user explicitly used the -mno- to disable the code.  */
   if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR
-  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 || 
TARGET_P9_MINMAX)
+  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0)
 rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+  else if (TARGET_P9_MINMAX)
+{
+  if (have_cpu)
+   {
+ if (cpu_index == PROCESSOR_POWER9)
+   /* legacy behavior: allow -mcpu-power9 with certain capabilities
+  (eg -mno-vsx) explicitly disabled.  */
+   rs6000_isa_flags |=
+ (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
+ else
+   error ("Power9 target option is incompatible with -mcpu= for "
+  " less than power9");
+   }
+  else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit)
+  != (ISA_3_0_MASKS_SERVER & rs6000_isa_flags
+  & rs6000_isa_flags_explicit))
+   /* Enforce that none of the ISA_3_0_MASKS_SERVER flags
+  were explicitly cleared.  */
+   error ("-mpower9-minmax incompatible with explicitly disabled options");
+  else
+   rs6000_isa_flags |= ISA_3_0_MASKS_SERVER;
+}
   else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO)
 rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit);
   else if (TARGET_VSX)
Index: gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
===
--- gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(revision 246624)
@@ -0,0 +1,65 @@
+#   Copyright (C) 2004-2017 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib gfortran-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_FFLAGS
+if ![info exists DEFAULT_FFLAGS] then {
+set DEFAULT_FFLAGS " -pedantic-errors"
+}
+
+# Initialize `dg'.
+dg-init
+
+global gfortran_test_path
+global gfortran_aux_module_flags
+set gfortran_test_path $srcdir/$subdir
+set gfortran_aux_module_flags $DEFAULT_FFLAGS
+proc dg-compile-aux-modules { args } {
+global gfortran_test_path
+global gfortran_aux_module_flags
+if { [llength $args] != 2 } {
+   error "dg-set-target-env-var: needs one argument"
+   return
+}
+
+set level [info level]
+if { [info procs dg-save-unknown] != [list] } {
+   rename dg-save-unknown dg-save-unknown-level-$level
+}
+
+dg-test $gfortran_test_path/[lindex $args 1] "" $gfortran_aux_module_flags
+# cleanup-modules is intentionally not invoked here.
+
+if { [info procs dg-save-unknown-level-$level] != [list] } {
+   rename dg-save-unknown-level-$level dg-save-unknown
+}
+}
+
+# 

Re: [PATCH] fwprop: Prevent infinite looping (PR79405)

2017-03-31 Thread Jeff Law

On 03/23/2017 08:58 AM, Segher Boessenkool wrote:

The algorithm fwprop uses never reconsiders a possible propagation,
although it could succeed if the def (in the def-use to propagate)
has changed.  This causes fwprop to do infinite propagations, like
in the scenario in the PR, where we end up with effectively
  B = A
  A = B
  D = A
where only propagations into the last statement are still tried, and
that loops (it becomes D = B, then back to D = A, etc.)

Fixing this properly isn't easy; this patch instead limits the number
of propagations performed to the number of uses we originally had,
which is the maximum number of propagations that can be done if there
are no such infinite loops.

Bootstrapped and regression checked on powerpc64-linux {-m64,-m32};
is this okay for trunk?


Segher


2017-03-23  Segher Boessenkool  

PR rtl-optimization/79405
* fwprop.c (propagations_left): New variable.
(forward_propagate_into): Decrement it.
(fwprop_init): Initialize it.
(fw_prop): If the variable has reached zero, stop propagating.
(fwprop_addr): Ditto.

gcc/testsuite/
PR rtl-optimization/79405
gcc.dg/pr79405.c: New testcase.
I installed this as a stopgap for gcc-7.  The bug is still open 
targetting gcc-8  to force us to come back and look at Richi's suggestion.


jeff



[PATCH] simplify-rtx: Fix compare of comparisons (PR60818)

2017-03-31 Thread Segher Boessenkool
The function simplify_binary_operation_1 has code that does
/* Convert (compare (gt (flags) 0) (lt (flags) 0)) to (flags).  */
but this transformation is only valid if "flags" has the same machine
mode as the outer compare.  This fixes it.

Bootstrapped and tested on powerpc64-linux {-m32,-m64} (and tested the
new testcase with {-m32,-m64}{,-misel}).  Is this okay for trunk?


Segher


2017-03-31  Segher Boessenkool  

PR rtl-optimization/60818
* simplify-rtx.c (simplify_binary_operation_1): Do not replace
a compare of comparisons with the thing compared if this results
in a different machine mode.

gcc/testsuite/
PR rtl-optimization/60818
* gcc.c-torture/compile/pr60818.c: New testcase.

---
 gcc/simplify-rtx.c| 6 +++---
 gcc/testsuite/gcc.c-torture/compile/pr60818.c | 5 +
 2 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr60818.c

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 3022779..10c2800 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -2367,10 +2367,10 @@
  return xop00;
 
if (REG_P (xop00) && REG_P (xop10)
-   && GET_MODE (xop00) == GET_MODE (xop10)
&& REGNO (xop00) == REGNO (xop10)
-   && GET_MODE_CLASS (GET_MODE (xop00)) == MODE_CC
-   && GET_MODE_CLASS (GET_MODE (xop10)) == MODE_CC)
+   && GET_MODE (xop00) == mode
+   && GET_MODE (xop10) == mode
+   && GET_MODE_CLASS (mode) == MODE_CC)
  return xop00;
}
   break;
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr60818.c 
b/gcc/testsuite/gcc.c-torture/compile/pr60818.c
new file mode 100644
index 000..b6171bb
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr60818.c
@@ -0,0 +1,5 @@
+int
+lx (int oi, int mb)
+{
+  return (oi < mb) < (mb < oi);
+}
-- 
1.9.3



Re: [PATCH] [gcc, testsuite] Don't xfail on s390.

2017-03-31 Thread Martin Sebor

On 03/29/2017 04:23 AM, Dominik Vogt wrote:

The attached patch removes the XFAIL in attr-alloc_size-11.c on
s390.  (PR 79356).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356

Untested.


It looks like the only target the test does fail on is x86.

The attached patch simplifies the test to XFAIL just those.
It passes with cross-compilers for arm-linux-gnueabi-*-*,
i386-pc-solaris2.11, powerpc64le-*-*, sparcv9-solaris2.11,
and s360*-*-*.

I don't have ready access to an s390 machine.  I assume you
do.  Does it work for you?

Martin
diff --git a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
index e5f2157..19e8680 100644
--- a/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
+++ b/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
@@ -47,8 +47,8 @@ typedef __SIZE_TYPE__size_t;
 
 /* The following tests fail because of missing range information.  The xfail
exclusions are PR79356.  */
-TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX);   /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for signed char" { xfail { ! { aarch64*-*-* arm*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
-TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "missing range info for short" { xfail { ! { aarch64*-*-* arm*-*-* ia64-*-* mips*-*-* powerpc*-*-* sparc*-*-* s390x-*-* } } } } */
+TEST (signed char, SCHAR_MIN + 2, ALLOC_MAX);   /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "bug 80086" { xfail { i?86-*-* x86_64-*-* } } } */
+TEST (short, SHRT_MIN + 2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" "bug 80086" { xfail { i?86-*-* x86_64-*-* } } } */
 TEST (int, INT_MIN + 2, ALLOC_MAX);/* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
 TEST (int, -3, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */
 TEST (int, -2, ALLOC_MAX); /* { dg-warning "argument 1 range \\\[13, \[0-9\]+\\\] exceeds maximum object size 12" } */


Re: Fix ICE with -fauto-profile when walking vdefs

2017-03-31 Thread Sebastian Pop
On Fri, Mar 31, 2017 at 1:50 PM, Richard Biener  wrote:
> That looks like a workaround rather than the correct fix.  Who sets .MEM? It 
> should assign the proper def.
>

Moving the auto_profile pass above several other passes fixes the problem.
The minimal change to fix the problem is by disabling these two passes:

--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -86,14 +86,12 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_ccp, false /* nonzero_p */);
   /* After CCP we rewrite no longer addressed locals into SSA
  form if possible.  */
-  NEXT_PASS (pass_forwprop);
   NEXT_PASS (pass_early_thread_jumps);
   NEXT_PASS (pass_sra_early);
   /* pass_build_ealias is a dummy pass that ensures that we
  execute TODO_rebuild_alias at this point.  */
   NEXT_PASS (pass_build_ealias);
   NEXT_PASS (pass_fre);
-  NEXT_PASS (pass_early_vrp);
   NEXT_PASS (pass_merge_phi);
   NEXT_PASS (pass_dse);
   NEXT_PASS (pass_cd_dce);

It seems to me that early_vrp is the one changing the IR in an inconsistent way.


[gomp4] update parsing for the bind clause in fortran

2017-03-31 Thread Cesar Philippidis
This patch does the following:

 * Update gfortran's bind parser to allow the bind with a string
   argument to be used with 'implicit none'
 * Teaches gfortran how to lower the bind clause like the c and c++
   front ends.

Note that the bind clause still isn't implemented in the middle end.
Also, due to the parsing changes, I had to xfail routine-8.f90 because
it no longer fails to compile. However, because bind is unimplemented in
the ME, this test fails to link since the bound names are missing.

I'll apply this patch to gomp-4_0-branch shortly.

Cesar
2017-03-31  Cesar Philippidis  

	gcc/fortran
	* gfortran.h (struct gfc_omp_clauses): Add bind_name member.
	* match.c (gfc_match_call_name): New function.
	(gfc_match_call): Break out function name parsing to
	gfc_match_call_name.  Call it.
	* match.h (gfc_match_call_named): Declare.
	* openmp.c (gfc_match_oacc_bind_clause): New function.
	(gfc_match_omp_clauses): Call it to parse the bind clause.
	* trans-openmp.c (gfc_trans_omp_clauses_1): Lower OMP_CLAUSE_BIND.

	gcc/testsuite/
	* gfortran.dg/goacc/routine-bind-1.f90: New test.

	libgomp/
	* testsuite/libgomp.oacc-fortran/routine-8.f90: Adjust xfails.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 9a7cb45..2adbe4c 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1315,7 +1315,7 @@ typedef struct gfc_omp_clauses
   unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
   unsigned wait:1, par_auto:1, gang_static:1, nohost:1, acc_collapse:1, bind:1;
   locus loc;
-
+  char bind_name[GFC_MAX_SYMBOL_LEN+1];
 }
 gfc_omp_clauses;
 
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 8470229..ddf2560 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4476,6 +4476,52 @@ match_typebound_call (gfc_symtree* varst)
   return MATCH_YES;
 }
 
+match
+gfc_match_call_name (char *name, gfc_symbol **sym, gfc_symtree **st, bool )
+{
+  exit = true;
+
+  if (gfc_get_ha_sym_tree (name, st))
+return MATCH_ERROR;
+
+  *sym = (*st)->n.sym;
+
+  /* If this is a variable of derived-type, it probably starts a type-bound
+ procedure call.  */
+  if (((*sym)->attr.flavor != FL_PROCEDURE
+   || gfc_is_function_return_value (*sym, gfc_current_ns))
+  && ((*sym)->ts.type == BT_DERIVED || (*sym)->ts.type == BT_CLASS))
+return match_typebound_call (*st);
+
+  /* If it does not seem to be callable (include functions so that the
+ right association is made.  They are thrown out in resolution.)
+ ...  */
+  if (!(*sym)->attr.generic
+  && !(*sym)->attr.subroutine
+  && !(*sym)->attr.function)
+{
+  if (!((*sym)->attr.external && !(*sym)->attr.referenced))
+	{
+	  /* ...create a symbol in this scope...  */
+	  if ((*sym)->ns != gfc_current_ns
+	&& gfc_get_sym_tree (name, NULL, st, false) == 1)
+return MATCH_ERROR;
+
+	  if (*sym != (*st)->n.sym)
+	*sym = (*st)->n.sym;
+	}
+
+  /* ...and then to try to make the symbol into a subroutine.  */
+  if (!gfc_add_subroutine (&(*sym)->attr, (*sym)->name, NULL))
+	return MATCH_ERROR;
+}
+
+  gfc_set_sym_referenced (*sym);
+  exit = false;
+
+  return MATCH_YES;
+}
+
 
 /* Match a CALL statement.  The tricky part here are possible
alternate return specifiers.  We handle these by having all
@@ -4495,6 +4541,7 @@ gfc_match_call (void)
   gfc_code *c;
   match m;
   int i;
+  bool exit;
 
   arglist = NULL;
 
@@ -4504,42 +4551,9 @@ gfc_match_call (void)
   if (m != MATCH_YES)
 return m;
 
-  if (gfc_get_ha_sym_tree (name, ))
-return MATCH_ERROR;
-
-  sym = st->n.sym;
-
-  /* If this is a variable of derived-type, it probably starts a type-bound
- procedure call.  */
-  if ((sym->attr.flavor != FL_PROCEDURE
-   || gfc_is_function_return_value (sym, gfc_current_ns))
-  && (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS))
-return match_typebound_call (st);
-
-  /* If it does not seem to be callable (include functions so that the
- right association is made.  They are thrown out in resolution.)
- ...  */
-  if (!sym->attr.generic
-	&& !sym->attr.subroutine
-	&& !sym->attr.function)
-{
-  if (!(sym->attr.external && !sym->attr.referenced))
-	{
-	  /* ...create a symbol in this scope...  */
-	  if (sym->ns != gfc_current_ns
-	&& gfc_get_sym_tree (name, NULL, , false) == 1)
-return MATCH_ERROR;
-
-	  if (sym != st->n.sym)
-	sym = st->n.sym;
-	}
-
-  /* ...and then to try to make the symbol into a subroutine.  */
-  if (!gfc_add_subroutine (>attr, sym->name, NULL))
-	return MATCH_ERROR;
-}
-
-  gfc_set_sym_referenced (sym);
+  m = gfc_match_call_name (name, , , exit);
+  if (exit)
+return m;
 
   if (gfc_match_eos () != MATCH_YES)
 {
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index c348113..d7d4394 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -95,6 +95,7 @@ match gfc_match_nullify (void);
 match 

[PATCH] Add gcc_jit_type_get_aligned

2017-03-31 Thread David Malcolm
On Thu, 2017-03-30 at 22:28 +0200, Florian Weimer wrote:
> * David Malcolm:
> 
> > Here's a work-in-progress implementation of the idea, adding this
> > entrypoint to the API:
> > 
> >   extern gcc_jit_type *
> >   gcc_jit_type_get_aligned (gcc_jit_type *type,
> > unsigned int alignment_in_bytes);
> 
> Should be size_t, not unsigned int.  A 2**31 alignment isn't as
> ridiculous as it might seem.  x86-64 already has a 2**30 alignment
> requirement in some contexts.

Thanks; fixed in this version.

Here's a completed version of the patch.

It also implements the missing C++ binding
gccjit::type::get_const, needed by a test case.

Successfully bootstrapped on x86_64-pc-linux-gnu.
Takes jit.sum from 8609 to 9349 PASS results.

Release managers: is it acceptable to commit this to trunk in
stage 4?  It purely touches jit-related code/testcases, but I
appreciate it's very late to be adding features.

Otherwise I'll commit it in the next stage 1.

gcc/jit/ChangeLog:
* docs/cp/topics/types.rst (gccjit::type::get_const): Remove
comment.
(gccjit::type::get_aligned): Add.
* docs/topics/compatibility.rst: Add LIBGCCJIT_ABI_7.
* docs/topics/types.rst: Add gcc_jit_type_get_aligned.
* jit-playback.c (gcc::jit::playback::type::get_aligned): New
method.
* jit-playback.h (gcc::jit::playback::type::get_aligned): New
method.
* jit-recording.c: Within namespace gcc::jit::recording...
(type::get_aligned): New method.
(memento_of_get_aligned::replay_into): New method.
(memento_of_get_aligned::make_debug_string): New method.
(memento_of_get_aligned::write_reproducer): New method.
* jit-recording.h: Within namespace gcc::jit::recording...
(type::get_aligned): New method.
(type::accepts_writes_from): Strip off qualifications from
this when comparing pointer equality.
(decorated_type): New subclass of type, subsuming the
commonality between memento_of_get_const and
memento_of_get_volatile.
(memento_of_get_const): Make a subclass of decorated_type,
rather than type.
(memento_of_get_volatile): Likewise.
(memento_of_get_aligned): Likewise.
* libgccjit++.h: Within namespace gccjit...
(type::get_const): New method.
(type::get_aligned): New method.
* libgccjit.c (gcc_jit_type_get_aligned): New function.
* libgccjit.h (gcc_jit_type_get_aligned): New decl.
* libgccjit.map (LIBGCCJIT_ABI_7): New
(gcc_jit_type_get_aligned): Add.

gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Add test-alignment.c.
* jit.dg/test-alignment.c: New test case.
* jit.dg/test-alignment.cc: New test case.
* jit.dg/test-error-gcc_jit_type_get_aligned-non-power-of-two.c:
New test case.
---
 gcc/jit/docs/cp/topics/types.rst   |  12 +-
 gcc/jit/docs/topics/compatibility.rst  |   7 +
 gcc/jit/docs/topics/types.rst  |  19 ++
 gcc/jit/jit-playback.c |  15 ++
 gcc/jit/jit-playback.h |   2 +
 gcc/jit/jit-recording.c|  52 +
 gcc/jit/jit-recording.h|  68 +++---
 gcc/jit/libgccjit++.h  |  15 ++
 gcc/jit/libgccjit.c|  24 +++
 gcc/jit/libgccjit.h|  16 ++
 gcc/jit/libgccjit.map  |   5 +
 gcc/testsuite/jit.dg/all-non-failing-tests.h   |  10 +
 gcc/testsuite/jit.dg/test-alignment.c  | 232 +
 gcc/testsuite/jit.dg/test-alignment.cc | 176 
 ...ror-gcc_jit_type_get_aligned-non-power-of-two.c |  30 +++
 15 files changed, 657 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-alignment.c
 create mode 100644 gcc/testsuite/jit.dg/test-alignment.cc
 create mode 100644 
gcc/testsuite/jit.dg/test-error-gcc_jit_type_get_aligned-non-power-of-two.c

diff --git a/gcc/jit/docs/cp/topics/types.rst b/gcc/jit/docs/cp/topics/types.rst
index 453f1d3..e85a492 100644
--- a/gcc/jit/docs/cp/topics/types.rst
+++ b/gcc/jit/docs/cp/topics/types.rst
@@ -82,8 +82,6 @@ Pointers, `const`, and `volatile`
 
Given type "T", get type "T*".
 
-.. FIXME: get_const doesn't seem to exist
-
 .. function::  gccjit::type gccjit::type::get_const ()
 
Given type "T", get type "const T".
@@ -92,6 +90,16 @@ Pointers, `const`, and `volatile`
 
Given type "T", get type "volatile T".
 
+.. function::  gccjit::type gccjit::type::get_aligned (size_t 
alignment_in_bytes)
+
+   Given type "T", get type:
+
+   .. code-block:: c
+
+  T __attribute__ ((aligned (ALIGNMENT_IN_BYTES)))
+
+   The alignment must be a power of two.
+
 .. function::  gccjit::type \
gccjit::context::new_array_type (gccjit::type 

[gomp4] fix an ICE involving derived-typed subarray

2017-03-31 Thread Cesar Philippidis
I'll apply this patch to gomp-4_0-branch shortly which fixes an ICE
triggered by using data clauses with derived-type subarray arguments.
Such subarrays can be handled generically.

Cesar
2017-03-31  Cesar Philippidis  

	gcc/fortran/
	* trans-openmp.c (gfc_trans_omp_clauses_1): Update handling of
	subarrays with derived types elements.

	libgomp/
	* testsuite/libgomp.oacc-fortran/derived-type-1.f90: New test.


diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index f3e1773..1d4a15b 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -2064,7 +2064,9 @@ gfc_trans_omp_clauses_1 (stmtblock_t *block, gfc_omp_clauses *clauses,
 		  && (n->expr->ref->next == NULL
 		  || (n->expr->ref->next != NULL
 			  && n->expr->ref->next->type == REF_ARRAY
-			  && n->expr->ref->next->u.ar.type == AR_FULL)))
+			  && n->expr->ref->next->u.ar.type == AR_FULL))
+		  && (n->expr->ref->type == REF_ARRAY
+		  && n->expr->ref->u.ar.type != AR_SECTION))
 		{
 		  gfc_ref *ref = n->expr->ref;
 		  gfc_component *c = ref->u.c.component;
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/derived-type-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/derived-type-1.f90
new file mode 100644
index 000..19b25fc
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/derived-type-1.f90
@@ -0,0 +1,26 @@
+! Test derived types with subarrays
+
+  implicit none
+  type dtype
+ integer :: a, b, c
+  end type dtype
+  integer, parameter :: n = 100
+  integer i
+  type (dtype), dimension(n) :: d
+
+  !$acc data copy(d(1:n))
+  !$acc parallel loop
+  do i = 1, n
+ d(i)%a = i
+ d(i)%b = i-1
+ d(i)%c = i+1
+  end do
+  !$acc end data
+
+  do i = 1, n
+ if (d(i)%a /= i) call abort
+ if (d(i)%b /= i-1) call abort
+ if (d(i)%c /= i+1) call abort
+  end do
+end program
+  


Re: [PATCH] Fix description of Wendif-labels (PR documentation/78732)

2017-03-31 Thread Martin Sebor

On 03/31/2017 09:06 AM, David Malcolm wrote:

As noted in the PR, c.opt's description of -Wendif-labels erroneously
refers to #elif, rather than #else.

warn_endif_labels is used by:
  libcpp/directives.c: do_else
  libcpp/directives.c: do_endif
in which they use it to guard calls to check_eol_endif_labels.

It's not used by do_elif.


Presumably it should to have GCC warn on the extra tokens after
the constant expression in the #elif directive just as warns about
those after the #else:

  #if 1
  #elif 1 foo bar
  #else if 1 foobar
  #endif baz
  a.c:3:7: warning: extra tokens at end of #else directive [-Wendif-labels]
   #else if 1 foobar
 ^~
  a.c:4:8: warning: extra tokens at end of #endif directive 
[-Wendif-labels]

   #endif baz
  ^~~
  a.c:4:0: warning: ISO C forbids an empty translation unit [-Wpedantic]
 #endif baz

Martin



doc/cppwarnopts.texi gets this right:


Do not warn whenever an @code{#else} or an @code{#endif} are followed by text.
This sometimes happens in older programs with code of the form


This patch fixes the description in c.opt.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as obvious (r246616).

gcc/c-family/ChangeLog:
PR documentation/78732
* c.opt (Wendif-labels): Fix description to refer to
#else rather than #elif.
---
 gcc/c-family/c.opt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 78fea61..13b930d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -486,7 +486,7 @@ Warn about an empty body in an if or else statement.

 Wendif-labels
 C ObjC C++ ObjC++ CPP(warn_endif_labels) CppReason(CPP_W_ENDIF_LABELS) 
Var(cpp_warn_endif_labels) Init(1) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wpedantic)
-Warn about stray tokens after #elif and #endif.
+Warn about stray tokens after #else and #endif.

 Wenum-compare
 C ObjC C++ ObjC++ Var(warn_enum_compare) Init(-1) Warning LangEnabledBy(C 
ObjC,Wall || Wc++-compat)





[patch, MIPS] Update -mvirt option description

2017-03-31 Thread Matthew Fortune
Hi Catherine,

I'm following up on PR target/80057 to update the description of -mvirt.

I agree with Roland that the description is inconsistent and should not
state 'application specific' as none of the other ASE options include
it. Instead I suggest we put the shortened form of (VZ) in like (XPA)
is shown for -mxpa. The short form of virtualization ASE is usually VZ
not VIRT which has always irritated me about this option name but that
is history.

What do you think?

gcc/
PR target/80057
* config/mips/mips.opt (-mvirt): Update description.

Thanks,
Matthew

diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index 7c4b607..ced2432 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -406,7 +406,7 @@ Put uninitialized constants in ROM (needs -membedded-data).
 
 mvirt
 Target Report Var(TARGET_VIRT)
-Use Virtualization Application Specific instructions.
+Use Virtualization (VZ) instructions.
 
 mxpa
 Target Report Var(TARGET_XPA)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8d3821e..19a85b6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -19345,7 +19345,7 @@ Use (do not use) the MIPS Enhanced Virtual Addressing 
instructions.
 @itemx -mno-virt
 @opindex mvirt
 @opindex mno-virt
-Use (do not use) the MIPS Virtualization Application Specific instructions.
+Use (do not use) the MIPS Virtualization (VZ) instructions.
 
 @item -mxpa
 @itemx -mno-xpa
-- 
2.2.1



Re: Fix ICE with -fauto-profile when walking vdefs

2017-03-31 Thread Richard Biener
On March 31, 2017 8:10:51 PM GMT+02:00, Sebastian Pop  wrote:
>On Fri, Mar 31, 2017 at 12:06 PM, Richard Biener 
>wrote:
>> That's not a default definition but bogus SSA form.  You have to fix
>that, not this symptom.
>>
>
>Ok.
>It also crashes when adding a call to verifty_ssa
>
>diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
>index 4b21340c6f0..b834a40af4d 100644
>--- a/gcc/auto-profile.c
>+++ b/gcc/auto-profile.c
>@@ -1589,6 +1590,7 @@ afdo_annotate_cfg (const stmt_set
>_stmts)
> static void
> early_inline ()
> {
>+  verify_ssa (true, true);
>compute_inline_parameters (cgraph_node::get (current_function_decl),
>true);
>   unsigned todo = early_inliner (cfun);
>   if (todo & TODO_update_ssa_any)
>
>The crash is on:
>
>  gcc_assert (!need_ssa_update_p (cfun));
>
>and after adding a call to update the SSA, it finishes compilation
>without errors.
>I am testing the following patch:

That looks like a workaround rather than the correct fix.  Who sets .MEM? It 
should assign the proper def.

OTOH I don't know why there's any inlining code in auto-profile.

Richard.

>* auto-profile.c (early_inline): Call update_ssa.
>
>--- a/gcc/auto-profile.c
>+++ b/gcc/auto-profile.c
>@@ -1589,6 +1589,8 @@ afdo_annotate_cfg (const stmt_set
>_stmts)
> static void
> early_inline ()
> {
>+  if (need_ssa_update_p (current_function_decl))
>+update_ssa (TODO_update_ssa);
>compute_inline_parameters (cgraph_node::get (current_function_decl),
>true);
>   unsigned todo = early_inliner (cfun);
>   if (todo & TODO_update_ssa_any)



Re: Patch ping

2017-03-31 Thread Jakub Jelinek
On Fri, Mar 31, 2017 at 09:07:14AM -0600, Jeff Law wrote:
> On 03/31/2017 12:36 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping two patches:
> > 
> > PR c++/79572
> >   - ubsan instrumentation of reference binding to NULL if the reference
> > is folded into INTEGER_CST with REFERENCE_TYPE
> > http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html
> Just one question here -- we're working with pure trees or perhaps generic,
> not gimple here, right?  Assuming that is true, this is OK.

It is invoked during genericization, i.e. when the C++ FE trees are lowered
into generic.

Jakub


Re: Fix ICE with -fauto-profile when walking vdefs

2017-03-31 Thread Sebastian Pop
On Fri, Mar 31, 2017 at 12:06 PM, Richard Biener  wrote:
> That's not a default definition but bogus SSA form.  You have to fix that, 
> not this symptom.
>

Ok.
It also crashes when adding a call to verifty_ssa

diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
index 4b21340c6f0..b834a40af4d 100644
--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -1589,6 +1590,7 @@ afdo_annotate_cfg (const stmt_set _stmts)
 static void
 early_inline ()
 {
+  verify_ssa (true, true);
   compute_inline_parameters (cgraph_node::get (current_function_decl), true);
   unsigned todo = early_inliner (cfun);
   if (todo & TODO_update_ssa_any)

The crash is on:

  gcc_assert (!need_ssa_update_p (cfun));

and after adding a call to update the SSA, it finishes compilation
without errors.
I am testing the following patch:

* auto-profile.c (early_inline): Call update_ssa.

--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -1589,6 +1589,8 @@ afdo_annotate_cfg (const stmt_set _stmts)
 static void
 early_inline ()
 {
+  if (need_ssa_update_p (current_function_decl))
+update_ssa (TODO_update_ssa);
   compute_inline_parameters (cgraph_node::get (current_function_decl), true);
   unsigned todo = early_inliner (cfun);
   if (todo & TODO_update_ssa_any)


Re: [PATCH, GCC/LTO, ping2] Fix PR69866: LTO with def for weak alias in regular object file

2017-03-31 Thread Richard Biener
On March 31, 2017 5:23:03 PM GMT+02:00, Jeff Law  wrote:
>On 03/16/2017 08:05 AM, Thomas Preudhomme wrote:
>> Ping?
>>
>> Is this ok for stage4?
>Given the lack of response from Richi, I'd suggest deferring to stage1.

Honza needs to review this, i habe too little knowledge here.

Richard.

>jeff



Re: Fix ICE with -fauto-profile when walking vdefs

2017-03-31 Thread Richard Biener
On March 31, 2017 6:04:32 PM GMT+02:00, Sebastian Pop  wrote:
>Hi,
>
>with trunk gcc as of today and gcc releases 6.* and 5.*,
>I get an ICE when compiling a large c++ project with autoFDO
>at -O1 and above with -fauto-profile=some.gcov
>
>internal compiler error: tree check: expected ssa_name, have var_decl
>in walk_aliased_vdefs_1, at tree-ssa-alias.c:2912
>0x1072fec tree_check_failed(tree_node const*, char const*, int, char
>const*, ...)
>../../gcc/tree.c:9819
>0xed6ad9 tree_check(tree_node*, char const*, int, char const*,
>tree_code)
>../../gcc/tree.h:3064
>0xed6ad9 walk_aliased_vdefs_1
>../../gcc/tree-ssa-alias.c:2912
>0xed6b61 walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*,
>tree_node*, void*), void*, bitmap_head**, bool*, unsigned int)
>../../gcc/tree-ssa-alias.c:2972
>0xbe97f0 parm_ref_data_preserved_p
>../../gcc/ipa-prop.c:1015
>0xbe97f0 ipa_load_from_parm_agg(ipa_func_body_info*,
>vec*, gimple*, tree_node*,
>int*, long*, long*, bool*, bool*)
>../../gcc/ipa-prop.c:1138
>0xbd3213 unmodified_parm_or_parm_agg_item
>../../gcc/ipa-inline-analysis.c:1626
>0xbd4d05 set_cond_stmt_execution_predicate
>../../gcc/ipa-inline-analysis.c:1789
>0xbd4d05 compute_bb_predicates
>../../gcc/ipa-inline-analysis.c:1925
>0xbdb140 estimate_function_body_sizes
>../../gcc/ipa-inline-analysis.c:2603
>0xbdfcce compute_inline_parameters(cgraph_node*, bool)
>../../gcc/ipa-inline-analysis.c:3048
>0x1446ce8 early_inline
>../../gcc/auto-profile.c:1592
>0x1449aac auto_profile
>../../gcc/auto-profile.c:1656
>
>The patch below fixes the ICE by checking that the vdef is an SSA_NAME
>before trying to walk to a def stmt.  At that point I see that the
>vdef is a var_decl:
>
>(gdb) p vdef
>$1 = (tree) 0x7fffda143750
>(gdb) pt
>warning: Expression is not an assignment (and might have no effect)
> type align 8 symtab 0 alias set -1 canonical type 0x765d4f18
>pointer_to_this >
>used static ignored external VOID file  line 0 col 0
>align 8>
>(gdb) pgs
>warning: Expression is not an assignment (and might have no effect)
>.MEM
>
>vdef comes from two frames above as gimple_vuse (stmt) in:
>
>int walked = walk_aliased_vdefs (, gimple_vuse (stmt),
>mark_modified,
>  , NULL);
>
>(gdb) p stmt
>$2 = (gimple *) 0x7fffd77d4730
>(gdb) pgg
># VUSE <.MEM>
>_66 = this_13(D)->s_;
>
>The reason why I have left the check in the do-while loop
>is because vdef is updated at the bottom of the loop as:
>
>  vdef = gimple_vuse (def_stmt);
>
>and that may again find a default definition vdef
>that is not pointing to another statement defining it.

That's not a default definition but bogus SSA form.  You have to fix that, not 
this symptom.

Richard.

>
>The patch passed bootstrap and regression test on x86_64-linux.
>Ok for trunk and other release branches?
>
>Thanks,
>Sebastian
>
>* tree-ssa-alias.c (walk_aliased_vdefs_1): Handle default virtual defs.
>
>diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
>index 3f0c650475d..5a66306610f 100644
>--- a/gcc/tree-ssa-alias.c
>+++ b/gcc/tree-ssa-alias.c
>@@ -2909,6 +2909,10 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree vdef,
> {
>   do
> {
>+  /* Before asking for a statement, check that it is an SSA_NAME. 
>*/
>+  if (TREE_CODE(vdef) != SSA_NAME)
>+   return cnt;
>+
>   gimple *def_stmt = SSA_NAME_DEF_STMT (vdef);
>
>   if (*visited



[committed] nvptx: correct -Wformat issue

2017-03-31 Thread Alexander Monakov
Hello,

I've applied the following patch as obvious to fix the -Wformat issue pointed
out by Thomas Schwinge.

* config/nvptx/nvptx.c (nvptx_output_softstack_switch): Correct format
string.

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 83f4610..4c35c16 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -1353,7 +1353,8 @@ nvptx_output_softstack_switch (FILE *file, bool entering,
output_reg (file, REGNO (size), VOIDmode);
   fputs (";\n", file);
   if (!CONST_INT_P (size) || UINTVAL (align) > GET_MODE_SIZE (DImode))
-   fprintf (file, "\t\tand.u%d %%r%d, %%r%d, -%d;\n",
+   fprintf (file,
+"\t\tand.u%d %%r%d, %%r%d, -" HOST_WIDE_INT_PRINT_DEC ";\n",
 bits, regno, regno, UINTVAL (align));
 }
   if (cfun->machine->has_softstack)


[PATCH] Fix spelling suggestions for reserved words (PR c++/80177)

2017-03-31 Thread David Malcolm
As noted in the PR, the C++ frontend currently offers a poor
suggestion for this misspelling:

a.C: In function ???void f()???:
a.C:3:3: error: ???static_assertion??? was not declared in this scope
   static_assertion (1 == 0, "1 == 0");
   ^~~~
a.C:3:3: note: suggested alternative: ???__cpp_static_assert???
   static_assertion (1 == 0, "1 == 0");
   ^~~~
   __cpp_static_assert

when it ought to offer "static_assert" as a suggestion instead.

The root causes are two issues within lookup_name_fuzzy
(called here with FUZZY_LOOKUP_NAME):

(a) If it finds a good enough match in the preprocessor it will
return the best match *before* considering reserved words,
rather than picking the closest match overall.

The fix is to have merge all the results into one best_match
instance, and pick the overall winner.  However, given that
some candidates are identifiers (trees), and others are cpp
macros, the best_match instance's candidate type needs to
be converted from tree to const char *.  This has some minor
knock-on effects within name-lookup.c.  Sadly it means some
extra calls to strlen (one per candidate), but this will be
purely when error-handling.

(b) It rejects "static_assert" here:

  4998if (!cp_keyword_starts_decl_specifier_p (resword->rid))
  4999  continue;

as "static_assert" doesn't start a decl specifier.

The fix is to only apply this rejection criterion if we're looking
for typenames, rather than for names in general.

This patch addresses both issues and adds test coverage.

Successfully bootstrapped on x86_64-pc-linux-gnu.
Adds 7 PASS and 1 UNSUPPORTED (for -std=c++98) to g++.sum

OK for next stage 1?

gcc/cp/ChangeLog:
PR c++/80177
* name-lookup.c (suggest_alternative_in_explicit_scope): Convert
candidate type of bm from tree to const char *.
(consider_binding_level): Likewise.
(lookup_name_fuzzy): Likewise, using this to merge the best
result from the preprocessor into bm, rather than immediately
returning, so that better matches from reserved words can "win".
Guard the rejection of keywords that don't start decl-specifiers
so it only happens for FUZZY_LOOKUP_TYPENAME.

gcc/testsuite/ChangeLog:
PR c++/80177
* g++.dg/spellcheck-pr80177.C: New test case.
---
 gcc/cp/name-lookup.c  | 37 +--
 gcc/testsuite/g++.dg/spellcheck-pr80177.C |  7 ++
 2 files changed, 23 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/spellcheck-pr80177.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 994f7f0..16ec0a1 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -48,7 +48,8 @@ static bool lookup_using_namespace (tree, struct 
scope_binding *, tree,
tree, int);
 static bool qualified_lookup_using_namespace (tree, tree,
  struct scope_binding *, int);
-static void consider_binding_level (tree name, best_match  ,
+static void consider_binding_level (tree name,
+   best_match  ,
cp_binding_level *lvl,
bool look_within_fields,
enum lookup_name_fuzzy_kind kind);
@@ -4550,14 +4551,13 @@ suggest_alternative_in_explicit_scope (location_t 
location, tree name,
 
   cp_binding_level *level = NAMESPACE_LEVEL (scope);
 
-  best_match  bm (name);
+  best_match  bm (name);
   consider_binding_level (name, bm, level, false, FUZZY_LOOKUP_NAME);
 
   /* See if we have a good suggesion for the user.  */
-  tree best_id = bm.get_best_meaningful_candidate ();
-  if (best_id)
+  const char *fuzzy_name = bm.get_best_meaningful_candidate ();
+  if (fuzzy_name)
 {
-  const char *fuzzy_name = IDENTIFIER_POINTER (best_id);
   gcc_rich_location richloc (location);
   richloc.add_fixit_replace (fuzzy_name);
   inform_at_rich_loc (, "suggested alternative: %qs",
@@ -4797,7 +4797,7 @@ qualified_lookup_using_namespace (tree name, tree scope,
Traverse binding level LVL, looking for good name matches for NAME
(and BM).  */
 static void
-consider_binding_level (tree name, best_match  ,
+consider_binding_level (tree name, best_match  ,
cp_binding_level *lvl, bool look_within_fields,
enum lookup_name_fuzzy_kind kind)
 {
@@ -4809,7 +4809,7 @@ consider_binding_level (tree name, best_match  ,
tree best_matching_field
  = lookup_member_fuzzy (type, name, want_type_p);
if (best_matching_field)
- bm.consider (best_matching_field);
+ bm.consider (IDENTIFIER_POINTER (best_matching_field));
   }
 
   for (tree t = lvl->names; t; t = 

Fix ICE with -fauto-profile when walking vdefs

2017-03-31 Thread Sebastian Pop
Hi,

with trunk gcc as of today and gcc releases 6.* and 5.*,
I get an ICE when compiling a large c++ project with autoFDO
at -O1 and above with -fauto-profile=some.gcov

internal compiler error: tree check: expected ssa_name, have var_decl
in walk_aliased_vdefs_1, at tree-ssa-alias.c:2912
0x1072fec tree_check_failed(tree_node const*, char const*, int, char
const*, ...)
../../gcc/tree.c:9819
0xed6ad9 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3064
0xed6ad9 walk_aliased_vdefs_1
../../gcc/tree-ssa-alias.c:2912
0xed6b61 walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*,
tree_node*, void*), void*, bitmap_head**, bool*, unsigned int)
../../gcc/tree-ssa-alias.c:2972
0xbe97f0 parm_ref_data_preserved_p
../../gcc/ipa-prop.c:1015
0xbe97f0 ipa_load_from_parm_agg(ipa_func_body_info*,
vec*, gimple*, tree_node*,
int*, long*, long*, bool*, bool*)
../../gcc/ipa-prop.c:1138
0xbd3213 unmodified_parm_or_parm_agg_item
../../gcc/ipa-inline-analysis.c:1626
0xbd4d05 set_cond_stmt_execution_predicate
../../gcc/ipa-inline-analysis.c:1789
0xbd4d05 compute_bb_predicates
../../gcc/ipa-inline-analysis.c:1925
0xbdb140 estimate_function_body_sizes
../../gcc/ipa-inline-analysis.c:2603
0xbdfcce compute_inline_parameters(cgraph_node*, bool)
../../gcc/ipa-inline-analysis.c:3048
0x1446ce8 early_inline
../../gcc/auto-profile.c:1592
0x1449aac auto_profile
../../gcc/auto-profile.c:1656

The patch below fixes the ICE by checking that the vdef is an SSA_NAME
before trying to walk to a def stmt.  At that point I see that the
vdef is a var_decl:

(gdb) p vdef
$1 = (tree) 0x7fffda143750
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 >
used static ignored external VOID file  line 0 col 0
align 8>
(gdb) pgs
warning: Expression is not an assignment (and might have no effect)
.MEM

vdef comes from two frames above as gimple_vuse (stmt) in:

  int walked = walk_aliased_vdefs (, gimple_vuse (stmt), mark_modified,
  , NULL);

(gdb) p stmt
$2 = (gimple *) 0x7fffd77d4730
(gdb) pgg
# VUSE <.MEM>
_66 = this_13(D)->s_;

The reason why I have left the check in the do-while loop
is because vdef is updated at the bottom of the loop as:

  vdef = gimple_vuse (def_stmt);

and that may again find a default definition vdef
that is not pointing to another statement defining it.

The patch passed bootstrap and regression test on x86_64-linux.
Ok for trunk and other release branches?

Thanks,
Sebastian

* tree-ssa-alias.c (walk_aliased_vdefs_1): Handle default virtual defs.

diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index 3f0c650475d..5a66306610f 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -2909,6 +2909,10 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree vdef,
 {
   do
 {
+  /* Before asking for a statement, check that it is an SSA_NAME.  */
+  if (TREE_CODE(vdef) != SSA_NAME)
+   return cnt;
+
   gimple *def_stmt = SSA_NAME_DEF_STMT (vdef);

   if (*visited


Re: [PATCH 2/5] omp-low: implement SIMT privatization, part 1

2017-03-31 Thread Alexander Monakov
Hello Jakub,

I've noticed while re-reading that this patch incorrectly handled SIMT case
in lower_lastprivate_clauses.  The code was changed to look for variables
with "omp simt private" attribute, and was left under
'simduid && DECL_HAS_VALUE_EXPR_P (new_var)' condition.  This effectively
constrained processing to privatized (i.e. addressable) variables, as
non-addressable variables now have neither the value-expr nor the attribute.

This wasn't caught in testing, as apparently all testcases that have target
simd loops with linear/lastprivate clauses also have the corresponding variables
mentioned in target map clause, which makes them addressable (is that 
necessary?),
and I didn't think to check something like that manually.

The following patch fixes it by adjusting the if's in lower_lastprivate_clauses;
alternatively it may be possible to keep that code as-is, and instead set up
value-expr and "omp simt private" attributes for all formally private variables,
not just addressable ones, but to me that sounds less preferable.  OK for trunk?

I think it's possible to improve test coverage for NVPTX by running all OpenMP
testcases via nvptx-none-run (it'll need some changes, but shouldn't be hard).

gcc/
* omp-low.c (lower_lastprivate_clauses): Correct handling of linear and
lastprivate clauses in SIMT case.

libgomp/
* testsuite/libgomp.c/target-36.c: New testcase.

Thanks.
Alexander

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 253dc85..02b681c 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -4768,11 +4768,10 @@ lower_lastprivate_clauses (tree clauses, tree 
predicate, gimple_seq *stmt_list,
TREE_NO_WARNING (new_var) = 1;
}
 
- if (simduid && DECL_HAS_VALUE_EXPR_P (new_var))
+ if (!maybe_simt && simduid && DECL_HAS_VALUE_EXPR_P (new_var))
{
  tree val = DECL_VALUE_EXPR (new_var);
- if (!maybe_simt
- && TREE_CODE (val) == ARRAY_REF
+ if (TREE_CODE (val) == ARRAY_REF
  && VAR_P (TREE_OPERAND (val, 0))
  && lookup_attribute ("omp simd array",
   DECL_ATTRIBUTES (TREE_OPERAND (val,
@@ -4792,26 +4791,26 @@ lower_lastprivate_clauses (tree clauses, tree 
predicate, gimple_seq *stmt_list,
TREE_OPERAND (val, 0), lastlane,
NULL_TREE, NULL_TREE);
}
- else if (maybe_simt
-  && VAR_P (val)
-  && lookup_attribute ("omp simt private",
-   DECL_ATTRIBUTES (val)))
+   }
+ else if (maybe_simt)
+   {
+ tree val = (DECL_HAS_VALUE_EXPR_P (new_var)
+ ? DECL_VALUE_EXPR (new_var)
+ : new_var);
+ if (simtlast == NULL)
{
- if (simtlast == NULL)
-   {
- simtlast = create_tmp_var (unsigned_type_node);
- gcall *g = gimple_build_call_internal
-   (IFN_GOMP_SIMT_LAST_LANE, 1, simtcond);
- gimple_call_set_lhs (g, simtlast);
- gimple_seq_add_stmt (stmt_list, g);
-   }
- x = build_call_expr_internal_loc
-   (UNKNOWN_LOCATION, IFN_GOMP_SIMT_XCHG_IDX,
-TREE_TYPE (val), 2, val, simtlast);
- new_var = unshare_expr (new_var);
- gimplify_assign (new_var, x, stmt_list);
- new_var = unshare_expr (new_var);
+ simtlast = create_tmp_var (unsigned_type_node);
+ gcall *g = gimple_build_call_internal
+   (IFN_GOMP_SIMT_LAST_LANE, 1, simtcond);
+ gimple_call_set_lhs (g, simtlast);
+ gimple_seq_add_stmt (stmt_list, g);
}
+ x = build_call_expr_internal_loc
+   (UNKNOWN_LOCATION, IFN_GOMP_SIMT_XCHG_IDX,
+TREE_TYPE (val), 2, val, simtlast);
+ new_var = unshare_expr (new_var);
+ gimplify_assign (new_var, x, stmt_list);
+ new_var = unshare_expr (new_var);
}
 
  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_LASTPRIVATE
diff --git a/libgomp/testsuite/libgomp.c/target-36.c 
b/libgomp/testsuite/libgomp.c/target-36.c
new file mode 100644
index 000..6925a2a
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/target-36.c
@@ -0,0 +1,18 @@
+int
+main ()
+{
+  int ah, bh, n = 1024;
+#pragma omp target map(from: ah, bh)
+  {
+int a, b;
+#pragma omp simd lastprivate(b)
+for (a = 0; a < n; a++)
+  {
+   b = a + n + 1;
+   asm volatile ("" : "+r"(b));
+  }
+ah = a, bh = b;
+  }
+  if (ah != n || bh != 2 * n)
+__builtin_abort ();
+}


Re: [PATCH rs6000] Fix PR target/80107, ICE in final_scan_insn

2017-03-31 Thread Segher Boessenkool
On Fri, Mar 31, 2017 at 10:25:00AM -0500, Pat Haugen wrote:
> float2_internal uses gen_extendhidi2 on a VSX
> register but extendhidi2 only supports GPRs if -mno-gen-cell-microcode
> is in effect. Fixed by adding a check of TARGET_VSX_SMALL_INTEGER.

Yuck :-)

> Bootstrap/regtest on powerpc64le-linux with no regressions, ok for
> trunk? The -mvsx-small-integer option/code was introduced in GCC 7 so no
> need for backport.

With this line removed:
> +! { dg-prune-output "-mno-gen-cell-microcode requires -mcpu=cell" }

Okay, thanks!


Segher


[PATCH] [PR tree-optimization/49498] Re-enable DOM for uninit-pred-8_b.c

2017-03-31 Thread Jeff Law


As discussed in the BZ, this bug was fixed long ago and we should 
re-enable DOM opts for this test.


Tested on cris-elf.  Installing on the trunk.

Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index dce1278..6e53829 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2017-03-31  Jeff Law  
+
+   PR tree-optimization/49498
+   * gcc.dg/uninit-pred-8_b.c: Reenable DOM.
+
 2017-03-31  Richard Biener  
  
* gcc.dg/tree-ssa/pr71347.c: Put back XFAIL on sparc.
diff --git a/gcc/testsuite/gcc.dg/uninit-pred-8_b.c 
b/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
index c1cc1f0..06e2eba 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
@@ -1,6 +1,6 @@
 
 /* { dg-do compile } */
-/* { dg-options "-Wuninitialized -fno-tree-dominator-opts -O2" } */
+/* { dg-options "-Wuninitialized -O2" } */
 
 int g;
 void bar();


[PATCH rs6000] Fix PR target/80107, ICE in final_scan_insn

2017-03-31 Thread Pat Haugen
float2_internal uses gen_extendhidi2 on a VSX
register but extendhidi2 only supports GPRs if -mno-gen-cell-microcode
is in effect. Fixed by adding a check of TARGET_VSX_SMALL_INTEGER.

Bootstrap/regtest on powerpc64le-linux with no regressions, ok for
trunk? The -mvsx-small-integer option/code was introduced in GCC 7 so no
need for backport.

-Pat


2017-03-31  Pat Haugen  

PR target/80107
* config/rs6000/rs6000.md (extendhi2): Add test for
TARGET_VSX_SMALL_INTEGER.

testsuite/ChangeLog:
2017-03-31  Pat Haugen  

* gfortran.dg/pr80107.f: New.


Index: config/rs6000/rs6000.md
===
--- config/rs6000/rs6000.md (revision 246534)
+++ config/rs6000/rs6000.md (working copy)
@@ -954,7 +954,7 @@ (define_expand "extendhi2"
 (define_insn "*extendhi2"
   [(set (match_operand:EXTHI 0 "gpc_reg_operand" "=r,r,?*wK,?*wK")
(sign_extend:EXTHI (match_operand:HI 1 "reg_or_mem_operand" 
"m,r,Z,wK")))]
-  "rs6000_gen_cell_microcode"
+  "rs6000_gen_cell_microcode || TARGET_VSX_SMALL_INTEGER"
   "@
lha%U1%X1 %0,%1
extsh %0,%1
Index: testsuite/gfortran.dg/pr80107.f
===
--- testsuite/gfortran.dg/pr80107.f (nonexistent)
+++ testsuite/gfortran.dg/pr80107.f (working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile { target { powerpc*-*-* } } }
+! { dg-options "-O0 -mpower9-dform-vector -mno-gen-cell-microcode" }
+
+  integer(kind=2) j, j2, ja
+  call c_c(CMPLX(j),(1.,0.),'CMPLX(integer(2))')
+  end
+! { dg-prune-output "-mno-gen-cell-microcode requires -mcpu=cell" }



Re: [PATCH, GCC/LTO, ping2] Fix PR69866: LTO with def for weak alias in regular object file

2017-03-31 Thread Jeff Law

On 03/16/2017 08:05 AM, Thomas Preudhomme wrote:

Ping?

Is this ok for stage4?

Given the lack of response from Richi, I'd suggest deferring to stage1.

jeff



Re: [PATCH] Fix description of Wendif-labels (PR documentation/78732)

2017-03-31 Thread Jeff Law

On 03/31/2017 09:06 AM, David Malcolm wrote:

As noted in the PR, c.opt's description of -Wendif-labels erroneously
refers to #elif, rather than #else.

warn_endif_labels is used by:
  libcpp/directives.c: do_else
  libcpp/directives.c: do_endif
in which they use it to guard calls to check_eol_endif_labels.

It's not used by do_elif.

doc/cppwarnopts.texi gets this right:


Do not warn whenever an @code{#else} or an @code{#endif} are followed by text.
This sometimes happens in older programs with code of the form


This patch fixes the description in c.opt.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as obvious (r246616).

gcc/c-family/ChangeLog:
PR documentation/78732
* c.opt (Wendif-labels): Fix description to refer to
#else rather than #elif.

OK.
jeff



Re: Patch ping

2017-03-31 Thread Jeff Law

On 03/31/2017 12:36 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping two patches:

PR c++/79572
  - ubsan instrumentation of reference binding to NULL if the reference
is folded into INTEGER_CST with REFERENCE_TYPE
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html

PR debug/79255
  - dwarf2out profiledbootstrap ICE while building gnat;
either the posted patch
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01257.html
or in gen_decl_die:
   case FUNCTION_DECL:
+/* decl is NULL only if when processing a function declaration in
+   BLOCK_NONLOCALIZED_VARS.  It is a normal declaration, not an
+   abstract copy of something, so make sure we don't handle it
+   like function inlined into something.  */
+if (decl == NULL_TREE)
+  {
+   decl = origin;
+   origin = NULL_TREE;
+  }
or something else (another possibility is to replace all decl
uses in case FUNCTION_DECL with decl_or_origin and
- if (!origin)
-   origin = decl_class_context (decl);
+ if (!decl || !origin)
+   origin = decl_class_context (decl_or_origin);
I think I prefer your original approach -- pass in the original 
FUNCTION_DECL.  It seems to me like the other approaches are just 
papering over the issue.


Original approach is OK for the trunk.

jeff



Re: Patch ping

2017-03-31 Thread Jeff Law

On 03/31/2017 12:36 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping two patches:

PR c++/79572
  - ubsan instrumentation of reference binding to NULL if the reference
is folded into INTEGER_CST with REFERENCE_TYPE
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html
Just one question here -- we're working with pure trees or perhaps 
generic, not gimple here, right?  Assuming that is true, this is OK.


If instead we are working with gimple, then consider renaming "stmt" in 
ubsan_maybe_instrument_reference -- when I see "stmt" I think a gimple 
statement, not a tree:-)


jeff



Re: [PATCH, rs6000] Document location of ELF V2 ABI specification

2017-03-31 Thread Bill Schmidt
On Mar 29, 2017, at 5:36 PM, Segher Boessenkool  
wrote:
> 
> On Wed, Mar 29, 2017 at 04:27:28PM -0500, Bill Schmidt wrote:
>> There is finally a permanent link to the OpenPOWER ELF V2 ABI Specification
>> document.  This patch adds a paragraph to the PowerPC Built-Ins section of
>> the GCC documentation to describe its value and provide a link to it.
> 
> Woohoo!
> 
>> I've generated and verified the PDF, and it looks ok.  I am very open to
>> changes in wording.  Is this ok for trunk?
> 
> It's fine with me, but maybe Gerald (cc:ed) has some remarks?

OK, I've committed this as r246617.  Gerald, please let me know if you'd like
any changes to the text.
> 
> 
>> 2017-03-29  Bill Schmidt  
>> 
>>  * doc/extend.texi (6.60.22 PowerPC AltiVec Built-in Functions):
> 
> Section numbers are useless: they are not in thre source document, and
> they also change all the time.

Removed...

Thanks,
Bill



Remove unused "default_kind" member from gcc/omp-low.c's "struct omp_context"

2017-03-31 Thread Thomas Schwinge
Hi!

It would appear that ever since the first version of gcc/omp-low.c got
committed to GCC trunk (more than ten years ago), it extraced OpenMP
default clause data that it doesn't actually use for anything.  OK to
commit the following cleanup to trunk in next stage 1?

commit cd157ff348694009f4043b84f47de8c62774931f
Author: Thomas Schwinge 
Date:   Fri Mar 31 15:26:55 2017 +0200

Remove unused "default_kind" member from gcc/omp-low.c's "struct 
omp_context"

gcc/
* omp-low.c (struct omp_context): Remove "default_kind" member.
Adjust all users.
---
 gcc/omp-low.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git gcc/omp-low.c gcc/omp-low.c
index 253dc85..d794e00 100644
--- gcc/omp-low.c
+++ gcc/omp-low.c
@@ -112,10 +112,6 @@ struct omp_context
  otherwise.  */
   gimple *simt_stmt;
 
-  /* What to do with variables with implicitly determined sharing
- attributes.  */
-  enum omp_clause_default_kind default_kind;
-
   /* Nesting depth of this context.  Used to beautify error messages re
  invalid gotos.  The outermost ctx is depth 1, with depth 0 being
  reserved for the main body of the function.  */
@@ -1162,10 +1158,6 @@ scan_sharing_clauses (tree clauses, omp_context *ctx,
  install_var_field (decl, by_ref, 3, ctx);
  break;
 
-   case OMP_CLAUSE_DEFAULT:
- ctx->default_kind = OMP_CLAUSE_DEFAULT_KIND (c);
- break;
-
case OMP_CLAUSE_FINAL:
case OMP_CLAUSE_IF:
case OMP_CLAUSE_NUM_THREADS:
@@ -1332,6 +1324,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx,
case OMP_CLAUSE_SEQ:
case OMP_CLAUSE_TILE:
case OMP_CLAUSE__SIMT_:
+   case OMP_CLAUSE_DEFAULT:
  break;
 
case OMP_CLAUSE_ALIGNED:
@@ -1826,7 +1819,6 @@ scan_omp_parallel (gimple_stmt_iterator *gsi, omp_context 
*outer_ctx)
   if (taskreg_nesting_level > 1)
 ctx->is_nested = true;
   ctx->field_map = splay_tree_new (splay_tree_compare_pointers, 0, 0);
-  ctx->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
   ctx->record_type = lang_hooks.types.make_type (RECORD_TYPE);
   name = create_tmp_var_name (".omp_data_s");
   name = build_decl (gimple_location (stmt),
@@ -1873,7 +1865,6 @@ scan_omp_task (gimple_stmt_iterator *gsi, omp_context 
*outer_ctx)
   if (taskreg_nesting_level > 1)
 ctx->is_nested = true;
   ctx->field_map = splay_tree_new (splay_tree_compare_pointers, 0, 0);
-  ctx->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
   ctx->record_type = lang_hooks.types.make_type (RECORD_TYPE);
   name = create_tmp_var_name (".omp_data_s");
   name = build_decl (gimple_location (stmt),
@@ -2360,7 +2351,6 @@ scan_omp_target (gomp_target *stmt, omp_context 
*outer_ctx)
 
   ctx = new_omp_context (stmt, outer_ctx);
   ctx->field_map = splay_tree_new (splay_tree_compare_pointers, 0, 0);
-  ctx->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
   ctx->record_type = lang_hooks.types.make_type (RECORD_TYPE);
   name = create_tmp_var_name (".omp_data_t");
   name = build_decl (gimple_location (stmt),


Grüße
 Thomas


Re: [PATCH] Real fix for AIX exception handling

2017-03-31 Thread Jeff Law

On 03/30/2017 02:11 AM, Michael Haubenwallner wrote:


When statically linked, shouldn't collect2 add libstdc++'s EH frames to
the main executable's registration table again?
Or is libstdc++'s constructor called instead?
I would think the latter -- because libstdc++ is already linked into a 
DSO.  If libstdc++ was an archive library, then it would be the former.


Jeff


[PATCH] Fix description of Wendif-labels (PR documentation/78732)

2017-03-31 Thread David Malcolm
As noted in the PR, c.opt's description of -Wendif-labels erroneously
refers to #elif, rather than #else.

warn_endif_labels is used by:
  libcpp/directives.c: do_else
  libcpp/directives.c: do_endif
in which they use it to guard calls to check_eol_endif_labels.

It's not used by do_elif.

doc/cppwarnopts.texi gets this right:

> Do not warn whenever an @code{#else} or an @code{#endif} are followed by text.
> This sometimes happens in older programs with code of the form

This patch fixes the description in c.opt.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as obvious (r246616).

gcc/c-family/ChangeLog:
PR documentation/78732
* c.opt (Wendif-labels): Fix description to refer to
#else rather than #elif.
---
 gcc/c-family/c.opt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 78fea61..13b930d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -486,7 +486,7 @@ Warn about an empty body in an if or else statement.
 
 Wendif-labels
 C ObjC C++ ObjC++ CPP(warn_endif_labels) CppReason(CPP_W_ENDIF_LABELS) 
Var(cpp_warn_endif_labels) Init(1) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wpedantic)
-Warn about stray tokens after #elif and #endif.
+Warn about stray tokens after #else and #endif.
 
 Wenum-compare
 C ObjC C++ ObjC++ Var(warn_enum_compare) Init(-1) Warning LangEnabledBy(C 
ObjC,Wall || Wc++-compat)
-- 
1.8.5.3



Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Rainer Orth
Hi Bin,

> Here is the patch.  Test result checked on arm-none-eabi.  Is it OK?

it passes on sparc-sun-solaris2.12, too.

Thanks.
Rainer

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


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Bin.Cheng
On Fri, Mar 31, 2017 at 2:57 PM, Bin.Cheng  wrote:
> On Fri, Mar 31, 2017 at 11:37 AM, Richard Biener  wrote:
>> On Fri, 31 Mar 2017, Markus Trippelsdorf wrote:
>>
>>> On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
>>> > On Fri, 31 Mar 2017, Richard Biener wrote:
>>> >
>>> > > On Fri, 31 Mar 2017, Rainer Orth wrote:
>>> > >
>>> > > > Hi Christophe,
>>> > > >
>>> > > > > With this patch, the following testcase now fails on arm* targets:
>>> > > > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
>>> > > >
>>> > > > same on Solaris/SPARC.
>>> > >
>>> > > I've reverted r241968 with (patch reverted).  It doesn't include
>>> > > sparc, so please amend as you see fit.
>>> >
>>> > Ah, r241441.  I'll fixup myself then.
>>>
>>> It also fails on some X86 configurations:
>>> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00237.html
>>> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00238.html
>>
>> I see.  The test is somewhat strange (well, it's an IVOPTS test).  To
>> simulate the effect of the PRE changes we could simply enable
>> -fpredictive-commoning on it.
>>
>> Let's ask Bin what the testcase was supposed to test... (the testcase
>> comment suggests that pcom is applied but it certainly wasn't before
>> the xfails were removed).
>
> It's supposed to test that both loads inside loop can be optimized,
> X[i-1] by predcom or pre; X[1] by loop invariant.  When the test is
> added, neither pre nor predcom (not at O2) can do this, but we have
> another chance that pre + ivopts + dom together can eliminate X[i-1].
> But this really depends on each pass does the right thing.  That's
> also why it is added with ivopts change.  Back in time, it was ivopts
> did "wrong".  Apparently, having a test on different passes is
> fragile.  I will send a patch adding option "-fpredictive-commoning"
> because predcom seems the right pass to do that.  Also given we are
> considering enabling predcom at O2 for GCC 8.
Here is the patch.  Test result checked on arm-none-eabi.  Is it OK?

Thanks,
bin
gcc/testsuite/ChangeLog
2017-03-31  Bin Cheng  

* gcc.dg/tree-ssa/pr71347.c: Add predcom and drop XFAIL.

Thanks,
bin
Index: gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr71347.c (revision 246615)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr71347.c (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-options "-O2 -fdump-tree-optimized -fpredictive-commoning" } */
 
 double in;
 extern void Write (double);
@@ -14,4 +14,4 @@
 }
 
 /* Load of X[i - i] can be omitted by reusing X[i] in previous iteration.  */
-/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" { xfail { 
ia64-*-* arm*-*-* m68k*-*-* sparc*-*-* } } } } */
+/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" } } */


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Bin.Cheng
On Fri, Mar 31, 2017 at 11:37 AM, Richard Biener  wrote:
> On Fri, 31 Mar 2017, Markus Trippelsdorf wrote:
>
>> On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
>> > On Fri, 31 Mar 2017, Richard Biener wrote:
>> >
>> > > On Fri, 31 Mar 2017, Rainer Orth wrote:
>> > >
>> > > > Hi Christophe,
>> > > >
>> > > > > With this patch, the following testcase now fails on arm* targets:
>> > > > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
>> > > >
>> > > > same on Solaris/SPARC.
>> > >
>> > > I've reverted r241968 with (patch reverted).  It doesn't include
>> > > sparc, so please amend as you see fit.
>> >
>> > Ah, r241441.  I'll fixup myself then.
>>
>> It also fails on some X86 configurations:
>> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00237.html
>> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00238.html
>
> I see.  The test is somewhat strange (well, it's an IVOPTS test).  To
> simulate the effect of the PRE changes we could simply enable
> -fpredictive-commoning on it.
>
> Let's ask Bin what the testcase was supposed to test... (the testcase
> comment suggests that pcom is applied but it certainly wasn't before
> the xfails were removed).

It's supposed to test that both loads inside loop can be optimized,
X[i-1] by predcom or pre; X[1] by loop invariant.  When the test is
added, neither pre nor predcom (not at O2) can do this, but we have
another chance that pre + ivopts + dom together can eliminate X[i-1].
But this really depends on each pass does the right thing.  That's
also why it is added with ivopts change.  Back in time, it was ivopts
did "wrong".  Apparently, having a test on different passes is
fragile.  I will send a patch adding option "-fpredictive-commoning"
because predcom seems the right pass to do that.  Also given we are
considering enabling predcom at O2 for GCC 8.

Thanks,
bin
>
> Richard.


[PATCH] Destroy arguments for _Cilk_spawn calling in the child (PR 80038)

2017-03-31 Thread Xi Ruoyao
Hi,

I''ve sent this patch once 
().
But I haven't got any response.  I'd like to resend it instead of pinging, and 
explain it more.

There was an ancient bug PR middle-end/60586 before r227423.  At that time GCC 
evaluated
parameters inside spawn worker, and violated Intel cilk spec.  To fix it, 
Balaji V. Iyer explictly
gimplified the "_Cilk_spawn" arguments in the caller, outside of "_cilk_spn_x" 
helpers.

However there is an unwanted side-effect with r227423.  Gimplifying arguments 
in the caller
produced destruction sequence of the arguments in the caller too.  So the 
caller would
destruct arguments even if the spawned callee is still running.  Then the 
program just dumps
core, or produces wrong result.

For example, NumericMonoid  produce 
wrong
answer in GCC 6/7.  And passing STL containers as _Cilk_spawn arguments would 
likely make
the program dump core.

This is also an Intel cilk spec violation, since the spec explicitly contrains 
the destruction
of arguments in the child.  See the spec

3.6 [4]:

> Any unnamed temporary variables created prior to the spawn point are not 
> destroyed until
> after the spawn point (i.e., *their destructors are invoked in the child*).

To fix this, I reverted r227423 at first.  But the revertion reintroduced PR 
60586.  So I re-fixed
it without violating the spec.  The pedigree operations are merged into 
built-in function
_cilkrts_detach like the version in cilk_fake.h within libcilkrts.  Then we 
just insert a call to it
in the exact correct location in GIMPLE instead of tree.  In the tree the 
argument evaluation
and function call is just a CALL_EXPR and we can not seperate them.  But in 
GIMPLE we can
insert detach sequence between them.

The patch has 500+ lines so I would attach it.

Although 80038 is a "c++" PR in the bugzilla, I think it should be "middle-end".
Maybe we should reclassify PR 80038 and modify the ChangeLog as well.

This patch has been bootstrapped and regtested in x86_64-linux-gnu.  Is it
OK for trunk?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
From dfbce2c4aafd4a555ef751af2d7422d2ba79189b Mon Sep 17 00:00:00 2001
From: Xi Ruoyao 
Date: Fri, 24 Mar 2017 04:35:23 +0800
Subject: [PATCH] Destroy temps for _Cilk_spawn calling in the child (PR
 c++/80038)

Revert r227423, and re-fix PR60586 without breaking cilk specs.

2017-03-24  Xi Ruoyao  

	PR c++/80038
	* c-family/c-common.h (cilk_gimplify_call_params_in_spawned_fn,
	  cilk_install_body_pedigree_operations): Remove prototypes.
	* c-family/c-gimplify.c (c_gimplify_expr): Remove the calls to
	  the function cilk_gimplify_call_params_in_spawned_fn.
	* c-family/cilk.c: (cilk_set_spawn_marker): Mark the function
	  calls which should be detached.
	  (cilk_gimplify_call_params_in_spawned_fn,
	   cilk_install_body_pedigree_operations): Remove function.
	  (gimplify_cilk_spawn): Add EXPR_STMT and CLEANUP_POINT_EXPR
	  unwrapping.
	* c/c-typeck.c (cilk_install_body_with_frame_cleanup):
	  Don't add pedigree operation and detach call here.
	* cp/cp-cilkplus.c (cilk_install_body_with_frame_cleanup): Ditto.
	* cp/cp-gimplify.c (cilk_cp_gimplify_call_params_in_spawned_fn):
	  Remove function.
	  (cp_gimplify_expr): Remove the calls to the function
	  cilk_cp_gimplify_call_params_in_spawned_fn.
	* cp/semantics.c: Preserve the flag of function calls should
	  be detached.
	* cilk_common.c (expand_builtin_cilk_detach): Move pedigree
	  operations here.
	* gimplify.c (gimplify_cilk_detach): New static function.
	  (gimplify_call_expr, gimplify_modify_expr): Call it for the
	  function calls should be detached.
	* lto/lto-lang.c (lto_init): Set in_lto_p earlier.
	* tree-core.h: Document new macro EXPR_CILK_SPAWN.
	* tree.h: Add new macro EXPR_CILK_SPAWN.
	* testsuite/g++.dg/cilk-plus/CK/pr80038.cc: New test.
---
 gcc/c-family/c-common.h  |   2 -
 gcc/c-family/c-gimplify.c|  10 +--
 gcc/c-family/cilk.c  | 102 +++
 gcc/c/c-typeck.c |   8 +--
 gcc/cilk-common.c|  49 +
 gcc/cp/cp-cilkplus.c |   6 +-
 gcc/cp/cp-gimplify.c |  40 ++-
 gcc/cp/semantics.c   |   2 +
 gcc/gimplify.c   |  21 ++
 gcc/lto/lto-lang.c   |   6 +-
 gcc/testsuite/g++.dg/cilk-plus/CK/pr80038.cc |  47 
 gcc/tree-core.h  |   4 ++
 gcc/tree.h   |   6 ++
 13 files changed, 150 insertions(+), 153 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cilk-plus/CK/pr80038.cc

diff --git 

[DOC PATCH] PowerPC extended asm example

2017-03-31 Thread Alan Modra
Some people over at OpenBLAS were asking me whether I knew of a
whitepaper on gcc asm.  I didn't besides the gcc manual, and wrote a
note explaining some tricks.  This patch is that note cleaned up.
Tested by an x86_64-linux build.  OK to apply?

BTW, anyone wandering over to look at OpenBLAS might notice that this
example doesn't match the file exactly.  Yes, writing this doco made
me realize I need to submit a patch there..

* doc/extend.texi (Extended Asm): Add OpenBLAS example.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 594b32a..05c6892 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2017-03-31  Alan Modra  
+
+   * doc/extend.texi (Extended Asm): Add OpenBLAS example.
+
 2017-03-31  Matthew Fortune  
 
* config/mips/mips-msa.md (msa_vec_extract_): Update
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fadbc96..991a2f6 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8516,6 +8516,84 @@ asm ("cmoveq %1, %2, %[result]"
: "r" (test), "r" (new), "[result]" (old));
 @end example
 
+Here is a larger PowerPC example taken from OpenBLAS.  The over 150
+lines of assembly have been removed except for comments added to check
+gcc's register assignments, because the assembly itself isn't that
+important.  You do need to know that all of the function parameters
+are inputs except for the @code{y} array, which is modified by the
+function, and that early assembly sets up four pointers into the
+@code{ap} array, @code{a0=ap}, @code{a1=ap+lda}, @code{a2=ap+2*lda},
+and @code{a3=ap+3*lda}.
+
+Illustrated here is a technique you can use to have gcc allocate
+temporary registers for an asm, giving the compiler more freedom than
+the programmer allocating fixed registers via clobbers.  This is done
+by declaring a variable and making it an early-clobber asm output as
+with @code{a2} and @code{a3}, or making it an output tied to an input
+as with @code{a0} and @code{a1}.  The vsx registers used by the asm
+could have used the same technique except for gcc's limit on number of
+asm parameters.  It shouldn't be surprising that @code{a0} is tied to
+@code{ap} from the above description, and @code{lda} is only used
+early so that register is available for reuse as @code{a1}.  Tying an
+input to an output is the way to set up an initialised temporary
+register that is modified by an asm.  The example also shows an
+initialised register unchanged by the asm; @code{"b" (16)} sets up
+@code{%11} to 16.
+
+Also shown is a somewhat better method than using a @code{"memory"}
+clobber to tell gcc that an asm accesses or modifies memory .  Here we
+use @code{"+m" (*y)} in the list of outputs to tell gcc that the
+@code{y} array is both read and written by the asm.  @code{"m" (*x)}
+and @code{"m" (*ap)} in the inputs tells gcc that these arrays are
+read.  At a minimum, aliasing rules will allow gcc to know what memory
+@emph{doesn't} need to be flushed, and if the function were inlined
+then gcc may be able to do even better.  Notice that @code{x},
+@code{y}, and @code{ap} all appear twice in the asm parameters, once
+to specify memory accessed, and once to specify a base register used
+by the asm.  You won't normally be wasting a register by doing this as
+gcc can use the same register for both purposes.  However, it would be
+foolish to use both @code{%0} and @code{%2} for @code{y} in your asm
+and expect them to be the same.
+
+@example
+static void
+dgemv_kernel_4x4 (long n, const double *ap, long lda,
+  const double *x, double *y, double alpha)
+@{
+  double *a0;
+  double *a1;
+  double *a2;
+  double *a3;
+
+  __asm__
+(
+ ...
+ "#n=%1 ap=%8=%12 lda=%13 x=%7=%10 y=%0=%2 alpha=%9 o16=%11\n"
+ "#a0=%3 a1=%4 a2=%5 a3=%6"
+ :
+   "+m" (*y),
+   "+r" (n),   // 1
+   "+b" (y),   // 2
+   "=b" (a0),  // 3
+   "=b" (a1),  // 4
+   "=" (a2), // 5
+   "=" (a3)  // 6
+ :
+   "m" (*x),
+   "m" (*ap),
+   "d" (alpha),// 9
+   "r" (x),// 10
+   "b" (16),   // 11
+   "3" (ap),   // 12
+   "4" (lda)   // 13
+ :
+   "cr0",
+   "vs32","vs33","vs34","vs35","vs36","vs37",
+   "vs40","vs41","vs42","vs43","vs44","vs45","vs46","vs47"
+ );
+@}
+@end example
+
 @anchor{Clobbers}
 @subsubsection Clobbers
 @cindex @code{asm} clobbers


-- 
Alan Modra
Australia Development Lab, IBM


[PATCH] Increase memory limit for genautomata on AIX

2017-03-31 Thread Sam Thursfield

When doing 64-bit builds of GCC on AIX, genautomata experiences malloc()
failures. It seems that a 512MB heap is no longer big enough.

I also updated the comments in this file to match the values passed to
the linker. The AIX `ld` manual says this about the maxdata option:

Sets the maximum size (in bytes) that is allowed for the user data
area (or user heap) when the executable program is run.

So the comments were giving incorrect values.

gcc/

* config/rs6000/x-aix: Increase memory limit for genautomata on AIX.
  It has been experiencing malloc() failures during 64-bit compiler
  builds. Also correct the comments.
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
diff --git a/gcc/config/rs6000/x-aix b/gcc/config/rs6000/x-aix
index d40690f2da6..da465671ee6 100644
--- a/gcc/config/rs6000/x-aix
+++ b/gcc/config/rs6000/x-aix
@@ -1,6 +1,6 @@
-# genautomata requires more than 256MB of data
-build/genautomata : override LDFLAGS += -Wl,-bmaxdata:0x2000
+# genautomata requires more than 1GB of data
+build/genautomata : override LDFLAGS += -Wl,-bmaxdata:0x4000
 
-# jc1 requires more than 256MB of data
+# jc1 requires more than 1GB of data
 $(COMPILERS) : override LDFLAGS += -Wl,-bmaxdata:0x4000
 


Re: Trunk patches required for gcc-6-branch to build for msp430

2017-03-31 Thread Jozef Lawrynowicz
The gcc-6-branch at the current upstream revision (r246561) doesn't
build when configured with the following options: "--target=msp430-elf
--enable-languages=c,c++"

The gcc-5-branch does build with these options.

Backporting r244727 and r243310 to the gcc-6-branch fixes the two
build issues, so the build completes successfully. The patches are at
the end of this message.
I don't have write access to the GCC repository, so would appreciate
if someone could backport these patches for me.

The error message when building GCC on the gcc-6-branch:

checking how size_t is mangled... x
configure: error: Unknown underlying type for size_t
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/srv/net/msp430/jozefl/gcc/build'
make: *** [all] Error 2

Applying r244727 fixes this configure error. Discussion on this patch
is here: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01448.html

Rebuilding results in this new error:

../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc: In function
âvoid* txnal_read_ptr(void* const*)â:
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:274:3: error:
static assertion failed: Pointers must be 32 bits or 64 bits wide
   static_assert(sizeof(uint64_t) == sizeof(void*)
   ^
make[4]: *** [cow-stdexcept.lo] Error 1

Applying r243310 fixes this build error. Discussion on this patch is
here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00950.html

GCC now builds successfully builds successfully:

Target: msp430-elf
Configured with: ../configure --target=msp430-elf --enable-languages=c,c++
Thread model: single
gcc version 6.3.1 20170329 (GCC)

The 2 patches are below, I verified GCC builds successfully for
x86_64-unknown-linux-gnu with both applied.

From b5aacd74cdd4209f28309d38d85cb0004cc93410 Mon Sep 17 00:00:00 2001

From: Jozef Lawrynowicz 
Date: Thu, 30 Mar 2017 15:46:26 +
Subject: [PATCH 1/2] Backport r244727

2017-01-20  Joe Seymour  

* acinclude.m4 (GLIBCXX_CHECK_SIZE_T_MANGLING): Support uint20_t.
* configure: Regenerate.

---
 libstdc++-v3/acinclude.m4 |  8 ++--
 libstdc++-v3/configure| 18 ++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 0576560..e48cf96 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4468,8 +4468,12 @@ AC_DEFUN([GLIBCXX_CHECK_SIZE_T_MANGLING], [
[glibcxx_cv_size_t_mangling=y], [
   AC_TRY_COMPILE([],
  [extern __SIZE_TYPE__ x; extern unsigned short x;],
- [glibcxx_cv_size_t_mangling=t],
- [glibcxx_cv_size_t_mangling=x])
+ [glibcxx_cv_size_t_mangling=t], [
+AC_TRY_COMPILE([],
+   [extern __SIZE_TYPE__ x; extern __int20
unsigned x;],
+   [glibcxx_cv_size_t_mangling=u6uint20],
+   [glibcxx_cv_size_t_mangling=x])
+  ])
 ])
   ])
 ])
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index b5ae421..f8635f8 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -80555,6 +80555,21 @@ _ACEOF
 if ac_fn_c_try_compile "$LINENO"; then :
   glibcxx_cv_size_t_mangling=t
 else
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+extern __SIZE_TYPE__ x; extern __int20 unsigned x;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  glibcxx_cv_size_t_mangling=u6uint20
+else
   glibcxx_cv_size_t_mangling=x
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
@@ -80569,6 +80584,9 @@ fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext

 fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result:
$glibcxx_cv_size_t_mangling" >&5
 $as_echo "$glibcxx_cv_size_t_mangling" >&6; }
   if test $glibcxx_cv_size_t_mangling = x; then
-- 
2.9.3

=

From: Jozef Lawrynowicz 
Date: Thu, 30 Mar 2017 15:42:26 +
Subject: [PATCH 2/2] Backport r243310

Added #ifdef case for when void* is 16 bits so it compiles in AVR
target.

2016-12-06  Felipe Magno de Almeida  

* src/c++11/cow-stdexcept.cc: Add special case for 16 bit pointers.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@243310
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libstdc++-v3/src/c++11/cow-stdexcept.cc | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++11/cow-stdexcept.cc
b/libstdc++-v3/src/c++11/cow-stdexcept.cc
index 31a89df..641b372 100644
--- a/libstdc++-v3/src/c++11/cow-stdexcept.cc
+++ b/libstdc++-v3/src/c++11/cow-stdexcept.cc
@@ -208,6 +208,8 @@ extern void* _ZGTtnaX (size_t sz) __attribute__((weak));
 extern void _ZGTtdlPv (void* ptr) 

Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Richard Biener
On Fri, 31 Mar 2017, Markus Trippelsdorf wrote:

> On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
> > On Fri, 31 Mar 2017, Richard Biener wrote:
> > 
> > > On Fri, 31 Mar 2017, Rainer Orth wrote:
> > > 
> > > > Hi Christophe,
> > > > 
> > > > > With this patch, the following testcase now fails on arm* targets:
> > > > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> > > > 
> > > > same on Solaris/SPARC.
> > > 
> > > I've reverted r241968 with (patch reverted).  It doesn't include
> > > sparc, so please amend as you see fit.
> > 
> > Ah, r241441.  I'll fixup myself then.
> 
> It also fails on some X86 configurations:
> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00237.html
> https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00238.html

I see.  The test is somewhat strange (well, it's an IVOPTS test).  To
simulate the effect of the PRE changes we could simply enable
-fpredictive-commoning on it.

Let's ask Bin what the testcase was supposed to test... (the testcase
comment suggests that pcom is applied but it certainly wasn't before
the xfails were removed).

Richard.


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Markus Trippelsdorf
On 2017.03.31 at 11:16 +0200, Richard Biener wrote:
> On Fri, 31 Mar 2017, Richard Biener wrote:
> 
> > On Fri, 31 Mar 2017, Rainer Orth wrote:
> > 
> > > Hi Christophe,
> > > 
> > > > With this patch, the following testcase now fails on arm* targets:
> > > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> > > 
> > > same on Solaris/SPARC.
> > 
> > I've reverted r241968 with (patch reverted).  It doesn't include
> > sparc, so please amend as you see fit.
> 
> Ah, r241441.  I'll fixup myself then.

It also fails on some X86 configurations:
https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00237.html
https://gcc.gnu.org/ml/gcc-regression/2017-03/msg00238.html

-- 
Markus


Re: [PATCHv2 0/5] OpenMP/PTX: improve correctness in SIMD regions

2017-03-31 Thread Thomas Schwinge
Hi!

On Wed, 22 Mar 2017 18:46:30 +0300, Alexander Monakov  
wrote:
> This patchset implements privatization of addressable variables in OpenMP SIMD
> regions lowered for SIMT targets (i.e. NVPTX) via the approach identified in
> the review of the previous submission.  [...]

Given that the subject describes this to "improve correctness in SIMD
regions": no test cases for this one?


I observe a few more instances of
"[...]/gcc/config/nvptx/nvptx.md:[...]:1: warning: operand [...]  missing
mode?".  Maybe something to look at/resolve, at some point.


And:

[...]/gcc/config/nvptx/nvptx.c: In function 'void 
nvptx_output_softstack_switch(FILE*, bool, rtx, rtx, rtx)':
[...]/gcc/config/nvptx/nvptx.c:1357:39: warning: format '%d' expects 
argument of type 'int', but argument 6 has type 'long unsigned int' [-Wformat]


Grüße
 Thomas


[patch,MIPS,committed] Fix extraction from odd-numbered MSA registers

2017-03-31 Thread Matthew Fortune
Another MSA related fix; this time relating to using -mno-odd-spreg.
This fixes a build-failure with gcc.c-torture/execute/20050604-1.c
when using -mabi=32 -mmsa -mno-odd-spreg.

The fix is to copy the whole vector from the odd-numbered source
register to the even numbered single-precision destination register
and then re-interpret the vector as single precision in the
destination. The mov.s is always eliminated as it is a trivial
no-op; this is permitted by the architecture as the single-precision
and double-precision registers overlay with the 0th element of the
MSA registers. Also, trivial no-ops were already being generated
and eliminated prior to this change when source and destination
register numbers happened to be the same.

No additional test failures introduced when running the testsuite
with -mmsa. The fix is covered by a pre-existing test so no new
testcase added.

gcc/
* config/mips/mips-msa.md (msa_vec_extract_): Update
extraction from odd-numbered MSA register

Committed.

Thanks,
Matthew


diff --git a/gcc/config/mips/mips-msa.md b/gcc/config/mips/mips-msa.md
index accb8de..c80be47 100644
--- a/gcc/config/mips/mips-msa.md
+++ b/gcc/config/mips/mips-msa.md
@@ -366,7 +366,20 @@ (define_insn_and_split "msa_vec_extract_"
   "#"
   "&& reload_completed"
   [(set (match_dup 0) (match_dup 1))]
-  "operands[1] = gen_rtx_REG (mode, REGNO (operands[1]));"
+{
+  /* An MSA register cannot be reinterpreted as a single precision
+ register when using -mno-odd-spreg and the MSA register is
+ an odd number.  */
+  if (mode == SFmode && !TARGET_ODD_SPREG
+  && (REGNO (operands[1]) & 1))
+{
+  emit_move_insn (gen_rtx_REG (mode, REGNO (operands[0])),
+ operands[1]);
+  operands[1] = operands[0];
+}
+  else
+operands[1] = gen_rtx_REG (mode, REGNO (operands[1]));
+}
   [(set_attr "move_type" "fmove")
(set_attr "mode" "")])


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Richard Biener
On Fri, 31 Mar 2017, Richard Biener wrote:

> On Fri, 31 Mar 2017, Rainer Orth wrote:
> 
> > Hi Christophe,
> > 
> > > With this patch, the following testcase now fails on arm* targets:
> > > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> > 
> > same on Solaris/SPARC.
> 
> I've reverted r241968 with (patch reverted).  It doesn't include
> sparc, so please amend as you see fit.

Ah, r241441.  I'll fixup myself then.

Richard.

> Richard.
> 
> 2017-03-31  Richard Biener  
>  
>   * gcc.dg/tree-ssa/pr71347.c: Put back XFAIL.
> 
> Index: gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/pr71347.c   (revision 241967)
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr71347.c   (revision 241968)
> @@ -14,4 +14,4 @@ void foo (void)
>  }
>  
>  /* Load of X[i - i] can be omitted by reusing X[i] in previous iteration.  */
> -/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" { xfail { 
> ia64-*-* arm*-*-* m68k*-*-* } } } } */
> +/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" } } */
> 
> 

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


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Richard Biener
On Fri, 31 Mar 2017, Rainer Orth wrote:

> Hi Christophe,
> 
> > With this patch, the following testcase now fails on arm* targets:
> > gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> 
> same on Solaris/SPARC.

I've reverted r241968 with (patch reverted).  It doesn't include
sparc, so please amend as you see fit.

Richard.

2017-03-31  Richard Biener  
 
* gcc.dg/tree-ssa/pr71347.c: Put back XFAIL.

Index: gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr71347.c (revision 241967)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr71347.c (revision 241968)
@@ -14,4 +14,4 @@ void foo (void)
 }
 
 /* Load of X[i - i] can be omitted by reusing X[i] in previous iteration.  */
-/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" { xfail { 
ia64-*-* arm*-*-* m68k*-*-* } } } } */
+/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" } } */



Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Richard Biener
On Fri, 31 Mar 2017, Christophe Lyon wrote:

> Hi Richard,
> 
> 
> On 30 March 2017 at 09:13, Richard Biener  wrote:
> > On Wed, 29 Mar 2017, Jeff Law wrote:
> >
> >> On 03/29/2017 04:05 AM, Richard Biener wrote:
> >> >
> >> > After quite some pondering over this and other related bugs I propose
> >> > the following for GCC 7 which tames down PRE a bit (back to levels
> >> > of GCC 6).  Technically it's the wrong place to fix this, we do
> >> > have measures in place during elimination but they are not in effect
> >> > at -O2.  For GCC 8 I'd like to be more aggressive there but that
> >> > would require to enable predictive commoning at -O2 (with some
> >> > limits to its unrolling) to not lose optimization opportunities.
> >> >
> >> > The other option is to ignore this issue and postpone the solution
> >> > to GCC 8.
> >> >
> >> > Bootstrapped / tested on x86_64-unknown-linux-gnu.
> >> >
> >> > Any preference?
> >> >
> >> > Thanks,
> >> > Richard.
> >> >
> >> > 2017-03-29  Richard Biener  
> >> >
> >> > PR tree-optimization/77498
> >> > * tree-ssa-pre.c (phi_translate_1): Do not allow simplifications
> >> > to non-constants over backedges.
> >> >
> >> > * gfortran.dg/pr77498.f: New testcase.
> >> I've got a slight preference for this patch.
> >>
> >> If you had a good start on the real fix then I'd lean more towards 
> >> postponing.
> >
> > I wouldn't it yet call "real fix" but just an idea (where I tested the
> > PRE side already, with the expected testsuite regressions).  I've done
> > no benchmarking at all for that.  For the proposed patch the situation
> > is that we're only going to remove some PRE that was done additionally
> > over GCC 6 because of the rev. that caused the regression, so I have
> > confidence that it won't make things worse when comparing to GCC 6.
> >
> > Thus I've now applied the patch.
> >
> 
> With this patch, the following testcase now fails on arm* targets:
> gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"
> 
> I'll have to rebuild manually if you need the dumps, let me know.

Ok, there was an XFAIL there which was removed after the PRE enhancement
and thus now needs to be put back.  I'll do that.

Thanks for noticing.

Richard.


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Rainer Orth
Hi Christophe,

> With this patch, the following testcase now fails on arm* targets:
> gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"

same on Solaris/SPARC.

Rainer

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


Re: [PATCH][RFC] Fix P1 PR77498

2017-03-31 Thread Christophe Lyon
Hi Richard,


On 30 March 2017 at 09:13, Richard Biener  wrote:
> On Wed, 29 Mar 2017, Jeff Law wrote:
>
>> On 03/29/2017 04:05 AM, Richard Biener wrote:
>> >
>> > After quite some pondering over this and other related bugs I propose
>> > the following for GCC 7 which tames down PRE a bit (back to levels
>> > of GCC 6).  Technically it's the wrong place to fix this, we do
>> > have measures in place during elimination but they are not in effect
>> > at -O2.  For GCC 8 I'd like to be more aggressive there but that
>> > would require to enable predictive commoning at -O2 (with some
>> > limits to its unrolling) to not lose optimization opportunities.
>> >
>> > The other option is to ignore this issue and postpone the solution
>> > to GCC 8.
>> >
>> > Bootstrapped / tested on x86_64-unknown-linux-gnu.
>> >
>> > Any preference?
>> >
>> > Thanks,
>> > Richard.
>> >
>> > 2017-03-29  Richard Biener  
>> >
>> > PR tree-optimization/77498
>> > * tree-ssa-pre.c (phi_translate_1): Do not allow simplifications
>> > to non-constants over backedges.
>> >
>> > * gfortran.dg/pr77498.f: New testcase.
>> I've got a slight preference for this patch.
>>
>> If you had a good start on the real fix then I'd lean more towards 
>> postponing.
>
> I wouldn't it yet call "real fix" but just an idea (where I tested the
> PRE side already, with the expected testsuite regressions).  I've done
> no benchmarking at all for that.  For the proposed patch the situation
> is that we're only going to remove some PRE that was done additionally
> over GCC 6 because of the rev. that caused the regression, so I have
> confidence that it won't make things worse when comparing to GCC 6.
>
> Thus I've now applied the patch.
>

With this patch, the following testcase now fails on arm* targets:
gcc.dg/tree-ssa/pr71347.c scan-tree-dump-not optimized ".* = MEM.*;"

I'll have to rebuild manually if you need the dumps, let me know.

Thanks,

Christophe

> Richard.


[AArch64] Tighten move constraints for symbolic operands

2017-03-31 Thread Richard Sandiford
The movsi and movdi constraints allowed the source to be any
absolute symbolic expression ("S").  That's OK for operands that
have already been vetted by the aarch64_mov_operand predicate but
causes problems if the register allocator substitutes an equivalence
(the usual "the constraints can't accept more than the predicates"
restriction).

Although all other uses of "S" in the backend are redundant and could
in principle be removed, "S" itself is a publicly-documented constraint
and so we'd have to keep its definition.  This patch therefore adds a
new "Usa" constraint for legitimate absolute address operands.

I saw this for a large testcase in which an equivalence was used
for a label_ref jump table.  It's not something that can be cut
down easily or that would give a robust regression test.

I don't think this is a regression, so maybe we don't want it for GCC 7.

Tested on aarch64-linux-gnu.  OK to install?

Thanks,
Richard


gcc/
* config/aarch64/constraints.md (Usa): New constraint.
* config/aarch64/aarch64.md (*movsi_aarch64, *movdi_aarch64): Use it.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 3717edf..260bd64 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1074,7 +1074,7 @@
 
 (define_insn_and_split "*movsi_aarch64"
   [(set (match_operand:SI 0 "nonimmediate_operand" "=r,k,r,r,r,r ,r,*w,m,  
m,r,r  ,*w, r,*w")
-   (match_operand:SI 1 "aarch64_mov_operand"  " r,r,k,M,n,Dv,m, 
m,rZ,*w,S,Ush,rZ,*w,*w"))]
+   (match_operand:SI 1 "aarch64_mov_operand"  " r,r,k,M,n,Dv,m, 
m,rZ,*w,Usa,Ush,rZ,*w,*w"))]
   "(register_operand (operands[0], SImode)
 || aarch64_reg_or_zero (operands[1], SImode))"
   "@
@@ -1108,7 +1108,7 @@
 
 (define_insn_and_split "*movdi_aarch64"
   [(set (match_operand:DI 0 "nonimmediate_operand" "=r,k,r,r,r,r ,r,*w,m,  
m,r,r,  *w, r,*w,w")
-   (match_operand:DI 1 "aarch64_mov_operand"  " r,r,k,N,n,Dv,m, 
m,rZ,*w,S,Ush,rZ,*w,*w,Dd"))]
+   (match_operand:DI 1 "aarch64_mov_operand"  " r,r,k,N,n,Dv,m, 
m,rZ,*w,Usa,Ush,rZ,*w,*w,Dd"))]
   "(register_operand (operands[0], DImode)
 || aarch64_reg_or_zero (operands[1], DImode))"
   "@
diff --git a/gcc/config/aarch64/constraints.md 
b/gcc/config/aarch64/constraints.md
index b77e096..5852a42 100644
--- a/gcc/config/aarch64/constraints.md
+++ b/gcc/config/aarch64/constraints.md
@@ -104,6 +104,14 @@
   (and (match_code "high")
(match_test "aarch64_valid_symref (XEXP (op, 0), GET_MODE (XEXP (op, 
0)))")))
 
+(define_constraint "Usa"
+  "@internal
+   A constraint that matches an absolute symbolic address that can be
+   loaded by a single ADR."
+  (and (match_code "const,symbol_ref,label_ref")
+   (match_test "aarch64_symbolic_address_p (op)")
+   (match_test "aarch64_mov_operand_p (op, GET_MODE (op))")))
+
 (define_constraint "Uss"
   "@internal
   A constraint that matches an immediate shift constant in SImode."



[PATCH] Cherry-pick upstream r299036 from libsanitizer (PR sanitizer/80166).

2017-03-31 Thread Martin Liška
Hello.

Cherry-picking the commit to fix PR reported originally to the GCC.
Ready to install after it finishes regression tests?

Thanks,
Martin
>From 36cc9827dd47f213bb17dd7e37b3b19b740a0928 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 31 Mar 2017 10:28:25 +0200
Subject: [PATCH] Cherry-pick upstream r299036 from libsanitizer (PR
 sanitizer/80166).

libsanitizer/ChangeLog:

2017-03-31  Martin Liska  

	* sanitizer_common/sanitizer_common_interceptors.inc (INTERCEPTOR):
	Cherry-pick upstream r299036.

gcc/testsuite/ChangeLog:

2017-03-31  Martin Liska  

	* gcc.dg/asan/pr80166.c: New test.
---
 gcc/testsuite/gcc.dg/asan/pr80166.c| 24 ++
 .../sanitizer_common_interceptors.inc  |  3 ++-
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/asan/pr80166.c

diff --git a/gcc/testsuite/gcc.dg/asan/pr80166.c b/gcc/testsuite/gcc.dg/asan/pr80166.c
new file mode 100644
index 000..629dd23a31c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr80166.c
@@ -0,0 +1,24 @@
+/* PR sanitizer/80166 */
+/* { dg-do run } */
+
+#include 
+#include 
+
+int
+main (int argc, char **argv)
+{
+  gid_t groups;
+  int r = getgroups (0, );
+  if (r < 0)
+__builtin_abort ();
+
+  r = getgroups (-1, );
+  if (r != -1)
+__builtin_abort ();
+
+  r = getgroups (-1, NULL);
+  if (r != -1)
+__builtin_abort ();
+
+  return 0;
+}
diff --git a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
index 0970eda5ee6..195014022a0 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
+++ b/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
@@ -3350,7 +3350,8 @@ INTERCEPTOR(int, getgroups, int size, u32 *lst) {
   // its metadata. See
   // https://github.com/google/sanitizers/issues/321.
   int res = REAL(getgroups)(size, lst);
-  if (res && lst) COMMON_INTERCEPTOR_WRITE_RANGE(ctx, lst, res * sizeof(*lst));
+  if (res >= 0 && lst && size > 0)
+COMMON_INTERCEPTOR_WRITE_RANGE(ctx, lst, res * sizeof(*lst));
   return res;
 }
 #define INIT_GETGROUPS COMMON_INTERCEPT_FUNCTION(getgroups);
-- 
2.12.0



Patch ping

2017-03-31 Thread Jakub Jelinek
Hi!

I'd like to ping two patches:

PR c++/79572
  - ubsan instrumentation of reference binding to NULL if the reference
is folded into INTEGER_CST with REFERENCE_TYPE
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01255.html

PR debug/79255
  - dwarf2out profiledbootstrap ICE while building gnat;
either the posted patch
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01257.html
or in gen_decl_die:
   case FUNCTION_DECL:
+/* decl is NULL only if when processing a function declaration in
+   BLOCK_NONLOCALIZED_VARS.  It is a normal declaration, not an
+   abstract copy of something, so make sure we don't handle it
+   like function inlined into something.  */
+if (decl == NULL_TREE)
+  {
+   decl = origin;
+   origin = NULL_TREE;
+  }
or something else (another possibility is to replace all decl
uses in case FUNCTION_DECL with decl_or_origin and
- if (!origin)
-   origin = decl_class_context (decl);
+ if (!decl || !origin)
+   origin = decl_class_context (decl_or_origin);
)?

Jakub


Re: [PATCH] Fix expansion of initializer extensions (PR c/80163)

2017-03-31 Thread Jakub Jelinek
Hi!

On Mon, Mar 27, 2017 at 09:51:27AM -0600, Jeff Law wrote:
> > 2017-03-24  Jakub Jelinek  
> > 
> > PR c/80163
> > * expr.c : For EXPAND_INITIALIZER determine SIGN_EXTEND
> > vs. ZERO_EXTEND based on signedness of treeop0's type rather than
> > signedness of the result type.
> > 
> > * gcc.dg/torture/pr80163.c: New test.
> > 
> > --- gcc/expr.c.jj   2017-03-07 09:04:04.0 +0100
> > +++ gcc/expr.c  2017-03-24 12:09:57.729854079 +0100
> > @@ -8333,7 +8333,8 @@ expand_expr_real_2 (sepops ops, rtx targ
> > }
> > 
> >else if (modifier == EXPAND_INITIALIZER)
> > -   op0 = gen_rtx_fmt_e (unsignedp ? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
> > +   op0 = gen_rtx_fmt_e (TYPE_UNSIGNED (TREE_TYPE (treeop0))
> > +? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
> ?!?
> 
> Shouldn't the zero/sign extension be derived from the target's type not the
> source types?

No, it needs to be derived from the source operand type, that is exactly the
bug here, we were deriving it from target's type.

> treeop0 is the first source operand, isn't it?

Yes.

If you look at the surrounding code, you can see e.g.:
  else if (target == 0)
op0 = convert_to_mode (mode, op0,
   TYPE_UNSIGNED (TREE_TYPE
  (treeop0)));
  else
{
  convert_move (target, op0,
TYPE_UNSIGNED (TREE_TYPE (treeop0)));
  op0 = target;
}
where the conversion is derived from the operand type, or also:
  else if (CONSTANT_P (op0))
{
  tree inner_type = TREE_TYPE (treeop0);
  machine_mode inner_mode = GET_MODE (op0);

  if (inner_mode == VOIDmode)
inner_mode = TYPE_MODE (inner_type);
  
  if (modifier == EXPAND_INITIALIZER)
op0 = lowpart_subreg (mode, op0, inner_mode);
  else
op0=  convert_modes (mode, inner_mode, op0,
 TYPE_UNSIGNED (inner_type));
}
(the lowpart_subreg unconditionally looks problematic too, e.g. if
op0 happens to be scalar int and mode is integral; but let's
deal with it incrementally; perhaps we are always folded and never
reach here with CONST_INTs).

Or consider what kind of extension you need if you have conversions
int -> unsigned long long   SIGN_EXTEND
unsigned int-> signed long long ZERO_EXTEND
(and just for completeness):
int -> signed long long (obviously SIGN_EXTEND)
unsigned int-> unsigned long long   (obviously ZERO_EXTEND)

Jakub


Re: [C++ PATCH] Add __is_aggregate trait builtin (PR libstdc++/80251)

2017-03-31 Thread Jeff Law

On 03/30/2017 02:34 PM, Jakub Jelinek wrote:

Hi!

As discussed with Jon, libstdc++ needs a GCC builtin in order to implement
this easily.

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

2017-03-30  Jakub Jelinek  

PR libstdc++/80251
c-family/
* c-common.h (enum rid): Add RID_IS_AGGREGATE.
* c-common.c (c_common_reswords): Add __is_aggregate trait.
* cp-tree.h (enum cp_trait_kind): Add CPTK_IS_AGGREGATE.
* cxx-pretty-print.c (pp_cxx_trait_expression): Handle
CPTK_IS_AGGREGATE.
* semantics.c (trait_expr_value): Handle CPTK_IS_AGGREGATE.
Remove extraneous parens.
(finish_trait_expr): Handle CPTK_IS_AGGREGATE.
* parser.c (cp_parser_primary_expression): Handle RID_IS_AGGREGATE.
(cp_parser_trait_expr): Likewise.
testsuite/
* g++.dg/ext/is_aggregate.C: New test.

OK.

jeff



Re: [PATCH] Fix expansion ICE on stores into parts of hard registers (PR middle-end/80173)

2017-03-31 Thread Jeff Law

On 03/30/2017 02:38 PM, Jakub Jelinek wrote:

Hi!

On some arches like x86_64 we allow some aggregates in named register
variables.  If those registers are wider than word, store_bit_field_1
was assuming it must be multiple registers and attempted to pick
a word sized subregister of it, which is fine for pseudos, but if the
destination is a hard register, sometimes such subreg will fail.
If it is a hard register and we know that its mode means a single
register (otherwise we wouldn't allow creating a named register variable for
it), then that subreg is certainly counter-productive, we just want to store
into the whole register.

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

2017-03-30  Jakub Jelinek  

PR middle-end/80173
* expmed.c (store_bit_field_1): Don't attempt to create
a word subreg out of hard registers wider than word if they
have HARD_REGNO_NREGS of 1 for their mode.

* gcc.target/i386/pr80173.c: New test.
I could easily argue that we shouldn't ever create subregs of hardregs. 
They should either be rejected or simplified into normal reg 
expressions.  There's been many bugs in the past due to these kinds of 
problems.


This patch clearly fits that general guidance.

OK for the trunk and any release branches where you want to backport it.

jeff