[wwwdocs] gcc-6/porting_to.html: Use instead of for code and command-line options.

[Gerald Pfeifer]

I found this in my tree.  It must date back a while ago, and I do
not remember full context, but probably I noticed this will reviewing
some patches.

Applied.

Gerald

Index: gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.21
diff -u -r1.21 porting_to.html
--- gcc-6/porting_to.html   22 Mar 2016 15:41:09 -  1.21
+++ gcc-6/porting_to.html   12 Apr 2016 04:44:30 -
@@ -265,8 +265,8 @@
 
 The std::auto_ptr class template was deprecated in C++11, so GCC
 now warns about its usage.  This warning can be suppressed with the
--Wno-deprecated-declarations command-line option, though we advise
-to port the code to use C++11's std::unique_ptr instead.
+-Wno-deprecated-declarations command-line option, though we
+advise to port the code to use C++11's std::unique_ptr instead.
 
 
 'constexpr' needed for in-class initialization of 
static data member
@@ -274,7 +274,7 @@
 
 Since C++11, the constexpr keyword is needed when initializing a
 non-integral static data member in a class.  As a GNU extension, the following
-program is accepted in C++03 (albeit with a -Wpedantic warning):
+program is accepted in C++03 (albeit with a -Wpedantic warning):
 
 
 
@@ -319,9 +319,10 @@
 Finally, the type and mangling of flexible array members has changed
 from previous releases.  While in GCC 5 and prior the type of a flexible
 array member is an array of zero elements (a GCC extension), in GCC 6 it
-is that of an array of an unspecified bound (i.e., T[] as opposed
-to T[0]).  This is a silent ABI change with no corresponding
--fabi-version or -Wabi option to disable or warn about.
+is that of an array of an unspecified bound (i.e., T[] as opposed
+to T[0]).  This is a silent ABI change with no corresponding
+-fabi-version or -Wabi option to disable or warn
+about.
 
 
 More aggressive optimization of 
-flifetime-dse

Re: [PATCH IRA] save a call to init_reload

[Vladimir Makarov]

On 04/10/2016 11:24 PM, Zhouyi Zhou wrote:

save a function call to init_reload when using lra, also remove the a
type error in reload1.c

because init_reload is called only once when compile process, the
performance reduction may not be significant when compiling multi function
source files.


Thank you for the patch.  The toplev.c part of the patch is ok for stage 1.

As for reload1.c part, I don't see what you actually changed.



performance evaluation using valgrind (gcc.c-torture/compile/simd-6.c):
valgrind --tool=lackey --log-file=tmp1  ../gcc/cc1.orig -O2  simd-6.c 
2>/dev/null
valgrind --tool=lackey --log-file=tmp  ../gcc/cc1 -O2  simd-6.c 2>/dev/null

orig:
==1139== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1139== Command: ../gcc/cc1.orig -O2 simd-6.c
==1139== Parent PID: 14895
==1139==
==1139==
==1139== Counted 1 call to main()
==1139==
==1139== Jccs:
==1139==   total: 2,309,094
==1139==   taken: 960,254 (42%)
==1139==
==1139== Executed:
==1139==   SBs entered:   2,671,880
==1139==   SBs completed: 1,662,561
==1139==   guest instrs:  15,729,468
==1139==   IRStmts:   93,198,764

after:
==1142== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1142== Command: ../gcc/cc1 -O2 simd-6.c
==1142== Parent PID: 14895
==1142==
==1142==
==1142== Counted 1 call to main()
==1142==
==1142== Jccs:
==1142==   total: 2,306,506
==1142==   taken: 959,362 (42%)
==1142==
==1142== Executed:
==1142==   SBs entered:   2,669,050
==1142==   SBs completed: 1,660,884
==1142==   guest instrs:  15,714,064
==1142==   IRStmts:   93,106,144



bootstrapped and checked on x86-64
Signed-off-by: Zhouyi Zhou 
---
  gcc/ChangeLog | 9 +
  gcc/reload1.c | 2 +-
  gcc/toplev.c  | 3 ++-
  3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8d9a94d..9f78348 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2016-04-11  Zhouyi Zhou  
+
+   * toplev.c (backend_init_target): save a function call to init_reload
+   when using lra.
+
+2016-04-11  Zhouyi Zhou  
+
+   * reload1.c : fix a type error in reload1.c.
+   
  2016-04-09  Tom de Vries  
  
  	PR tree-optimization/68953

diff --git a/gcc/reload1.c b/gcc/reload1.c
index c2800f8..8310dc5 100644
--- a/gcc/reload1.c
+++ b/gcc/reload1.c
@@ -412,7 +412,7 @@ static bool gen_reload_chain_without_interm_reg_p (int, 
int);
  static int reloads_conflict (int, int);
  static rtx_insn *gen_reload (rtx, rtx, int, enum reload_type);
  static rtx_insn *emit_insn_if_valid_for_reload (rtx);
-
+
  /* Initialize the reload pass.  This is called at the beginning of compilation
 and may be called again if the target is reinitialized.  */
  
diff --git a/gcc/toplev.c b/gcc/toplev.c

index c480bfc..14ac9c5 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1620,7 +1620,8 @@ backend_init_target (void)
init_alias_target ();
  
/* Depends on HARD_FRAME_POINTER_REGNUM.  */

-  init_reload ();
+  if (!ira_use_lra_p)
+init_reload ();
  
/* Depends on the enabled attribute.  */

recog_init ();

[gomp4] backport parallel reduction changes

[Cesar Philippidis]

This patch backports the reduction changes in trunk to gomp-4_0-branch.
Prior to this patch, gomp-4_0-branch was having the gimplifier create a
temporary variable for reference-typed reductions. That's no longer
necessary with this patch.

Besides for the reference reduction changes, this patch also addresses
some problems with reductions in acc parallel directives. Specifically,
private and firstprivate reductions are reported as errors now, so that
resolves PR70357.

Thomas, there's still some divergence between trunk and gomp-4_0-branch
in the various FEs. Those changes are too late for trunk right now. I'll
take a closer look at them later, but maybe we should drop them in
gomp-4_0-branch.

I've applied this patch to gomp-4_0-branch.

Cesar

2016-04-08  Cesar Philippidis  

	gcc/
	PR tree-optimization/70357
	* gimplify.c (gimplify_scan_omp_clauses): Remove stale acc reduction
	code.
	(gimplify_adjust_omp_clauses): Add or adjust data clauses for acc
	parallel reductions as necessary.  Error on those that are private.
	(localize_reductions_r): Delete.
	(localize_reductions): Delete.
	(gimplify_omp_for): Don't call localize_reductions.
	(gimplify_omp_workshare): Likewise.
	* omp-low.c (build_outer_var_ref): Remove stale reduction-specific
	corner cases.
	(fixup_remapped_decl): Likewise.
	(scan_sharing_clauses):  Don't install variables which are used in
	acc parallel reductions.
	(check_omp_nesting_restrictions): Remove stale reduction-specific
	corner cases.
	(scan_omp_1_stmt): Clean up whitespace.
	(lower_rec_input_clauses): Remove stale reduction-specific corner
	cases.
	(lower_oacc_reductions): Update it to handle parallel, reference and
	nested reductions.
	(lower_omp_target): Don't remap variables appearing in acc parallel
	reductions.
	* tree-core.h (enum omp_clause_code): Remove stale comments about
	the fifth reduction clause operand.
	* tree.c (omp_clause_num_ops): Set the number of reduction clause
	operands to 5.
	(walk_tree_1): Update error checking for the reduction clause.
	* tree.h (OMP_CLAUSE_MAP_IN_REDUCTION): New macro.

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 5800fed..374d786 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6542,12 +6542,9 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
   tree c, clauses = *list_p;
   hash_map *struct_map_to_clause = NULL;
   tree *prev_list_p = NULL;
-  vec redvec;
-  bool processed_reductions = false;
 
   ctx = new_omp_context (region_type);
   outer_ctx = ctx->outer_context;
-  redvec.create (8);
   if (code == OMP_TARGET && !lang_GNU_Fortran ())
 {
   ctx->target_map_pointers_as_0len_arrays = true;
@@ -6696,10 +6693,6 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
 		  || TREE_CODE (decl) == INDIRECT_REF)
 		decl = TREE_OPERAND (decl, 0);
 	}
