Re: [Patch] regex bracket expression implementaion

2013-08-03 Thread Paolo Carlini


Hi,

>What's the format I should use? An email? Comments in the code? A PDF
>document? Or?

All sorts of comments in the code are always welcome: blurbs at the beginning 
of each file explaining the main design choices, then smaller comments 
explaining tricky points, TODO or FIXME when appropriate, etc.

But in my previous message I was thinking just short informal emails, to have 
an idea of the current status, what already works, what doesn't, the major 
challenges ahead. If you like together with actual patch submissions.

Thanks,
Paolo



Re: C++ PATCH for c++/51239, 57138 (pack expansion and alias templates)

2013-08-03 Thread Jason Merrill

On 08/03/2013 06:43 PM, Gabriel Dos Reis wrote:

On Sat, Aug 3, 2013 at 3:31 PM, Jason Merrill  wrote:

DR 1430 seems to be being resolved to prohibit passing a pack expansion to a
non-pack parameter of an alias template.  I disagree with this direction,
but I'm going to go ahead and implement it for now.


I too disagree.  Do we need a NB-level comment to get a reconsideration?


1430 is still in drafting, so an NB comment on the CD wouldn't make 
sense procedurally.  You might drop a note of concern to Mike Miller, 
though.



The second patch implements DR 1286, which allows an alias template to be
equivalent to another template if the type it aliases is the same as the
type of the other template.


this was part of the original intent.  I am mystified it was reversed.


It wasn't reversed, particularly; Core just noticed that it wasn't 
specified by the language, so we fixed the example to match the 
normative text.


Jason



Re: [Patch] regex bracket expression implementaion

2013-08-03 Thread Tim Shen
On Fri, Aug 2, 2013 at 9:33 PM, Paolo Carlini  wrote:
> If nobody has further comments over the next day or so, patch is Ok with me.

Committed. // http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00826.html

> PS: I think it would be nice if from to time you could provide a rough
> estimate of the amount of work done vs the work still needed; major
> milestones; etc. Just to have an idea.

What's the format I should use? An email? Comments in the code? A PDF
document? Or?


-- 
Tim Shen


Re: C++ PATCH for c++/51239, 57138 (pack expansion and alias templates)

2013-08-03 Thread Gabriel Dos Reis
On Sat, Aug 3, 2013 at 3:31 PM, Jason Merrill  wrote:
> DR 1430 seems to be being resolved to prohibit passing a pack expansion to a
> non-pack parameter of an alias template.  I disagree with this direction,
> but I'm going to go ahead and implement it for now.

I too disagree.  Do we need a NB-level comment to get a reconsideration?

> The second patch implements DR 1286, which allows an alias template to be
> equivalent to another template if the type it aliases is the same as the
> type of the other template.

this was part of the original intent.  I am mystified it was reversed.

Thanks for doing it!

-- Gaby


C++ PATCH for c++/51239, 57138 (pack expansion and alias templates)

2013-08-03 Thread Jason Merrill
DR 1430 seems to be being resolved to prohibit passing a pack expansion 
to a non-pack parameter of an alias template.  I disagree with this 
direction, but I'm going to go ahead and implement it for now.


The second patch implements DR 1286, which allows an alias template to 
be equivalent to another template if the type it aliases is the same as 
the type of the other template.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 74510935cc6b482407a30e53ee27f6f13b8b3d0f
Author: Jason Merrill 
Date:   Fri Apr 5 15:39:35 2013 -0400

	DR 1430
	PR c++/51239
	* pt.c (pack_expansion_args_count): Rename from
	any_pack_expanson_args_p.
	(coerce_template_parms): Reject pack expansion to
	non-pack template parameter of alias template.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 82c72dd..bbaeb7d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6542,18 +6542,22 @@ coerce_template_parameter_pack (tree parms,
   return argument_pack;
 }
 
-/* Returns true if the template argument vector ARGS contains
-   any pack expansions, false otherwise.  */
+/* Returns the number of pack expansions in the template argument vector
+   ARGS.  */
 
-static bool
-any_pack_expanson_args_p (tree args)
+static int
+pack_expansion_args_count (tree args)
 {
   int i;
+  int count = 0;
   if (args)
 for (i = 0; i < TREE_VEC_LENGTH (args); ++i)
-  if (PACK_EXPANSION_P (TREE_VEC_ELT (args, i)))
-	return true;
-  return false;
+  {
+	tree elt = TREE_VEC_ELT (args, i);
+	if (elt && PACK_EXPANSION_P (elt))
+	  ++count;
+  }
+  return count;
 }
 
 /* Convert all template arguments to their appropriate types, and
@@ -6588,6 +6592,7 @@ coerce_template_parms (tree parms,
  subtract it from nparms to get the number of non-variadic
  parameters.  */
   int variadic_p = 0;
+  int variadic_args_p = 0;
   int post_variadic_parms = 0;
 
   if (args == error_mark_node)