-	  if ((region_type & ORT_ACC) && ((region_type & ORT_TARGET) != 0)
-	  && (outer_ctx == NULL 
-		  || outer_ctx->region_type == ORT_ACC_DATA))
-	redvec.safe_push (OMP_CLAUSE_DECL (c));
 	  goto do_add_decl;
 	case OMP_CLAUSE_LINEAR:
 	  if (gimplify_expr (_CLAUSE_LINEAR_STEP (c), pre_p, NULL,
@@ -7553,46 +7546,6 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
 	  gcc_unreachable ();
 	}
 
-  /* Add an implicit data-movement clause for an OpenACC parallel
-	 reduction, if necessary.  */
-  if (OMP_CLAUSE_CHAIN (c) == NULL && !processed_reductions
-	  && ((region_type & ORT_TARGET) != 0)
-	  && (region_type & ORT_ACC))
-	{
-	  tree t;
-
-	  while (!redvec.is_empty ())
-	{
-	  tree decl = redvec.pop ();
-	  bool mapped = false;
-
-	  for (t = clauses; t; t = OMP_CLAUSE_CHAIN (t))
-		if (OMP_CLAUSE_CODE (t) == OMP_CLAUSE_MAP
-		&& OMP_CLAUSE_DECL (t) == decl)
-		  {
-		mapped = true;
-		if (OMP_CLAUSE_MAP_KIND (t) == GOMP_MAP_TOFROM
-			&& OMP_CLAUSE_MAP_KIND (t) != GOMP_MAP_FORCE_TOFROM)
-		  error_at (OMP_CLAUSE_LOCATION (t),
-"incompatible data clause");
-		break;
-		  }
-
-	  if (!mapped)
-		{
-		  /* Let gimplify_adjust_omp_clauses_1 create a new data
-		 clause for the reduction.  */
-
-		  splay_tree_node n;
-
-		  n = splay_tree_lookup (ctx->variables, (splay_tree_key)decl);
-		  n->value |= GOVD_MAP;
-		}
-	}
-
-	  processed_reductions = true;
-	}
-
   if (remove)
 	*list_p = OMP_CLAUSE_CHAIN (c);
   else
@@ -8061,6 +8014,34 @@ gimplify_adjust_omp_clauses (gimple_seq *pre_p, gimple_seq body, tree *list_p,
 	  break;
 	}
 	  decl = OMP_CLAUSE_DECL (c);
+	  /* Data clasues associated with acc parallel reductions must be
+	 compatible with present_or_copy.  Warn and adjust the clause
+	 if that is not the case.  */
+	  if (ctx->region_type == ORT_ACC_PARALLEL)
+	{
+	  tree t = DECL_P (decl) ? decl : TREE_OPERAND (decl, 0);
+	  n = NULL;
+
+	  if (DECL_P (t))
+		n = splay_tree_lookup (ctx->variables, (splay_tree_key) t);
+
+	  if (n && (n->value & GOVD_REDUCTION))
+		{
+		  enum 

Re: [DOC Patch] Add sample for @cc constraint

[David Wohlferd]

Ping?

dw

On 4/1/2016 4:39 PM, David Wohlferd wrote:
> I would like executable code that verifies that this feature is 
indeed working as intended.


First draft is attached.  It tests all 28 (14 conditions plus 14 
inverted).  I wasn't sure what to set for optimization (O2? O3? O0?), 
so I left the default.


It looks like even at O3 there are some missed optimizations here, but 
that's an issue for another day.


> Is there any _actual_ problem here? Like, if you combine the output 
and the clobber you run into problems? Looks to me like an explicit 
"cc" clobber is just ignored on x86. We just need to make sure this 
stays working (testcases).


Today?  No.  You can clobber or not clobber and both will produce the 
exact same output.


But letting people program this two different ways guarantees that 
people *will* program it both ways.  And just because there isn't any 
definable reason to limit this today doesn't mean that there won't 
ever be.  But by then it will be 'too late' to change it because it 
"breaks existing code."


>> 1) Leave this text in.
>> 2) Remove the text and add the compiler check to v6.
>> 3) Remove the text and add the compiler check to v7.
>> 4) Leave the text in v6, then in v7: remove the text and add the 
compiler check.
>> 5) (Reluctantly) remove the text and hope this never becomes a 
problem.


So, I've made my pitch, but it sounds like you want #5?

> My question would be, can this information ever be relevant to 
users? They may notice that their code still works if they omit the 
"cc", but that's not really a habit we want to encourage.


People do this now without understanding how or why it works.

> I think this is an internal implementation detail that doesn't 
necessarily even have to be documented.


One time it would matter is if people want to move from basic asm 
(which doesn't clobber "cc") to any type of extended asm (which always 
does).  It /probably/ won't matter in that case (and may even make 
things better).  But it shouldn't be a secret.


dw

Re: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support

[Faraz Shahbazker]

Bump.