@@ -6617,11 +6622,14 @@ coerce_template_parms (tree parms,
   if (!post_variadic_parms)
 inner_args = expand_template_argument_pack (inner_args);
 
+  /* Count any pack expansion args.  */
+  variadic_args_p = pack_expansion_args_count (inner_args);
+
   nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
   if ((nargs > nparms && !variadic_p)
   || (nargs < nparms - variadic_p
 	  && require_all_args
-	  && !any_pack_expanson_args_p (inner_args)
+	  && !variadic_args_p
 	  && (!use_default_args
 	  || (TREE_VEC_ELT (parms, nargs) != error_mark_node
   && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
@@ -6644,6 +6652,33 @@ coerce_template_parms (tree parms,
 
   return error_mark_node;
 }
+  /* We can't pass a pack expansion to a non-pack parameter of an alias
+ template (DR 1430).  */
+  else if (in_decl && DECL_ALIAS_TEMPLATE_P (in_decl)
+	   && variadic_args_p
+	   && nargs - variadic_args_p < nparms - variadic_p)
+{
+  if (complain & tf_error)
+	{
+	  for (int i = 0; i < TREE_VEC_LENGTH (inner_args); ++i)
+	{
+	  tree arg = TREE_VEC_ELT (inner_args, i);
+	  tree parm = TREE_VALUE (TREE_VEC_ELT (parms, i));
+
+	  if (PACK_EXPANSION_P (arg)
+		  && !template_parameter_pack_p (parm))
+		{
+		  error ("pack expansion argument for non-pack parameter "
+			 "%qD of alias template %qD", parm, in_decl);
+		  inform (DECL_SOURCE_LOCATION (parm), "declared here");
+		  goto found;
+		}
+	}
+	  gcc_unreachable ();
+	found:;
+	}
+  return error_mark_node;
+}
 
   /* We need to evaluate the template arguments, even though this
  template-id may be nested within a "sizeof".  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-33.C b/gcc/testsuite/g++.dg/cpp0x/alias-decl-33.C
new file mode 100644
index 000..25781a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-33.C
@@ -0,0 +1,14 @@
+// PR c++/51239
+// { dg-require-effective-target c++11 }
+
+template
+class list{};
+template
+using tail=list;
+template 
+void f(tail);		// { dg-error "alias" }
+
+int main()
+{
+  f({});
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-37.C b/gcc/testsuite/g++.dg/cpp0x/alias-decl-37.C
new file mode 100644
index 000..d6a3e12
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-37.C
@@ -0,0 +1,21 @@
+// PR c++/57138
+// { dg-do compile { target c++11 } }
+
+template  class T, typename ... Y>
+struct D
+{
+  template 
+  using type = T ;	// { dg-error "pack expansion" }
+};
+template 
+class A {};
+template 
+struct B;
+template 
+struct B 
+{
+  typedef A  type;
+};
+template 
+using C = typename B ::type;
+struct E : public D  {};

commit 42137e0d2c1a1dd94080707a95b60266c6aa
Author: Jason Merrill 
Date:   Fri Aug 2 20:08:48 2013 -0400

	DR 1286
	* pt.c (get_underlying_template): New.
	(convert_template_argument, lookup_template_class_1): Use it.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bbaeb7d..d03c1cf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5111,6 +5111,34 @@ alias_template_specialization_p (const_tree t)
 	  && DECL_ALIAS_TEMP

New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

2013-08-03 Thread Xinliang David Li
Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
in ix86_tune_features[], indexed by ix86_tune_indices) to perform
micro-arch specific performance tuning. However such settings are hard
coded (fixed with a given -mtune setting) and is very hard to do
performance experiment.

The attached patch fixes the problem. The patch introduces a new
option -mtune-ctrl=. Its parameter is a comma separated list of
feature names to turn on associated features. Feature name can be
prefixed by ^ to do the opposite. For instance,

  -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns

tells the compiler to use move instructions in prologue/epilogue
(instead of push/pop), and *not* pad return instructions.

To facilitate the change, the feature tuning enums defined in i386.h
are moved to a new file x86-tune.def and this file can be used to
generate both the enums and names of the features.


Ok for trunk?


thanks,

David

2013-08-03  Xinliang David Li  

* config/i386/i386.opt: New option -mtune-ctrl=.
* config/i386/x86-tune.def: New file.
* config/i386/i386.h: include x86-tune.def.
* config/i386/i386.c (ix86_option_override_internal):
Parsing -mtune-ctrl= option and set tune features.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 201458)
+++ config/i386/i386.c  (working copy)
@@ -1833,6 +1833,13 @@ const struct processor_costs *ix86_cost
(PPro/PENT4/NOCONA/CORE2/Athlon/K8).  */
 #define m_GENERIC (m_GENERIC32 | m_GENERIC64)
 
+const char* ix86_tune_feature_names[X86_TUNE_LAST] = {
+#undef DEF_TUNE
+#define DEF_TUNE(tune, name) name,
+#include "x86-tune.def"
+#undef DEF_TUNE
+};
+
 /* Feature tests against the various tunings.  */
 unsigned char ix86_tune_features[X86_TUNE_LAST];
 
@@ -3550,6 +3557,40 @@ ix86_option_override_internal (bool main
   for (i = 0; i < X86_TUNE_LAST; ++i)
 ix86_tune_features[i] = !!(initial_ix86_tune_features[i] & ix86_tune_mask);
 
+  if (ix86_tune_ctrl_string)
+{
+  /* parse the tune ctrl string in the following form:
+ [^]tune_name1,[^]tune_name2,..a */
+  char *next_feature_string = NULL;
+  char *curr_feature_string = xstrdup (ix86_tune_ctrl_string);
+  char *orig = curr_feature_string;
+  do {
+bool clear = false;
+
+next_feature_string = strchr (curr_feature_string, ',');
+   if (next_feature_string)
+  *next_feature_string++ = '\0';
+if (*curr_feature_string == '^')
+ {
+   curr_feature_string++;
+   clear = true;
+ }
+for (i = 0; i < X86_TUNE_LAST; i++)
+ {
+if (!strcmp (curr_feature_string, ix86_tune_feature_names[i]))
+ {
+ix86_tune_features[i] = !clear;
+break;
+  }
+ }
+if (i == X86_TUNE_LAST)
+ warning (0, "Unknown parameter to option -mtune-ctrl: %s",
+  clear ? curr_feature_string - 1 : curr_feature_string);
+   curr_feature_string = next_feature_string;
+  } while (curr_feature_string);
+  free (orig);
+}
+
 #ifndef USE_IX86_FRAME_POINTER
 #define USE_IX86_FRAME_POINTER 0
 #endif
Index: config/i386/i386.h
===
--- config/i386/i386.h  (revision 201458)
+++ config/i386/i386.h  (working copy)
@@ -261,81 +261,11 @@ extern const struct processor_costs ix86
 
 /* Feature tests against the various tunings.  */
 enum ix86_tune_indices {
-  X86_TUNE_USE_LEAVE,
-  X86_TUNE_PUSH_MEMORY,
-  X86_TUNE_ZERO_EXTEND_WITH_AND,
-  X86_TUNE_UNROLL_STRLEN,
-  X86_TUNE_BRANCH_PREDICTION_HINTS,
-  X86_TUNE_DOUBLE_WITH_ADD,
-  X86_TUNE_USE_SAHF,
-  X86_TUNE_MOVX,
-  X86_TUNE_PARTIAL_REG_STALL,
-  X86_TUNE_PARTIAL_FLAG_REG_STALL,
-  X86_TUNE_LCP_STALL,
-  X86_TUNE_USE_HIMODE_FIOP,
-  X86_TUNE_USE_SIMODE_FIOP,
-  X86_TUNE_USE_MOV0,
-  X86_TUNE_USE_CLTD,
-  X86_TUNE_USE_XCHGB,
-  X86_TUNE_SPLIT_LONG_MOVES,
-  X86_TUNE_READ_MODIFY_WRITE,
-  X86_TUNE_READ_MODIFY,
-  X86_TUNE_PROMOTE_QIMODE,
-  X86_TUNE_FAST_PREFIX,
-  X86_TUNE_SINGLE_STRINGOP,
-  X86_TUNE_QIMODE_MATH,
-  X86_TUNE_HIMODE_MATH,
-  X86_TUNE_PROMOTE_QI_REGS,
-  X86_TUNE_PROMOTE_HI_REGS,
-  X86_TUNE_SINGLE_POP,
-  X86_TUNE_DOUBLE_POP,
-  X86_TUNE_SINGLE_PUSH,
-  X86_TUNE_DOUBLE_PUSH,
-  X86_TUNE_INTEGER_DFMODE_MOVES,
-  X86_TUNE_PARTIAL_REG_DEPENDENCY,
-  X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY,
-  X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL,
-  X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL,
-  X86_TUNE_SSE_PACKED_SINGLE_INSN_OPTIMAL,
-  X86_TUNE_SSE_SPLIT_REGS,
-  X86_TUNE_SSE_TYPELESS_STORES,
-  X86_TUNE_SSE_LOAD0_BY_PXOR,
-  X86_TUNE_MEMORY_MISMATCH_STALL,
-  X86_TUNE_PROLOGUE_USING_MOVE,
-  X86_TUNE_EPILOGUE_USING_MOVE,
-  X86_TUNE_SHIFT1,
-  X86_TUNE_USE_FFREEP,
-  X86_TUNE_INTER_UNIT_MOVES_TO_VEC,
-  X86_TUNE_INTER_UNIT_MOVES_FROM_VEC,
-  X86_TUNE_INTER_UNIT_CONVERSIONS,
-  X86_TUNE_FOUR_JUMP_LIMIT

Cleanup up pretty printers [0/n]

2013-08-03 Thread Gabriel Dos Reis

This is the first in a series of cleanup patches to the pretty printer
data structures and routines.

Tested on an x86_64-suse-linux.
Applied to trunk.

2013-08-03  Gabriel Dos Reis  

* pretty-print.h (pp_underscore): New.
(pp_comma): Tidy.
* gimple-pretty-print.c (dump_unary_rhs): Use specialized pretty
printer functions instead of pp_character.
(dump_binary_rhs): Likewise.
(dump_ternary_rhs): Likewise.
(dump_gimple_call_args): Likewise.
(pp_points_to_solution): Likewise.
(dump_gimple_call): Likewise.
(dump_gimple_switch): Likewise.
(dump_gimple_cond): Likewise.
(dump_gimple_bind): Likewise.
(dump_gimple_try): Likewise.
(dump_gimple_omp_for): Likewise.
(dump_gimple_omp_continue): Likewise.
(dump_gimple_omp_single): Likewise.
(dump_gimple_omp_sections): Likewise.
(dump_gimple_omp_block): Likewise.
(dump_gimple_omp_critical): Likewise.
(dump_gimple_transaction): Likewise.
(dump_gimple_asm): Likewise.
(dump_gimple_phi): Likewise.
(dump_gimple_omp_parallel): Likewise.
(dump_gimple_omp_task): Likewise.
(dump_gimple_omp_atomic_load): Likewise.
(dump_gimple_omp_atomic_store): Likewise.
(dump_gimple_mem_ops): Likewise.
(pp_gimple_stmt_1): Likewise.
(pp_cfg_jump): Likewise.
(dump_implicit_edges): Likewise.
(gimple_dump_bb_for_graph): Likewise.
* graph.c (draw_cfg_node): Likewise.
* langhooks.c (lhd_print_error_function): Likewise.
* sched-vis.c (print_exp): Likewise.
(print_value): Likewise.
(print_pattern): Likewise.
(print_insn): Likewise.
(rtl_dump_bb_for_graph): Likewise.
* tree-pretty-print.c (dump_function_declaration): Likewise.
(dump_array_domain): Likewise.
(dump_omp_clause): Likewise.
(dump_location): Likewise.
(dump_generic_node): Likewise.
(print_struct_decl): Likewise.
* diagnostic.c (diagnostic_show_locus): Use pp_space.

c-family/
2013-08-03  Gabriel Dos Reis  

* c-ada-spec.c (print_ada_macros): Use specialized pretty printer
functions instead of pp_character.
(pp_ada_tree_identifier): Likewise.
(dump_ada_double_name): Likewise.
(dump_ada_function_declaration): Likewise.
(dump_ada_array_domains): Likewise.
(dump_template_types): Likewise.
(dump_generic_ada_node): Likewise.
(print_ada_declaration): Likewise.
(print_ada_struct_decl): Likewise.
* c-pretty-print.c (pp_c_integer_constant): Likewise.

cp/
2013-08-03  Gabriel Dos Reis  

* error.c (dump_aggr_type): Use specialized pretty printer
functions instead of pp_character.
(dump_type_prefix): Likewise.
(dump_simple_decl): Likewise.
(type_to_string): Likewise.

Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c   (revision 201466)
+++ c-family/c-ada-spec.c   (working copy)
@@ -418,7 +418,7 @@
 
  pp_string (pp, ";  --  ");
  pp_string (pp, sloc.file);
- pp_character (pp, ':');
+ pp_colon (pp);
  pp_scalar (pp, "%d", sloc.line);
  pp_newline (pp);
}
@@ -1253,7 +1253,7 @@
{
  append_withs (s1, limited_access);
  pp_string (buffer, s1);
- pp_character (buffer, '.');
+ pp_dot (buffer);
}
  free (s1);
}
@@ -1375,7 +1375,7 @@
   pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (t1)));
 }
 
-  pp_character (buffer, '_');
+  pp_underscore (buffer);
 
   if (DECL_NAME (t1))
 pp_ada_tree_identifier (buffer, DECL_NAME (t2), t2, false);
@@ -1489,7 +1489,7 @@
   if (num_args > 0)
 {
   pp_space (buffer);
-  pp_character (buffer, '(');
+  pp_left_paren (buffer);
 }
 
   if (TREE_CODE (func) == FUNCTION_DECL)
@@ -1550,7 +1550,7 @@
 
   if (num < num_args)
{
- pp_character (buffer, ';');
+ pp_semicolon (buffer);
 
  if (num_args > 2)
newline_and_indent (buffer, spc + INDENT_INCR);
@@ -1566,7 +1566,7 @@
 }
 
   if (num_args > 0)
-pp_character (buffer, ')');
+pp_right_paren (buffer);
   return num_args;
 }
 
@@ -1577,7 +1577,7 @@
 dump_ada_array_domains (pretty_printer *buffer, tree node, int spc)
 {
   int first = 1;
-  pp_character (buffer, '(');
+  pp_left_paren (buffer);
 
   for (; TREE_CODE (node) == ARRAY_TYPE; node = TREE_TYPE (node))
 {
@@ -1606,7 +1606,7 @@
   else
pp_string (buffer, "size_t");
 }
-  pp_character (buffer, ')');
+  pp_right_paren (buffer);
 }
 
 /* Dump in BUFFER file:line information related to NODE.  */
@@ -1706,7 +1706,7 @@
   for (i = 0;

Re: Updated patch (was Re: [PATCH 11/11] Make opt_pass and gcc::pipeline be GC-managed)

2013-08-03 Thread Richard Henderson
On 08/02/2013 02:48 PM, David Malcolm wrote:
> +pass_manager::gt_ggc_mx ()
> +{
> +  ::gt_ggc_mx (all_passes);
> +  ::gt_ggc_mx (all_small_ipa_passes);
> +  ::gt_ggc_mx (all_lowering_passes);
> +  ::gt_ggc_mx (all_regular_ipa_passes);
> +  ::gt_ggc_mx (all_lto_gen_passes);
> +  ::gt_ggc_mx (all_late_ipa_passes);
> +
> +  for (int i = 0; i < passes_by_id_size; i++)
> +::gt_ggc_mx (passes_by_id[i]);
> +
> +#define INSERT_PASSES_AFTER(PASS)
> +#define PUSH_INSERT_PASSES_WITHIN(PASS)
> +#define POP_INSERT_PASSES()
> +#define NEXT_PASS(PASS, NUM) ::gt_ggc_mx (PASS ## _ ## NUM);
> +#define TERMINATE_PASS_LIST()
> +
> +#include "pass-instances.def"
> +
> +#undef INSERT_PASSES_AFTER
> +#undef PUSH_INSERT_PASSES_WITHIN
> +#undef POP_INSERT_PASSES
> +#undef NEXT_PASS
> +#undef TERMINATE_PASS_LIST
> +
> +}

You're marking all passes, and also walking through the chain of sub/next
within the passes themselves?  That seems unnecessary.  Either the passes
are reachable via sub/next or they aren't.

Alternately, don't walk the sub/next fields and instead only walk all of
the passes explicitly, here.  That avoids some of the recursion in the
opt_pass marking, and keeps the call chain flatter.


r~


Re: [C++14/lambda] Experimental polymorphic lambda patches

2013-08-03 Thread Paolo Carlini
.. I don't know if at this Stage we are paying attention to these minor 
details, but at least Patch 1 and 3 appear to have some overlong lines.


Thanks!
Paolo.


Re: Updated patch 10 (was Re: [PATCH 10/11] Make gcc::context be GC-managed)

2013-08-03 Thread Richard Henderson
On 08/02/2013 02:43 PM, David Malcolm wrote:
> gcc/
>   * Makefile.in (GTFILES): Add context.h.
>   * context.c (gcc::context::operator new): New.
>   (gcc::context::gt_ggc_mx): New.
>   (gcc::context::gt_pch_nx): New.
>   (gcc::context::gt_pch_nx): New.
>   * context.h (gcc::context): Add GTY((user)) marking.
>   (gcc::context::operator new): New.
>   (gcc::context::gt_ggc_mx): New.
>   (gcc::context::gt_pch_nx): New.
>   (gcc::context::gt_pch_nx): New.
>   (g): Add GTY marking.
>   (gt_ggc_mx (gcc::context *)): New.
>   (gt_pch_nx (gcc::context *)): New.
>   (gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
>   void *cookie)): New.
>   * gengtype.c (open_base_files) : Add context.h.

Ok.


r~


[RFC Patch, Aarch64] : Macros for profile code generation to enable gprof support

2013-08-03 Thread Venkataramanan Kumar
Hi Maintainers,

This patch adds macros to support gprof in Aarch64. The difference
from the previous patch is that the compiler, while generating
"mcount" routine for an instrumented function, also passes the return
address as argument.

The "mcount" routine in glibc will be modified as follows.

(-Snip-)
 #define MCOUNT \
-void __mcount (void) \
+void __mcount (void* frompc)
   \
 {\
-  mcount_internal ((u_long) RETURN_ADDRESS (1), (u_long) RETURN_ADDRESS (0)); \
+  mcount_internal ((u_long) frompc, (u_long) RETURN_ADDRESS (0)); \
 }
(-Snip-)

Also in Aarch64 cases__builtin_return_adderess(n) where n>0, still be
returning 0 as it was doing before.

If this is Ok I will send the patch to glibc as well.

2013-08-02  Venkataramanan Kumar  

 * config/aarch64/aarch64.h (MCOUNT_NAME): Define.
   (NO_PROFILE_COUNTERS): Likewise.
   (PROFILE_HOOK): Likewise.
   (FUNCTION_PROFILER): Likewise.
*  config/aarch64/aarch64.c (aarch64_function_profiler): Remove.
   .

regards,
Venkat.


gcc.gprof.diff
Description: Binary data


Re: [PATCH 3.1/11] Explicitly initialize the macro-generated pass fields (was Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes)

2013-08-03 Thread Richard Henderson
On 08/02/2013 02:38 PM, David Malcolm wrote:
> OK for trunk? (as part of patches 3-6)

Ok.


Re: Introduce local aliases for call targets when possible

2013-08-03 Thread David Edelsohn
This patch introduced new C++ testsuite regressions.

FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98  scan-ipa-dump-times inline
"Discovered a virtual call to a known target" 3
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98  scan-ipa-dump-times inline
"and turned into root of the clone tree" 1
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11  scan-ipa-dump-times inline
"Discovered a virtual call to a known target" 3
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11  scan-ipa-dump-times inline
"and turned into root of the clone tree" 1

FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++11 (test for excess errors)

Thanks, David


[patch, fortran] RFD: PR 56666 Allow suppression of zero-trip DO loop warning

2013-08-03 Thread Thomas Koenig

Hello world,

the rather self-explanatory patch implements the -Wzerotrip
option.  The positive form is not really useful, because
the option is on by default (so the default behavior is
not changed).

The negative form of the option, -Wno-zerotrip, suppresses the
warning.  I have also added information of how to suppress the
warning in the message.

Alternatively, it is also possible to only activate the warning
if it is set explicitly, or with -Wall.  I can easily change the
patch to do so, if that turns out to be the consensus (I have no
strong opinion on the matter either way)

Regression-tested. OK for trunk?

Thomas

2013-08-03  Thomas Koenig  

PR fortran/5
* gfortran.h (gfc_option_t):  Add warn_zerotrip.
* invoke.texi (-Wzerotrip):  Document option.
* lang.opt (Wzerotrip):  Add.
* options.c (gfc_init_options):  Initialize warn_zerotrip.
(gfc_handle_option):  Handle OPT_Wzerotrip.
* resolve.c (gfc_resolve_iterator): Honor
gfc_option.warn_zerotrip; update error message to show
how to suppress the warning.

2013-08-03  Thomas Koenig  

PR fortran/5
* gfortran.dg/do_check_10.f90:  New test.
Index: gfortran.h
===
--- gfortran.h	(Revision 201448)
+++ gfortran.h	(Arbeitskopie)
@@ -2252,6 +2252,7 @@ typedef struct
   int warn_align_commons;
   int warn_real_q_constant;
   int warn_unused_dummy_argument;
+  int warn_zerotrip;
   int warn_realloc_lhs;
   int warn_realloc_lhs_all;
   int warn_compare_reals;
Index: invoke.texi
===
--- invoke.texi	(Revision 201448)
+++ invoke.texi	(Arbeitskopie)
@@ -954,6 +954,12 @@ This option is implied by @option{-Wextra}.
 Warn if the pointer in a pointer assignment might be longer than the its
 target. This option is implied by @option{-Wall}.
 
+@item -Wzerotrip
+@opindex @code{Wzerotrip}
+Warn if a @code{DO} loop is known to execute zero times at compile
+time.  This option is on by default and can be deactivated by
+@option{-Wno-zerotrip}.
+
 @item -Werror
 @opindex @code{Werror}
 @cindex warnings, to errors
Index: lang.opt
===
--- lang.opt	(Revision 201448)
+++ lang.opt	(Arbeitskopie)
@@ -293,6 +293,10 @@ Wunused-dummy-argument
 Fortran Warning
 Warn about unused dummy arguments.
 
+Wzerotrip
+Fortran Warning
+Warn about zero-trip DO loops
+
 cpp
 Fortran Negative(nocpp)
 Enable preprocessing
Index: options.c
===
--- options.c	(Revision 201448)
+++ options.c	(Arbeitskopie)
@@ -109,6 +109,7 @@ gfc_init_options (unsigned int decoded_options_cou
   gfc_option.warn_align_commons = 1;
   gfc_option.warn_real_q_constant = 0;
   gfc_option.warn_unused_dummy_argument = 0;
+  gfc_option.warn_zerotrip = 1;
   gfc_option.warn_realloc_lhs = 0;
   gfc_option.warn_realloc_lhs_all = 0;
   gfc_option.warn_compare_reals = 0;
@@ -747,6 +748,10 @@ gfc_handle_option (size_t scode, const char *arg,
   gfc_option.warn_unused_dummy_argument = value;
   break;
 
+case OPT_Wzerotrip:
+  gfc_option.warn_zerotrip = value;
+  break;
+
 case OPT_fall_intrinsics:
   gfc_option.flag_all_intrinsics = 1;
   break;
Index: resolve.c
===
--- resolve.c	(Revision 201448)
+++ resolve.c	(Arbeitskopie)
@@ -6282,8 +6282,10 @@ gfc_resolve_iterator (gfc_iterator *iter, bool rea
 	  sgn = mpfr_sgn (iter->step->value.real);
 	  cmp = mpfr_cmp (iter->end->value.real, iter->start->value.real);
 	}
-  if ((sgn > 0 && cmp < 0) || (sgn < 0 && cmp > 0))
-	gfc_warning ("DO loop at %L will be executed zero times",
+  if (gfc_option.warn_zerotrip &&
+	  ((sgn > 0 && cmp < 0) || (sgn < 0 && cmp > 0)))
+	gfc_warning ("DO loop at %L will be executed zero times"
+		 " (use -Wno-zerotrip to suppress)",
 		 &iter->step->where);
 }
 
! { dg-do compile }
! { dg-options "-Wno-zerotrip" }
program main
  do i=1,0
print *,i
  end do
end program main


Re: Request to merge Undefined Behavior Sanitizer in (take 2)

2013-08-03 Thread Jason Merrill

On 08/01/2013 02:06 PM, Marek Polacek wrote:

SAVE_EXPRs are evaluated only once;
in that COMPOUND_EXPR, when we first encounter SAVE_EXPR  and
call get_initialized_tmp_var, we get temporary value for it, x.2.
Then, in the second part of the COMPOUND_EXPR, we meet SAVE_EXPR 
again, but it already has been resolved, so we don't create any
initialized var for it.


Right.  When you have a SAVE_EXPR in a conditional context, you need to 
make sure that it gets evaluated before the condition.



What we could perhaps do is to move the x.2 = x; initialization
before the condition, so that it's always initialized.  It's not readily
obvious to me how to implement that nicely, but I could try something, if
this is the way to go.  Does anyone have a better idea?


Where are the SAVE_EXPRs coming from?  It doesn't seem to me that x 
needs to be wrapped in a SAVE_EXPR at all in this case.  For cases where 
the SAVE_EXPR is needed and not used in the test, you could add the 
SAVE_EXPR before the condition with a COMPOUND_EXPR.


Jason



Re: [PATCH 2/4] [lambda] Support implicit conversion of a stateless generic lambda to a function pointer.

2013-08-03 Thread Jason Merrill

On 08/01/2013 08:25 AM, Adam Butcher wrote:

+= DECL_TEMPLATE_INFO (callop)
+&& DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (callop)) == callop;


An expression broken across lines should be parenthesized.

And let's move the building of 'call' for the non-template case up to be 
with the template case.


Otherwise, looks good!

Jason



[Patch, Fortran] PR 58058: [4.7/4.8/4.9 Regression] Memory leak with transfer function

2013-08-03 Thread Janus Weil
Hi all,

the attached patch plugs a memory leak of the TRANSFER intrinsic,
which can occur when transferring to CHARACTER strings. For details
see the PR.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?

Cheers,
Janus


2013-08-03  Janus Weil  

PR fortran/58058
* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Free the temporary
string, if necessary.

2013-08-03  Janus Weil  

PR fortran/58058
* gfortran.dg/transfer_intrinsic_6.f90: New.


pr58058.diff
Description: Binary data


transfer_intrinsic_6.f90
Description: Binary data


Re: Backend specific params.def? (Was Re: New parameters to control stringop expansion libcall strategy)

2013-08-03 Thread Xinliang David Li
On Sat, Aug 3, 2013 at 1:06 AM, Jan Hubicka  wrote:
>> On x86_64, when the expected size of memcpy/memset is known (e.g, with
>> FDO), libcall strategy is used with the size is > 8192. This value is
>> hard coded, which makes it hard to do performance tuning. This patch
>> adds two new parameters to do that. Potential usage includes
>> per-application libcall strategy min-size tuning based on summary data
>> with FDO (e.g, instruction workset size).
>>
>> Bootstrap and tested on x86_64/linux. Ok for trunk?
>>
>> thanks,
>>
>> David
>>
>>
>> 2013-08-02  Xinliang David Li  
>>
>> * params.def: New parameters.
>> * config/i386/i386.c (ix86_option_override_internal):
>> Override default libcall size limit with parameters.
>
> Hi,
> problem with this is that we introduce generic --param that is used only
> by x86 backend.  I am not really guru on the command line options, but I think
> this is first time we try to do such thing.  I wonder if
> 1) We want to introduce target specific params.def

We do have target specific tuning code for parameters though  --
backend overrides the default value -- I think this is essentially
target specific params.

> 2) We want to use usual -msomething= options
> 3) We want to go this way?