On 02/05/2016 10:36 AM, Faraz Shahbazker wrote:
> Enable non-executable stack mode if assembler and linker support it.
> 
> Currently the MIPS FPU emulator uses eXecute Out of Line (XOL) on the stack to
> handle instructions in the delay slots of FPU branches.  Because of this MIPS
> cannot have a non-executable stack. While the solution on the kernel side is
> not yet finalized, we propose changes required on the tools-side to make them
> ready for a seamless transition whenever a fixed kernel becomes available.
> 
> glibc/dynamic linker:
> 
> * When non-executable stack is requested, first check AT_FLAGS in the
>   auxiliary vector to decide if this kernel supports a non-executable
>   stack. Persist with the non-executable mode specified on the
>   PT_GNU_STACK segment only if kernel supports it, else revert to an
>   executable stack.
> 
> * The 25th bit (1<<24) in AT_FLAGS is reserved for use by the kernel to
>   indicate that it supports a non-executable stack on MIPS.
> 
> * glibc's ABIVERSION is incremented from 3 to 5, so that applications linked
>   for this glibc can't be accidentally run against older versions. ABIVERSION
>   4 has been skipped over because it was chosen for IFUNC support, which is
>   still under review.
> 
> Patch under review: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html
> 
> binutils:
> 
> * Increment the ABIVERSION to 5 for objects with non-executable stacks.
> 
> Patch under review: https://sourceware.org/ml/binutils/2016-02/msg00087.html
> 
> gcc:
> 
> * Check if assembler/dynamic linker support the new behaviour
>   (ABIVERSION >= 5). If yes, enable non-executable stack by default
>   for all objects.
> 
> gcc/ChangeLog
>   * configure.ac: Check if assembler supports the new PT_GNU_STACK
>   ABI change; if yes, enable non-executable stack mode by default.
>   * configure: Regenerate.
>   * config.in: Regenerate.
>   * config/mips/mips.c: Define TARGET_ASM_FILE_END to indicate
>   stack mode for each C file if LD_MIPS_GNUSTACK is enabled.
> 
> libgcc/ChangeLog
>   config/mips/crti.S: Add .note.GNU-stack marker if LD_MIPS_GNUSTACK
>   support is enabled.
>   config/mips/crtn.S: Add .note.GNU-stack marker if LD_MIPS_GNUSTACK
>   support is enabled.
>   config/mips/mips16.S: Add .note.GNU-stack marker if
>   LD_MIPS_GNUSTACK support is enabled.
>   config/mips/vr4120-div.S: Add .note.GNU-stack marker if
>   LD_MIPS_GNUSTACK support is enabled.
> 
> -- gcc/configure.ac gcc/config/mips/mip.c config/mips/crti.S 
> config/mips/crtn.S config/mips/mips16.S config/mips/vr4120-div.S
> ---
>  gcc/config/mips/mips.c  |5 +
>  gcc/configure.ac|   23 +++
>  libgcc/config/mips/crti.S   |6 ++
>  libgcc/config/mips/crtn.S   |6 ++
>  libgcc/config/mips/mips16.S |7 +++
>  libgcc/config/mips/vr4120-div.S |7 +++
>  6 files changed, 54 insertions(+)
> 
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index ea18ad6..c3eefc0 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -20194,6 +20194,11 @@ mips_promote_function_mode (const_tree type 
> ATTRIBUTE_UNUSED,
>  #undef TARGET_HARD_REGNO_SCRATCH_OK
>  #define TARGET_HARD_REGNO_SCRATCH_OK mips_hard_regno_scratch_ok
>  
> +#if HAVE_LD_MIPS_GNUSTACK
> +#undef TARGET_ASM_FILE_END
> +#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
> +#endif
> +
>  struct gcc_target targetm = TARGET_INITIALIZER;
>  
>  #include "gt-mips.h"
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 0a626e9..9b8190e 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -4562,6 +4562,29 @@ pointers into PC-relative form.])
>AC_MSG_ERROR(
>   [Requesting --with-nan= requires assembler support for -mnan=])
>  fi
> +
> +AC_CACHE_CHECK([linker for GNU-stack ABI support],
> +  [gcc_cv_ld_mips_gnustack],
> +  [gcc_cv_ld_mips_gnustack=no
> +   if test x$gcc_cv_as != x \
> +-a x$gcc_cv_ld != x \
> +-a x$gcc_cv_readelf != x ; then
> +  cat > conftest.s < +.section .note.GNU-stack,"",%progbits
> +EOF
> +  if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 \
> + && $gcc_cv_ld -o conftest conftest.o > /dev/null 2>&1; then
> +abi_version=`$gcc_cv_readelf -h conftest 2>&1 | grep "ABI Version:" 
> | cut -d: -f2 | tr -d '[[:space:]]'`
> +if test "$abi_version" -ge 5; then
> +  gcc_cv_ld_mips_gnustack=yes
> +fi
> +  fi
> +   fi
> +   rm -f conftest.s conftest.o conftest])
> +if test x$gcc_cv_ld_mips_gnustack = xyes; then
> + AC_DEFINE(HAVE_LD_MIPS_GNUSTACK, 1,
> +  [Define if your linker can handle PT_GNU_STACK segments correctly.])
> +fi
>  ;;
>  s390*-*-*)
>  gcc_GAS_CHECK_FEATURE([.gnu_attribute support],
> diff --git a/libgcc/config/mips/crti.S b/libgcc/config/mips/crti.S
> index 8521d3c..aa85d94 

[PATCH] Fix PR c++/70610 (wrong overload resolution during template processing)

[Patrick Palka]

The gist of the issue is that with -std=c++03 or earlier a
NON_DEPENDENT_EXPR is considered to always be an lvalue according to
lvalue_kind().  This causes overload resolution to malfunction during
template processing because it sometimes chooses an overload that
expects an lvalue argument even though the expression underlying the
NON_DEPENDENT_EXPR is not an lvalue.  My patch for PR c++/21802
exacerbated this issue by having operator overload resolution get
performed only once, at template processing time (where we see
NON_DEPENDENT_EXPRs), instead of twice, at template processing time and
then at instantiation time (where we don't see NON_DEPENDENT_EXPRs).
The issue though is not restricted to operator overloads, it also
manifests itself in regular function overloads (see pr70610-3.C which
currently fails with an ambiguous overload error).

>From what I can tell the special casing done in lvalue_kind() for older
cxx_dialects is no longer necessary, so this patch removes it to have
lvalue_kind() unconditionally recurse into NON_DEPENDENT_EXPRs.  This
however caused a c++98 regression in g++.dg/template/lvalue2.C which is
fixed by removing the guard against cxx_dialect in
build_x_conditional_expr which also no longer seems necessary.  Although
I haven't looked too carefully...

Bootstrapped + regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/70610
* tree.c (lvalue_kind) [NON_DEPENDENT_EXPR]: Unconditionally
recurse into it.
* typeck.c (build_x_conditional_expr): Unconditionally remember
that the result is an lvalue or xvalue.

gcc/testsuite/ChangeLog:

PR c++/70610
* g++.dg/template/pr70610.C: New test.
* g++.dg/template/pr70610-2.C: New test.
* g++.dg/template/pr70610-3.C: New test.
* g++.dg/template/pr70610-4.C: New test.
---
 gcc/cp/tree.c |  8 +---
 gcc/cp/typeck.c   |  6 ++
 gcc/testsuite/g++.dg/template/pr70610-2.C | 21 +
 gcc/testsuite/g++.dg/template/pr70610-3.C | 21 +
 gcc/testsuite/g++.dg/template/pr70610-4.C | 19 +++
 gcc/testsuite/g++.dg/template/pr70610.C   | 21 +
 6 files changed, 85 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/pr70610-2.C
 create mode 100644 gcc/testsuite/g++.dg/template/pr70610-3.C
 create mode 100644 gcc/testsuite/g++.dg/template/pr70610-4.C
 create mode 100644 gcc/testsuite/g++.dg/template/pr70610.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 5d9de34..df2981f 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -224,13 +224,7 @@ lvalue_kind (const_tree ref)
   return lvalue_kind (BASELINK_FUNCTIONS (CONST_CAST_TREE (ref)));
 
 case NON_DEPENDENT_EXPR:
-  /* We just return clk_ordinary for NON_DEPENDENT_EXPR in C++98, but
-in C++11 lvalues don't bind to rvalue references, so we need to
-work harder to avoid bogus errors (c++/44870).  */
-  if (cxx_dialect < cxx11)
-   return clk_ordinary;
-  else
-   return lvalue_kind (TREE_OPERAND (ref, 0));
+  return lvalue_kind (TREE_OPERAND (ref, 0));
 
 default:
   if (!TREE_TYPE (ref))
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 4dc1b55..a62bae4 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -6275,10 +6275,8 @@ build_x_conditional_expr (location_t loc, tree ifexp, 
tree op1, tree op2,
 {
   tree min = build_min_non_dep (COND_EXPR, expr,
orig_ifexp, orig_op1, orig_op2);
-  /* In C++11, remember that the result is an lvalue or xvalue.
- In C++98, lvalue_kind can just assume lvalue in a template.  */
-  if (cxx_dialect >= cxx11
- && lvalue_or_rvalue_with_address_p (expr)
+  /* Remember that the result is an lvalue or xvalue.  */
+  if (lvalue_or_rvalue_with_address_p (expr)
  && !lvalue_or_rvalue_with_address_p (min))
TREE_TYPE (min) = cp_build_reference_type (TREE_TYPE (min),
   !real_lvalue_p (expr));
diff --git a/gcc/testsuite/g++.dg/template/pr70610-2.C 
b/gcc/testsuite/g++.dg/template/pr70610-2.C
new file mode 100644
index 000..3368a5e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr70610-2.C
@@ -0,0 +1,21 @@
+// PR c++/70610
+// { dg-do link }
+
+struct A { };
+
+void operator+ (const A &, A &);
+void operator+ (A &, const A &);
+void operator+ (const A &, const A &) { }
+
+template 
+void
+foo ()
+{
+  A () + A ();
+}
+
+int
+main ()
+{
+  foo ();
+}
diff --git a/gcc/testsuite/g++.dg/template/pr70610-3.C 
b/gcc/testsuite/g++.dg/template/pr70610-3.C
new file mode 100644
index 000..4be458c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr70610-3.C
@@ -0,0 +1,21 @@
+// PR c++/70610
+// { dg-do link }
+
+void bar (const int &, int &);
+void bar (int &, const int &);
+void bar (const int &, const int &) { }
+
+int a, b;

Re: [PATCH] Fix ssa coalescing with inline asm (PR middle-end/70593)

[Jeff Law]

On 04/08/2016 10:10 AM, Jakub Jelinek wrote:

On Fri, Apr 08, 2016 at 06:04:38PM +0200, Richard Biener wrote:

Hmm, don't we simply want to do this for all stmts (OK, only asm have multiple 
defs...)?


For all stmts that have multiple defs (which is only GIMPLE_ASM right now).
I thought the atomic support added support for statements with multiple 
outputs?


Jeff

[PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

[Jim Wilson]

Here is a patch to correct the -fabi-version docs on the GCC 5 branch.

This was tested with an x86_64-linux bootstrap, make doc, make dvi,
and checking the output info and dvi files to make sure the changes
look right.

Ok to check in?

Jim
Index: ChangeLog
===
--- ChangeLog	(revision 234867)
+++ ChangeLog	(working copy)
@@ -1,3 +1,12 @@
+2016-04-11  Jim Wilson  
+
+	Partial backport from trunk r228017.
+	2015-09-22  Jason Merrill  
+
+	PR c++/70613
+	* doc/invoke.texi (-fabi-version): Document version 9.
+	(-Wabi): Document version 9.  Mention version 8 is default for GCC 5.1.
+
 2016-04-09  Oleg Endo  
 
 	Backport from mainline
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 234867)
+++ doc/invoke.texi	(working copy)
@@ -2118,6 +2118,9 @@ scope.
 Version 8, which first appeared in G++ 4.9, corrects the substitution
 behavior of function types with function-cv-qualifiers.
 
+Version 9, which first appeared in G++ 5.2, corrects the alignment of
+@code{nullptr_t}.
+
 See also @option{-Wabi}.
 
 @item -fabi-compat-version=@var{n}
@@ -2619,7 +2622,15 @@ When mangling a function type with function-cv-qua
 un-qualified function type was incorrectly treated as a substitution
 candidate.
 
-This was fixed in @option{-fabi-version=8}.
+This was fixed in @option{-fabi-version=8}, the default for GCC 5.1.
+
+@item
+@code{decltype(nullptr)} incorrectly had an alignment of 1, leading to
+unaligned accesses.  Note that this did not affect the ABI of a
+function with a @code{nullptr_t} parameter, as parameters have a
+minimum alignment.
+
+This was fixed in @option{-fabi-version=9}, the default for GCC 5.2.
 @end itemize
 
 It also warns about psABI-related changes.  The known psABI changes at this

Re: [PATCH] c++/70594 debug info differences

[Patrick Palka]

On Mon, Apr 11, 2016 at 3:42 PM, Nathan Sidwell  wrote:
> This proto patch addresses 70594, where the constexpr machinery causes
> differences in -fcompare-debug checking.  I'm looking for initial comments
> about the approach this patch is taking.
>
> As described in the comments of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594  the change is being
> caused by differing GC points with and without debug info generation.  We
> generate different patterns of DECL_UID.
>
> With Patrick's patch to address 70542 constexpr_call_table is now
> gc-deletable, and he introduced a cache for constexpr fn bodies, also
> gc-deletable.
>
> This patch changes things so that both constexpr_call_table and
> fundef_copies_table are no longer gc-deletable.  Instead we simply count the
> size of the constexpr_call_table and manually delete it if it gets 'too
> big'.
>
> The bulk of this patch is adding gc machinery to the fundef_copies_table_t
> type, as we now need to walk it during GC.
>
> I modified maybe_initialize_constexpr_call_table to delete the table if it
> is too big, and we're at the outermost level of a constexpr call evaluation
> stack.  I picked a hard coded value for reasons I discuss below.  It would
> be nice to delete the table only if we discover we're going to do call
> evaluation (rather than hit an already cached value), but that was a little
> awkward.  So I punted.
>
> I've added a new hook to delete these two tables at the end of parsing.
> This is called from c_parse_final_cleanup.  There's no point having them
> hang around during the rest of compilation.
>
> In addition to bootstrapping and testing, I repeated Patrick's experiment of
> building dwarf2out.c with -fcompare-debug.  No changes were observed.
>
> Observations:
>
> 1) I think this approach is not globally best.  We're inventing another
> memory-usage related heuristic, rather than relying on the already available
> GC machinery.  That's why I've gone with a hard coded value for now, rather
> than add a new user-frobable  param.  The right solution is to stop
> generating new DECL_UIDs when copying fns for constexpr evaluation.  IIUC
> the UID is being used to map decls to values.  I don't see why we can't just
> use the (copied) DECL's address as a key to find its associated value (but
> I've not investigated that approach).  It's not like we particularly care
> about the stability of that mapping between different compilations on
> different machines -- it doesn't affect code generation.  Reproducibility of
> a class of compiler bugs would be reduced, but probably only marginally so,

This sounds like a good idea to me!

>
> 2) The constexpr_call_table and fundef_copies_table are closely related data
> structures.  I think it would be cleaner to combine these into a single data
> structure.  Possibly along with the call_stack and associated variables.
> Such a cleanup would be good even if we don't go with this approach to the
> defect, but could wait until 7.0.  If we go with this approach, IMHO it
> would be good to do some of this merging now.

Hmm, my initial approach for PR c++/70452 actually tacked the freelist
onto the constexpr_fundef_table, see
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00086.html.  The
implementation was only switched to a separate fundef_copies_table
table only so that it could be deleted during GC which we now know is
problematic.  Maybe it's worth going back to this approach?  (I don't
readily see how the consetxpr_call_table and fundef_copies_table can
be merged since the former is indexed by more than just the function
decl.)

>
> 3) In experimenting I looked at the 70542 testcase.  Allowing the caches to
> grow unboundedly we end up with about 500K constexpr_call_table slots used,
> 20 fundef_copies slots all taking up about 55MB (out of about 65MB) of
> gc-able memory.
>
> In the 70594 testcase we use 127 constexpr_call_table slots, and about 1MB
> of gcable  memory.
>
> Picking a limit of 2 constexpr_call_table slots causes several
> reallocations and interestingly actually led to faster parsing for 70542 of
> 6.8 seconds rather than 7.0 seconds.  Presumably by keeping the reachable
> working set smaller.
>
> 4) We could definitely do better with the when-to-delete heuristic.  For
> instance, not deleting if there's been no GC since the previous deletion
> event.  That would reduce the deletions I observed in the 70542 testcase, as
> there were many more of them than GCs.
>
> comments?
>
> nathan

[PATCH] c++/70594 debug info differences

[Nathan Sidwell]

This proto patch addresses 70594, where the constexpr machinery causes 
differences in -fcompare-debug checking.  I'm looking for initial comments about 
the approach this patch is taking.


As described in the comments of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594  the change is being caused 
by differing GC points with and without debug info generation.  We generate 
different patterns of DECL_UID.


With Patrick's patch to address 70542 constexpr_call_table is now gc-deletable, 
and he introduced a cache for constexpr fn bodies, also gc-deletable.


This patch changes things so that both constexpr_call_table and 
fundef_copies_table are no longer gc-deletable.  Instead we simply count the 
size of the constexpr_call_table and manually delete it if it gets 'too big'.


The bulk of this patch is adding gc machinery to the fundef_copies_table_t type, 
as we now need to walk it during GC.


I modified maybe_initialize_constexpr_call_table to delete the table if it is 
too big, and we're at the outermost level of a constexpr call evaluation stack. 
 I picked a hard coded value for reasons I discuss below.  It would be nice to 
delete the table only if we discover we're going to do call evaluation (rather 
than hit an already cached value), but that was a little awkward.  So I punted.


I've added a new hook to delete these two tables at the end of parsing.  This is 
called from c_parse_final_cleanup.  There's no point having them hang around 
during the rest of compilation.


In addition to bootstrapping and testing, I repeated Patrick's experiment of 
building dwarf2out.c with -fcompare-debug.  No changes were observed.


Observations:

1) I think this approach is not globally best.  We're inventing another 
memory-usage related heuristic, rather than relying on the already available GC 
machinery.  That's why I've gone with a hard coded value for now, rather than 
add a new user-frobable  param.  The right solution is to stop generating new 
DECL_UIDs when copying fns for constexpr evaluation.  IIUC the UID is being used 
to map decls to values.  I don't see why we can't just use the (copied) DECL's 
address as a key to find its associated value (but I've not investigated that 
approach).  It's not like we particularly care about the stability of that 
mapping between different compilations on different machines -- it doesn't 
affect code generation.  Reproducibility of a class of compiler bugs would be 
reduced, but probably only marginally so,


2) The constexpr_call_table and fundef_copies_table are closely related data 
structures.  I think it would be cleaner to combine these into a single data 
structure.  Possibly along with the call_stack and associated variables.  Such a 
cleanup would be good even if we don't go with this approach to the defect, but 
could wait until 7.0.  If we go with this approach, IMHO it would be good to do 
some of this merging now.


3) In experimenting I looked at the 70542 testcase.  Allowing the caches to grow 
unboundedly we end up with about 500K constexpr_call_table slots used, 20 
fundef_copies slots all taking up about 55MB (out of about 65MB) of gc-able memory.


In the 70594 testcase we use 127 constexpr_call_table slots, and about 1MB of 
gcable  memory.


Picking a limit of 2 constexpr_call_table slots causes several reallocations 
and interestingly actually led to faster parsing for 70542 of 6.8 seconds rather 
than 7.0 seconds.  Presumably by keeping the reachable working set smaller.


4) We could definitely do better with the when-to-delete heuristic.  For 
instance, not deleting if there's been no GC since the previous deletion event. 
 That would reduce the deletions I observed in the 70542 testcase, as there 
were many more of them than GCs.


comments?