I don't have strong opinion either way. To avoid controversy, let me
work on a -mxxx= version of the patch -- and hopefully it will be more
powerful.

thanks,

David

>
> Honza


[PATCH, committed] Update SLSR candidate table for update_stmt replacements

2013-08-03 Thread Bill Schmidt
In the fix for PR57993, I missed some cases where the candidate table
needed to be updated when a candidate statement in the table might
become stale.  This corrects those issues.  One of the missing cases
showed up in povray when compiling SPEC cpu2006.

Bootstrapped and tested on powerpc64-unknown-linux-gnu with no
regressions; committed as obvious.

Thanks,
Bill


gcc:

2013-08-03  Bill Schmidt  

* gimple-ssa-strength-reduction.c (replace_mult_candidate): Update
candidate table when replacing a candidate statement.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.

gcc/testsuite:

2013-08-03  Bill Schmidt  

* gcc.dg/torture/pr57993-2.cpp: New.


Index: gcc/testsuite/gcc.dg/torture/pr57993-2.cpp
===
--- gcc/testsuite/gcc.dg/torture/pr57993-2.cpp  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr57993-2.cpp  (revision 0)
@@ -0,0 +1,213 @@
+/* This ICEd due to an incomplete fix for PR57993.  */
+/* { dg-compile } */
+
+extern "C"
+{
+  extern double sqrt (double __x) throw ();
+  typedef long unsigned int size_t;
+  typedef struct
+  {
+  }
+  __mbstate_t;
+  void *pov_malloc (size_t size, const char *file, int line, const char *msg);
+  typedef struct Object_Struct OBJECT;
+  typedef struct Ray_Struct RAY;
+  typedef struct istack_struct ISTACK;
+  typedef struct istk_entry INTERSECTION;
+  typedef double UV_VECT[2];
+  typedef double VECTOR[3];
+  typedef struct Transform_Struct TRANSFORM;
+  typedef struct Method_Struct METHODS;
+  typedef int (*ALL_INTERSECTIONS_METHOD) (OBJECT *, RAY *, ISTACK *);
+  typedef int (*INSIDE_METHOD) (VECTOR, OBJECT *);
+  typedef void (*NORMAL_METHOD) (VECTOR, OBJECT *, INTERSECTION *);
+  typedef void (*UVCOORD_METHOD) (UV_VECT, OBJECT *, INTERSECTION *);
+  typedef void *(*COPY_METHOD) (OBJECT *);
+  typedef void (*TRANSLATE_METHOD) (OBJECT *, VECTOR, TRANSFORM *);
+  typedef void (*ROTATE_METHOD) (OBJECT *, VECTOR, TRANSFORM *);
+  typedef void (*SCALE_METHOD) (OBJECT *, VECTOR, TRANSFORM *);
+  typedef void (*TRANSFORM_METHOD) (OBJECT *, TRANSFORM *);
+  typedef void (*INVERT_METHOD) (OBJECT *);
+  typedef void (*DESTROY_METHOD) (OBJECT *);
+  struct Method_Struct
+  {
+ALL_INTERSECTIONS_METHOD All_Intersections_Method;
+INSIDE_METHOD Inside_Method;
+NORMAL_METHOD Normal_Method;
+UVCOORD_METHOD UVCoord_Method;
+COPY_METHOD Copy_Method;
+TRANSLATE_METHOD Translate_Method;
+ROTATE_METHOD Rotate_Method;
+SCALE_METHOD Scale_Method;
+TRANSFORM_METHOD Transform_Method;
+INVERT_METHOD Invert_Method;
+DESTROY_METHOD Destroy_Method;
+  };
+  typedef struct Bicubic_Patch_Struct BICUBIC_PATCH;
+  typedef struct Bezier_Node_Struct BEZIER_NODE;
+  struct Bezier_Node_Struct
+  {
+int Node_Type;
+int Count;
+  };
+  struct Bicubic_Patch_Struct
+  {
+METHODS *Methods;
+int Patch_Type, U_Steps, V_Steps;
+VECTOR Control_Points[4][4];
+BEZIER_NODE *Node_Tree;
+  };
+  typedef enum
+  {
+CSV, SYS, PPM, TARGA, PNG, NONE
+  }
+  SHELLDATA;
+  typedef enum STATS
+  {
+Number_Of_Pixels =
+  0, Number_Of_Pixels_Supersampled, Number_Of_Samples, Number_Of_Rays,
+  Calls_To_DNoise, Calls_To_Noise, ADC_Saves, Istack_overflows,
+  Ray_RBezier_Tests, Ray_RBezier_Tests_Succeeded, Ray_Bicubic_Tests,
+  Ray_Bicubic_Tests_Succeeded, Ray_Blob_Tests, Ray_Blob_Tests_Succeeded,
+  Blob_Element_Tests, Blob_Element_Tests_Succeeded, Blob_Bound_Tests,
+  Blob_Bound_Tests_Succeeded, Ray_Box_Tests, Ray_Box_Tests_Succeeded,
+  Ray_Cone_Tests, Ray_Cone_Tests_Succeeded, Ray_CSG_Intersection_Tests,
+  Ray_CSG_Intersection_Tests_Succeeded, Ray_CSG_Merge_Tests,
+  Ray_CSG_Merge_Tests_Succeeded, Ray_CSG_Union_Tests,
+  Ray_CSG_Union_Tests_Succeeded, Ray_Disc_Tests, Ray_Disc_Tests_Succeeded,
+  Ray_Fractal_Tests, Ray_Fractal_Tests_Succeeded, Ray_HField_Tests,
+  Ray_HField_Tests_Succeeded, Ray_HField_Box_Tests,
+  Ray_HField_Box_Tests_Succeeded, Ray_HField_Triangle_Tests,
+  Ray_HField_Triangle_Tests_Succeeded, Ray_HField_Block_Tests,
+  Ray_HField_Block_Tests_Succeeded, Ray_HField_Cell_Tests,
+  Ray_HField_Cell_Tests_Succeeded, Ray_IsoSurface_Tests,
+  Ray_IsoSurface_Tests_Succeeded, Ray_IsoSurface_Bound_Tests,
+  Ray_IsoSurface_Bound_Tests_Succeeded, Ray_IsoSurface_Cache,
+  Ray_IsoSurface_Cache_Succeeded, Ray_Lathe_Tests,
+  Ray_Lathe_Tests_Succeeded, Lathe_Bound_Tests,
+  Lathe_Bound_Tests_Succeeded, Ray_Mesh_Tests, Ray_Mesh_Tests_Succeeded,
+  Ray_Plane_Tests, Ray_Plane_Tests_Succeeded, Ray_Polygon_Tests,
+  Ray_Polygon_Tests_Succeeded, Ray_Prism_Tests, Ray_Prism_Tests_Succeeded,
+  Prism_Bound_Tests, Prism_Bound_Tests_Succeeded, Ray_Parametric_Tests,
+  Ray_Parametric_Tests_Succeeded, Ray_Par_Bound_Tests,
+  Ray_Par_Bound_Tests_Succeeded, Ray_Quadric_Tests,
+  Ray_Quadric_Tests_Succeeded, Ray_Poly_Tests, Ray_P

Re: [PATCH 4/4] Grammar "it's" to "its".

2013-08-03 Thread Adam Butcher

On 03.08.2013 14:35, Gabriel Dos Reis wrote:
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher  
wrote:

---
 gcc/cp/pt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a7baaba..99bc71b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
  tree decl_arg_types;

  /* This is an ordinary member function.  However, since
-we're here, we can assume it's enclosing class is a
+we're here, we can assume its enclosing class is a
 template class.  For example,

   template  struct S { void f(); };
@@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree 
parms, bool is_primary,

  || DECL_INITIALIZED_IN_CLASS_P (decl)))
 /* We already checked these parameters when the template was
declared, so there's no need to do it again now.  This 
function
-   was defined in class scope, but we're processing it's body 
now
+   was defined in class scope, but we're processing its body 
now

that the class is complete.  */
 return true;

@@ -7482,7 +7482,7 @@ lookup_template_class_1 (tree d1, tree 
arglist, tree in_decl, tree context,

the one of #0.

When we encounter #1, we want to store the partial 
instantiation
-   of M (template S::M) in it's 
CLASSTYPE_TI_TEMPLATE.
+   of M (template S::M) in its 
CLASSTYPE_TI_TEMPLATE.


For all cases other than this "explicit specialization of 
member of a
class template", we just want to store the most general 
template into

--
1.8.3



OK.
Do you have copyright assignment on file?

Yes.  I only came across these as I was addressing one of Jason's 
comments for my own bad grammar!




Re: [PATCH 3/4] [lambda] Address review comments.

2013-08-03 Thread Adam Butcher

On 03.08.2013 14:39, Gabriel Dos Reis wrote:
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher  
wrote:

---
 gcc/cp/cp-tree.h | 2 +-
 gcc/cp/decl.c| 3 ++-
 gcc/cp/lambda.c  | 2 +-
 gcc/cp/parser.c  | 6 ++
 gcc/cp/pt.c  | 4 ++--
 5 files changed, 8 insertions(+), 9 deletions(-)


When submitting patches, you also need to add ChangeLogs:

  http://www.gnu.org/prep/standards/html_node/Change-Logs.html
  http://gcc.gnu.org/wiki/ChangeLog


These patches were intended as incremental updates to an ongoing review

  http://gcc.gnu.org/ml/gcc-patches/2013-07/threads.html#00755
  http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00130.html

I intend to submit a clean set with appropriate changelog once Jason is 
happy with them.  I wasn't intending these to be committed as is.


Cheers,
Adam



Re: [PATCH 3/4] [lambda] Address review comments.

2013-08-03 Thread Gabriel Dos Reis
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher  wrote:
> ---
>  gcc/cp/cp-tree.h | 2 +-
>  gcc/cp/decl.c| 3 ++-
>  gcc/cp/lambda.c  | 2 +-
>  gcc/cp/parser.c  | 6 ++
>  gcc/cp/pt.c  | 4 ++--
>  5 files changed, 8 insertions(+), 9 deletions(-)

When submitting patches, you also need to add ChangeLogs:

  http://www.gnu.org/prep/standards/html_node/Change-Logs.html
  http://gcc.gnu.org/wiki/ChangeLog

-- Gaby


Re: [PATCH 4/4] Grammar "it's" to "its".

2013-08-03 Thread Gabriel Dos Reis
On Thu, Aug 1, 2013 at 7:25 AM, Adam Butcher  wrote:
> ---
>  gcc/cp/pt.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index a7baaba..99bc71b 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
>   tree decl_arg_types;
>
>   /* This is an ordinary member function.  However, since
> -we're here, we can assume it's enclosing class is a
> +we're here, we can assume its enclosing class is a
>  template class.  For example,
>
>template  struct S { void f(); };
> @@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree parms, bool 
> is_primary,
>   || DECL_INITIALIZED_IN_CLASS_P (decl)))
>  /* We already checked these parameters when the template was
> declared, so there's no need to do it again now.  This function
> -   was defined in class scope, but we're processing it's body now
> +   was defined in class scope, but we're processing its body now
> that the class is complete.  */
>  return true;
>
> @@ -7482,7 +7482,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree 
> in_decl, tree context,
> the one of #0.
>
> When we encounter #1, we want to store the partial instantiation
> -   of M (template S::M) in it's CLASSTYPE_TI_TEMPLATE.
> +   of M (template S::M) in its CLASSTYPE_TI_TEMPLATE.
>
> For all cases other than this "explicit specialization of member of a
> class template", we just want to store the most general template into
> --
> 1.8.3
>

OK.
Do you have copyright assignment on file?

-- Gaby


[PATCH 4/4] Grammar "it's" to "its".

2013-08-03 Thread Adam Butcher
---
 gcc/cp/pt.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a7baaba..99bc71b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1986,7 +1986,7 @@ determine_specialization (tree template_id,
  tree decl_arg_types;
 
  /* This is an ordinary member function.  However, since
-we're here, we can assume it's enclosing class is a
+we're here, we can assume its enclosing class is a
 template class.  For example,
 
   template  struct S { void f(); };
@@ -4337,7 +4337,7 @@ check_default_tmpl_args (tree decl, tree parms, bool 
is_primary,
  || DECL_INITIALIZED_IN_CLASS_P (decl)))
 /* We already checked these parameters when the template was
declared, so there's no need to do it again now.  This function
-   was defined in class scope, but we're processing it's body now
+   was defined in class scope, but we're processing its body now
that the class is complete.  */
 return true;
 
@@ -7482,7 +7482,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree 
in_decl, tree context,
the one of #0.
 
When we encounter #1, we want to store the partial instantiation
-   of M (template S::M) in it's CLASSTYPE_TI_TEMPLATE.
+   of M (template S::M) in its CLASSTYPE_TI_TEMPLATE.
 
For all cases other than this "explicit specialization of member of a
class template", we just want to store the most general template into
-- 
1.8.3



[PATCH 3/4] [lambda] Address review comments.

2013-08-03 Thread Adam Butcher
---
 gcc/cp/cp-tree.h | 2 +-
 gcc/cp/decl.c| 3 ++-
 gcc/cp/lambda.c  | 2 +-
 gcc/cp/parser.c  | 6 ++
 gcc/cp/pt.c  | 4 ++--
 5 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 64ff4e3..17bb8b9 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1089,7 +1089,7 @@ struct GTY(()) saved_scope {
 #define processing_specialization scope_chain->x_processing_specialization
 #define processing_explicit_instantiation 
scope_chain->x_processing_explicit_instantiation
 
-/* Nonzero if the function being declared was made a template due to it's
+/* Nonzero if the function being declared was made a template due to its
parameter list containing generic type specifiers (`auto' or concept
identifiers) rather than an explicit template parameter list.  */
 
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 98e8dc9..72332ba 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10331,7 +10331,8 @@ grokdeclarator (const cp_declarator *declarator,
 
   if (type_uses_auto (type) && cxx_dialect < cxx1y)
{
- error ("parameter declared % (unsupported prior to C++1y)");
+ error ("use of % in parameter declaration only available with "
+"-std=c++1y or -std=gnu++1y");
  type = error_mark_node;
}
 
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index cf662bb..015e6d1 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -776,7 +776,7 @@ maybe_add_lambda_conv_op (tree type)
   if (generic_lambda_p)
 {
   /* Construct the dependent member call for the static member function
-'_FUN' and remove 'auto' from it's return type to allow for simple
+'_FUN' and remove 'auto' from its return type to allow for simple
 implementation of the conversion operator.  */
 
   tree instance = build_nop (type, null_pointer_node);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 45f5d7e..5169f66 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8821,9 +8821,8 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, tree 
lambda_expr)
 
   if (cxx_dialect < cxx1y)
cp_parser_error (parser,
-"Generic lambdas are only supported in C++1y mode.");
-
-  push_deferring_access_checks (dk_deferred);
+"generic lambdas are only available with "
+"-std=c++1y or -std=gnu++1y");
 
   template_param_list = cp_parser_template_parameter_list (parser);
 
@@ -8928,7 +8927,6 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, tree 
lambda_expr)
DECL_NAME (DECL_ARGUMENTS (fco)) = get_identifier ("__closure");
if (template_param_list)
  {
-   pop_deferring_access_checks ();
fco = finish_member_template_decl (fco);
finish_template_decl (template_param_list);
--parser->num_template_parameter_lists;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6e209f8..a7baaba 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21025,7 +21025,7 @@ is_auto (const_tree type)
 }
 
 /* Returns the first tree within T that is directly matched by PRED.  T may be 
a
-   type or PARM_DECL and is incrementally decomposed toward it's type-specifier
+   type or PARM_DECL and is incrementally decomposed toward its type-specifier
until a match is found.  NULL_TREE is returned if PRED does not match any
part of T.
 
@@ -21341,7 +21341,7 @@ add_implicit_template_parms (size_t count, tree 
parameters)
template has no explicit template parameter list so has not been through the
normal template head and tail processing.  add_implicit_template_parms tries
to do the head; this tries to do the tail.  MEMBER_DECL_OPT should be
-   provided if the declaration is a class member such that it's template
+   provided if the declaration is a class member such that its template
declaration can be completed.  If MEMBER_DECL_OPT is provided the finished
form is returned.  Otherwise NULL_TREE is returned. */
 
-- 
1.8.3



Re: [C++14/lambda/impicit-templates] Experimental polymorphic lambda and implicit function template patches

2013-08-03 Thread Adam Butcher
Hi Jason,

I've addressed your review comments and provided support for
conversion to function pointer for generic lambdas.  I've sent the
patches as updates to the previous set.  I'll wait for any further
comments before formalizing them into a cleaner set.

The changes now support the examples given in N3690 ยง5.1.2.{5,6} and
the test program included at the end of this mail.  I think it is
feature-complete.

On 19.07.2013 17:56, Jason Merrill wrote:
> On 07/19/2013 05:00 AM, Adam Butcher wrote:
> >
> > +  push_deferring_access_checks (dk_deferred);
> >
> Why do you need this?
>
I don't think I do.  I had thought that it would be necessary to
handle deferred friendship situations but I don't think that can apply
to generic lambdas.  I've ditched them.

> > +/* Nonzero if the function being declared was made a template due to it's
> >
> "its"
>
I've fixed this and a couple of others in my own comments.  I've also
fixed others I found in the same file (as a separate patch).

> > +  else // extend current template parameter list
> >
> Do we still need to do this, now that we're handling all the
> parameters at the end of the parameter list?
>
I think extending the current parameter list is still needed when
'auto' is found in a parameter declaration of an existing function
template.

E.g.
   template  void f(T& t, auto& a) { ... }

I think that it is necessary to keep everything consistent as if the
template had been declared in the 'conventional' way.  The template
parameter generated for the generic parameter 'a' effectively makes
'f's template parameter list into ''.

Cheers,
Adam


Patch summary (4):
  Preserve type qualifiers for implicit template parameters.
  Support implicit conversion of a stateless generic lambda to a
function pointer.
  Address review comments.
  Grammar "it's" to "its".

 gcc/cp/cp-tree.h |  2 +-
 gcc/cp/decl.c|  3 ++-
 gcc/cp/lambda.c  | 77 +---
 gcc/cp/parser.c  |  6 ++---
 gcc/cp/pt.c  | 21 ++--
 5 files changed, 76 insertions(+), 33 deletions(-)


Test program:


  /* Function templates at namespace scope.  */
  
  auto f1 (auto& a, auto const& b) { return a += b; }
  
  template 
  auto f2 (A& a, auto const& b) { return a += b; }
  
  template 
  auto f3 (auto& a, B const& b) { return a += b; }
  
  template 
  auto f4 (A& a, B const& b) { return a += b; }
  
  
  struct S
  {
/* Non-static member function templates.  */
  
auto mf1 (auto& a, auto const& b) { return a += b; }
  
template 
auto mf2 (A& a, auto const& b) { return a += b; }
  
template 
auto mf3 (auto& a, B const& b) { return a += b; }
  
template 
auto mf4 (A& a, B const& b) { return a += b; }
  
/* Static member function templates.  */
  
static auto smf1 (auto& a, auto const& b) { return a += b; }
  
template 
static auto smf2 (A& a, auto const& b) { return a += b; }
  
template 
static auto smf3 (auto& a, B const& b) { return a += b; }
  
template 
static auto smf4 (A& a, B const& b) { return a += b; }
  };
  
  
  #undef NDEBUG
  #include 
  
  
  #define CHECK(A, b, f) do {  \
 A a1 = 5, a2 = 12;\
 auto r1 = f (a1, b);  \
 auto r2 = f (a2, b);  \
 assert ((#f, a1 == 5 + b));   \
 assert ((#f, a2 == 12 + b));  \
 assert ((#f, r1 == a1));  \
 assert ((#f, r2 == a2));  \
  } while (0)
  
  
  #define INVOKEi(f, A, b, i) do { CHECK (A, b, f ## i); } while (0)
  #define INVOKE4(f, A, b) do { INVOKEi (f, A, b, 1); \
  INVOKEi (f, A, b, 2); \
  INVOKEi (f, A, b, 3); \
  INVOKEi (f, A, b, 4); } while (0)
  
  #define AS_FUNi(f, A, b, i) do { CHECK (A, b, f ## i._FUN); } while (0)
  #define AS_FUN4(f, A, b) do { AS_FUNi (f, A, b, 1); \
  AS_FUNi (f, A, b, 2); \
  AS_FUNi (f, A, b, 3); \
  AS_FUNi (f, A, b, 4); } while (0)
  
  #define AS_PTRi(f, A, B, b, i) do { A (*pfn) (A&, B const&) = f ## i; \
CHECK (A, b, pfn); } while (0)
  #define AS_PTR4(f, A, B, b) do { AS_PTRi (f, A, B, b, 1); \
 AS_PTRi (f, A, B, b, 2); \
 AS_PTRi (f, A, B, b, 3); \
 AS_PTRi (f, A, B, b, 4); } while (0)
  
  
  int main()
  {
/* Check namespace templates.  */
  
INVOKE4 (f, float, 7);
AS_PTR4 (f, float, int, 7);
  
/* Check member templates.  */
  
S s;
INVOKE4 (s.mf, float, 7);
INVOKE4 (s.smf, float, 7);
INVOKE4 (S::smf, float, 7);
AS_PTR4 (s.smf, float, int, 7);
AS_PTR4 (S::smf, float, int, 7);
  
/* Regression check non-template stateless lambda and its conversion
   to function pointer.  */
  
auto lf0 = [] (float& a, int const& b) { return a += b; };
  
INVOKEi (lf, float, 7

[PATCH 2/4] [lambda] Support implicit conversion of a stateless generic lambda to a function pointer.

2013-08-03 Thread Adam Butcher
---
 gcc/cp/lambda.c | 77 ++---
 1 file changed, 57 insertions(+), 20 deletions(-)

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 98a7925..cf662bb 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -759,12 +759,9 @@ maybe_add_lambda_conv_op (tree type)
   if (processing_template_decl)
 return;
 
-  if (DECL_TEMPLATE_INFO (callop) && DECL_TEMPLATE_RESULT
-(DECL_TI_TEMPLATE (callop)) == callop)
-{
-  warning (0, "Conversion of a generic lambda to a function pointer is not 
currently implemented.");
-  return;
-}
+  bool generic_lambda_p
+= DECL_TEMPLATE_INFO (callop)
+&& DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (callop)) == callop;
 
   if (DECL_INITIAL (callop) == NULL_TREE)
 {
@@ -773,7 +770,38 @@ maybe_add_lambda_conv_op (tree type)
   return;
 }
 
-  stattype = build_function_type (TREE_TYPE (TREE_TYPE (callop)),
+  tree fn_result = TREE_TYPE (TREE_TYPE (callop));
+  tree fn_args = copy_list (DECL_CHAIN (DECL_ARGUMENTS (callop)));
+
+  if (generic_lambda_p)
+{
+  /* Construct the dependent member call for the static member function
+'_FUN' and remove 'auto' from it's return type to allow for simple
+implementation of the conversion operator.  */
+
+  tree instance = build_nop (type, null_pointer_node);
+  argvec = make_tree_vector ();
+  for (arg = fn_args; arg; arg = DECL_CHAIN (arg))
+   {
+ mark_exp_read (arg);
+ vec_safe_push (argvec, arg);
+   }
+
+  tree objfn = build_min (COMPONENT_REF, NULL_TREE,
+ instance, DECL_NAME (callop), NULL_TREE);
+  call = build_nt_call_vec (objfn, argvec);
+
+  if (type_uses_auto (fn_result))
+   {
+ ++processing_template_decl;
+ fn_result = finish_decltype_type
+   (call, /*id_expression_or_member_access_p=*/false,
+tf_warning_or_error);
+ --processing_template_decl;
+   }
+}
+
+  stattype = build_function_type (fn_result,
  FUNCTION_ARG_CHAIN (callop));
 
   /* First build up the conversion op.  */
@@ -801,6 +829,9 @@ maybe_add_lambda_conv_op (tree type)
   if (nested)
 DECL_INTERFACE_KNOWN (fn) = 1;
 
+  if (generic_lambda_p)
+fn = add_inherited_template_parms (fn, DECL_TI_TEMPLATE (callop));
+
   add_method (type, fn, NULL_TREE);
 
   /* Generic thunk code fails for varargs; we'll complain in mark_used if
@@ -827,8 +858,8 @@ maybe_add_lambda_conv_op (tree type)
   DECL_NOT_REALLY_EXTERN (fn) = 1;
   DECL_DECLARED_INLINE_P (fn) = 1;
   DECL_STATIC_FUNCTION_P (fn) = 1;
-  DECL_ARGUMENTS (fn) = copy_list (DECL_CHAIN (DECL_ARGUMENTS (callop)));
-  for (arg = DECL_ARGUMENTS (fn); arg; arg = DECL_CHAIN (arg))
+  DECL_ARGUMENTS (fn) = fn_args;
+  for (arg = fn_args; arg; arg = DECL_CHAIN (arg))
 {
   /* Avoid duplicate -Wshadow warnings.  */
   DECL_NAME (arg) = NULL_TREE;
@@ -837,6 +868,9 @@ maybe_add_lambda_conv_op (tree type)
   if (nested)
 DECL_INTERFACE_KNOWN (fn) = 1;
 
+  if (generic_lambda_p)
+fn = add_inherited_template_parms (fn, DECL_TI_TEMPLATE (callop));
+
   add_method (type, fn, NULL_TREE);
 
   if (nested)
@@ -860,19 +894,22 @@ maybe_add_lambda_conv_op (tree type)
   body = begin_function_body ();
   compound_stmt = begin_compound_stmt (0);
 
-  arg = build1 (NOP_EXPR, TREE_TYPE (DECL_ARGUMENTS (callop)),
-   null_pointer_node);
-  argvec = make_tree_vector ();
-  argvec->quick_push (arg);
-  for (arg = DECL_ARGUMENTS (statfn); arg; arg = DECL_CHAIN (arg))
+  if (!generic_lambda_p)
 {
-  mark_exp_read (arg);
-  vec_safe_push (argvec, arg);
+  arg = build1 (NOP_EXPR, TREE_TYPE (DECL_ARGUMENTS (callop)),
+   null_pointer_node);
+  argvec = make_tree_vector ();
+  argvec->quick_push (arg);
+  for (arg = DECL_ARGUMENTS (statfn); arg; arg = DECL_CHAIN (arg))
+   {
+ mark_exp_read (arg);
+ vec_safe_push (argvec, arg);
+   }
+  call = build_call_a (callop, argvec->length (), argvec->address ());
+  CALL_FROM_THUNK_P (call) = 1;
+  if (MAYBE_CLASS_TYPE_P (TREE_TYPE (call)))
+   call = build_cplus_new (TREE_TYPE (call), call, tf_warning_or_error);
 }
-  call = build_call_a (callop, argvec->length (), argvec->address ());
-  CALL_FROM_THUNK_P (call) = 1;
-  if (MAYBE_CLASS_TYPE_P (TREE_TYPE (call)))
-call = build_cplus_new (TREE_TYPE (call), call, tf_warning_or_error);
   call = convert_from_reference (call);
   finish_return_stmt (call);
 
-- 
1.8.3



[PATCH 1/4] [lambda] Preserve type qualifiers for implicit template parameters.

2013-08-03 Thread Adam Butcher
---
 gcc/cp/pt.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dea1ec0..6e209f8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21317,8 +21317,15 @@ add_implicit_template_parms (size_t count, tree 
parameters)
 
   // Rewrite the type of P to be the template_parm added above (getdecls is
   // used to retrieve it since it is the most recent declaration in this
-  // scope).
-  TREE_TYPE (generic_type_ptr) = TREE_TYPE (getdecls ());
+  // scope).  Qualifiers need to be preserved also.
+
+  tree& cur_type = TREE_TYPE (generic_type_ptr);
+  tree new_type = TREE_TYPE (getdecls ());
+
+  if (TYPE_QUALS (cur_type))
+   cur_type = cp_build_qualified_type (new_type, TYPE_QUALS (cur_type));
+  else
+   cur_type = new_type;
 }
 
   gcc_assert (synth_idx == count);
-- 
1.8.3



Re: [PATCH, Fortran, PR 57987] Do not call cgraph_finalize_function multiple times on finalizers

2013-08-03 Thread Dominique Dhumieres
Hi Martin,

I have applied the patch on top of r201441 and I still get the warning for
gcc/testsuite/gfortran.dg/class_48.f90 with -m32 -O(2|s):

/opt/gcc/work/gcc/testsuite/gfortran.dg/class_48.f90: In function 
'__final_test2_T.2136.constprop.0':
/opt/gcc/work/gcc/testsuite/gfortran.dg/class_48.f90:39:0: warning: iteration 
2147483648 invokes undefined behavior [-Waggressive-loop-optimizations]
 class(t), allocatable :: a
 ^
/opt/gcc/work/gcc/testsuite/gfortran.dg/class_48.f90:39:0: note: containing loop

The test gcc/testsuite/gfortran.dg/pr57987.f90 passes.

Dominique


Backend specific params.def? (Was Re: New parameters to control stringop expansion libcall strategy)

2013-08-03 Thread Jan Hubicka
> On x86_64, when the expected size of memcpy/memset is known (e.g, with
> FDO), libcall strategy is used with the size is > 8192. This value is
> hard coded, which makes it hard to do performance tuning. This patch
> adds two new parameters to do that. Potential usage includes
> per-application libcall strategy min-size tuning based on summary data
> with FDO (e.g, instruction workset size).
> 
> Bootstrap and tested on x86_64/linux. Ok for trunk?
> 
> thanks,
> 
> David
> 
> 
> 2013-08-02  Xinliang David Li  
> 
> * params.def: New parameters.
> * config/i386/i386.c (ix86_option_override_internal):
> Override default libcall size limit with parameters.

Hi,
problem with this is that we introduce generic --param that is used only
by x86 backend.  I am not really guru on the command line options, but I think
this is first time we try to do such thing.  I wonder if
1) We want to introduce target specific params.def
2) We want to use usual -msomething= options
3) We want to go this way?

Honza