nathan
Index: cp/constexpr.c
===
--- cp/constexpr.c	(revision 234878)
+++ cp/constexpr.c	(working copy)
@@ -915,7 +915,7 @@ struct constexpr_ctx {
 /* A table of all constexpr calls that have been evaluated by the
compiler in this translation unit.  */
 
-static GTY ((deletable)) hash_table *constexpr_call_table;
+static GTY (()) hash_table *constexpr_call_table;
 
 static tree cxx_eval_constant_expression (const constexpr_ctx *, tree,
 	  bool, bool *, bool *, tree * = NULL);
@@ -956,19 +956,10 @@ constexpr_call_hasher::equal (constexpr_
   return lhs_bindings == rhs_bindings;
 }
 
-/* Initialize the constexpr call table, if needed.  */
-
-static void
-maybe_initialize_constexpr_call_table (void)
-{
-  if (constexpr_call_table == NULL)
-constexpr_call_table = hash_table::create_ggc (101);
-}
-
 /* The representation of a single node in the per-function freelist maintained
by FUNDEF_COPIES_TABLE.  */
 
-struct fundef_copy
+struct GTY((for_user)) fundef_copy
 {
   tree body;
   tree parms;
@@ -986,20 +977,63 @@ struct fundef_copy
that's keyed off of the original FUNCTION_DECL and whose value is the chain

[PATCH] Make distclean clean up more (PR70173)

[Segher Boessenkool]

Currently, distclean does not remove the libcc1, gnattools, and gotools
directories, and not the stage_final file either.  Fix that.

This finishes PR70173.

Tested on powerpc64-linux, --enable-languages=all,ada,go,obj-c++ ,
followed by "make distclean".  Is this okay for trunk?


Segher


2016-04-11  Segher Boessenkool  

PR bootstrap/70173
* Makefile.tpl (local-distclean): Delete the libcc1, gnattools,
and gotools directories.  Delete the stage_final file.
* Makefile.in: Regenerate.

---
 Makefile.in  | 5 +++--
 Makefile.tpl | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index a519a54..1522e39 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2316,7 +2316,7 @@ local-clean:
 
 local-distclean:
-rm -f Makefile config.status config.cache mh-frag mt-frag
-   -rm -f maybedep.tmp serdep.tmp
+   -rm -f maybedep.tmp serdep.tmp stage_final
-if [ "$(TARGET_SUBDIR)" != "." ]; then \
  rm -rf $(TARGET_SUBDIR); \
else true; fi
@@ -2328,7 +2328,8 @@ local-distclean:
-rm -f texinfo/doc/Makefile texinfo/po/POTFILES
-rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2>/dev/null
-rmdir texinfo/makeinfo texinfo/po texinfo/util 2>/dev/null
-   -rmdir fastjar gcc libiberty texinfo zlib 2>/dev/null
+   -rmdir fastjar gcc gnattools gotools libcc1 libiberty 2>/dev/null
+   -rmdir texinfo zlib 2>/dev/null
-find . -name config.cache -exec rm -f {} \; \; 2>/dev/null
 
 local-maintainer-clean:
diff --git a/Makefile.tpl b/Makefile.tpl
index 829f664..6b2eb6a 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -810,7 +810,7 @@ local-clean:
 
 local-distclean:
-rm -f Makefile config.status config.cache mh-frag mt-frag
-   -rm -f maybedep.tmp serdep.tmp
+   -rm -f maybedep.tmp serdep.tmp stage_final
-if [ "$(TARGET_SUBDIR)" != "." ]; then \
  rm -rf $(TARGET_SUBDIR); \
else true; fi
@@ -822,7 +822,8 @@ local-distclean:
-rm -f texinfo/doc/Makefile texinfo/po/POTFILES
-rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2>/dev/null
-rmdir texinfo/makeinfo texinfo/po texinfo/util 2>/dev/null
-   -rmdir fastjar gcc libiberty texinfo zlib 2>/dev/null
+   -rmdir fastjar gcc gnattools gotools libcc1 libiberty 2>/dev/null
+   -rmdir texinfo zlib 2>/dev/null
-find . -name config.cache -exec rm -f {} \; \; 2>/dev/null
 
 local-maintainer-clean:
-- 
1.9.3

Re: Fix pure/const discovery WRT interposition part 1

[Bernd Edlinger]

+  /* If this is a reference from symbol itself and there are no aliases, we
+ may be sure that the symbol was not interposed by soemthing else because
+ the symbol itself would be unreachable otherwise.  */

typo: s/soemthing/something/

Bernd.

[PATCH] [FIX PR c/48116] -Wreturn-type does not work as advertised

[Prasad Ghangal]

Hi!

This is proposed patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116 (-Wreturn-type does
not work as advertised)

Currently gcc doesn't give any warning with -Wreturn-type or -Wall
option for test cases like :

void x (void) { }
void y(void) { return x(); }


applying this patch gives:

$gcc foo.c -S -Wreturn-type
foo.c: In function ‘y’:
foo.c:2:23: warning: ISO C forbids ‘return’ with expression, in
function returning void [-Wreturn-type]
 void y(void) { return x(); }
   ^~~
foo.c:2:6: note: declared here
 void y(void) { return x(); }
  ^

$gcc foo.c -S -Wall
foo.c: In function ‘y’:
foo.c:2:23: warning: ISO C forbids ‘return’ with expression, in
function returning void [-Wreturn-type]
 void y(void) { return x(); }
   ^~~
foo.c:2:6: note: declared here
 void y(void) { return x(); }
  ^

$gcc foo.c -S -pedantic
foo.c: In function ‘y’:
foo.c:2:23: warning: ISO C forbids ‘return’ with expression, in
function returning void [-Wpedantic]
 void y(void) { return x(); }
   ^~~
foo.c:2:6: note: declared here
 void y(void) { return x(); }
  ^


I have fully bootstrapped and tested on x86_64-pc-linux.



Thanks,
Prasad Ghangal
Index: gcc/c/ChangeLog
===
diff --git a/trunk/gcc/c/ChangeLog b/trunk/gcc/c/ChangeLog
--- a/trunk/gcc/c/ChangeLog	(revision 234872)
+++ b/trunk/gcc/c/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-04-11  Prasad Ghangal  
+
+	PR c/48116
+	* c-typeck.c (c_finish_return): Check -Wreturn-type option
+
 2016-04-04  Marek Polacek  
 
 	PR c/70307
Index: gcc/c/c-typeck.c
===
diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c
--- a/trunk/gcc/c/c-typeck.c	(revision 234872)
+++ b/trunk/gcc/c/c-typeck.c	(working copy)
@@ -9680,6 +9680,10 @@
 	warned_here = pedwarn
 	  (xloc, 0,
 	   "% with a value, in function returning void");
+  else if (warn_return_type)
+	warned_here = warning_at
+	  (xloc, OPT_Wreturn_type, "ISO C forbids "
+	   "% with expression, in function returning void");
   else
 	warned_here = pedwarn
 	  (xloc, OPT_Wpedantic, "ISO C forbids "
Index: gcc/testsuite/ChangeLog
===
diff --git a/trunk/gcc/testsuite/ChangeLog b/trunk/gcc/testsuite/ChangeLog
--- a/trunk/gcc/testsuite/ChangeLog	(revision 234872)
+++ b/trunk/gcc/testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-04-11  Prasad Ghangal  
+
+	PR c/48116
+	* gcc.dg/pr48116.c: New test
+
 2016-04-10  Paolo Carlini  
 
 	PR c++/69066
Index: gcc/testsuite/gcc.dg/pr48116.c
===
diff --git a/trunk/gcc/testsuite/gcc.dg/pr48116.c b/trunk/gcc/testsuite/gcc.dg/pr48116.c
new file mode 10644
--- /dev/null	(revision 0)
+++ b/trunk/gcc/testsuite/gcc.dg/pr48116.c	(working copy)
@@ -0,0 +1,6 @@
+/* PR c/48116 */
+/* { dg-do compile } */
+/* { dg-options "-Wreturn-type" } */
+
+static void f() {}
+static void g() { return f(); }  /* { dg-warning "forbids 'return'" "missing return" } */
Index: libatomic/ChangeLog
===
diff --git a/trunk/libatomic/ChangeLog b/trunk/libatomic/ChangeLog
--- a/trunk/libatomic/ChangeLog	(revision 234872)
+++ b/trunk/libatomic/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-04-11  Prasad Ghangal  
+
+	PR c/48116
+	* flag.c (atomic_flag_clear_explicit): Remove return 
+
 2016-01-06  Szabolcs Nagy  
 
 	PR other/67627
Index: libatomic/flag.c
===
diff --git a/trunk/libatomic/flag.c b/trunk/libatomic/flag.c
--- a/trunk/libatomic/flag.c	(revision 234872)
+++ b/trunk/libatomic/flag.c	(working copy)
@@ -60,5 +60,5 @@
 (atomic_flag_clear_explicit) (volatile atomic_flag *object,
 			  memory_order order)
 {
-  return atomic_flag_clear_explicit (object, order);
+  atomic_flag_clear_explicit (object, order);
 }
Index: libgomp/ChangeLog
===
diff --git a/trunk/libgomp/ChangeLog b/trunk/libgomp/ChangeLog
--- a/trunk/libgomp/ChangeLog	(revision 234872)
+++ b/trunk/libgomp/ChangeLog	(working copy)
@@ -1,3 +1,12 @@
+2016-04-11  Prasad Ghangal  
+	
+	PR c/48116
+	* fortran.c (omp_set_default_device_): Remove return 
+	* fortran.c (omp_set_default_device_8_): Likewise
+	* target.c (GOMP_target): Split return and call on separate lines
+	* target.c (GOMP_target_data): Likewise
+	* target.c (GOMP_taget_data_ext): Likewise
+
 2016-04-08  Cesar Philippidis  
 
 	PR lto/70289
Index: libgomp/fortran.c
===
diff --git 

Re: [PATCH 2/3] [graphite] add array access function in the right order

[Sebastian Pop]

On Sat, Apr 9, 2016 at 11:00 AM, Tom de Vries  wrote:
> On 09/12/15 19:26, Sebastian Pop wrote:
>>
>> we used to add the access functions in the wrong order, Fortran style,
>> leading to unprofitable interchanges.
>> ---
>>   gcc/graphite-sese-to-poly.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
>> index 887c212..480c552 100644
>> --- a/gcc/graphite-sese-to-poly.c
>> +++ b/gcc/graphite-sese-to-poly.c
>> @@ -912,7 +912,7 @@ pdr_add_memory_accesses (isl_map *acc, dr_info )
>> for (i = 0; i < nb_subscripts; i++)
>>   {
>> isl_pw_aff *aff;
>> -  tree afn = DR_ACCESS_FN (dr, nb_subscripts - 1 - i);
>> +  tree afn = DR_ACCESS_FN (dr, i);
>>
>> aff = extract_affine (scop, afn,
>> isl_space_domain (isl_map_get_space (acc)));
>>
>
> Hi,
>
> I think the fix for PR68953 (
> https://gcc.gnu.org/viewcvs/gcc?view=revision=234851 ) undoes this
> fix.
>
> What problem was this patch intending to address?
>
> In other words, have I re-introduced a problem by fixing PR68953 ?
>

>From the commit message of r234851, it was an interchange profitability
that triggered the change.  I think there is still a problem in the way we are
parsing arrays in C vs. Fortran.  It is good that now we have the correctness
testcase that you added with the patch.

Thanks,
Sebastian

Re: C++ PATCH for implicit abi_tag on template member function

[Jason Merrill]

On 04/06/2016 12:22 PM, Jason Merrill wrote:

We were incorrectly omitting the ABI tag on the instantiation of this
member function because we were setting the tags on the instantiation
and looking for them on the temploid.


Still not quite right...

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


commit 6e6a82cf6bad124a9d97622a6f42968baf72ba2b
Author: Jason Merrill 
Date:   Sat Apr 9 12:07:26 2016 -0400

	* mangle.c (decl_is_template_id): The template itself counts as a
	template-id.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 5d38373..0e44409 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -264,9 +264,9 @@ static void write_java_integer_type_codes (const tree);
 #define write_unsigned_number(NUMBER)	\
   write_number ((NUMBER), /*unsigned_p=*/1, 10)
 
-/* If DECL is a template instance, return nonzero and, if
-   TEMPLATE_INFO is non-NULL, set *TEMPLATE_INFO to its template info.
-   Otherwise return zero.  */
+/* If DECL is a template instance (including the uninstantiated template
+   itself), return nonzero and, if TEMPLATE_INFO is non-NULL, set
+   *TEMPLATE_INFO to its template info.  Otherwise return zero.  */
 
 static int
 decl_is_template_id (const tree decl, tree* const template_info)
@@ -290,7 +290,8 @@ decl_is_template_id (const tree decl, tree* const template_info)
 {
   /* Check if this is a primary template.  */
   if (DECL_LANG_SPECIFIC (decl) != NULL
-	  && DECL_USE_TEMPLATE (decl)
+	  && VAR_OR_FUNCTION_DECL_P (decl)
+	  && DECL_TEMPLATE_INFO (decl)
 	  && PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (decl))
 	  && TREE_CODE (decl) != TEMPLATE_DECL)
 	{
diff --git a/gcc/testsuite/g++.dg/abi/abi-tag20.C b/gcc/testsuite/g++.dg/abi/abi-tag20.C
new file mode 100644
index 000..229c170
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/abi-tag20.C
@@ -0,0 +1,15 @@
+// { dg-do compile { target c++11 } }
+// { dg-final { scan-assembler "_ZN1B1gIcEEN7__cxx111XEv" } }
+
+inline namespace __cxx11 __attribute__((__abi_tag__ ("ABI_TAG"))) {
+  class X {};
+}
+struct B {
+  X f();
+  template  X g();
+};
+int main() {
+  B b;
+  b.g();
+  return 0;
+}

Re: [PATCH][ARM] PR target/70566 Check that condition register is dead in tst-imm -> lsls-imm Thumb2 peepholes

[Kyrill Tkachov]

On 08/04/16 10:30, Richard Earnshaw (lists) wrote:

On 07/04/16 15:51, Kyrill Tkachov wrote:

Hi all,

In this wrong-code PR we have a Thumb2 peephole transforming:
 tstr3, #2
 bne.L3
 beq.L6

into:
 lslsr3, r3, #30  // LSLS is shorter than TST in Thumb2
 bmi.L3
 beq.L6

that is, the branch following the extract+compare has its condition
properly changed but the
following branch doesn't get updated to check the opposite condition of
MI (PL).
Since the peepholes in thumb2.md only see the compare and a single
branch the solution,
suggested by Richard, is to guard those peepholes on the condition that
the condition register
is dead after the first branch. This patch does that and with it we no
longer perform the transformation
on the testcase. I've checked manually that we still perform the
peephole when the condition register
is indeed dead after the sequence.

Bootstrapped and tested on on arm-none-linux-gnueabihf with
--with-mode=thumb as this affects only
Thumb2 codegen.

Ok for trunk?

This PR also affects GCC 5 and 4.9 so I'll be testing the patch there as
well.

Thanks,
Kyrill


2016-04-07  Kyrylo Tkachov  

 PR target/70566
 * config/arm/thumb2.md (tst + branch-> lsls + branch
 peephole below *orsi_not_shiftsi_si): Require that condition
 register is dead after the peephole.
 (second peephole after the above): Likewise.

2016-04-07  Kyrylo Tkachov  

 PR target/70566
 * gcc.c-torture/execute/pr70566.c: New test.


OK.


Thanks, the patch has passed bootstrap and test on the GCC 5 and 4.9
branches. Is it ok to backport it there as well?

Thanks,
Kyrill



R.

Fix pure/const discovery WRT interposition part 1

[Jan Hubicka]

Hi,
this is preparation patch for fix for PR ipa/70018.  It adds
binds_to_current_def predicate that works just like decl_binds_to_current_def
but at symtab level.  The main change is that local binding depends on user
(if function refers itself and has no aliases, it must bind to current def
and likewise within the comdat group).

With followup patch I plan to disable const discovery for functions that are
not binding to current def (most C++ inlines without LTO!) and at least with
this chnage the patch does not disable detection on all self recursive
functions (which is surprisingly common case for libreoffice). See PR log for
details.

Next stage1 we can work harder and implement tracking of existence of memory
references down from pre-gimple stages.

The new code path with REF parameter is unused otherwise and the patch has
no effect by itself thus.

Bootstrapped/regtested x86_64-linux

Honza

PR ipa/70018
* cgraph.c (cgraph_node::get_availability): Add REF parameter.
(cgraph_node::function_symbol): Likewise.
(cgraph_node::function_or_virtual_thunk_symbol): Likewise.
* cgraph.h (symtab_node::get_availabbility): Add REF parameter.
(symtab_node::ultimate_alias_target): Add REF parameter.
(symtab_node::binds_to_current_def_p): Declare.
(symtab_node;:ultimate_alias_target_1): Add REF parameter.
(cgraph_node::function_symbol): Likewise.
(cgraph_node::function_or_virtual_thunk_symbol): Likewise.
(cgraph_node::get_availability): Likewise.
(cgraph_edge::binds_to_current_def_p): New inline function.
(varpool_node::get_availability): Add REF parameter.
(varpool_node::ultimate_alias_target): Likewise.
* symtab.c (symtab_node::ultimate_alias_target_1): Likewise.
(symtab_node::binds_to_current_def_p): Likewise.
* varpool.c (varpool_node::get_availability): Likewise.
Index: cgraph.c
===
--- cgraph.c(revision 234761)
+++ cgraph.c(working copy)
@@ -2209,19 +2209,36 @@ cgraph_node::unnest (void)
 /* Return function availability.  See cgraph.h for description of individual
return values.  */
 enum availability
-cgraph_node::get_availability (void)
+cgraph_node::get_availability (symtab_node *ref)
 {
+  if (ref)
+{
+  cgraph_node *cref = dyn_cast  (ref);
+  if (cref)
+   ref = cref->global.inlined_to;
+}
   enum availability avail;
   if (!analyzed)
 avail = AVAIL_NOT_AVAILABLE;
   else if (local.local)
 avail = AVAIL_LOCAL;
+  else if (global.inlined_to)
+avail = AVAIL_AVAILABLE;
   else if (transparent_alias)
-ultimate_alias_target ();
+ultimate_alias_target (, ref);
   else if (lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)))
 avail = AVAIL_INTERPOSABLE;
   else if (!externally_visible)
 avail = AVAIL_AVAILABLE;
+  /* If this is a reference from symbol itself and there are no aliases, we
+ may be sure that the symbol was not interposed by soemthing else because
+ the symbol itself would be unreachable otherwise.
+
+ Also comdat groups are always resolved in groups.  */
+  else if ((this == ref && !has_aliases_p ())
+   || (ref && get_comdat_group ()
+   && get_comdat_group () == ref->get_comdat_group ()))
+avail = AVAIL_AVAILABLE;
   /* Inline functions are safe to be analyzed even if their symbol can
  be overwritten at runtime.  It is not meaningful to enforce any sane
  behavior on replacing inline function by different body.  */
@@ -2232,11 +2249,7 @@ cgraph_node::get_availability (void)
  care at least of two notable extensions - the COMDAT functions
  used to share template instantiations in C++ (this is symmetric
  to code cp_cannot_inline_tree_fn and probably shall be shared and
- the inlinability hooks completely eliminated).
-
- ??? Does the C++ one definition rule allow us to always return
- AVAIL_AVAILABLE here?  That would be good reason to preserve this
- bit.  */
+ the inlinability hooks completely eliminated).  */
 
   else if (decl_replaceable_p (decl) && !DECL_EXTERNAL (decl))
 avail = AVAIL_INTERPOSABLE;
@@ -3250,24 +3286,28 @@ cgraph_node::verify_cgraph_nodes (void)
 
 /* Walk the alias chain to return the function cgraph_node is alias of.
Walk through thunks, too.
-   When AVAILABILITY is non-NULL, get minimal availability in the chain.  */
+   When AVAILABILITY is non-NULL, get minimal availability in the chain.
+   When REF is non-NULL, assume that reference happens in symbol REF
+   when determining the availability.  */
 
 cgraph_node *
-cgraph_node::function_symbol (enum availability *availability)
+cgraph_node::function_symbol (enum availability *availability,
+ struct symtab_node *ref)
 {
-  cgraph_node *node = ultimate_alias_target (availability);
+  cgraph_node *node = ultimate_alias_target (availability, ref);
 
   

Re: [PATCH], Re-fix PR 70381 (disable -mfloat128 by default) and add workaround for PR 70589

[David Edelsohn]

On Thu, Apr 7, 2016 at 7:44 PM, Michael Meissner
 wrote:
> After applying the fix for PR 70381 to not enable -mfloat128 by default, I
> discovered the IEEE 128-bit floating point emulation routines in libgcc are no
> longer being built.
>
> The reason for this is the configuration test involved compiling this program:
>
> #pragma GCC target ("vsx,float128")
> __float128 add (__float128 *a) { return *a + *(a+1); }
>
> to see if the __float128 support was enabled.  Unfortunately, I discovered 
> that
> you can't currently set/disable float128 via the target option attribute or
> target pragmas. This is due to the fact that if -mfloat128 is disabled, the
> __float128 and __ibm128 keywords are not created.
>
> I raised this as a separate bug (70589).
>
> This patch does several things:
>
>1)   It disables using float128 in target attributes or target pragmas.
>
>2)   It fixes the configure test for software emulation to just see if the
> ISA 2.06 (vsx) instruction set is available. The makefile options in
> the PowerPC libgcc build ensures that -mfloat128 is used. I used
> similar logic to detect ISA 3.0 to see if we have support for the IEEE
> 128-bit floating point hardware.
>
>3)   I updated the documentation for -mfloat128.
>
>4)   I added two executable tests to verify that the float emulation is
> correct.  In working on adding the tests, I discovered I had the 
> return
> value from main inverted, and the test would fail.
>
> I have run a boostrap build and a make check to verify that the IEEE 128-bit
> floating point emulator in libgcc is indeed built. Are these patches ok to
> install in the GCC trunk?
>
> [gcc]
> 2016-04-07  Michael Meissner  
>
> PR target/70589
> * config/rs6000/rs6000.c (rs6000_opt_masks): Disable using the
> target attribute and pragma from changing the -mfloat128
> and -mfloat128-hardware options.
>
> * doc/extend.texi (Additional Floating Types): Document PowerPC
> __float128 restrictions.
>
> [libgcc]
> 2016-04-07  Michael Meissner  
>
> PR target/70381
> * configure.ac (powerpc*-*-linux*): Rework tests to build
> __float128 emulation routines to not depend on using #pragma GCC
> target to enable -mfloat128.
> * configure: Regnerate.
>
> [gcc/testsuite]
> 2016-04-07  Michael Meissner  
>
> PR target/70381
> * gcc.target/powerpc/float128-1.c: New tests to make sure the
> __float128 emulator is built and runs.
> * gcc.target/powerpc/float128-1.c: Likewise.
>
> * lib/target-supports.exp (check_ppc_float128_sw_available):
> Rework tests for __float128 software and hardware
> availability. Fix exit condition to return 0 on success.

This is okay.

Thanks, David

Re: rs6000 stack_tie mishap again

[Olivier Hainque]

> On Mar 28, 2016, at 19:41 , Richard Henderson  wrote:
> 
> But I expect for stage4, the best solution is to strengthen the stack_tie 
> pattern to block all memory.  Early scheduling of the stack frame 
> deallocation (a simple logic insn) can't really be that important to 
> performance.

Something like the attached patch, at least for next stage1 until the
more general issue is sorted out ?

Only basic testing at this point. I can do more if considered appropriate.

Thanks for your feedback,

With Kind Regards,

Olivier

* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Add a
(clobber mem:BLK (scratch)) to the set of effects, blocking
all memory accesses.



stronger_rs6000_tie.diff
Description: Binary data

Re: [Patch AArch64 0/3] Fix PR70133

[Richard Earnshaw (lists)]

On 06/04/16 11:10, James Greenhalgh wrote:
> Hi,
> 
> This patch set fixes PR70133, which is a bug in the way we handle extension
> strings after using -march or -mcpu=native. In investigating this, I found
> other bugs in the way we communicate architceture intention between the
> compiler and the assembler.
> 
> This patch set cleans this up somewhat.
> 
> Tested on a Cortex-A57 based board, a Cortex-A57/Cortex-A53 big.LITTLE
> based board, a Cortex-A72/Cortex-A53 big.LITTLE based board and an xgene1
> based board. I don't have access to the board in the bug report, but I fed
> representative data to the detection code to check that worked too.
> 
> The patch set goes as follows...
> 
> [Patch AArch64 1/3] Enable CRC by default for armv8.1-a
> 
>   The assmebler will enable CRC by default for -march=armv8.1-a, and we should
>   follow that expectation in GCC.
> 
> [Patch AArch64 2/3] Rework the code to print extension strings (pr70133)
> 
>   There are a number of bugs that come from the way we enable and disable
>   extension strings. Rework this code so we always put out a safe and minimal
>   set of flags for a -march/-mcpu input.
> 
> [Patch AArch64 3/3] Fix up for pr70133
> 
>   Use the infratructure added in 2/3 to fix the PR.
> 
> OK for trunk?
> 

OK for all of these.

R.

> Thanks,
> James
> 
> ---
> [Patch AArch64 1/3] Enable CRC by default for armv8.1-a
> 
> 2016-04-06  James Greenhalgh  
> 
>   * config/aarch64/aarch64.h (AARCH64_FL_FOR_ARCH8_1): Also add
>   AARCH64_FL_CRC.
> 
> 
> [Patch AArch64 2/3] Rework the code to print extension strings (pr70133)
> 
> gcc/
> 
> 2016-04-06  James Greenhalgh  
> 
>   PR target/70133
>   * config/aarch64/aarch64-common.c (aarch64_option_extension): Keep
>   track of a canonical flag name.
>   (all_extensions): Likewise.
>   (arch_to_arch_name): Also track extension flags enabled by the arch.
>   (all_architectures): Likewise.
>   (aarch64_parse_extension): Move to here.
>   (aarch64_get_extension_string_for_isa_flags): Take a new argument,
>   rework.
>   (aarch64_rewrite_selected_cpu): Update for above change.
>   * config/aarch64/aarch64-option-extensions.def: Rework the way flags
>   are handled, such that the single explicit value enabled by an
>   extension is kept seperate from the implicit values it also enables.
>   * config/aarch64/aarch64-protos.h (aarch64_parse_opt_result): Move
>   to here.
>   (aarch64_parse_extension): New.
>   * config/aarch64/aarch64.c (aarch64_parse_opt_result): Move from
>   here to config/aarch64/aarch64-protos.h.
>   (aarch64_parse_extension): Move from here to
>   common/config/aarch64/aarch64-common.c.
>   (aarch64_option_print): Update.
>   (aarch64_declare_function_name): Likewise.
>   (aarch64_start_file): Likewise.
>   * config/aarch64/driver-aarch64.c (arch_extension): Keep track of
>   the canonical flag for extensions.
>   * config.gcc (aarch64*-*-*): Extend regex for capturing extension
>   flags.
> 
> gcc/testsuite/
> 
> 2016-04-06  James Greenhalgh  
> 
>   PR target/70133
>   * gcc.target/aarch64/mgeneral-regs_4.c: Fix expected output.
>   * gcc.target/aarch64/target_attr_15.c: Likewise.
> 
> [Patch AArch64 3/3] Fix up for pr70133
> 
> 2016-04-06  James Greenhalgh  
> 
>   PR target/70133
> 
>   * config/aarch64/driver-aarch64.c
>   (aarch64_get_extension_string_for_isa_flags): New.
>   (arch_extension): Rename to...
>   (aarch64_arch_extension): ...This.
>   (ext_to_feat_string): Rename to...
>   (aarch64_extensions): ...This.
>   (aarch64_core_data): Keep track of architecture extension flags.
>   (cpu_data): Rename to...
>   (aarch64_cpu_data): ...This.
>   (aarch64_arch_driver_info): Keep track of architecture extension
>   flags.
>   (get_arch_name_from_id): Rename to...
>   (get_arch_from_id): ...This, change return type.
>   (host_detect_local_cpu): Update and reformat for renames, handle
>   extensions through common infrastructure.
> 

[wwwdocs] index.html -- remove obsolete text/css section

[Gerald Pfeifer]

This has not been active for some months, but somehow survived.

Gone it is, now.

Gerald

Index: index.html 
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1000
diff -u -r1.1000 index.html
--- index.html  10 Apr 2016 08:42:39 -  1.1000
+++ index.html  11 Apr 2016 08:00:54 -
@@ -2,9 +2,6 @@
 
 
 GCC, the GNU Compiler Collection
-
-  h2 { font-size: 1.2em; margin-bottom:1%; }
-
 
 
 

Re: [Patch AArch64 3/3] Fix up for pr70133

[James Greenhalgh]

> Hi,
> 
> Having updated the way we parse and output extension strings, now we just
> need to wire up the native detection to use these new features.
> 
> In doing some cleanup and rename I ended up fixing 8-spaces to tabs in
> about half the file. I've done the rest while I'm here to save us from
> some a mixed-style file.

Richard Earnshaw pointed out off-list that it was perhaps a little
anti-social to ask a reviewer to wade through all the tabs-to-spaces changes
to find the real content of this patch. I can't disagree with that.

Here's the diff regenerated with '-w' to skip the whitespace changes.

OK?

Thanks,
James

> ---
> 2016-04-06  James Greenhalgh  
> 
>   PR target/70133
> 
>   * config/aarch64/driver-aarch64.c
>   (aarch64_get_extension_string_for_isa_flags): New.
>   (arch_extension): Rename to...
>   (aarch64_arch_extension): ...This.
>   (ext_to_feat_string): Rename to...
>   (aarch64_extensions): ...This.
>   (aarch64_core_data): Keep track of architecture extension flags.
>   (cpu_data): Rename to...
>   (aarch64_cpu_data): ...This.
>   (aarch64_arch_driver_info): Keep track of architecture extension
>   flags.
>   (get_arch_name_from_id): Rename to...
>   (get_arch_from_id): ...This, change return type.
>   (host_detect_local_cpu): Update and reformat for renames, handle
>   extensions through common infrastructure.
> 
diff --git a/gcc/config/aarch64/driver-aarch64.c b/gcc/config/aarch64/driver-aarch64.c
index 8925ec1..ce771ec 100644
--- a/gcc/config/aarch64/driver-aarch64.c
+++ b/gcc/config/aarch64/driver-aarch64.c
@@ -18,9 +18,16 @@
.  */
 
 #include "config.h"
+#define INCLUDE_STRING
 #include "system.h"
+#include "coretypes.h"
+#include "tm.h"
 
-struct arch_extension
+/* Defined in common/config/aarch64/aarch64-common.c.  */
+std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
+			unsigned long);
+
+struct aarch64_arch_extension
 {
   const char *ext;
   unsigned int flag;
@@ -29,7 +36,7 @@ struct arch_extension
 
 #define AARCH64_OPT_EXTENSION(EXT_NAME, FLAG_CANONICAL, FLAGS_ON, FLAGS_OFF, FEATURE_STRING) \
   { EXT_NAME, FLAG_CANONICAL, FEATURE_STRING },
-static struct arch_extension ext_to_feat_string[] =
+static struct aarch64_arch_extension aarch64_extensions[] =
 {
 #include "aarch64-option-extensions.def"
 };
@@ -42,15 +49,16 @@ struct aarch64_core_data
   const char* arch;
   const char* implementer_id;
   const char* part_no;
+  const unsigned long flags;
 };
 
 #define AARCH64_CORE(CORE_NAME, CORE_IDENT, SCHED, ARCH, FLAGS, COSTS, IMP, PART) \
-  { CORE_NAME, #ARCH, IMP, PART },
+  { CORE_NAME, #ARCH, IMP, PART, FLAGS },
 
-static struct aarch64_core_data cpu_data [] =
+static struct aarch64_core_data aarch64_cpu_data[] =
 {
 #include "aarch64-cores.def"
-  { NULL, NULL, NULL, NULL }
+  { NULL, NULL, NULL, NULL, 0 }
 };
 
 #undef AARCH64_CORE
@@ -59,37 +67,37 @@ struct aarch64_arch_driver_info
 {
   const char* id;
   const char* name;
+  const unsigned long flags;
 };
 
 #define AARCH64_ARCH(NAME, CORE, ARCH_IDENT, ARCH_REV, FLAGS) \
-  { #ARCH_IDENT, NAME  },
+  { #ARCH_IDENT, NAME, FLAGS },
 
 static struct aarch64_arch_driver_info aarch64_arches[] =
 {
 #include "aarch64-arches.def"
-  {NULL, NULL}
+  {NULL, NULL, 0}
 };
 
 #undef AARCH64_ARCH
 
-/* Return the full architecture name string corresponding to the
-   identifier ID.  */
+/* Return an aarch64_arch_driver_info for the architecture described
+   by ID, or NULL if ID describes something we don't know about.  */
 
-static const char*
-get_arch_name_from_id (const char* id)
+static struct aarch64_arch_driver_info*
+get_arch_from_id (const char* id)
 {
   unsigned int i = 0;
 
   for (i = 0; aarch64_arches[i].id != NULL; i++)
 {
   if (strcmp (id, aarch64_arches[i].id) == 0)
-return aarch64_arches[i].name;
+	return _arches[i];
 }
 
   return NULL;
 }
 
-
 /* Check wether the string CORE contains the same CPU part numbers
as BL_STRING.  For example CORE="{0xd03, 0xd07}" and BL_STRING="0xd07.0xd03"
should return true.  */
@@ -142,7 +150,7 @@ host_detect_local_cpu (int argc, const char **argv)
 {
   const char *arch_id = NULL;
   const char *res = NULL;
-  static const int num_exts = ARRAY_SIZE (ext_to_feat_string);
+  static const int num_exts = ARRAY_SIZE (aarch64_extensions);
   char buf[128];
   FILE *f = NULL;
   bool arch = false;
@@ -156,6 +164,8 @@ host_detect_local_cpu (int argc, const char **argv)
   unsigned int n_imps = 0;
   bool processed_exts = false;
   const char *ext_string = "";
+  unsigned long extension_flags = 0;
+  unsigned long default_flags = 0;
 
   gcc_assert (argc);
 
@@ -184,14 +194,15 @@ host_detect_local_cpu (int argc, const char **argv)
 {
   if (strstr (buf, "implementer") != NULL)
 	{
-	  for (i = 0; cpu_data[i].name != NULL; i++)
-	if (strstr (buf, cpu_data[i].implementer_id) != NULL
-   

Re: [gomp4] Remove superfluous passes in kernels pass list

[Jakub Jelinek]

On Mon, Apr 11, 2016 at 08:30:09AM +0200, Tom de Vries wrote:
> Hi,
> 
> this patch removes passes from the kernels pass list on gomp-4_0-branch,
> that are not present in the kernels pass list on trunk.
> 
> Bootstrapped and reg-tested on x86-64.
> 
> Committed to trunk.

You mean committed to branch ;)

Jakub

Re: [PATCH] libcc1: Clean compiler-name.h (PR70173)

[Jakub Jelinek]

On Sun, Apr 10, 2016 at 08:44:20PM -0500, Segher Boessenkool wrote:
> Ping?

Ok for stage4.

> > 2016-04-04  Segher Boessenkool  
> > 
> > libcc1/
> > PR bootstrap/70173
> > * Makefile.am (MOSTLYCLEANFILES): New, add compiler-name.h .
> > (compiler-name.h): Shorten recipe so that it fits the line.
> > * Makefile.in: Regenerate.

Jakub

Re: [wwwdocs] Simplify gcc-4.5/cxx0x_status.html (and convert to global CSS)

[Gerald Pfeifer]

On Wed, 6 Apr 2016, Gerald Pfeifer wrote:
> I plan on tackling the other C++ status pages in the coming days
> as well.

And this is the version for GCC 4.5.

Applied.

Only two more to go...

Gerald

Index: gcc-4.5/cxx0x_status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/cxx0x_status.html,v
retrieving revision 1.11
diff -u -r1.11 cxx0x_status.html
--- gcc-4.5/cxx0x_status.html   5 Dec 2011 21:51:05 -   1.11
+++ gcc-4.5/cxx0x_status.html   10 Apr 2016 08:08:16 -
@@ -2,13 +2,6 @@
 
 
   Status of Experimental C++0x Support in GCC 4.5
-  
-/*  */
-  
 
 
 
@@ -36,7 +29,7 @@
 
 
 
-  
+  
 
   Language Feature
   Proposal
@@ -45,320 +38,322 @@
 
   Rvalue references
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html;>N2118
-   Yes
+   Yes
 
 
   Rvalue references for *this
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm;>N2439
-  No
+  No
 
 
   Initialization of class objects by rvalues
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html;>N1610
-  Yes
+  Yes
 
 
   Non-static data member initializers
   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2756.htm;>N2756
-  No
+  No
 
 
   Variadic templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf;>N2242
-   Yes
+   Yes
 
 
   Extending variadic template template 
parameters
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf;>N2555
-   Yes
+   Yes
 
 
   Initializer lists
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm;>N2672
-   Yes
+   Yes
 
 
   Static assertions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html;>N1720
-   Yes
+   Yes
 
 
   auto-typed variables
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf;>N1984
-   Yes
+   Yes
 
 
   Multi-declarator auto
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf;>N1737
-   Yes
+   Yes
 
 
   Removal of auto as a storage-class 
specifier
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2546.htm;>N2546
-   Yes
+   Yes
 
 
   New function declarator syntax
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm;>N2541
-   Yes
+   Yes
 
 
   New wording for C++0x lambdas
   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2927.pdf;>N2927
-  Yes
+  Yes
 
 
   Declared type of an expression
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf;>N2343
-   Yes
+   Yes
 
 
   Right angle brackets
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html;>N1757
-   Yes
+   Yes
 
 
   Default template arguments for function templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226;>DR226
-   Yes
+   Yes
 
 
   Solving the SFINAE problem for expressions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html;>DR339
-   Yes
+   Yes
 
 
   Template aliases
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf;>N2258
-  No
+  No
 
 
   Extern templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm;>N1987
-   Yes
+   Yes
 
 
   Null pointer constant
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf;>N2431
-  No
+  No
 
 
   Strongly-typed enums
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf;>N2347
-   Yes
+   Yes
 
 
   Forward declarations for enums
   
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf;>N2764
   
-  No
+  No
 
 
   Generalized attributes
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf;>N2761
-  No
+  No
 
 
   Generalized constant expressions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf;>N2235
-  No
+  No
 
 
   Alignment support
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf;>N2341
-  No
+  No
 
 
 
 
   Delegating constructors
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf;>N1986
-  No
+  No
 
 
   Inheriting constructors
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm;>N2540
-  No
+  No
 
 
   Explicit conversion operators

[gomp4] Remove superfluous passes in kernels pass list

[Tom de Vries]

Hi,

this patch removes passes from the kernels pass list on gomp-4_0-branch, 
that are not present in the kernels pass list on trunk.


Bootstrapped and reg-tested on x86-64.

Committed to trunk.

Thanks,
- Tom
Remove superfluous passes in kernels pass list

2016-04-11  Tom de Vries  

	* passes.def: Remove superfluous passes from kernels pass list.
	* tree-ssa-loop.c (pass_scev_cprop::clone, pass_tree_loop_init::clone)
	(pass_tree_loop_done::clone): Remove function.

	* g++.dg/tree-ssa/pr19637.C: Update for removing dominator passes.
	* g++.dg/tree-ssa/pr61009.C: Same.
	* g++.dg/tree-ssa/ssa-dom.C: Same.
	* gcc.dg/pr20115-1.c: Same.
	* gcc.dg/tree-prof/20050826-2.c: Same.
	* gcc.dg/tree-prof/cmpsf-1.c: Same.
	* gcc.dg/tree-ssa/20030530-2.c: Same.
	* gcc.dg/tree-ssa/20030611-1.c: Same.
	* gcc.dg/tree-ssa/20030703-1.c: Same.
	* gcc.dg/tree-ssa/20030703-2.c: Same.
	* gcc.dg/tree-ssa/20030708-1.c: Same.
	* gcc.dg/tree-ssa/20030709-3.c: Same.
	* gcc.dg/tree-ssa/20030710-1.c: Same.
	* gcc.dg/tree-ssa/20030711-1.c: Same.
	* gcc.dg/tree-ssa/20030711-2.c: Same.
	* gcc.dg/tree-ssa/20030711-3.c: Same.
	* gcc.dg/tree-ssa/20030714-1.c: Same.
	* gcc.dg/tree-ssa/20030714-2.c: Same.
	* gcc.dg/tree-ssa/20030729-1.c: Same.
	* gcc.dg/tree-ssa/20030730-1.c: Same.
	* gcc.dg/tree-ssa/20030730-2.c: Same.
	* gcc.dg/tree-ssa/20030731-1.c: Same.
	* gcc.dg/tree-ssa/20030807-1.c: Same.
	* gcc.dg/tree-ssa/20030807-11.c: Same.
	* gcc.dg/tree-ssa/20030807-2.c: Same.
	* gcc.dg/tree-ssa/20030807-3.c: Same.
	* gcc.dg/tree-ssa/20030807-5.c: Same.
	* gcc.dg/tree-ssa/20030807-8.c: Same.
	* gcc.dg/tree-ssa/20030807-9.c: Same.
	* gcc.dg/tree-ssa/20030814-1.c: Same.
	* gcc.dg/tree-ssa/20030814-2.c: Same.
	* gcc.dg/tree-ssa/20030814-3.c: Same.
	* gcc.dg/tree-ssa/20030814-4.c: Same.
	* gcc.dg/tree-ssa/20030814-5.c: Same.
	* gcc.dg/tree-ssa/20030814-6.c: Same.
	* gcc.dg/tree-ssa/20030814-7.c: Same.
	* gcc.dg/tree-ssa/20030821-1.c: Same.
	* gcc.dg/tree-ssa/20030922-1.c: Same.
	* gcc.dg/tree-ssa/20030922-2.c: Same.
	* gcc.dg/tree-ssa/20031022-1.c: Same.
	* gcc.dg/tree-ssa/20040513-2.c: Same.
	* gcc.dg/tree-ssa/20040615-1.c: Same.
	* gcc.dg/tree-ssa/20040624-1.c: Same.
	* gcc.dg/tree-ssa/20040703-1.c: Same.
	* gcc.dg/tree-ssa/pr21417.c: Same.
	* gcc.dg/tree-ssa/pr61607.c: Same.
	* gcc.dg/tree-ssa/pr67755.c: Same.
	* gcc.dg/tree-ssa/pr68619-2.c: Same.
	* gcc.dg/tree-ssa/pr69270-2.c: Same.
	* gcc.dg/tree-ssa/pr69270.c: Same.
	* gcc.dg/tree-ssa/pr70232.c: Same.
	* gcc.dg/tree-ssa/slsr-27.c: Same.
	* gcc.dg/tree-ssa/slsr-28.c: Same.
	* gcc.dg/tree-ssa/slsr-29.c: Same.
	* gcc.dg/tree-ssa/slsr-30.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-branch-1.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-cse-3.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-cse-5.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-cse-6.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-1.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2a.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2c.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2d.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2e.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2f.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2g.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-2h.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-5.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Same.
	* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same.
	* gcc.dg/tree-ssa/ssa-thread-12.c: Same.
	* gcc.dg/tree-ssa/vrp47.c: Same.
	* gfortran.dg/unconstrained_commons.f:  Same.
	* gcc.dg/pr41488.c: Update for removing sccp pass.
	* gcc.dg/tree-ssa/loop-17.c: Same.
	* gcc.dg/tree-ssa/loop-39.c: Same.
	* gcc.dg/tree-ssa/scev-7.c: Same.
	* c-c++-common/restrict-2.c: Update for removing lim pass.
	* c-c++-common/restrict-4.c: Same.
	* g++.dg/tree-ssa/pr33615.C: Same.
	* g++.dg/tree-ssa/restrict1.C: Same.
	* gcc.dg/tm/pub-safety-1.c: Same.
	* gcc.dg/tm/reg-promotion.c: Same.
	* gcc.dg/tree-ssa/20050314-1.c: Same.
	* gcc.dg/tree-ssa/loop-32.c: Same.
	* gcc.dg/tree-ssa/loop-33.c: Same.
	* gcc.dg/tree-ssa/loop-34.c: Same.
	* gcc.dg/tree-ssa/loop-35.c: Same.
	* gcc.dg/tree-ssa/loop-7.c: Same.
	* gcc.dg/tree-ssa/pr23109.c: Same.
	* gcc.dg/tree-ssa/restrict-3.c: Same.
	* gcc.dg/tree-ssa/restrict-5.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-1.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-10.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-11.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-12.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-2.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-3.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-6.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-7.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-8.c: Same.
	* gcc.dg/tree-ssa/ssa-lim-9.c: Same.
	* gcc.dg/tree-ssa/structopt-1.c: Same.
	* gfortran.dg/pr32921.f: Same.

---
 gcc/passes.def|  8 
 gcc/testsuite/c-c++-common/restrict-2.c   |  4 ++--
 gcc/testsuite/c-c++-common/restrict-4.c   |  4 ++--
 gcc/testsuite/g++.dg/tree-ssa/pr19637.C   |  4 ++--
 gcc/testsuite/g++.dg/tree-ssa/pr33615.C 

[wwwdocs] Simplify gcc-4.4/cxx0x_status.html (and convert to global CSS)

[Gerald Pfeifer]

And here is the version for GCC 4.4.

Applied.

Gerald

Index: gcc-4.4/cxx0x_status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/cxx0x_status.html,v
retrieving revision 1.12
diff -u -r1.12 cxx0x_status.html
--- gcc-4.4/cxx0x_status.html   19 May 2010 16:07:29 -  1.12
+++ gcc-4.4/cxx0x_status.html   11 Apr 2016 06:23:35 -
@@ -2,13 +2,6 @@
 
 
   Status of Experimental C++0x Support in GCC 4.4
-  
-/*  */
-  
 
 
 
@@ -36,7 +29,7 @@
 
 
 
-  
+  
 
   Language Feature
   Proposal
@@ -45,301 +38,303 @@
 
   Rvalue references
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html;>N2118
-   Yes
+   Yes
 
 
   Rvalue references for *this
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm;>N2439
-  No
+  No
 
 
   Initialization of class objects by rvalues
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html;>N1610
-  Yes
+  Yes
 
 
 
   Variadic templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf;>N2242
-   Yes
+   Yes
 
 
   Extending variadic template template 
parameters
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf;>N2555
-   Yes
+   Yes
 
 
   Initializer lists
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm;>N2672
-   Yes
+   Yes
 
 
   Static assertions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html;>N1720
-   Yes
+   Yes
 
 
   auto-typed variables
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf;>N1984
-   Yes
+   Yes
 
 
   Multi-declarator auto
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf;>N1737
-   Yes
+   Yes
 
 
   Removal of auto as a storage-class 
specifier
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2546.htm;>N2546
-   Yes
+   Yes
 
 
   New function declarator syntax
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm;>N2541
-   Yes
+   Yes
 
 
   Lambda expressions and closures
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf;>N2550
-  No
+  No
 
 
   Constness of lambda functions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2658.pdf;>N2658
-  No
+  No
 
 
   Declared type of an expression
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf;>N2343
-   Yes
+   Yes
 
 
   Right angle brackets
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html;>N1757
-   Yes
+   Yes
 
 
   Default template arguments for function templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226;>DR226
-   Yes
+   Yes
 
 
   Solving the SFINAE problem for expressions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html;>DR339
-   Yes
+   Yes
 
 
   Template aliases
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf;>N2258
-  No
+  No
 
 
   Extern templates
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm;>N1987
-   Yes
+   Yes
 
 
   Null pointer constant
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf;>N2431
-  No
+  No
 
 
   Strongly-typed enums
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf;>N2347
-   Yes
+   Yes
 
 
   Forward declarations for enums
   
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf;>N2764
   
-  No
+  No
 
 
   Generalized attributes
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf;>N2761
-  No
+  No
 
 
   Generalized constant expressions
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf;>N2235
-  No
+  No
 
 
   Alignment support
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf;>N2341
-  No
+  No
 
 
 
 
   Delegating constructors
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf;>N1986
-  No
+  No
 
 
   Inheriting constructors
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm;>N2540
-  No
+  No
 
 
   Explicit conversion operators
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf;>N2437
-  No
+  No
 
 
   New character types