Re: [RFC][IPA-VRP] Early VRP Implementation

[Andrew Pinski]

On Thu, Jul 14, 2016 at 9:45 PM, kugan
 wrote:
>
> Hi,
>
>
>
> This patch adds a very simple early vrp implementation. This visits the
> basic blocks in the dominance order and set the Value Ranges (VR) for
>
> SSA_NAMEs in the scope. Use this VR to discover more VRs. Restore the old VR
> once the scope is exit.


Why separate out early VRP from tree-vrp?  Just a little curious.
Also it seems like if you are going to do that, putting the following
functions in a class would be better:
+extern void vrp_initialize (void);
+extern void vrp_finalize (bool update, bool warn_array_bounds_p);
+extern void vrp_intersect_ranges (value_range *vr0, value_range *vr1);
+extern void vrp_meet (value_range *vr0, value_range *vr1);
+extern enum ssa_prop_result vrp_visit_stmt (gimple *stmt,
+edge *taken_edge_p,
+tree *output_p);
+extern enum ssa_prop_result vrp_visit_phi_node (gphi *phi);
+extern bool stmt_interesting_for_vrp (gimple *stmt);
+
+extern void extract_range_from_assert (value_range *vr_p, tree expr);
+extern bool update_value_range (const_tree var, value_range *vr);
+extern value_range *get_value_range (const_tree var);
+extern void set_value_range (value_range *vr, enum value_range_type t,
+ tree min, tree max, bitmap equiv);
+extern void change_value_range (const_tree var, value_range *new_vr);
+
+extern void dump_value_range (FILE *, value_range *);

That is vrp_initialize becomes the constructor and vrp_finalize
becomes the deconstructor.
With both jump_thread and warn_array_bounds_p being variables you set
while running your pass.

Thanks,
Andrew

>
>
>
> Thanks,
>
> Kugan
>
>
>
>
>
> gcc/ChangeLog:
>
>
>
> 2016-07-14  Kugan Vivekanandarajah  
>
>
>
> * Makefile.in: Add tree-early-vrp.o.
>
> * common.opt: New option -ftree-evrp.
>
> * doc/invoke.texi: Document -ftree-evrp.
>
> * passes.def: Define new pass_early_vrp.
>
> * timevar.def: Define new TV_TREE_EARLY_VRP.
>
> * tree-early-vrp.c: New file.
>
> * tree-pass.h (make_pass_early_vrp): New.
>
>
>
> gcc/testsuite/ChangeLog:
>
>
>
> 2016-07-14  Kugan Vivekanandarajah  
>
>
>
> * gcc.dg/tree-ssa/evrp1.c: New test.
>
> * gcc.dg/tree-ssa/evrp2.c: New test.
>
> * gcc.dg/tree-ssa/evrp3.c: New test.
>
> * g++.dg/tree-ssa/pr31146-2.C: Run with -fno-tree-evrp as evrp also
>
> does the same transformation.
>
> * gcc.dg/tree-ssa/pr20318.c: Check for the pattern in evrp dump.
>
> * gcc.dg/tree-ssa/pr22117.c: Likewise.
>
> * gcc.dg/tree-ssa/pr25382.c: Likewise.
>
> * gcc.dg/tree-ssa/pr68431.c: LIkewise.
>
> * gcc.dg/tree-ssa/vrp19.c: Likewise.
>
> * gcc.dg/tree-ssa/vrp23.c: Likewise.
>
> * gcc.dg/tree-ssa/vrp24.c: Likewise.
>
> * gcc.dg/tree-ssa/vrp58.c: Likewise.
>
> * gcc.dg/tree-ssa/vrp67.c: Likewise.
>
> * gcc.dg/tree-ssa/vrp98.c: Likewise.
>
>
>
>
>

[RFC][IPA-VRP] Teach tree-vrp to use the VR set in params

[kugan]

Hi,



This patch teaches tree-vrp to use the VR set in params.



Thanks,

Kugan



gcc/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



 * tree-vrp.c (get_value_range): Teach PARM_DECL to use ipa-vrp

 results.

>From 1900ff9210f1dd673f815b3a421c6ec1e02f6e05 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Thu, 14 Jul 2016 19:28:10 +1000
Subject: [PATCH 6/6] Teach tree-vrp to use ipa-vrp results

---
 gcc/tree-vrp.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 8c87c06..ad3891c 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -667,6 +667,20 @@ get_value_range (const_tree var)
 	  if (POINTER_TYPE_P (TREE_TYPE (sym))
 	  && nonnull_arg_p (sym))
 	set_value_range_to_nonnull (vr, TREE_TYPE (sym));
+	  else if (!POINTER_TYPE_P (TREE_TYPE (sym)))
+	{
+	  wide_int min, max;
+	  value_range_type rtype = get_range_info (var, , );
+	  if (rtype == VR_RANGE || rtype == VR_ANTI_RANGE)
+		{
+		  vr->type = rtype;
+		  vr->min = wide_int_to_tree (TREE_TYPE (var), min);
+		  vr->max = wide_int_to_tree (TREE_TYPE (var), max);
+		  vr->equiv = NULL;
+		}
+	  else
+		set_value_range_to_varying (vr);
+	}
 	  else
 	set_value_range_to_varying (vr);
 	}
-- 
1.9.1

[RFC][IPA-VRP] Add support for IPA VRP in ipa-cp/ipa-prop

[kugan]

Hi,



This patch extends ipa-cp/ipa-prop infrastructure to handle propagation 
of VR.




Thanks,

Kugan





gcc/testsuite/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



* gcc.dg/ipa/vrp1.c: New test.

* gcc.dg/ipa/vrp2.c: New test.

* gcc.dg/ipa/vrp3.c: New test.





gcc/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



* common.opt: New option -fipa-vrp.

* ipa-cp.c (ipa_get_vr_lat): New.

(ipcp_vr_lattice::print): Likewise.

(print_all_lattices): Call ipcp_vr_lattice::print.

(ipcp_vr_lattice::meet_with): New.

(ipcp_vr_lattice::meet_with_1): Likewise.

(ipcp_vr_lattice::top_p): Likewise.

(ipcp_vr_lattice::bottom_p): Likewsie.

(ipcp_vr_lattice::set_to_bottom): Likewise.

(set_all_contains_variable): Call VR set_to_bottom.

(initialize_node_lattices): Init VR lattices.

(propagate_vr_accross_jump_function): New.

(propagate_constants_accross_call): Call

propagate_vr_accross_jump_function.

(ipcp_store_alignment_results): Rename to

ipcp_store_alignment_and_vr_results and handke VR.

* ipa-prop.c (ipa_set_jf_unknown):

(ipa_compute_jump_functions_for_edge): Handle Value Range.

(ipa_node_params_t::duplicate): Likewise.

(ipa_write_jump_function): Likewise.

(ipa_read_jump_function): Likewise.

(write_ipcp_transformation_info): Likewise.

(read_ipcp_transformation_info): Likewise.

(ipcp_update_alignments): Rename to ipcp_update_vr_and_alignments

and handle VR.





>From 092cbccd79c3859ff24846bb0e1892ef5d8086bc Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 21 Jun 2016 12:43:01 +1000
Subject: [PATCH 5/6] Add ipa vrp

---
 gcc/common.opt  |   4 +
 gcc/ipa-cp.c| 220 +++-
 gcc/ipa-prop.c  | 110 ++--
 gcc/ipa-prop.h  |  16 +++
 gcc/testsuite/gcc.dg/ipa/vrp1.c |  32 ++
 gcc/testsuite/gcc.dg/ipa/vrp2.c |  35 +++
 gcc/testsuite/gcc.dg/ipa/vrp3.c |  30 ++
 7 files changed, 433 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp1.c
 create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp2.c
 create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp3.c

diff --git a/gcc/common.opt b/gcc/common.opt
index 29d0e4d..7bf7305 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2475,6 +2475,10 @@ ftree-evrp
 Common Report Var(flag_tree_early_vrp) Init(1) Optimization
 Perform Early Value Range Propagation on trees.
 
+fipa-vrp
+ommon Report Var(flag_ipa_vrp) Init(1) Optimization
+Perform IPA Value Range Propagation on trees.
+
 fsplit-paths
 Common Report Var(flag_split_paths) Init(0) Optimization
 Split paths leading to loop backedges.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 4b7f6bb..97cd04b 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -120,6 +120,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "ipa-inline.h"
 #include "ipa-utils.h"
+#include "tree-vrp.h"
 
 template  class ipcp_value;
 
@@ -266,6 +267,25 @@ private:
   bool meet_with_1 (unsigned new_align, unsigned new_misalign);
 };
 
+/* Lattice of value ranges.  */
+
+class ipcp_vr_lattice
+{
+public:
+  value_range vr;
+
+  inline bool bottom_p () const;
+  inline bool top_p () const;
+  inline bool set_to_bottom ();
+  bool meet_with (const value_range *vr);
+  bool meet_with (const ipcp_vr_lattice );
+  void init () { vr.type = VR_UNDEFINED; }
+  void print (FILE * f);
+
+private:
+  bool meet_with_1 (const value_range *vr);
+};
+
 /* Structure containing lattices for a parameter itself and for pieces of
aggregates that are passed in the parameter or by a reference in a parameter
plus some other useful flags.  */
@@ -281,6 +301,8 @@ public:
   ipcp_agg_lattice *aggs;
   /* Lattice describing known alignment.  */
   ipcp_alignment_lattice alignment;
+  /* Lattice describing value range.  */
+  ipcp_vr_lattice vr;
   /* Number of aggregate lattices */
   int aggs_count;
   /* True if aggregate data were passed by reference (as opposed to by
@@ -348,6 +370,15 @@ ipa_get_poly_ctx_lat (struct ipa_node_params *info, int i)
   return >ctxlat;
 }
 
+/* Return the lattice corresponding to the value range of the Ith formal
+   parameter of the function described by INFO.  */
+static inline ipcp_vr_lattice *
+ipa_get_vr_lat (struct ipa_node_params *info, int i)
+{
+  struct ipcp_param_lattices *plats = ipa_get_parm_lattices (info, i);
+  return >vr;
+}
+
 /* Return whether LAT is a lattice with a single constant and without an
undefined value.  */
 
@@ -458,6 +489,16 @@ ipcp_alignment_lattice::print (FILE * f)
 fprintf (f, " Alignment %u, misalignment %u\n", align, misalign);
 }
 
+/* Print vr lattice to F.  */
+
+void

Re: [RFC][IPA-VRP] Check for POINTER_TYPE_P before accessing SSA_NAME_PTR_INFO in tree-inline

[Andrew Pinski]

On Thu, Jul 14, 2016 at 9:43 PM, kugan
 wrote:
>
> Hi,
>
>
>
> This patch adds check for POINTER_TYPE_P before accessing SSA_NAME_PTR_INFO
> in remap_ssa_name in gcc/tree-inline.c. This is not related to IPA_VRP but
> was exposed by that.

SSA_NAME_PTR_INFO should be NULL for non POINTER_TYPE ssa names?  Why
is it not null in your case?
In both cases there is a check for SSA_NAME_PTR_INFO being NULL before using it.

Thanks,
Andrew

>
>
>
> Thanks,
>
> Kugan
>
>
>
>
>
> gcc/ChangeLog:
>
>
>
> 2016-07-14  Kugan Vivekanandarajah  
>
>
>
> * tree-inline.c (remap_ssa_name): Check for POINTER_TYPE_P before
>
> accessing SSA_NAME_PTR_INFO.
>
>
>
>
>

[RFC][IPA-VRP] Early VRP Implementation

[kugan]

Hi,



This patch adds a very simple early vrp implementation. This visits the 
basic blocks in the dominance order and set the Value Ranges (VR) for


SSA_NAMEs in the scope. Use this VR to discover more VRs. Restore the 
old VR once the scope is exit.




Thanks,

Kugan





gcc/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



* Makefile.in: Add tree-early-vrp.o.

* common.opt: New option -ftree-evrp.

* doc/invoke.texi: Document -ftree-evrp.

* passes.def: Define new pass_early_vrp.

* timevar.def: Define new TV_TREE_EARLY_VRP.

* tree-early-vrp.c: New file.

* tree-pass.h (make_pass_early_vrp): New.



gcc/testsuite/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



* gcc.dg/tree-ssa/evrp1.c: New test.

* gcc.dg/tree-ssa/evrp2.c: New test.

* gcc.dg/tree-ssa/evrp3.c: New test.

* g++.dg/tree-ssa/pr31146-2.C: Run with -fno-tree-evrp as evrp also

does the same transformation.

* gcc.dg/tree-ssa/pr20318.c: Check for the pattern in evrp dump.

* gcc.dg/tree-ssa/pr22117.c: Likewise.

* gcc.dg/tree-ssa/pr25382.c: Likewise.

* gcc.dg/tree-ssa/pr68431.c: LIkewise.

* gcc.dg/tree-ssa/vrp19.c: Likewise.

* gcc.dg/tree-ssa/vrp23.c: Likewise.

* gcc.dg/tree-ssa/vrp24.c: Likewise.

* gcc.dg/tree-ssa/vrp58.c: Likewise.

* gcc.dg/tree-ssa/vrp67.c: Likewise.

* gcc.dg/tree-ssa/vrp98.c: Likewise.





>From d73d443762e1741b810143b2333801cf952c8f17 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Fri, 24 Jun 2016 14:45:24 +1000
Subject: [PATCH 4/6] Add early vrp

---
 gcc/Makefile.in   |   1 +
 gcc/common.opt|   4 +
 gcc/doc/invoke.texi   |   9 +
 gcc/passes.def|   1 +
 gcc/testsuite/g++.dg/tree-ssa/pr31146-2.C |   2 +-
 gcc/testsuite/gcc.dg/tree-ssa/evrp1.c |  13 ++
 gcc/testsuite/gcc.dg/tree-ssa/evrp2.c |  18 ++
 gcc/testsuite/gcc.dg/tree-ssa/evrp3.c |  15 ++
 gcc/testsuite/gcc.dg/tree-ssa/pr20318.c   |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr22117.c   |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr25382.c   |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr68431.c   |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp19.c |   6 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp23.c |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp24.c |   5 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp58.c |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp67.c |   4 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp98.c |   6 +-
 gcc/timevar.def   |   1 +
 gcc/tree-early-vrp.c  | 324 ++
 gcc/tree-pass.h   |   1 +
 21 files changed, 411 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp3.c
 create mode 100644 gcc/tree-early-vrp.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 776f6d7..1804632 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1528,6 +1528,7 @@ OBJS = \
 	tree-vect-loop-manip.o \
 	tree-vect-slp.o \
 	tree-vectorizer.o \
+	tree-early-vrp.o \
 	tree-vrp.o \
 	tree.o \
 	valtrack.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index f0d7196..29d0e4d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2471,6 +2471,10 @@ ftree-vrp
 Common Report Var(flag_tree_vrp) Init(0) Optimization
 Perform Value Range Propagation on trees.
 
+ftree-evrp
+Common Report Var(flag_tree_early_vrp) Init(1) Optimization
+Perform Early Value Range Propagation on trees.
+
 fsplit-paths
 Common Report Var(flag_split_paths) Init(0) Optimization
 Split paths leading to loop backedges.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e000218..f4dc88d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7665,6 +7665,10 @@ enabled by default at @option{-O2} and higher.  Null pointer check
 elimination is only done if @option{-fdelete-null-pointer-checks} is
 enabled.
 
+@item -ftree-evrp
+@opindex ftree-evrp
+Perform Early Value Range Propagation on trees.
+
 @item -fsplit-paths
 @opindex fsplit-paths
 Split paths leading to loop backedges.  This can improve dead code
@@ -12270,6 +12274,11 @@ is made by appending @file{.slp} to the source file name.
 Dump each function after Value Range Propagation (VRP).  The file name
 is made by appending @file{.vrp} to the source file name.
 
+@item early vrp
+@opindex fdump-tree-evrp
+Dump each function after Early Value Range Propagation (EVRP).  The file name
+is made by appending @file{.evrp} to the source file name.
+
 @item oaccdevlow
 @opindex fdump-tree-oaccdevlow
 Dump each function after applying device-specific OpenACC transformations.
diff --git a/gcc/passes.def b/gcc/passes.def
index 

[RFC][IPA-VRP] Re-factor tree-vrp to factor out common code

[kugan]

Hi,



This patch re-factors common code in tree-vrp to be used in early vrp. I 
am not entirely sure where I should place struct value_range. For now I 
have placed in tree.h.




Thanks,

Kugan



2016-07-14  Kugan Vivekanandarajah  



* tree-ssanames.h (enum value_range_type): Move to tree.h.

* tree-vrp.c (struct value_range): Add GTY marker and move to

tree.h.

(set_value_range_to_varying): Move inline function to tree-vrp.h

(symbolic_range_p): Likewise.

(change_value_range): New.

(vrp_finalize): Add param jump_thread_p and make function global.

(execute_vrp): Make function global.

(extract_range_from_assert): Likewise.

(stmt_interesting_for_vrp): Likewise.

(vrp_initialize): Likewise.

(vrp_meet): Likewise.

(vrp_visit_stmt): Likewise.

(vrp_visit_phi_node): Likewise.

* tree-vrp.h: New file.





>From ce7b251bc5a17ae04be57a7fb1db22e86adac282 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 21 Jun 2016 12:42:44 +1000
Subject: [PATCH 3/6] Refactor vrp

---
 gcc/tree-ssanames.h |  5 ---
 gcc/tree-vrp.c  | 93 +
 gcc/tree-vrp.h  | 65 +
 gcc/tree.h  | 31 ++
 4 files changed, 125 insertions(+), 69 deletions(-)
 create mode 100644 gcc/tree-vrp.h

diff --git a/gcc/tree-ssanames.h b/gcc/tree-ssanames.h
index c81b1a1..8e66ce6 100644
--- a/gcc/tree-ssanames.h
+++ b/gcc/tree-ssanames.h
@@ -62,11 +62,6 @@ struct GTY ((variable_size)) range_info_def {
 #define num_ssa_names (vec_safe_length (cfun->gimple_df->ssa_names))
 #define ssa_name(i) ((*cfun->gimple_df->ssa_names)[(i)])
 
-
-/* Type of value ranges.  See value_range_d In tree-vrp.c for a
-   description of these types.  */
-enum value_range_type { VR_UNDEFINED, VR_RANGE, VR_ANTI_RANGE, VR_VARYING };
-
 /* Sets the value range to SSA.  */
 extern void set_range_info (tree, enum value_range_type, const wide_int_ref &,
 			const wide_int_ref &);
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 23c12b5..8c87c06 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -58,32 +58,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "omp-low.h"
 #include "target.h"
 #include "case-cfn-macros.h"
-
-/* Range of values that can be associated with an SSA_NAME after VRP
-   has executed.  */
-struct value_range
-{
-  /* Lattice value represented by this range.  */
-  enum value_range_type type;
-
-  /* Minimum and maximum values represented by this range.  These
- values should be interpreted as follows:
-
-	- If TYPE is VR_UNDEFINED or VR_VARYING then MIN and MAX must
-	  be NULL.
-
-	- If TYPE == VR_RANGE then MIN holds the minimum value and
-	  MAX holds the maximum value of the range [MIN, MAX].
-
-	- If TYPE == ANTI_RANGE the variable is known to NOT
-	  take any values in the range [MIN, MAX].  */
-  tree min;
-  tree max;
-
-  /* Set of SSA names whose value ranges are equivalent to this one.
- This set is only valid when TYPE is VR_RANGE or VR_ANTI_RANGE.  */
-  bitmap equiv;
-};
+#include "tree-vrp.h"
 
 #define VR_INITIALIZER { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL }
 
@@ -103,8 +78,6 @@ live_on_edge (edge e, tree name)
 /* Local functions.  */
 static int compare_values (tree val1, tree val2);
 static int compare_values_warnv (tree val1, tree val2, bool *);
-static void vrp_meet (value_range *, value_range *);
-static void vrp_intersect_ranges (value_range *, value_range *);
 static tree vrp_evaluate_conditional_warnv_with_ops (enum tree_code,
 		 tree, tree, bool, bool *,
 		 bool *);
@@ -351,21 +324,9 @@ set_value_range_to_undefined (value_range *vr)
 }
 
 
-/* Set value range VR to VR_VARYING.  */
-
-static inline void
-set_value_range_to_varying (value_range *vr)
-{
-  vr->type = VR_VARYING;
-  vr->min = vr->max = NULL_TREE;
-  if (vr->equiv)
-bitmap_clear (vr->equiv);
-}
-
-
 /* Set value range VR to {T, MIN, MAX, EQUIV}.  */
 
-static void
+void
 set_value_range (value_range *vr, enum value_range_type t, tree min,
 		 tree max, bitmap equiv)
 {
@@ -660,7 +621,7 @@ abs_extent_range (value_range *vr, tree min, tree max)
If we have no values ranges recorded (ie, VRP is not running), then
return NULL.  Otherwise create an empty range if none existed for VAR.  */
 
-static value_range *
+value_range *
 get_value_range (const_tree var)
 {
   static const value_range vr_const_varying
@@ -717,6 +678,19 @@ get_value_range (const_tree var)
   return vr;
 }
 
+/* Update the value range VR to VAR.  */
+
+void change_value_range (const_tree var, value_range *vr)
+{
+  unsigned ver = SSA_NAME_VERSION (var);
+
+  if (!vr_value)
+return;
+
+  if (ver < num_vr_values)
+  vr_value[ver] = vr;
+}
+
 /* Return true, if VAL1 and VAL2 are equal values for VRP purposes.  */
 
 static inline bool
@@ 

[RFC][IPA-VRP] Check for POINTER_TYPE_P before accessing SSA_NAME_PTR_INFO in tree-inline

[kugan]

Hi,



This patch adds check for POINTER_TYPE_P before accessing 
SSA_NAME_PTR_INFO in remap_ssa_name in gcc/tree-inline.c. This is not 
related to IPA_VRP but was exposed by that.




Thanks,

Kugan





gcc/ChangeLog:



2016-07-14  Kugan Vivekanandarajah  



* tree-inline.c (remap_ssa_name): Check for POINTER_TYPE_P before

accessing SSA_NAME_PTR_INFO.





>From 7c1e5f3058a55d635e57bb4e9f2fd4ff14cd2b94 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 5 Jul 2016 17:14:52 +1000
Subject: [PATCH 2/6] Inliner Check for POINTER_TYPE

---
 gcc/tree-inline.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 07f6a83..f926304 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -244,6 +244,7 @@ remap_ssa_name (tree name, copy_body_data *id)
   /* At least IPA points-to info can be directly transferred.  */
   if (id->src_cfun->gimple_df
 	  && id->src_cfun->gimple_df->ipa_pta
+	  && POINTER_TYPE_P (TREE_TYPE (name))
 	  && (pi = SSA_NAME_PTR_INFO (name))
 	  && !pi->pt.anything)
 	{
@@ -276,6 +277,7 @@ remap_ssa_name (tree name, copy_body_data *id)
   /* At least IPA points-to info can be directly transferred.  */
   if (id->src_cfun->gimple_df
 	  && id->src_cfun->gimple_df->ipa_pta
+	  && POINTER_TYPE_P (TREE_TYPE (name))
 	  && (pi = SSA_NAME_PTR_INFO (name))
 	  && !pi->pt.anything)
 	{
-- 
1.9.1

[RFC][IPA-VRP] Disable setting param of __builtin_constant_p to null

[kugan]

Hi,



VRP assumes that it is run after inlining. Therefore, if there is a call 
to __builtin_constant_p with function parameter, it resolve it to false 
to avoid bogus warnings. Since we use this as an early vrp before 
inling, it leads to  wrong code. As a workaround I have disabled it for 
the time being. That is, this patch is not intended for committing but 
just to get the VRP tested.




Original patch which introduced this also talks about doing it earlier.





Thanks,

Kugan
>From 99f8e7884d582cfae2d7cb50ad59dab7ac6772fc Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Sat, 25 Jun 2016 11:52:57 +1000
Subject: [PATCH 1/6] Hack-Prevent setting __builtin_constant_p of param to
 null before inlining in Early VRP

---
 gcc/tree-vrp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index ecfab1f..23c12b5 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -3759,8 +3759,10 @@ extract_range_basic (value_range *vr, gimple *stmt)
 	  && SSA_NAME_IS_DEFAULT_DEF (arg)
 	  && TREE_CODE (SSA_NAME_VAR (arg)) == PARM_DECL)
 	{
+#if 0
 	  set_value_range_to_null (vr, type);
 	  return;
+#endif
 	}
 	  break;
 	  /* Both __builtin_ffs* and __builtin_popcount return
-- 
1.9.1

[RFC][IPA-VRP] IPA VRP Implementation

[kugan]

Hi,



This patch series implements IPA-VRP based on the previous discussions 
in https://gcc.gnu.org/ml/gcc/2016-01/msg00063.html.




0001-Hack-Prevent-setting-__builtin_constant_p-of-param-t.patch -This is 
to prevent EVRP setting result of __builtin_constant_p to null that will 
inlined later.




0002-Inliner-Check-for-POINTER_TYPE.patch - This is to make sure that we 
call SSA_NAME_PTR_INFO only for POINTER_TYPE_P. This is exposed with 
IPA-VRP but not related to rest of the patch.




0003-Refactor-vrp.patch - Re-factors tree-vrp to expose some of the 
common functionalities.


0004-Add-early-vrp.patch - Adds a simple Early VRP pass.

0005-Add-ipa-vrp.patch - Implements IPA VRP

0006-Teach-tree-vrp-to-use-ipa-vrp-results.patch - Teaches tree-vrp to 
use the value ranges set for the PARMs.




More details about the patches are later with each patch.



Before I go into the details, here is a simple example and the relevant 
dumps as of now:




static __attribute__((noinline, noclone))

int foo (int i)

{

  if (i > 5)

printf ("OK\n");

  else

printf ("NOK\n");

}



int bar (int j)

{

  if (j > 8)

return foo (j + 2);

  else if (j > 2)

return foo (j + 3);



  return 0;

}





The Early VRP dump shows:



_1: [11, +INF(OVF)]

_2: [6, 11]





bar (int j)

{



  _8 = foo (_1);

  goto ;



  :

  if (j_5(D) > 2)

goto ;

  else

goto ;



  :

  _2 = j_5(D) + 3;

  _10 = foo (_2);








The IPA-CP dump shows:



Modification phase of node foo/0

Setting value range of param 0 [6, 2147483647]

__attribute__((noclone, noinline))

foo (int i)







The VRP1 dump shows:



Value ranges after VRP:



.MEM_1: VARYING

i_2(D): [6, +INF]





Folding predicate i_2(D) > 5 to 1

Removing basic block 4

Merging blocks 2 and 3

Merging blocks 2 and 5

__attribute__((noclone, noinline))

foo (int i)

{

  :

  __builtin_puts (&"OK"[0]);

  return;



}



I have bootstrapped and regression tested the patches in this series on 
x86-64 and aarch64 (both normal bootstrap and LTO bootstrap).


There are couple of testcase failures which I am looking into.



Any thoughts?



Thanks,

Kugan

Re: [PATCH/AARCH64] Add rtx_costs routine for vulcan.

[Virendra Pathak]

Hi James/Julian,

Kindly merge this patch to the trunk.
Thanks.

>> Julian has commit rights and is on the ChangeLog, so I'll let him
>> commit the patch on your behalf.
> Julian, Kindly commit the patch to the trunk.
>

with regards,
Virendra Pathak


On Mon, Jul 11, 2016 at 2:50 PM, Virendra Pathak
 wrote:
> Hi James,
>
>> This patch is OK.
> Thanks for the review.
>
>> Julian has commit rights and is on the ChangeLog, so I'll let him
>> commit the patch on your behalf.
> Julian, Kindly commit the patch to the trunk.
>
> Thanks.
>
> with regards,
> Virendra Pathak
>
>
> On Mon, Jul 11, 2016 at 2:28 PM, James Greenhalgh
>  wrote:
>> On Fri, Jul 08, 2016 at 04:01:33PM +0530, Virendra Pathak wrote:
>>> Hi James,
>>>
>>> Please find the patch after taking care of your comments.
>>>
>>>
>>> > Did you see those patches, and did you consider whether there would be a
>>> > benefit to doing the same for Vulcan?
>>> In our simulation environment, we did not observe any performance gain
>>> for specfp2006.
>>> However, we did it to keep the cost strategy same as cortexa-57/53.
>>>
>>> Please review and merge to trunk.
>>
>> Hi Virendra,
>>
>> This patch is OK.
>>
>> Julian has commit rights and is on the ChangeLog, so I'll let him
>> commit the patch on your behalf.
>>
>> Thanks,
>> James
>>
>>> gcc/ChangeLog:
>>>
>>> Virendra Pathak  
>>> Julian Brown  
>>>
>>> * config/aarch64/aarch64-cores.def: Update vulcan COSTS.
>>> * config/aarch64/aarch64-cost-tables.h
>>> (vulcan_extra_costs): New variable.
>>> * config/aarch64/aarch64.c
>>> (vulcan_addrcost_table): Likewise.
>>> (vulcan_regmove_cost): Likewise.
>>> (vulcan_vector_cost): Likewise.
>>> (vulcan_branch_cost): Likewise.
>>> (vulcan_tunings): Likewise.
>>

[PATCH] Fix OpenACC vector_length parsing in fortran

[Cesar Philippidis]

The fortran FE is currently scanning for the vector clause before
vector_length. That's a problem match_oacc_clause_gwv matches 'vector'
without looking for whatever follows it. The correction I made here was
to scan for vector_length before vector.

Is this OK for trunk and gcc6?

Cesar
2016-07-14  Cesar Philippidis  

	gcc/fortran/
	* openmp.c (gfc_match_omp_clauses): Scan for clause vector_length
	before vector.

	gcc/testsuite/
	* gfortran.dg/goacc/vector_length.f90: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 865e0d9..b70ff3e 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1338,6 +1338,11 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask,
 	continue;
 	  break;
 	case 'v':
+	  if ((mask & OMP_CLAUSE_VECTOR_LENGTH)
+	  && c->vector_length_expr == NULL
+	  && (gfc_match ("vector_length ( %e )", >vector_length_expr)
+		  == MATCH_YES))
+	continue;
 	  if ((mask & OMP_CLAUSE_VECTOR)
 	  && !c->vector
 	  && gfc_match ("vector") == MATCH_YES)
@@ -1353,11 +1358,6 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask,
 		needs_space = true;
 	  continue;
 	}
-	  if ((mask & OMP_CLAUSE_VECTOR_LENGTH)
-	  && c->vector_length_expr == NULL
-	  && (gfc_match ("vector_length ( %e )", >vector_length_expr)
-		  == MATCH_YES))
-	continue;
 	  break;
 	case 'w':
 	  if ((mask & OMP_CLAUSE_WAIT)
diff --git a/gcc/testsuite/gfortran.dg/goacc/vector_length.f90 b/gcc/testsuite/gfortran.dg/goacc/vector_length.f90
new file mode 100644
index 000..ddab9cf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/vector_length.f90
@@ -0,0 +1,11 @@
+program t
+  implicit none
+  integer, parameter :: n = 100
+  integer a(n), i
+
+  !$acc parallel loop num_gangs(100) num_workers(1) vector_length(32)
+  do i = 1, n
+ a(i) = i
+  enddo
+  !$acc end parallel loop
+end program t

Re: [PATCH] zero-length arrays in OpenACC

[Cesar Philippidis]

Ping, x2.

Cesar

On 06/01/2016 02:35 PM, Cesar Philippidis wrote:
> This patch teaches c and c++ front ends and omp-low how to deal with
> subarray involving GOMP_MAP_FORCE_{PRESENT,TO,FROM,TOFROM} data
> mappings. As the libgomp test case shows, it might be possible for a
> subarray to have zero length. This patch fixes that.
> 
> I also updated *parser_oacc_declare not to handle GOMP_MAP_POINTER,
> because subarray pointers are now firstprivate.
> 
> Is this OK for trunk?
> 
> Cesar
> 

Re: [patch, fortran] PR62125 Nested select type not accepted (rejects valid)

[Jerry DeLisle]

Hit send too soon and forgot to fill out the subject line. Correctly 
given here.

On 07/14/2016 10:47 AM, Jerry DeLisle wrote:

This simple patch kindly provided by Marco solves the problem.

Regression tested on x86_64-Linux, Test case provided also.

OK to commit to trunk?

Jerry

2016-07-14  Jerry DeLisle  
Marco Restelli 

PR fortran/62125
* symbol.c (select_type_insert_tmp): Recursively call self to take care
of nested select type.

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 0ee7dec..c967f25 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2930,7 +2930,11 @@ select_type_insert_tmp (gfc_symtree **st)
   gfc_select_type_stack *stack = select_type_stack;
   for (; stack; stack = stack->prev)
 if ((*st)->n.sym == stack->selector && stack->tmp)
-  *st = stack->tmp;
+  {
+*st = stack->tmp;
+select_type_insert_tmp (st);
+return;
+  }
 }

[libstdc++] Add C++17clamp

[Ed Smith-Rowland]

Here is an implementation of P0025
An algorithm to "clamp" a value between a pair of boundary values.

Testing is almost finished - looks good so far.

OK if testing passes?

I didn't see a feature test in any of the SD-6 papers or P0025.


2016-07-15  Edward Smith-Rowland  <3dw...@verizon.net>

Implement C++17 P0025 clamp.
* include/bits/algorithmfwd.h: Declare clamp overloads.
* include/bits/stl_algo.h: Implement clamp.
* testsuite/25_algorithms/clamp/1.cc: New test.
* testsuite/25_algorithms/clamp/2.cc: New test.
* testsuite/25_algorithms/clamp/constexpr.cc: New test.
* testsuite/25_algorithms/clamp/requirements/explicit_instantiation/
1.cc: New test.
* testsuite/25_algorithms/clamp/requirements/explicit_instantiation/
pod.cc: New test.
Index: include/bits/algorithmfwd.h
===
--- include/bits/algorithmfwd.h (revision 238302)
+++ include/bits/algorithmfwd.h (working copy)
@@ -48,6 +48,7 @@
 all_of (C++0x)
 any_of (C++0x)
 binary_search
+clamp (C++17)
 copy
 copy_backward
 copy_if (C++0x)
@@ -208,6 +209,18 @@
 bool 
 binary_search(_FIter, _FIter, const _Tp&, _Compare);
 
+#if __cplusplus > 201402L
+  template
+_GLIBCXX14_CONSTEXPR
+const _Tp&
+clamp(const _Tp&, const _Tp&, const _Tp&);
+
+  template
+_GLIBCXX14_CONSTEXPR
+const _Tp&
+clamp(const _Tp&, const _Tp&, const _Tp&, _Compare);
+#endif
+
   template
 _OIter 
 copy(_IIter, _IIter, _OIter);
Index: include/bits/stl_algo.h
===
--- include/bits/stl_algo.h (revision 238302)
+++ include/bits/stl_algo.h (working copy)
@@ -3698,8 +3698,44 @@
   return std::__is_permutation(__first1, __last1, __first2, __last2,
   __gnu_cxx::__ops::__iter_comp_iter(__pred));
 }
-#endif
 
+#if __cplusplus > 201402L
+  /**
+   *  @brief  Returns the value clamped between lo and hi.
+   *  @ingroup sorting_algorithms
+   *  @param  __val  A value of arbitrary type.
+   *  @param  __lo   A lower limit of arbitrary type.
+   *  @param  __hi   An upper limit of arbitrary type.
+   *  @return max(__val, __lo) if __val < __hi or min(__val, __hi) otherwise.
+   */
+  template
+constexpr const _Tp&
+clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi)
+{
+  __glibcxx_assert(!(__hi < __lo));
+  return (__val < __lo) ? __lo : (__hi < __val) ? __hi : __val;
+}
+
+  /**
+   *  @brief  Returns the value clamped between lo and hi.
+   *  @ingroup sorting_algorithms
+   *  @param  __val   A value of arbitrary type.
+   *  @param  __loA lower limit of arbitrary type.
+   *  @param  __hiAn upper limit of arbitrary type.
+   *  @param  __comp  A comparison functor.
+   *  @return max(__val, __lo, __comp) if __comp(__val, __hi)
+   * or min(__val, __hi, __comp) otherwise.
+   */
+  template
+constexpr const _Tp&
+clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi, _Compare __comp)
+{
+  __glibcxx_assert(!__comp(__hi, __lo));
+  return __comp(__val, __lo) ? __lo : __comp(__hi, __val) ? __hi : __val;
+}
+#endif // C++17
+#endif // C++14
+
 #ifdef _GLIBCXX_USE_C99_STDINT_TR1
   /**
*  @brief Shuffle the elements of a sequence using a uniform random
Index: testsuite/25_algorithms/clamp/1.cc
===
--- testsuite/25_algorithms/clamp/1.cc  (nonexistent)
+++ testsuite/25_algorithms/clamp/1.cc  (working copy)
@@ -0,0 +1,48 @@
+// { dg-options "-std=gnu++17" }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+#include 
+
+void test01()
+{
+  bool test __attribute__((unused)) = true;
+
+  const int x = std::clamp(1, 2, 4);
+  const int y = std::clamp(3, 2, 4);
+  const int z = std::clamp(5, 2, 4);
+  VERIFY( x == 2 );
+  VERIFY( y == 3 );
+  VERIFY( z == 4 );
+
+  const int xc = std::clamp(1, 2, 4, std::greater());
+  const int yc = std::clamp(3, 2, 4, std::greater());
+  const int zc = std::clamp(5, 2, 4, std::greater());
+  VERIFY( xc == 4 );
+  VERIFY( yc == 2 );
+  VERIFY( zc == 2 );
+}
+
+int
+main()
+{
+  

Re: [PATCH 2/3] Run profile feedback tests with autofdo

[Andi Kleen]

> >> I haven't seen that. Unstable in what way?
> > For GCC doesn't support FDO, it run below tests as you said:
> >
> > PASS: gcc.dg/tree-prof/20041218-1.c compilation,  -g
> > UNSUPPORTED: gcc.dg/tree-prof/20041218-1.c: Cannot run create_gcov
> > --binary /data/work/trunk/build/gcc/testsuite/gcc/20041218-1.gcda
> >
> > Normally, it doesn't create gcov data file, thus the next test is
> > unsupported.  I guess in parallel test, the second test picks up gcov
> > data files from other process, which results in random pass.
> > Is it possible to not have these when fdo is supported?
> Hmm, typo:  s/supported/not supported/.

I don't see how this can happen: as you can see the .gcda file name
is unique for each test case.

I think there may be problems with the perf.data, could add a postfix.
But you should only see that with real autofdo.

-Andi

Re: [PATCH] Add missing OBJCOPY variable to Makefile.in

[JonY]

On 7/14/2016 06:22, Jeff Law wrote:
> On 07/03/2016 05:56 AM, JonY wrote:
>> This patch allows OBJCOPY to be set by configure. It was missing in
>> Makefile.in.
>>
>> Patch OK?
> With a ChangeLog and verification that some host/target combination
> still builds this is OK.
> 
> jeff
> 
> 

Modified the patch slightly to include Makefile.tpl.
Tested with Cygwin and cross to mingw-w64.

ChangeLog:
2016-03-26  Corinna Vinschen  

* Makefile.tpl: Add missing OBJCOPY variable.
* Makefile.in: Regenerate.

diff --git a/Makefile.in b/Makefile.in
index 117fbf5..737e602 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -400,6 +400,7 @@ DLLTOOL = @DLLTOOL@
 LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
+OBJCOPY = @OBJCOPY@
 OBJDUMP = @OBJDUMP@
 RANLIB = @RANLIB@
 READELF = @READELF@
diff --git a/Makefile.tpl b/Makefile.tpl
index 94a4f79..597107c 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -403,6 +403,7 @@ DLLTOOL = @DLLTOOL@
 LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
+OBJCOPY = @OBJCOPY@
 OBJDUMP = @OBJDUMP@
 RANLIB = @RANLIB@
 READELF = @READELF@
 Makefile.in  |1 +
 Makefile.tpl |1 +
 2 files changed, 2 insertions(+)




signature.asc
Description: OpenPGP digital signature

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

[Jeff Law]

On 06/28/2016 06:24 AM, Ilya Enkovich wrote:



Here is an updated patch version.

Thanks,
Ilya
--
gcc/

2016-05-28  Ilya Enkovich  

* dbgcnt.def (vect_tail_combine): New.
* params.def (PARAM_VECT_COST_INCREASE_COMBINE_THRESHOLD): New.
* tree-vect-data-refs.c (vect_get_new_ssa_name): Support vect_mask_var.
* tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): Support
epilogue combined with loop body.
(vect_do_peeling_for_loop_bound): LIkewise.
(vect_do_peeling_for_alignment): ???
* tree-vect-loop.c Include alias.h and dbgcnt.h.
(vect_estimate_min_profitable_iters): Add 
ret_min_profitable_combine_niters
arg, compute number of iterations for which loop epilogue combining is
profitable.
(vect_generate_tmps_on_preheader): Support combined apilogue.
(vect_gen_ivs_for_masking): New.
(vect_get_mask_index_for_elems): New.
(vect_get_mask_index_for_type): New.
(vect_gen_loop_masks): New.
(vect_mask_reduction_stmt): New.
(vect_mask_mask_load_store_stmt): New.
(vect_mask_load_store_stmt): New.
(vect_combine_loop_epilogue): New.
(vect_transform_loop): Support combined apilogue.


diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 41b9380..08fad82 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6895,6 +7044,489 @@ vect_generate_tmps_on_preheader (loop_vec_info 
loop_vinfo,
   return;
 }


 +

+/* Function vect_gen_loop_masks.
+
+   Create masks to mask a loop described by LOOP_VINFO.  Masks
+   are created according to LOOP_VINFO_REQUIRED_MASKS and are stored
+   into MASKS vector.
+
+   Index of a mask in a vector is computed according to a number
+   of masks's elements.  Masks are sorted by number of its elements
+   in descending order.  Index 0 is used to access a mask with
+   current_vector_size elements.  Among masks with the same number
+   of elements the one with lower index is used to mask iterations
+   with smaller iteration counter.  Note that you may get NULL elements
+   for masks which are not required.  Use vect_get_mask_index_for_elems
+   or vect_get_mask_index_for_type to access resulting vector.  */
+
+static void
+vect_gen_loop_masks (loop_vec_info loop_vinfo, vec *masks)
I find myself wondering if this ought to be broken down a bit (without 
changing the underlying semantics).



+
+  /* Create narrowed masks.  */
+  cur_mask_elems = iv_elems;
+  nmasks = ivs.length ();
+  while (cur_mask_elems < max_mask_elems)
+{
+  prev_mask = vect_get_mask_index_for_elems (cur_mask_elems);
+
+  cur_mask_elems <<= 1;
+  nmasks >>= 1;
+
+  cur_mask = vect_get_mask_index_for_elems (cur_mask_elems);
+
+  mask_type = build_truth_vector_type (cur_mask_elems, vec_size);
+
+  for (unsigned i = 0; i < nmasks; i++)
+   {
+ tree mask_low = (*masks)[prev_mask++];
+ tree mask_hi = (*masks)[prev_mask++];
+ mask = vect_get_new_ssa_name (mask_type, vect_mask_var);
+ stmt = gimple_build_assign (mask, VEC_PACK_TRUNC_EXPR,
+ mask_low, mask_hi);
+ gsi_insert_before (, stmt, GSI_SAME_STMT);
+ (*masks)[cur_mask++] = mask;
+   }
+}
For example, pull this into its own function as well as the code to 
create widened masks.  In fact, didn't I see those functions in one of 
the other patches as their own separate subroutines?


It's not a huge deal and I don't think it requires another round of 
review.  I just found myself scrolling through multiple pages of this 
function and thought it'd be slightly easier to grok if were simply smaller.




+
+/* Function vect_mask_reduction_stmt.
+
+   Mask given vectorized reduction statement STMT using
+   MASK.  In case scalar reduction statement is vectorized
+   into several vector statements then PREV holds a
+   preceding vetor statement copy for STMT.

s/vetor/vector/

With the one function split up and the typo fix I think this is OK for 
the trunk when the set as a whole is ready.


jeff

Re: [PATCH, vec-tails 08/10] Support loop epilogue masking and low trip count loop vectorization

[Jeff Law]

On 06/24/2016 05:46 AM, Ilya Enkovich wrote:


Here is an updated version.  It allows vectorization with a smaller vector size
in case we fail to vectorize with masking.

Thanks,
Ilya
--
gcc/

2016-05-24  Ilya Enkovich  

* dbgcnt.def (vect_tail_mask): New.
* tree-vect-loop.c (vect_analyze_loop_2): Support masked loop
epilogues and low trip count loops.
(vect_get_known_peeling_cost): Ignore scalar epilogue cost for
loops we are going to mask.
(vect_estimate_min_profitable_iters): Support masked loop
epilogues and low trip count loops.
* tree-vectorizer.c (vectorize_loops): Add a message for a case
when loop epilogue can't be vectorized.


This is OK once the rest of the series is approved.

jeff

PR fortran/29819 -- fix committed.

[Steve Kargl]

Committed as obvious.

2016-07-14  Steven G. Kargl  

PR fortran/29819
* parse.c (parse_contained): Use proper locus.
 

2016-07-14  Steven G. Kargl  

PR fortran/29819
* gfortran.dg/bind_c_usage_9.f03: Move dg-error.
* gfortran.dg/contains.f90: Ditto.
* gfortran.dg/contains_empty_1.f03: Ditto.
* gfortran.dg/submodule_3.f08: Ditto.

Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 238345)
+++ gcc/fortran/parse.c (working copy)
@@ -5321,6 +5321,7 @@ parse_contained (int module)
   gfc_statement st;
   gfc_symbol *sym;
   gfc_entry_list *el;
+  locus old_loc;
   int contains_statements = 0;
   int seen_error = 0;
 
@@ -5337,6 +5338,7 @@ parse_contained (int module)
  next:
   /* Process the next available statement.  We come here if we got an error
 and rejected the last statement.  */
+  old_loc = gfc_current_locus;
   st = next_statement ();
 
   switch (st)
@@ -5442,7 +5444,7 @@ parse_contained (int module)
   pop_state ();
   if (!contains_statements)
 gfc_notify_std (GFC_STD_F2008, "CONTAINS statement without "
-   "FUNCTION or SUBROUTINE statement at %C");
+   "FUNCTION or SUBROUTINE statement at %L", _loc);
 }
 
 
Index: gcc/testsuite/gfortran.dg/bind_c_usage_9.f03
===
--- gcc/testsuite/gfortran.dg/bind_c_usage_9.f03(revision 238345)
+++ gcc/testsuite/gfortran.dg/bind_c_usage_9.f03(working copy)
@@ -6,42 +6,42 @@
 ! for Fortran 2003.
 !
 subroutine foo() bind(c)
-contains
+contains ! { dg-error "Fortran 2008: CONTAINS statement" }
   subroutine bar() bind (c) ! { dg-error "may not be specified for an 
internal" }
   end subroutine bar ! { dg-error "Expected label" }
-end subroutine foo ! { dg-error "Fortran 2008: CONTAINS statement" }
+end subroutine foo
 
 subroutine foo2() bind(c)
   use iso_c_binding
-contains
+contains ! { dg-error "Fortran 2008: CONTAINS statement" }
   integer(c_int) function barbar() bind (c) ! { dg-error "may not be specified 
for an internal" }
   end function barbar ! { dg-error "Expecting END SUBROUTINE" }
-end subroutine foo2 ! { dg-error "Fortran 2008: CONTAINS statement" }
+end subroutine foo2
 
 function one() bind(c)
   use iso_c_binding
   integer(c_int) :: one
   one = 1
-contains
+contains ! { dg-error "Fortran 2008: CONTAINS statement" }
   integer(c_int) function two() bind (c) ! { dg-error "may not be specified 
for an internal" }
   end function two ! { dg-error "Expected label" }
-end function one ! { dg-error "Fortran 2008: CONTAINS statement" }
+end function one
 
 function one2() bind(c)
   use iso_c_binding
   integer(c_int) :: one2
   one2 = 1
-contains
+contains ! { dg-error "Fortran 2008: CONTAINS statement" }
   subroutine three() bind (c) ! { dg-error "may not be specified for an 
internal" }
   end subroutine three ! { dg-error "Expecting END FUNCTION statement" }
-end function one2 ! { dg-error "Fortran 2008: CONTAINS statement" }
+end function one2
 
 program main
   use iso_c_binding
   implicit none
-contains
+contains ! { dg-error "Fortran 2008: CONTAINS statement" }
   subroutine test() bind(c) ! { dg-error "may not be specified for an 
internal" }
   end subroutine test ! { dg-error "Expecting END PROGRAM" }
   integer(c_int) function test2() bind (c) ! { dg-error "may not be specified 
for an internal" }
   end function test2  ! { dg-error "Expecting END PROGRAM" }
-end program main ! { dg-error "Fortran 2008: CONTAINS statement" }
+end program main
Index: gcc/testsuite/gfortran.dg/contains.f90
===
--- gcc/testsuite/gfortran.dg/contains.f90  (revision 238345)
+++ gcc/testsuite/gfortran.dg/contains.f90  (working copy)
@@ -3,9 +3,9 @@
 ! Check whether empty contains are allowd
 ! PR fortran/29806
 module x
- contains
-end module x ! { dg-error "CONTAINS statement without FUNCTION or SUBROUTINE 
statement" }
+ contains ! { dg-error "CONTAINS statement without FUNCTION or SUBROUTINE 
statement" }
+end module x
 
 program y
-  contains
-end program y ! { dg-error "CONTAINS statement without FUNCTION or SUBROUTINE 
statement" }
+  contains  ! { dg-error "CONTAINS statement without FUNCTION or SUBROUTINE 
statement" }
+end program y
Index: gcc/testsuite/gfortran.dg/contains_empty_1.f03
===
--- gcc/testsuite/gfortran.dg/contains_empty_1.f03  (revision 238345)
+++ gcc/testsuite/gfortran.dg/contains_empty_1.f03  (working copy)
@@ -2,10 +2,10 @@
 ! { dg-options "-std=f2003 -pedantic" }
 program test
   print *, 'hello there'
-contains
-end program test ! { dg-error "Fortran 2008: CONTAINS statement without" }
+contains ! { dg-error "Fortran 2008: CONTAINS statement without" }
+end program test
 
 module 

Re: [PATCH, vec-tails 03/10] Support epilogues vectorization with no masking

[Jeff Law]

On 06/24/2016 01:40 AM, Ilya Enkovich wrote:



Here is an updated version with disabled alias checks for loop epilogues.
Instead of calling vect_analyze_data_ref_dependence I just use VF of the
original loop as MAX_VF for epilogue.

Thanks,
Ilya
--
gcc/

2016-05-24  Ilya Enkovich  

* tree-if-conv.c (tree_if_conversion): Make public.
* tree-if-conv.h: New file.
* tree-vect-data-refs.c (vect_analyze_data_ref_dependences) Avoid
dynamic alias checks for epilogues.
(vect_enhance_data_refs_alignment): Don't try to enhance alignment
for epilogues.
* tree-vect-loop-manip.c (vect_do_peeling_for_loop_bound): Return
created loop.
* tree-vect-loop.c: include tree-if-conv.h.
(destroy_loop_vec_info): Preserve LOOP_VINFO_ORIG_LOOP_INFO in
loop->aux.
(vect_analyze_loop_form): Init LOOP_VINFO_ORIG_LOOP_INFO and reset
loop->aux.
(vect_analyze_loop): Reset loop->aux.
(vect_transform_loop): Check if created epilogue should be returned
for further vectorization.  If-convert epilogue if required.
* tree-vectorizer.c (vectorize_loops): Add a queue of loops to
process and insert vectorized loop epilogues into this queue.
* tree-vectorizer.h (vect_do_peeling_for_loop_bound): Return created
loop.
(vect_transform_loop): Return created loop.
I know Richi wasn't all that happy with the call into if-conversion and 
I don't particularly like the use of aux for smuggling data around.  But 
I think those are warts, not fundamental design flaws.


OK once the rest of the bits are approved.

jeff

Re: [PATCH] Handle undefined extern vars in output_in_order

[Jeff Law]

On 06/23/2016 08:45 AM, Alexander Monakov wrote:

Hi,

I've discovered that this assert in my patch was too restrictive:

+  if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+   {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+DECL_ATTRIBUTES (pv->decl)));

Testing for the nvptx target uncovered that there's another case where a
global variable would have a value expr: emutls.  Sorry for not spotting it
earlier (but at least the new assert did its job).  I think we should always
skip here over decls that have value-exprs, just like hard-reg vars are
skipped.  The following patch does that.  Is this still OK?

(bootstrapped/regtested on x86-64)

Alexander

* cgraphunit.c (cgraph_order_sort_kind): New entry ORDER_VAR_UNDEF.
(output_in_order): Loop over undefined variables too.  Output them
via assemble_undefined_decl.  Skip variables that correspond to hard
registers or have value-exprs.
* varpool.c (symbol_table::output_variables): Handle undefined
variables together with defined ones.

OK.  Thanks for your patience.
jeff

Re: [PATCH] Handle undefined extern vars in output_in_order

[Jeff Law]

On 07/14/2016 12:33 PM, Alexander Monakov wrote:

On Thu, 14 Jul 2016, Jeff Law wrote:

Is the point here to be able to deduce what symbols are external & undefined
and emit some kind of directive to the assembler in that case?


Yes, PTX assembly requires that properly typed declarations are emitted for
external references.  Today, the NVPTX backend in GCC performs that internally
for function symbols, and relies on the middle-end to do that for data symbols,
but when the port was added that was implemented only when -ftoplevel-reorder is
in effect (the default).
Right.  I remember noting that in my brief review of the PTX assembly 
specs and figuring it wouldn't be a big deal since we had a functional 
hack in place for the PA/SOM which has similar requirements.




*nod*, although as I mentioned above today it's handled in a generic way only
for undefined data symbols, not undefined function symbols.
Understood.  Quickly reviewing the PA code, the other bit of magic is we 
avoided importing a symbol which was declared as extern, but never 
actually used.  IIRC that caused the HP/SOM linker to core dump. 
Hopefully the PTX assembler/linker/finalizer handles that case more 
gracefully...


Jeff

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[Eric Gallager]

On 7/14/16, Jeff Law  wrote:
> On 07/14/2016 04:57 AM, Eric Gallager wrote:
>> On 7/13/16, Jeff Law  wrote:
>>> On 06/27/2016 08:10 PM, Eric Gallager wrote:
 The last time I ran ./contrib/download_prerequisites, I already had
 previous symlinks set up from a previous run of the script, so `ln`
 followed the existing symlinks and created the new ones in the
 directories to which the symlinks pointed. This patch should fix that
 by removing the old symlinks before creating new ones. (For some
 reason the `-f` flag to `ln` that was already there wasn't enough for
 me.) Tested by running the script and ensuring that the new isl
 symlink pointed to the correct directory, and that there were no bad
 symlinks in the old isl directory. Could someone commit this trivial
 patch for me, or something like it? I don't have write access.
>>> I'd really rather know why the "-f" flag didn't work for you.  The whole
>>> point of -f is to remove the destination file first.
>>>
>>> Jeff
>>>
>>
>> Reading my ln manpage, it describes the "-f" flag like this:
>>
>>
>>  -fIf the target file already exists, then unlink it so that the
>>link may occur.  (The -f option overrides any previous -i
>>options.)
>>
>> Okay, so that seems like it should do what you say, but the manpage
>> also describes a separate uppercase "-F" option:
>>
>>  -FIf the target file already exists and is a directory, then
>>remove it so that the link may occur.  The -F option should be
>>used with either -f or -i options.  If none is specified, -f
>> is
>>implied.  The -F option is a no-op unless -s option is speci-
>>fied.
>>
>> So it seems to imply that "-f" will only remove the destination file
>> if it's a regular file, while "-F" is needed if the destination file
>> is a directory. The page also has this to say about "-F" later:
>>
>>  The -F option is FreeBSD extention and should not be used in
>> portable
>>  scripts.
>>
>> So this could be a BSD vs. GNU thing.
> I don't have any BSD systems running.  I can confirm that while "-f"
> refers to files in the man page, it will happy delete the old symlink as
> well.
>
> -bash-4.3$ ln -s /bin/ls jj
> -bash-4.3$ ln -s -f /bin/bash jj
> -bash-4.3$ ls -l jj
> lrwxrwxrwx. 1 law law 9 Jul 14 13:22 jj -> /bin/bash
> -bash-4.3$ which ln
> /usr/bin/ln
> -bash-4.3$ rpm -q --whatprovides /usr/bin/ln
> coreutils-8.24-6.fc23.x86_64
>
> Could you test this on your system?
>
> Jeff
>

$ ln -s /bin/ls jj
$ ln -s -f /bin/bash jj
$ ls -l jj
lrwxr-xr-x  1 root  wheel  9 Jul 14 15:45 jj -> /bin/bash
$ which ln
/bin/ln
$ rpm -q --whatprovides /bin/ln
file /bin/ln is not owned by any package
$ which rpm
/sw/bin/rpm

So apparently the "-f" flag properly overwrites symlinks that point to
regular files, but I also did this in my gcc builddir:

$ mkdir isl-0.1.2.3
$ ln -s isl-0.1.2.3 isl-s
$ ln -sfv isl isl-s
isl-s/isl -> isl
$ ln -sfFv isl isl-s
isl-s/isl -> isl
$ ls -l isl-s
lrwxr-xr-x  1 root  wheel  11 Jul 14 07:03 isl-s -> isl-0.1.2.3
$ unlink isl-s
$ ln -sfFv isl isl-s
isl-s -> isl
$ ls -l isl-s
lrwxr-xr-x  1 root  wheel  3 Jul 14 15:51 isl-s -> isl

...it just doesn't overwrite symlinks that point to a directory.

Re: [PATCH] Tweak diagnostic-token.ranges.c testcase (PR testsuite/71865)

[Jakub Jelinek]

On Thu, Jul 14, 2016 at 02:29:10PM -0400, David Malcolm wrote:
> > Tested on x86_64-linux and i686-linux, ok for trunk?
> 
> Thanks.  I think I can approve this with my "libcpp/diagnostic messages
> " maintainer hat on.
> 
> Did you test the case with a build for one of the affected targets to
> verify the fix?

Tested just with the cross-compiler to powerpc64le-linux besides
x86_64/i686 bootstrap/regtests, in the cross it fails without the patch
and succeeds with it.  Change committed.

> > 2016-07-14  Jakub Jelinek  
> > 
> > PR testsuite/71865
> > * gcc.dg/diagnostic-token-ranges.c: Add -std=c11 to dg-options.
> > (wide_string_literal_in_asm): Use __asm instead of asm, adjust
> > expected diagnostics.

Jakub

Re: [C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[Jakub Jelinek]

On Thu, Jul 14, 2016 at 02:22:36PM -0400, David Malcolm wrote:
> I agree with the points you raise; in that light I'm fine with your
> patch.

Ok, Marek has approved it earlier, so I went ahead and committed.

> > shouldn't be lowered (say for at
> > most 4 chars identifiers only consider levenshtein distance 1 and not
> > more,
> > e.g. for 3 character identifiers allowing distance of 2 or 3 means
> > you pretty
> > much suggest any other 3 char identifier), regardless of if it is a
> > builtin or not.
> 
> The logic in get_best_meaningful_candidate is currently:
> 
>   unsigned int cutoff = MAX (m_goal_len, m_best_candidate_len) / 2;
>   if (m_best_distance > cutoff)
>  return NULL;
> 
> For a pair of 3 character identifiers, cutoff will be 3 / 2 == 1, so it
> will suggest within a distance of 1 and reject if the distance is 2 or
> 3.   Or is there a bug?
> 
> That cutoff could definitely be improved.  Perhaps the MAX should be
> changed to a MIN?  Or just base it off the goal length e.g. 
>   unsigned int cutoff = m_goal_len / 2;
> thus implicitly rejecting
> suggestions when m_goal_len == 1.
> That would eliminate the "bar" to
> "char" suggestion in the PR, since m_goal_len == 3 would have a cutoff
> of 1.

I'm afraid I don't have enough experience, so we'll need to look at lost of
suggestions and find the right tuning.

Jakub

Re: [PATCH] Handle undefined extern vars in output_in_order

[Alexander Monakov]

On Thu, 14 Jul 2016, Jeff Law wrote:
> Is the point here to be able to deduce what symbols are external & undefined
> and emit some kind of directive to the assembler in that case?

Yes, PTX assembly requires that properly typed declarations are emitted for
external references.  Today, the NVPTX backend in GCC performs that internally
for function symbols, and relies on the middle-end to do that for data symbols,
but when the port was added that was implemented only when -ftoplevel-reorder is
in effect (the default).

The point of my patch is to handle it under -fno-toplevel-reorder in the same
way.

> Avoiding duplicates

this is not required for PTX, but nevertheless a good cleanup we get for free

> as well as symbols which may have had originally looked like external &
> undefined, but later we find a definition?

I think this only would be a problem if GCC continued to support
-fno-unit-at-a-time.  AFAIK today GCC's symtab reflects symbol availability
exactly, because the whole translation unit has been read upfront.

> The reason I ask someone might be able to simplify a bit of the PA backend if
> that's the goal here.  The PA (when using the SOM object format) has similar
> needs.  We solved it by queuing up everything that might need "importing".
> Then at the end of the compilation unit, we'd walk that queue of symbols
> emitting the proper magic.

*nod*, although as I mentioned above today it's handled in a generic way only
for undefined data symbols, not undefined function symbols.

Alexander

Re: [PATCH 2/2] C++ FE: handle misspelled identifiers and typenames

[David Malcolm]

On Wed, 2016-07-13 at 16:12 -0600, Jeff Law wrote:
> On 06/30/2016 12:53 PM, David Malcolm wrote:
> > This is a port of the C frontend's r237714 [1] to the C++ frontend:
> >   https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01052.html
> > offering spelling suggestions for misspelled identifiers, macro
> > names,
> > and some keywords (e.g. "singed" vs "signed" aka PR c/70339).
> > 
> > Unlike the C frontend, there doesn't seem to be an easy way to
> > distinguish between cases where we're expecting a typename vs
> > a variable name, so some of the logic is a little different.
> > 
> > Examples of suggestions can be seen in the test case.
> > 
> > Successfully bootstrapped on x86_64-pc-linux-gnu
> > (in combination with the prior patch); adds 240 PASS results to
> > g++.sum.
> > 
> > OK for trunk?
> > 
> > Dave
> > 
> > [1] aka 8469aece13814deddf2cd80538d33c2d0a8d60d9 in the git mirror
> > 
> > gcc/c/ChangeLog:
> > PR c/70339
> > * c-decl.c (struct edit_distance_traits): Move
> > to
> > spellcheck-tree.h
> > (best_macro_match): Likewise, converting from a typedef to a
> > subclass.
> > (find_closest_macro_cpp_cb): Move to spellcheck-tree.c.
> > (lookup_name_fuzzy): Update for change of best_macro_match to a
> > subclass with a ctor that calls cpp_forall_identifiers.
> These are fine.
> 
> > 
> > gcc/cp/ChangeLog:
> > PR c/70339
> > * name-lookup.c: Include gcc-rich-location.h, spellcheck
> > -tree.h,
> > and parser.h.
> > (suggest_alternatives_for): If no candidates are found, try
> > lookup_name_fuzzy and report if if finds a suggestion.
> > (consider_binding_level): New function.
> > (consider_binding_levels): New function.
> > (lookup_name_fuzzy) New function.
> > * parser.c: Include gcc-rich-location.h.
> > (cp_lexer_next_token_is_decl_specifier_keyword): Move most of
> > logic into...
> > (cp_keyword_starts_decl_specifier_p): ...this new function.
> > (cp_parser_diagnose_invalid_type_name): When issuing
> > "does not name a type" errors, attempt to make a suggestion
> > using
> > lookup_name_fuzzy.
> > * parser.h (cp_keyword_starts_decl_specifier_p): New prototype.
> > * search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Don't
> > attempt to access TYPE_FIELDS within a TYPE_PACK_EXPANSION.
> Going to let Jason on this part.

Thanks.  The corresponding code in the C frontend is likely to change
due to the fix being discussed for PR c/71858, so I think I'll wait
until that other PR is fixed, and then resubmit an updated version of
this for review, incorporating equivalent fixes for C++.

> > 
> > gcc/ChangeLog:
> > PR c/70339
> > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
> > the
> > same location as last time, don't skip if we have fix-it hints.
> > Clarify the skipping logic by converting it from one "if"
> > clause
> > to repeated "if" clauses.
> > * spellcheck-tree.c: Include "cpplib.h".
> > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
> > (best_macro_match::best_macro_match): New constructor.
> > * spellcheck-tree.h (struct edit_distance_traits > *>):
> > Move here from c/c-decl.c.
> > (class best_macro_match): Move here from c/c-decl.c, converting
> > from a typedef to a subclass, gaining a ctor.
> OK.
> 
> > 
> > gcc/testsuite/ChangeLog:
> > PR c/70339
> > * g++.dg/spellcheck-identifiers.C: New test case, based on
> > gcc.dg/spellcheck-identifiers.c.
> > * g++.dg/spellcheck-typenames.C: New test case, based on
> > gcc.dg/spellcheck-typenames.c
> OK
> 
> 
> jeff
> 

Re: [PATCH] Tweak diagnostic-token.ranges.c testcase (PR testsuite/71865)

[David Malcolm]

On Thu, 2016-07-14 at 16:55 +0200, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, this testcase behaves differently on
> powerpc*/spu/s390* targets, because in non-iso modes they predefine
> conditional macros like bool and that affects the behavior of the
> suggestions.
> 
> We should certainly discuss what to do with the conditional macros,
> but in the mean time IMHO it doesn't hurt to just avoid this
> problem.
> 
> Tested on x86_64-linux and i686-linux, ok for trunk?

Thanks.  I think I can approve this with my "libcpp/diagnostic messages
" maintainer hat on.

Did you test the case with a build for one of the affected targets to
verify the fix?

> 2016-07-14  Jakub Jelinek  
> 
>   PR testsuite/71865
>   * gcc.dg/diagnostic-token-ranges.c: Add -std=c11 to dg-options.
>   (wide_string_literal_in_asm): Use __asm instead of asm, adjust
>   expected diagnostics.
> 
> --- gcc/testsuite/gcc.dg/diagnostic-token-ranges.c.jj 2016-07
> -14 11:06:23.0 +0200
> +++ gcc/testsuite/gcc.dg/diagnostic-token-ranges.c2016-07-14
> 14:47:50.399907380 +0200
> @@ -1,4 +1,4 @@
> -/* { dg-options "-fdiagnostics-show-caret -Wc++-compat" } */
> +/* { dg-options "-fdiagnostics-show-caret -Wc++-compat -std=c11" }
> */
>  
>  /* Verify that various diagnostics show source code ranges.  */
>  
> @@ -68,11 +68,11 @@ foo (unknown_type param); /* { dg-error
>  
>  void wide_string_literal_in_asm (void)
>  {
> -  asm (L"nop"); /* { dg-error "wide string literal in 'asm'" } */
> +  __asm (L"nop"); /* { dg-error "wide string literal in 'asm'" } */
>  /*
>  { dg-begin-multiline-output "" }
> -   asm (L"nop");
> -^~
> +   __asm (L"nop");
> +  ^~
>  { dg-end-multiline-output "" }
>  */
>  }
> 
>   Jakub

Re: [C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[David Malcolm]

On Thu, 2016-07-14 at 19:47 +0200, Jakub Jelinek wrote:
> On Thu, Jul 14, 2016 at 01:22:27PM -0400, David Malcolm wrote:
> > I wrote a patch for this, similar to yours, but with a slightly
> > different approach for handling builtins.
> > 
> > I think it's reasonable to offer suggestions for misspellings of
> > e.g.
> > "snprintf" even if the pertinent header hasn't been included, since
> > it
> > will help guide a novice developer to the missing header.  For
> > example,
> > if the user has:
> > 
> > void
> > test_7 (int i, int j)
> > {
> >   int buffer[100];
> >   snprint (buffer, 100, "%i of %i", i, j);
> > }
> > 
> > ...then they get:
> > 
> > test.c: In function ‘test_7’:
> > test.c:5:3: warning: implicit declaration of function ‘snprint’;
> > did
> > you mean ‘snprintf’? [-Wimplicit-function-declaration]
> >snprint (buffer, 100, "%i of %i", i, j);
> >^~~
> >snprintf
> > 
> > ...and on correcting it, they get the "you forgot "
> > warning:
> 
> I find it weird.  What is special on the builtins?  Lots of standard
> headers
> contain lots of functions that aren't backed by builtins, some of
> them used
> more often than the builtins; the reason for builtins is often just
> that gcc
> wants to be able to optimize them somehow.
> 
> E.g. note fopen is not a builtin, so you still will not suggest it if
> stdio.h is not included.
> 
> Not all the builtins out there are even enabled in all compilation
> modes
> when the containing header is included, it can depend on the language
> version, feature test macros, etc.  So, by considering invisible
> builtins
> you could e.g. suggest C99 builtins in strict C89 compilation mode
> where the
> header would not define it, etc.
> 
> In any case, this is your baby, so it is up to the FE maintainers and
> you to
> get agreement on, I won't fight on this.

Thanks.

I agree with the points you raise; in that light I'm fine with your
patch.

> > What I find surprising is the suggestion of "carg"; I've seen this
> > a
> > few times as a suggestion.   I confess to having to look up carg;
> > IMHO
> > "carg" is much less likely to be a useful suggestion than, say,
> > "printf".
> 
> For the short identifiers, the question is if the maximum Damerau
> -Levenshtein
> distance (do you handle transpositions now?) 

We don't currently handle transpositions, but it would be good to do so
(PR other/69968).

> shouldn't be lowered (say for at
> most 4 chars identifiers only consider levenshtein distance 1 and not
> more,
> e.g. for 3 character identifiers allowing distance of 2 or 3 means
> you pretty
> much suggest any other 3 char identifier), regardless of if it is a
> builtin or not.

The logic in get_best_meaningful_candidate is currently:

  unsigned int cutoff = MAX (m_goal_len, m_best_candidate_len) / 2;
  if (m_best_distance > cutoff)
 return NULL;

For a pair of 3 character identifiers, cutoff will be 3 / 2 == 1, so it
will suggest within a distance of 1 and reject if the distance is 2 or
3.   Or is there a bug?

That cutoff could definitely be improved.  Perhaps the MAX should be
changed to a MIN?  Or just base it off the goal length e.g. 
  unsigned int cutoff = m_goal_len / 2;
thus implicitly rejecting
suggestions when m_goal_len == 1.
That would eliminate the "bar" to
"char" suggestion in the PR, since m_goal_len == 3 would have a cutoff
of 1.

> 
> > @@ -3992,6 +3995,26 @@ lookup_name_fuzzy (tree name, enum
> > lookup_name_fuzzy_kind kind)
> > if (kind == FUZZY_LOOKUP_TYPENAME)
> >   if (TREE_CODE (binding->decl) != TYPE_DECL)
> > continue;
> > +   if (kind == FUZZY_LOOKUP_FUNCTION_NAME)
> > + if (TREE_CODE (binding->decl) != FUNCTION_DECL)
> > +   continue;
> 
> Note this is handled in the second patch I've posted, and this one
> doesn't
> handle function pointer variables/parameters.
> 
>   Jakub

Re: [PATCH] Handle undefined extern vars in output_in_order

[Jeff Law]

On 06/23/2016 08:45 AM, Alexander Monakov wrote:

Hi,

I've discovered that this assert in my patch was too restrictive:

+  if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+   {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+DECL_ATTRIBUTES (pv->decl)));

Testing for the nvptx target uncovered that there's another case where a
global variable would have a value expr: emutls.  Sorry for not spotting it
earlier (but at least the new assert did its job).  I think we should always
skip here over decls that have value-exprs, just like hard-reg vars are
skipped.  The following patch does that.  Is this still OK?

(bootstrapped/regtested on x86-64)

Alexander

* cgraphunit.c (cgraph_order_sort_kind): New entry ORDER_VAR_UNDEF.
(output_in_order): Loop over undefined variables too.  Output them
via assemble_undefined_decl.  Skip variables that correspond to hard
registers or have value-exprs.
* varpool.c (symbol_table::output_variables): Handle undefined
variables together with defined ones.
I haven't followed this issue at all.  So bear with me if I ask a 
question you've already answered.


Is the point here to be able to deduce what symbols are external & 
undefined and emit some kind of directive to the assembler in that case? 
 Avoiding duplicates as well as symbols which may have had originally 
looked like external & undefined, but later we find a definition?


The reason I ask someone might be able to simplify a bit of the PA 
backend if that's the goal here.  The PA (when using the SOM object 
format) has similar needs.  We solved it by queuing up everything that 
might need "importing".  Then at the end of the compilation unit, we'd 
walk that queue of symbols emitting the proper magic.


Jeff

Re: [PATCH v2] extend shift count warnings to vector types

[Jeff Law]

On 07/01/2016 08:29 AM, Jan Beulich wrote:

gcc/c/
2016-07-01  Jan Beulich  

* c-fold.c (c_fully_fold_internal): Also emit shift count
warnings for vector types.
* c-typeck.c (build_binary_op): Likewise.

gcc/testsuite/
2016-07-01  Jan Beulich  

* gcc.dg/vshift-6.c, gcc.dg/vshift-7.c: New.

OK.  Thanks for putting together some tests.

jeff

Re: [Fortran, Patch, PR71807, v1] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[Jerry DeLisle]

On 07/14/2016 09:17 AM, Andre Vehreschild wrote:
> Hi all,
> 
> attached patch fixes the ICE when assigning null() to an allocatable
> component in an initializer.
> 
> Bootstrapped and regtested on x86_64-linux/F23 ok for trunk,
> gcc-6-branch and gcc-5-branch.
> 
> Ok for trunk and one week later for the other branches?
> 
> Regards,
>   Andre
> 

Yes, OK and thanks for patch.

Jerry

Re: [PATCH PR71503/PR71683]Fix ICE in tree-if-conv.c

[Jeff Law]

On 07/14/2016 10:12 AM, Bin Cheng wrote:

Hi,
This is a simple patch fixing ICE in tree-if-conv.c.  Existing code does not 
setup a variable (cond) when predicate of basic block is true and it asserts on 
the variable.  Interesting thing is dead code is not cleaned up before ifcvt, 
but that's another story.
Bootstrap and test on x86_64.  Is it OK?

Thanks,
bin

2016-07-13  Bin Cheng  

PR tree-optimization/71503
PR tree-optimization/71683
* tree-if-conv.c (gen_phi_arg_condition): Set cond when predicate
is true.
Maybe I'm missing something, but in the case where we COND is already 
set and we encounter a true predicate later, shouldn't that make the 
result true as well?


I don't think the code will though -- we just throw away the true 
condition.  ISTM that the right thing to do is


if (is_true_predicate (c))
  {
cond = c;
continue;
  }

Can you see if you can trigger a case where we have an existing cond, 
then later find a true condition to verify the right thing happens?


jeff

[patch, fortran]

[Jerry DeLisle]

This simple patch kindly provided by Marco solves the problem.

Regression tested on x86_64-Linux, Test case provided also.

OK to commit to trunk?

Jerry

2016-07-14  Jerry DeLisle  
Marco Restelli 

PR fortran/62125
* symbol.c (select_type_insert_tmp): Recursively call self to take care
of nested select type.

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 0ee7dec..c967f25 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2930,7 +2930,11 @@ select_type_insert_tmp (gfc_symtree **st)
   gfc_select_type_stack *stack = select_type_stack;
   for (; stack; stack = stack->prev)
 if ((*st)->n.sym == stack->selector && stack->tmp)
-  *st = stack->tmp;
+  {
+*st = stack->tmp;
+select_type_insert_tmp (st);
+return;
+  }
 }
! { dg-do run }
! PR62125  Nested select type not accepted (rejects valid) 
module m
 implicit none
 type, abstract :: t1
  logical :: l
 end type t1
 type, extends(t1), abstract :: t2
  integer :: i
 end type t2
 type, extends(t2) :: t3
  real :: x
 end type t3
contains
 subroutine s(u)
  class(t1), intent(in) :: u
  if(.not.u%l) call abort()
   select type(u); class is(t2)
 if(u%i.ne.2) call abort()
 select type(u); class is(t3)
   if(u%x.ne.3.5) call abort()
 end select
   end select
 end subroutine s
end module m

program p
 use m
 implicit none
 type(t3) :: var = t3( l=.true. , i=2 , x=3.5 )
 call s(var)
end program p

Re: [C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[Jakub Jelinek]

On Thu, Jul 14, 2016 at 01:22:27PM -0400, David Malcolm wrote:
> I wrote a patch for this, similar to yours, but with a slightly
> different approach for handling builtins.
> 
> I think it's reasonable to offer suggestions for misspellings of e.g.
> "snprintf" even if the pertinent header hasn't been included, since it
> will help guide a novice developer to the missing header.  For example,
> if the user has:
> 
> void
> test_7 (int i, int j)
> {
>   int buffer[100];
>   snprint (buffer, 100, "%i of %i", i, j);
> }
> 
> ...then they get:
> 
> test.c: In function ‘test_7’:
> test.c:5:3: warning: implicit declaration of function ‘snprint’; did
> you mean ‘snprintf’? [-Wimplicit-function-declaration]
>snprint (buffer, 100, "%i of %i", i, j);
>^~~
>snprintf
> 
> ...and on correcting it, they get the "you forgot " warning:

I find it weird.  What is special on the builtins?  Lots of standard headers
contain lots of functions that aren't backed by builtins, some of them used
more often than the builtins; the reason for builtins is often just that gcc
wants to be able to optimize them somehow.

E.g. note fopen is not a builtin, so you still will not suggest it if
stdio.h is not included.

Not all the builtins out there are even enabled in all compilation modes
when the containing header is included, it can depend on the language
version, feature test macros, etc.  So, by considering invisible builtins
you could e.g. suggest C99 builtins in strict C89 compilation mode where the
header would not define it, etc.

In any case, this is your baby, so it is up to the FE maintainers and you to
get agreement on, I won't fight on this.

> What I find surprising is the suggestion of "carg"; I've seen this a
> few times as a suggestion.   I confess to having to look up carg; IMHO
> "carg" is much less likely to be a useful suggestion than, say,
> "printf".

For the short identifiers, the question is if the maximum Damerau-Levenshtein
distance (do you handle transpositions now?) shouldn't be lowered (say for at
most 4 chars identifiers only consider levenshtein distance 1 and not more,
e.g. for 3 character identifiers allowing distance of 2 or 3 means you pretty
much suggest any other 3 char identifier), regardless of if it is a builtin or 
not.

> @@ -3992,6 +3995,26 @@ lookup_name_fuzzy (tree name, enum 
> lookup_name_fuzzy_kind kind)
>   if (kind == FUZZY_LOOKUP_TYPENAME)
> if (TREE_CODE (binding->decl) != TYPE_DECL)
>   continue;
> + if (kind == FUZZY_LOOKUP_FUNCTION_NAME)
> +   if (TREE_CODE (binding->decl) != FUNCTION_DECL)
> + continue;

Note this is handled in the second patch I've posted, and this one doesn't
handle function pointer variables/parameters.

Jakub

Re: [PATCH, vec-tails 10/10] Tests

[Jeff Law]

On 07/05/2016 09:44 AM, Ilya Enkovich wrote:

Hi,

This patch adds several tests to check tails vectorization functionality.

Thanks,
Ilya
--
gcc/testsuite/

2016-07-05  Ilya Enkovich  

* lib/target-supports.exp (check_avx2_hw_available): New.
(check_effective_target_avx2_runtime): New.
* gcc.dg/vect/vect-tail-combine-1.c: New test.
* gcc.dg/vect/vect-tail-combine-2.c: New test.
* gcc.dg/vect/vect-tail-combine-3.c: New test.
* gcc.dg/vect/vect-tail-combine-4.c: New test.
* gcc.dg/vect/vect-tail-combine-5.c: New test.
* gcc.dg/vect/vect-tail-combine-6.c: New test.
* gcc.dg/vect/vect-tail-combine-7.c: New test.
* gcc.dg/vect/vect-tail-combine-9.c: New test.
* gcc.dg/vect/vect-tail-mask-1.c: New test.
* gcc.dg/vect/vect-tail-mask-2.c: New test.
* gcc.dg/vect/vect-tail-mask-3.c: New test.
* gcc.dg/vect/vect-tail-mask-4.c: New test.
* gcc.dg/vect/vect-tail-mask-5.c: New test.
* gcc.dg/vect/vect-tail-mask-6.c: New test.
* gcc.dg/vect/vect-tail-mask-7.c: New test.
* gcc.dg/vect/vect-tail-mask-8.c: New test.
* gcc.dg/vect/vect-tail-mask-9.c: New test.
* gcc.dg/vect/vect-tail-nomask-1.c: New test.
* gcc.dg/vect/vect-tail-nomask-2.c: New test.
* gcc.dg/vect/vect-tail-nomask-3.c: New test.
* gcc.dg/vect/vect-tail-nomask-4.c: New test.
* gcc.dg/vect/vect-tail-nomask-5.c: New test.
* gcc.dg/vect/vect-tail-nomask-6.c: New test.
* gcc.dg/vect/vect-tail-nomask-7.c: New test.

This is fine when the rest of the patches go in.



+ unsigned int eax, ebx, ecx, edx;
+ if (!__get_cpuid (1, , , , )
+ || ((ecx & bit_OSXSAVE) != bit_OSXSAVE))
+   return 1;
+
+ if (__get_cpuid_max (0, NULL) < 7)
+   return 1;
+
+ __cpuid_count (7, 0, eax, ebx, ecx, edx);
+
+ return (ebx & bit_AVX2) != bit_AVX2;
Ugh.  I'm going to trust this is correct.  I vaguely recall mucking 
around with this stuff for the original AVX in glibc several years ago.


jeff

[v3 PATCH] Fix the constraints for any's assignment operator template to properly reject assignment from a non-copyable lvalue.

[Ville Voutilainen]

Tested on Linux-x64.

2016-07-14  Ville Voutilainen  

Fix the constraints for any's assignment operator template to properly
reject assignment from a non-copyable lvalue.
* include/std/any (operator=(_ValueType&&)): Constrain the decayed
type for is_copy_constructible,
* testsuite/20_util/any/requirements.cc: Add a test for
non-copyable lvalues.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 54882d7..4add118 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -238,9 +238,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
 /// Store a copy of @p __rhs as the contained object.
-template
-enable_if_t<__and_<__not_>>,
-  is_copy_constructible<_ValueType>>::value, any&>
+template>
+enable_if_t::value, any&>
   operator=(_ValueType&& __rhs)
   {
*this = any(std::forward<_ValueType>(__rhs));
diff --git a/libstdc++-v3/testsuite/20_util/any/requirements.cc 
b/libstdc++-v3/testsuite/20_util/any/requirements.cc
index 67e4253..f33cd67 100644
--- a/libstdc++-v3/testsuite/20_util/any/requirements.cc
+++ b/libstdc++-v3/testsuite/20_util/any/requirements.cc
@@ -30,4 +30,7 @@ static_assert(std::is_assignable::value);
 static_assert(!std::is_assignable::value);
 static_assert(std::is_constructible::value);
 static_assert(!std::is_constructible::value);
-
+static_assert(!std::is_assignable::value);
+static_assert(!std::is_constructible::value);
+static_assert(!std::is_assignable::value);
+static_assert(!std::is_constructible::value);

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[Jeff Law]

On 07/14/2016 04:57 AM, Eric Gallager wrote:

On 7/13/16, Jeff Law  wrote:

On 06/27/2016 08:10 PM, Eric Gallager wrote:

The last time I ran ./contrib/download_prerequisites, I already had
previous symlinks set up from a previous run of the script, so `ln`
followed the existing symlinks and created the new ones in the
directories to which the symlinks pointed. This patch should fix that
by removing the old symlinks before creating new ones. (For some
reason the `-f` flag to `ln` that was already there wasn't enough for
me.) Tested by running the script and ensuring that the new isl
symlink pointed to the correct directory, and that there were no bad
symlinks in the old isl directory. Could someone commit this trivial
patch for me, or something like it? I don't have write access.

I'd really rather know why the "-f" flag didn't work for you.  The whole
point of -f is to remove the destination file first.

Jeff



Reading my ln manpage, it describes the "-f" flag like this:


 -fIf the target file already exists, then unlink it so that the
   link may occur.  (The -f option overrides any previous -i
   options.)

Okay, so that seems like it should do what you say, but the manpage
also describes a separate uppercase "-F" option:

 -FIf the target file already exists and is a directory, then
   remove it so that the link may occur.  The -F option should be
   used with either -f or -i options.  If none is specified, -f is
   implied.  The -F option is a no-op unless -s option is speci-
   fied.

So it seems to imply that "-f" will only remove the destination file
if it's a regular file, while "-F" is needed if the destination file
is a directory. The page also has this to say about "-F" later:

 The -F option is FreeBSD extention and should not be used in portable
 scripts.

So this could be a BSD vs. GNU thing.
I don't have any BSD systems running.  I can confirm that while "-f" 
refers to files in the man page, it will happy delete the old symlink as 
well.


-bash-4.3$ ln -s /bin/ls jj
-bash-4.3$ ln -s -f /bin/bash jj
-bash-4.3$ ls -l jj
lrwxrwxrwx. 1 law law 9 Jul 14 13:22 jj -> /bin/bash
-bash-4.3$ which ln
/usr/bin/ln
-bash-4.3$ rpm -q --whatprovides /usr/bin/ln
coreutils-8.24-6.fc23.x86_64

Could you test this on your system?

Jeff

Re: [C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[David Malcolm]

On Thu, 2016-07-14 at 16:50 +0200, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, anticipated decls should be ignored from
> fuzzy
> lookups, unless the corresponding decl is declared first.

I wrote a patch for this, similar to yours, but with a slightly
different approach for handling builtins.

I think it's reasonable to offer suggestions for misspellings of e.g.
"snprintf" even if the pertinent header hasn't been included, since it
will help guide a novice developer to the missing header.  For example,
if the user has:

void
test_7 (int i, int j)
{
  int buffer[100];
  snprint (buffer, 100, "%i of %i", i, j);
}

...then they get:

test.c: In function ‘test_7’:
test.c:5:3: warning: implicit declaration of function ‘snprint’; did
you mean ‘snprintf’? [-Wimplicit-function-declaration]
   snprint (buffer, 100, "%i of %i", i, j);
   ^~~
   snprintf

...and on correcting it, they get the "you forgot " warning:

test.c: In function ‘test_7’:
test.c:5:3: warning: implicit declaration of function ‘snprintf’ [
-Wimplicit-function-declaration]
   snprintf (buffer, 100, "%i of %i", i, j);
   ^~~~
test.c:5:3: warning: incompatible implicit declaration of built-in
function ‘snprintf’
test.c:5:3: note: include ‘’ or provide a declaration of
‘snprintf’

(and more errors, it's missing a  argument).


What I find surprising is the suggestion of "carg"; I've seen this a
few times as a suggestion.   I confess to having to look up carg; IMHO
"carg" is much less likely to be a useful suggestion than, say,
"printf".

Attached is the patch I wrote (not tested yet, and no ChangeLog,
sorry), which keeps the anticipated decls, but uses a crude heuristic
to reject short ones.

As noted in the patch, a more sophisticated approach might be to
analyze a large corpus of real-world code and see how often each
builtin is used, and filter out the less-frequently-used ones.

But I felt a simple "reject any builtin name with length <= 4" was good
enough as a first iteration.

Thoughts?

> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2016-07-13  Jakub Jelinek  
> 
>   PR c/71858
>   * c-decl.c (lookup_name_fuzzy): Ignore binding->invisible.
> 
>   * gcc.dg/spellcheck-identifiers.c (snprintf): Declare.
>   * gcc.dg/spellcheck-identifiers-2.c: New test.
>   * gcc.dg/diagnostic-token-ranges.c (nanl): Declare.
>   * c-c++-common/attributes-1.c: Adjust dg-prune-output.
> 
> --- gcc/c/c-decl.c.jj 2016-06-24 12:59:22.0 +0200
> +++ gcc/c/c-decl.c2016-07-13 22:40:23.410658411 +0200
> @@ -4021,7 +4021,7 @@ lookup_name_fuzzy (tree name, enum looku
>for (c_scope *scope = current_scope; scope; scope = scope->outer)
>  for (c_binding *binding = scope->bindings; binding; binding =
> binding->prev)
>{
> - if (!binding->id)
> + if (!binding->id || binding->invisible)
> continue;
>   /* Don't use bindings from implicitly declared functions,
>  as they were likely misspellings themselves.  */
> --- gcc/testsuite/gcc.dg/spellcheck-identifiers.c.jj  2016-06
> -24 12:59:12.0 +0200
> +++ gcc/testsuite/gcc.dg/spellcheck-identifiers.c 2016-07-14
> 10:03:36.147466813 +0200
> @@ -121,7 +121,7 @@ test_6 (enum foo f)
>  }
>  }
>  
> -/* Verify that we offer names of builtins as suggestions.  */
> +int snprintf (char *, __SIZE_TYPE__, const char *, ...);
>  void
>  test_7 (int i, int j)
> --- gcc/testsuite/gcc.dg/spellcheck-identifiers-2.c.jj2016-07
> -14 09:44:16.351537449 +0200
> +++ gcc/testsuite/gcc.dg/spellcheck-identifiers-2.c   2016-07-14
> 10:02:21.965426567 +0200
> @@ -0,0 +1,33 @@
> +/* PR c/71858 */
> +/* Make sure anticipated builtins are not considered before they are
> declared.  */
> +/* { dg-do compile } */
> +/* { dg-options "-Wimplicit-function-declaration -fdiagnostics-show
> -caret" } */
> +
> +int sscafn (const char *, const char *, ...);
> +
> +int
> +test_1 (const char *p)
> +{
> +  int i;
> +  return ssacnf (p, "%d", ); /* { dg-warning "10: implicit
> declaration of function .ssacnf.; did you mean .sscafn.?" } */
> +  /* { dg-begin-multiline-output "" }
> +   return ssacnf (p, "%d", );
> +  ^~
> +  sscafn
> +   { dg-end-multiline-output "" } */
> +}
> +
> +int scafn (const char *, ...);
> +int scanf (const char *, ...);
> +
> +int
> +test_2 (void)
> +{
> +  int i;
> +  return sacnf ("%d", ); /* { dg-warning "10: implicit declaration
> of function .sacnf.; did you mean .scanf.?" } */
> +  /* { dg-begin-multiline-output "" }
> +   return sacnf ("%d", );
> +  ^
> +  scanf
> +   { dg-end-multiline-output "" } */
> +}
> --- gcc/testsuite/gcc.dg/diagnostic-token-ranges.c.jj 2016-06
> -24 12:59:12.0 +0200
> +++ gcc/testsuite/gcc.dg/diagnostic-token-ranges.c2016-07-14
> 11:06:23.013803011 +0200
> @@ -2,6 +2,8 @@
>  
>  /* Verify that various diagnostics show source code ranges.  */
>  
> +long double nanl (const char *);
> +
>  /* These 

Re: [PATCH] doc fix for c/71560 - union compound literal initializes wrong union field

[Jeff Law]

On 07/14/2016 09:03 AM, Martin Sebor wrote:

Ping.  The updated patch at the link below corrects the issues
with the tags pointed out by Sandra in her review.

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00350.html

OK.
jeff

Re: [PATCH testsuite]XFAIL gcc.dg/tree-ssa/pr71347 on some targets

[Jeff Law]

On 07/14/2016 10:11 AM, Bin Cheng wrote:

Hi, Test gcc.dg/tree-ssa/pr71347 failed on some targets if the two
memory references are re-written into different forms by IVOPT.  This
could be because of various reasons, for example, auto-increment
addressing mode.  Since the address expressions are of different
form, DOM fails to eliminate the redundant load at the moment.  I
think DOM should be improved to handle address expressions appearing
in different forms (at least for simple cases).  For now, I will
XFAIL this test indicating a possible enhancement.
FWIW, Adam Lawrence did some work in this area a few months ago. 
Essentially enhancing DOM to be able to detect certain MEM_REF and 
ARRAY_REF accesses were in fact equivalent.





Test checked on affected targets.  Is it OK?

Yes.  This is fine.
jeff

Re: [JAVA PATCH] Enable more array bounds check elimination

[Andrew Hughes]

snip...

> 
> At a very high level, you should be aware of a general belief that GCJ's
> life is limited.  There's been various calls to deprecate it.  So
> spending a lot of time optimizing GCJ's output may not be the best use
> of your skills :-)
> 

Unless things have changed since it was last discussed, the plan was
for it to be deprecated in GCC 6 and removed in 7. If that's the case,
these changes may sadly not see a release.

It does seem that no-one has bitten the bullet of removing it yet though.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Re: [PATCH, ARM 7/7] Enable atomics for ARMv8-M Mainline

[Thomas Preudhomme]

On Thursday 14 July 2016 17:23:46 Kyrill Tkachov wrote:
> Hi Thomas,
> 
> On 14/07/16 14:37, Thomas Preudhomme wrote:
> > Hi Kyrill,
> > 
> > On Thursday 19 May 2016 17:18:29 Kyrill Tkachov wrote:
> >> Hi Thomas,
> >> 
> >> On 17/05/16 11:15, Thomas Preudhomme wrote:
> >>> Ping?
> >>> 
> >>> *** gcc/ChangeLog ***
> >>> 
> >>> 2015-12-17  Thomas Preud'homme  
> >>> 
> >>>   * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M
> >>>   Mainline.
> >>> 
> >>> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> >>> index
> >>> 347b5b0a5cc0bc1e3b5020c8124d968e76ce48a4..e154bd31b8084f9f45ad4409e7b38d
> >>> e6
> >>> 52538c51 100644
> >>> --- a/gcc/config/arm/arm.h
> >>> +++ b/gcc/config/arm/arm.h
> >>> @@ -266,7 +266,7 @@ extern void
> >>> (*arm_lang_output_object_attributes_hook)
> >>> (void);
> >>> 
> >>>|| arm_arch7) && arm_arch_notm)
> >>>
> >>>/* Nonzero if this chip supports load-acquire and store-release.  */
> >>> 
> >>> -#define TARGET_HAVE_LDACQ(TARGET_ARM_ARCH >= 8 && arm_arch_notm)
> >>> +#define TARGET_HAVE_LDACQ(TARGET_ARM_ARCH >= 8 && TARGET_32BIT)
> >> 
> >> So this change is correct because ARMv8-M Mainline uses Thumb2
> >> and is therefore TARGET_32BIT.
> >> 
> >> This is ok but I'd like to see a follow up patch to enable the tests
> >> that exercise acquire-release instructions in the arm.exp testsuite
> >> for ARMv8-M Mainline so that we can be sure they get proper testsuite
> >> coverage.
> > 
> > I've respinned the patch because of the changes to atomic_loaddi output
> > template in config/arm/sync.md. This patch now creates a new macro
> > TARGET_HAVE_LDACQEXD to guard LDACQEXD and STLEXD instructions that are
> > not
> > available in ARMv8-M Mainline. It took advantage of the respin to also add
> > the tests you were asking for.
> > 
> > ChangeLog entries are as follow:
> > 
> > *** gcc/ChangeLog ***
> > 
> > 2016-07-05  Thomas Preud'homme  
> > 
> >  * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M
> >  Mainline.
> >  (TARGET_HAVE_LDACQD): New macro.
> >  * config/arm/sync.md (atomic_loaddi): Use TARGET_HAVE_LDACQD
> >  rather
> >  than TARGET_HAVE_LDACQ.
> >  (arm_load_acquire_exclusivedi): Likewise.
> >  (arm_store_release_exclusivedi): Likewise.
> > 
> > *** gcc/testsuite/ChangeLog ***
> > 
> > 2016-07-05  Thomas Preud'homme  
> > 
> >  * gcc.target/arm/atomic-comp-swap-release-acquire.c: Rename into
> >  ...
> >  * gcc.target/arm/atomic-comp-swap-release-acquire-1.c: This.
> >  * gcc.target/arm/atomic-op-acq_rel.c: Rename into ...
> >  * gcc.target/arm/atomic-op-acq_rel-1.c: This.
> >  * gcc.target/arm/atomic-op-acquire.c: Rename into ...
> >  * gcc.target/arm/atomic-op-acquire-1.c: This.
> >  * gcc.target/arm/atomic-op-char.c: Rename into ...
> >  * gcc.target/arm/atomic-op-char-1.c: This.
> >  * gcc.target/arm/atomic-op-consume.c: Rename into ...
> >  * gcc.target/arm/atomic-op-consume-1.c: This.
> >  * gcc.target/arm/atomic-op-int.c: Rename into ...
> >  * gcc.target/arm/atomic-op-int-1.c: This.
> >  * gcc.target/arm/atomic-op-relaxed.c: Rename into ...
> >  * gcc.target/arm/atomic-op-relaxed-1.c: This.
> >  * gcc.target/arm/atomic-op-release.c: Rename into ...
> >  * gcc.target/arm/atomic-op-release-1.c: This.
> >  * gcc.target/arm/atomic-op-seq_cst.c: Rename into ...
> >  * gcc.target/arm/atomic-op-seq_cst-1.c: This.
> >  * gcc.target/arm/atomic-op-short.c: Rename into ...
> >  * gcc.target/arm/atomic-op-short-1.c: This.
> >  * gcc.target/arm/atomic-comp-swap-release-acquire-2.c: New test.
> >  * gcc.target/arm/atomic-op-acq_rel-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-acquire-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-char-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-consume-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-int-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-relaxed-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-release-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-seq_cst-2.c: Likewise.
> >  * gcc.target/arm/atomic-op-short-2.c: Likewise.
> > 
> > Testsuite shows no regression and atomic tests [1] are passing for ARMv8-M
> > Mainline.
> > 
> > [1] gcc.dg/atomic*, g++.dg/ext/atomic*, gcc.target/arm/atomic*,
> > gcc.target/arm/sync* and libstdc++-v3/testsuite/29_atomic/*
> 
> Thanks, this is ok if testing on arm-none-linux-gnueabihf is ok.
> In particular, please make sure that the tests still pass for an A-profile
> target.

Oh yes, I forgot to mention that I also tested the same tests for armv8-a 
without any code generation change for both ARM and Thumb. The whole 

Re: [PATCH, GCC/LRA] Teach LRA to not use same register value for multiple output operands of an insn

[Vladimir Makarov]

On 07/08/2016 11:07 AM, Thomas Preudhomme wrote:

Hi,

While investigating the root cause a testsuite regression for the
ARM/embedded-5-branch GCC in gcc.dg/vect/slp-perm-5.c, we found that the bug
seems to also affect trunk. The bug manifests itself as an ICE in cselib due to
a parallel insn with two SET to the same register. When processing the second
SET in cselib_record_set (), the assert gcc_assert (REG_VALUES (dreg)->elt ==
0) fails because the field was already set when processing the first SET. The
root cause seems to be a register allocation issue in lra-constraints.

When considering an output operand with matching input operand(s),
match_reload does a number of checks to see if it can reuse the first matching
input operand register value or if a new unique value should be given to the
output operand. The current check ignores the case of multiple output operands
(as in neon_vtrn_insn insn pattern in config/arm/arm.md). This can lead
to cases where multiple output operands share a same register value when the
first matching input operand has the same value as another output operand,
leading to the ICE in cselib. This patch changes match_reload to get
information about other output operands and check whether this case is met or
not.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-07-01  Thomas Preud'homme  

 * lra-constraints.c (match_reload): Pass information about other
 output operands.  Create new unique register value if matching input
 operand shares same register value as output operand being considered.
 (curr_insn_transform): Record output operands already processed.


Patch passed bootstrap under arm-none-linux-gnueabihf (Cortex-A57 in ARM mode
as well as Thumb mode), aarch64-linux-gnu (Cortex-A57) and x86_64-linux-gnu
and testsuite results does not regress for these and for arm-none-eabi
targeting Cortex-A8.
Sorry, it took sometime to think about the problem.  It is a nontrivial 
problem with a lot of possible scenarios in general case.  The patch is 
safe in any case (it can not create a wrong code if LRA w/o the patch 
does not create a wrong code).

Is this ok for trunk?




Yes.  Thank you, Thomas.

Re: [PATCH, ARM 7/7] Enable atomics for ARMv8-M Mainline

[Kyrill Tkachov]

Hi Thomas,

On 14/07/16 14:37, Thomas Preudhomme wrote:

Hi Kyrill,

On Thursday 19 May 2016 17:18:29 Kyrill Tkachov wrote:

Hi Thomas,

On 17/05/16 11:15, Thomas Preudhomme wrote:

Ping?

*** gcc/ChangeLog ***

2015-12-17  Thomas Preud'homme  

  * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M
  Mainline.

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index
347b5b0a5cc0bc1e3b5020c8124d968e76ce48a4..e154bd31b8084f9f45ad4409e7b38de6
52538c51 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -266,7 +266,7 @@ extern void (*arm_lang_output_object_attributes_hook)
(void);

 || arm_arch7) && arm_arch_notm)
   
   /* Nonzero if this chip supports load-acquire and store-release.  */


-#define TARGET_HAVE_LDACQ  (TARGET_ARM_ARCH >= 8 && arm_arch_notm)
+#define TARGET_HAVE_LDACQ  (TARGET_ARM_ARCH >= 8 && TARGET_32BIT)

So this change is correct because ARMv8-M Mainline uses Thumb2
and is therefore TARGET_32BIT.

This is ok but I'd like to see a follow up patch to enable the tests
that exercise acquire-release instructions in the arm.exp testsuite
for ARMv8-M Mainline so that we can be sure they get proper testsuite
coverage.

I've respinned the patch because of the changes to atomic_loaddi output
template in config/arm/sync.md. This patch now creates a new macro
TARGET_HAVE_LDACQEXD to guard LDACQEXD and STLEXD instructions that are not
available in ARMv8-M Mainline. It took advantage of the respin to also add the
tests you were asking for.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

 * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M Mainline.
 (TARGET_HAVE_LDACQD): New macro.
 * config/arm/sync.md (atomic_loaddi): Use TARGET_HAVE_LDACQD rather
 than TARGET_HAVE_LDACQ.
 (arm_load_acquire_exclusivedi): Likewise.
 (arm_store_release_exclusivedi): Likewise.


*** gcc/testsuite/ChangeLog ***

2016-07-05  Thomas Preud'homme  

 * gcc.target/arm/atomic-comp-swap-release-acquire.c: Rename into ...
 * gcc.target/arm/atomic-comp-swap-release-acquire-1.c: This.
 * gcc.target/arm/atomic-op-acq_rel.c: Rename into ...
 * gcc.target/arm/atomic-op-acq_rel-1.c: This.
 * gcc.target/arm/atomic-op-acquire.c: Rename into ...
 * gcc.target/arm/atomic-op-acquire-1.c: This.
 * gcc.target/arm/atomic-op-char.c: Rename into ...
 * gcc.target/arm/atomic-op-char-1.c: This.
 * gcc.target/arm/atomic-op-consume.c: Rename into ...
 * gcc.target/arm/atomic-op-consume-1.c: This.
 * gcc.target/arm/atomic-op-int.c: Rename into ...
 * gcc.target/arm/atomic-op-int-1.c: This.
 * gcc.target/arm/atomic-op-relaxed.c: Rename into ...
 * gcc.target/arm/atomic-op-relaxed-1.c: This.
 * gcc.target/arm/atomic-op-release.c: Rename into ...
 * gcc.target/arm/atomic-op-release-1.c: This.
 * gcc.target/arm/atomic-op-seq_cst.c: Rename into ...
 * gcc.target/arm/atomic-op-seq_cst-1.c: This.
 * gcc.target/arm/atomic-op-short.c: Rename into ...
 * gcc.target/arm/atomic-op-short-1.c: This.
 * gcc.target/arm/atomic-comp-swap-release-acquire-2.c: New test.
 * gcc.target/arm/atomic-op-acq_rel-2.c: Likewise.
 * gcc.target/arm/atomic-op-acquire-2.c: Likewise.
 * gcc.target/arm/atomic-op-char-2.c: Likewise.
 * gcc.target/arm/atomic-op-consume-2.c: Likewise.
 * gcc.target/arm/atomic-op-int-2.c: Likewise.
 * gcc.target/arm/atomic-op-relaxed-2.c: Likewise.
 * gcc.target/arm/atomic-op-release-2.c: Likewise.
 * gcc.target/arm/atomic-op-seq_cst-2.c: Likewise.
 * gcc.target/arm/atomic-op-short-2.c: Likewise.


Testsuite shows no regression and atomic tests [1] are passing for ARMv8-M
Mainline.

[1] gcc.dg/atomic*, g++.dg/ext/atomic*, gcc.target/arm/atomic*,
gcc.target/arm/sync* and libstdc++-v3/testsuite/29_atomic/*


Thanks, this is ok if testing on arm-none-linux-gnueabihf is ok.
In particular, please make sure that the tests still pass for an A-profile 
target.

Kyrill



Best regards,

Thomas

[Fortran, Patch, PR71807, v1] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[Andre Vehreschild]

Hi all,

attached patch fixes the ICE when assigning null() to an allocatable
component in an initializer.

Bootstrapped and regtested on x86_64-linux/F23 ok for trunk,
gcc-6-branch and gcc-5-branch.

Ok for trunk and one week later for the other branches?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/71807
* trans-expr.c (gfc_trans_subcomponent_assign): Special casing
when allocatable component is set to null() in initializer.

gcc/testsuite/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/71807
* gfortran.dg/null_9.f90: New test.


diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 4321850..e3559f4 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7200,6 +7200,12 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm, gfc_expr * expr,
   tmp = gfc_trans_alloc_subarray_assign (tmp, cm, expr);
   gfc_add_expr_to_block (, tmp);
 }
+  else if (init && cm->attr.allocatable && expr->expr_type == EXPR_NULL)
+{
+  /* NULL initialization for allocatable components.  */
+  gfc_add_modify (, dest, fold_convert (TREE_TYPE (dest),
+		  null_pointer_node));
+}
   else if (init && (cm->attr.allocatable
 	   || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
 	   && expr->ts.type != BT_CLASS)))
diff --git a/gcc/testsuite/gfortran.dg/null_9.f90 b/gcc/testsuite/gfortran.dg/null_9.f90
new file mode 100644
index 000..9afd938
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/null_9.f90
@@ -0,0 +1,30 @@
+! { dg-do run }
+
+MODULE fold_convert_loc_ice
+  IMPLICIT NONE
+  PRIVATE
+
+  TYPE, PUBLIC :: ta
+PRIVATE
+INTEGER :: a_comp
+  END TYPE ta
+
+  TYPE, PUBLIC :: tb
+TYPE(ta), ALLOCATABLE :: b_comp
+  END TYPE tb
+
+  PUBLIC :: proc
+CONTAINS
+  SUBROUTINE proc
+TYPE(tb) :: b
+
+b = tb(null())
+if (allocated( b%b_comp )) call abort()
+  END SUBROUTINE proc
+END MODULE fold_convert_loc_ice
+
+  USE fold_convert_loc_ice
+
+  call proc()
+END
+

Re: [PATCH] Fix tree-data-ref.c ICE (PR tree-optimization/71872)

[Richard Biener]

On July 14, 2016 5:28:03 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>As mentioned in the PR, we ICE on the following testcase, because
>tree-data-ref.c for VIEW_CONVERT_EXPR(0) attempts to create
>ADDR_EXPR of INTEGER_CST, which is not really valid.
>
>I've successfully bootstrapped/regtested earlier version of this patch
>with is_gimple_constant instead of is_gimple_min_invariant on
>x86_64-linux
>and i686-linux, ok for trunk if even this version succeeds?

OK.

Richard.

>2016-07-14  Jakub Jelinek  
>
>   PR tree-optimization/71872
>   * tree-data-ref.c (get_references_in_stmt): Ignore references
>   with is_gimple_constant get_base_address.
>
>   * gcc.c-torture/compile/pr71872.c: New test.
>
>--- gcc/tree-data-ref.c.jj 2016-07-11 22:18:08.0 +0200
>+++ gcc/tree-data-ref.c2016-07-14 14:03:57.902899566 +0200
>@@ -3868,7 +3868,8 @@ get_references_in_stmt (gimple *stmt, ve
>   if (DECL_P (op1)
> || (REFERENCE_CLASS_P (op1)
> && (base = get_base_address (op1))
>-&& TREE_CODE (base) != SSA_NAME))
>+&& TREE_CODE (base) != SSA_NAME
>+&& !is_gimple_min_invariant (base)))
>   {
> ref.ref = op1;
> ref.is_read = true;
>--- gcc/testsuite/gcc.c-torture/compile/pr71872.c.jj   2016-07-14
>14:14:17.132889043 +0200
>+++ gcc/testsuite/gcc.c-torture/compile/pr71872.c  2016-07-14
>14:14:05.0 +0200
>@@ -0,0 +1,15 @@
>+/* PR tree-optimization/71872 */
>+
>+struct __attribute__((may_alias)) S { int a; };
>+
>+void
>+foo (int *x, struct S *y)
>+{
>+  int i;
>+  for (i = 0; i < 16; i++)
>+{
>+  int a = 0;
>+  if (*x)
>+*(struct S *) y = *(struct S *) 
>+}
>+}
>
>   Jakub

[PATCH PR71503/PR71683]Fix ICE in tree-if-conv.c

[Bin Cheng]

Hi,
This is a simple patch fixing ICE in tree-if-conv.c.  Existing code does not 
setup a variable (cond) when predicate of basic block is true and it asserts on 
the variable.  Interesting thing is dead code is not cleaned up before ifcvt, 
but that's another story.
Bootstrap and test on x86_64.  Is it OK?

Thanks,
bin

2016-07-13  Bin Cheng  

PR tree-optimization/71503
PR tree-optimization/71683
* tree-if-conv.c (gen_phi_arg_condition): Set cond when predicate
is true.

gcc/testsuite/ChangeLog
2016-07-13  Bin Cheng  

PR tree-optimization/71503
PR tree-optimization/71683
* gcc.dg/tree-ssa/ifc-pr71503.c: New test.
* gcc.dg/tree-ssa/ifc-pr71683.c: New test.
diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c
index e5a3372..3dce0de 100644
--- a/gcc/tree-if-conv.c
+++ b/gcc/tree-if-conv.c
@@ -1687,7 +1687,11 @@ gen_phi_arg_condition (gphi *phi, vec *occur,
   e = gimple_phi_arg_edge (phi, (*occur)[i]);
   c = bb_predicate (e->src);
   if (is_true_predicate (c))
-   continue;
+   {
+ if (!cond)
+   cond = c;
+ continue;
+   }
   c = force_gimple_operand_gsi_1 (gsi, unshare_expr (c),
  is_gimple_condexpr, NULL_TREE,
  true, GSI_SAME_STMT);
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71503.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71503.c
new file mode 100644
index 000..5a90abf
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71503.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast" { target *-*-* } } */
+
+int a, b;
+unsigned long d;
+void fn1() {
+  unsigned long *h = 
+line1 : {
+  int i = 4;
+  for (; b; i++) {
+d = ((d + 6 ?: *h) ? a : 7) && (i &= 0 >= b);
+b += a;
+  }
+}
+  h = 0;
+  for (; *h;)
+goto line1;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71683.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71683.c
new file mode 100644
index 000..851be37
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71683.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast" { target *-*-* } } */
+
+short unsigned int ve;
+
+void
+u1 (void)
+{
+  int oq = 0;
+
+  while (ve != 0)
+{
+  int j4, w7 = oq;
+
+  oq = 0 / oq;
+  ve %= oq;
+  j4 = ve ^ 1;
+  ve ^= oq;
+  if (j4 != 0 ? j4 : ve)
+oq = ve;
+  else
+if (w7 != 0)
+  oq = ve;
+}
+}

[PATCH testsuite]XFAIL gcc.dg/tree-ssa/pr71347 on some targets

[Bin Cheng]

Hi,
Test gcc.dg/tree-ssa/pr71347 failed on some targets if the two memory 
references are re-written into different forms by IVOPT.  This could be because 
of various reasons, for example, auto-increment addressing mode.  Since the 
address expressions are of different form, DOM fails to eliminate the redundant 
load at the moment.  I think DOM should be improved to handle address 
expressions appearing in different forms (at least for simple cases).  For now, 
I will XFAIL this test indicating a possible enhancement.

Test checked on affected targets.  Is it OK?

Thanks,
bin

gcc/testsuite/ChangeLog
2016-06-20  Bin Cheng  

PR tree-optimization/71347
* gcc.dg/tree-ssa/pr71347.c: XFAIL on ia64, arm, m68k and sparc.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
index c8f87a9..428e41b 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
@@ -14,4 +14,4 @@ void foo (void)
 }
 
 /* Load of X[i - i] can be omitted by reusing X[i] in previous iteration.  */
-/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized"} } */
+/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized" { xfail { 
ia64-*-* arm*-*-* m68k*-*-* sparc*-*-* } } } } */

[PATCH test]Refine test string for scev-8.c

[Bin Cheng]

Hi,
Dump information of IVOPT has been improved, but scanning string in 
gcc.dg/tree-ssa/scev-8.c was left over because it appears as PASS.  This patch 
changes test string to what should be tested.
Test result checked.  This is an obvious change.

Thanks,
bin

gcc/testsuite/ChangeLog
2016-07-14  Bin Cheng  

* gcc.dg/tree-ssa/scev-8.c: Update test string.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c 
b/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c
index 766f674..bb2ee7a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-8.c
@@ -59,4 +59,4 @@ foo4 (unsigned char s, unsigned char l)
 }
 
 /* Address of array references are not scevs.  */
-/* { dg-final { scan-tree-dump-not "use \[0-9\]\n  address" "ivopts" } } */
+/* { dg-final { scan-tree-dump-not "  Type:\\tADDRESS\n  Use \[0-9\].\[0-9\]:" 
"ivopts" } } */

Re: [PATCH] Amend dump expectation in slsr-8.c (PR, tree-optimization/71490)

[Martin Liška]

On 07/14/2016 01:21 PM, Richard Biener wrote:
> On Thu, Jul 14, 2016 at 1:06 PM, Martin Liška  wrote:
>> On 07/13/2016 07:21 PM, Jeff Law wrote:
>>> Isn't that a code quality regression?  So instead shouldn't we be keeping 
>>> the same expectation, but xfailing the test?
>>>
>>> jeff
>>
>> Hello.
>>
>> Disabling a pass before slsr makes the test to catch both opportunities.
>> Is the patch fine?
> 
> No, this is still a code quality regression.  What happens is that for
> some reason we fail to sink for GCC 6.

So should I just mark the test-case as a xfail?

M.

> 
> Richard.
> 
>> Thanks,
>> Martin

Re: [patch] Fix type merging deficiency during WPA

[Eric Botcazou]

> Yeah, as said such optimistic merging would need to happen during canoncial
> type merging for example by completely ignoring TYPE_DOMAIN or
> DECL_FIELD_OFFSET ... (a non-constant in one unit may be the same as a
> constant in another...).

OK, that's really optimistic, and we can probably get away without going this 
far, e.g. by completely ignoring non-constant fields only, but I see, thanks.

-- 
Eric Botcazou

Re: [PATCH] Add header for std::search to testcase

[Jonathan Wakely]

On 14/07/16 16:29 +0100, Jonathan Wakely wrote:

* testsuite/experimental/functional/searchers.cc: Include 
for std::search.

This test was failing in Parallel Mode, because it wasn't including
the  header for std::search.


Actually that fix isn't quite enough. Even if the testcase didn't use
std::search, the  header does, and so it
needs more than just  when Parallel Mode is active.

Tested x86_64-linux, committed to trunk.

commit 4757fa3aed51ca0e7075c9126c8f9919489bebb4
Author: Jonathan Wakely 
Date:   Thu Jul 14 16:33:11 2016 +0100

Include header for std::__parallel::search

	* include/experimental/functional: Include  in
	Parallel Mode.

diff --git a/libstdc++-v3/include/experimental/functional b/libstdc++-v3/include/experimental/functional
index 2095310..ed41f5a 100644
--- a/libstdc++-v3/include/experimental/functional
+++ b/libstdc++-v3/include/experimental/functional
@@ -42,6 +42,9 @@
 #include 
 #include 
 #include 
+#ifdef _GLIBCXX_PARALLEL
+# include  // For std::__parallel::search
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {

Re: [Ada] Another small tweak in LTO mode

[Eric Botcazou]

> I am not quite sure I understand your explanation.  Can you, please, show me
> how the types differ? So you have one type which contains ptr_type_node and
> other which is array?

For one compilation unit, the type is an array of pointer to something, for 
example a record type and, for another compilation unit, the type is an array 
of ptr_type_node.  That's because the "something" isn't even parsed by the 
compiler in the second case, so that you can change the implementation without 
recompiling all the clients.

-- 
Eric Botcazou

[PATCH] Add header for std::search to testcase

[Jonathan Wakely]

* testsuite/experimental/functional/searchers.cc: Include 
for std::search.

This test was failing in Parallel Mode, because it wasn't including
the  header for std::search.

Tested x86_64-linux, committed to trunk.

commit ca8663b7b1451f4ca0097af7eb902367970f7b33
Author: redi 
Date:   Thu Jul 14 15:27:09 2016 +

Add header for std::search to testcase

* testsuite/experimental/functional/searchers.cc: Include 
for std::search.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238341 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/testsuite/experimental/functional/searchers.cc 
b/libstdc++-v3/testsuite/experimental/functional/searchers.cc
index 5e585f8..143593f 100644
--- a/libstdc++-v3/testsuite/experimental/functional/searchers.cc
+++ b/libstdc++-v3/testsuite/experimental/functional/searchers.cc
@@ -22,6 +22,7 @@
 #ifdef _GLIBCXX_USE_WCHAR_T
 # include 
 #endif
+#include 
 #include 
 
 using std::experimental::make_default_searcher;

[PATCH] Fix tree-data-ref.c ICE (PR tree-optimization/71872)

[Jakub Jelinek]

Hi!

As mentioned in the PR, we ICE on the following testcase, because
tree-data-ref.c for VIEW_CONVERT_EXPR(0) attempts to create
ADDR_EXPR of INTEGER_CST, which is not really valid.

I've successfully bootstrapped/regtested earlier version of this patch
with is_gimple_constant instead of is_gimple_min_invariant on x86_64-linux
and i686-linux, ok for trunk if even this version succeeds?

2016-07-14  Jakub Jelinek  

PR tree-optimization/71872
* tree-data-ref.c (get_references_in_stmt): Ignore references
with is_gimple_constant get_base_address.

* gcc.c-torture/compile/pr71872.c: New test.

--- gcc/tree-data-ref.c.jj  2016-07-11 22:18:08.0 +0200
+++ gcc/tree-data-ref.c 2016-07-14 14:03:57.902899566 +0200
@@ -3868,7 +3868,8 @@ get_references_in_stmt (gimple *stmt, ve
   if (DECL_P (op1)
  || (REFERENCE_CLASS_P (op1)
  && (base = get_base_address (op1))
- && TREE_CODE (base) != SSA_NAME))
+ && TREE_CODE (base) != SSA_NAME
+ && !is_gimple_min_invariant (base)))
{
  ref.ref = op1;
  ref.is_read = true;
--- gcc/testsuite/gcc.c-torture/compile/pr71872.c.jj2016-07-14 
14:14:17.132889043 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr71872.c   2016-07-14 
14:14:05.0 +0200
@@ -0,0 +1,15 @@
+/* PR tree-optimization/71872 */
+
+struct __attribute__((may_alias)) S { int a; };
+
+void
+foo (int *x, struct S *y)
+{
+  int i;
+  for (i = 0; i < 16; i++)
+{
+  int a = 0;
+  if (*x)
+*(struct S *) y = *(struct S *) 
+}
+}

Jakub

[C++ PATCH] Fix up vector cond expr handling in templates (PR c++/71871)

[Jakub Jelinek]

Hi!

This patch reverts part of
https://gcc.gnu.org/ml/gcc-patches/2012-10/msg01665.html
which looks wrong to me.
The problem is that in templates, if the build_x_conditional_expr
arguments aren't type dependent, we might get NON_DEPENDENT_EXPR
wrappers around the argument, so after issuing possibly needed diagnostics
we need to return back to the original unmodified arguments,
which for VEC_COND_EXPR the condition has been bypassing and we ended up
with NON_DEPENDENT_EXPR in the IL, which nothing strips away
(plus VEC_COND_EXPR isn't really supported in tsubst_copy/tsubst_copy_and_build
and perhaps other spots).
While we could do build_min_non_dep with VEC_COND_EXPR and teach pt.c about
VEC_COND_EXPR, I really don't see advantages of doing that, if we build just
COND_EXPR, build_min_non_dep ensures that it will have the right type, and
when we instantiate it build_x_conditional_expr will be called again and
that will create VEC_COND_EXPR when not processing_template_decl.

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

2016-07-14  Jakub Jelinek  

PR c++/71871
* typeck.c (build_x_conditional_expr): Revert the 2012-10-25 change.

* g++.dg/ext/vector31.C: New test.

--- gcc/cp/typeck.c.jj  2016-07-11 11:14:28.0 +0200
+++ gcc/cp/typeck.c 2016-07-14 12:47:48.436699222 +0200
@@ -6288,8 +6288,7 @@ build_x_conditional_expr (location_t loc
 }
 
   expr = build_conditional_expr (loc, ifexp, op1, op2, complain);
-  if (processing_template_decl && expr != error_mark_node
-  && TREE_CODE (expr) != VEC_COND_EXPR)
+  if (processing_template_decl && expr != error_mark_node)
 {
   tree min = build_min_non_dep (COND_EXPR, expr,
orig_ifexp, orig_op1, orig_op2);
--- gcc/testsuite/g++.dg/ext/vector31.C.jj  2016-07-14 13:01:04.933206583 
+0200
+++ gcc/testsuite/g++.dg/ext/vector31.C 2016-07-14 13:00:59.943272143 +0200
@@ -0,0 +1,29 @@
+// PR c++/71871
+// { dg-do compile }
+
+typedef unsigned int V __attribute__ ((__vector_size__ (32)));
+
+template 
+void
+foo (V *x)
+{
+  V a = *x;
+  a = a ? a : -1;
+  *x = a;
+}
+
+template 
+void
+bar (T *x)
+{
+  T a = *x;
+  a = a ? a : -1;
+  *x = a;
+}
+
+void
+test (V *x, V *y)
+{
+  foo<0> (x);
+  bar (y);
+}

Jakub

[patch] Add new hook to diagnose address space usage

[Georg-Johann Lay]

This adds a new hook that allows to emit better diagnostics if an address space 
is used that's not available.


One solution would be no not register the address space with 
c_register_addr_space but that gives ugly report like


error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f321'

The hook allows better diagnostics:  The address spaces are registered with 
c_register_addr_space and if the parser comes across an address space it 
provides the hook with the needed information, in particular the location of 
the token so that the message would be something like


ptiny.c:12:11: error: address space '__flash2' not supported for devices with 
flash size up to 128 KiB

 const int __flash2 f321[] = { 321, 654 };
   ^~~~

This only works if address spaces are part of the language dialect.

Default implementation is void.

The intended user is the avr backend which currently emits diagnostics in some 
hook like TARGET_INSERT_ATTRIBUTER, but the locations are out of sync there.


Ok for trunk if bootstrap passes?

Johann


gcc/
* target.def (addr_space): Add new diagnose_usage to hook vector.
* targhooks.c (default_addr_space_diagnose_usage): Add default
implementation and...
* targhooks.h (default_addr_space_diagnose_usage): ... its prototype.
* c/c-parser.c (c_lex_one_token) [CPP_NAME]: If the token
is some address space, call targetm.addr_space.diagnose_usage.
* doc/tm.texi.in (Named Address Spaces): Add anchor for
TARGET_ADDR_SPACE_DIAGNOSE_USAGE documentation.
* doc/tm.texi: Regenerate.
Index: target.def
===
--- target.def	(revision 237587)
+++ target.def	(working copy)
@@ -3241,6 +3241,21 @@ The result is the value to be used with
  int, (addr_space_t as),
  default_addr_space_debug)
 
+/* Function to emit custom diagnostic if an address space is used.  */
+DEFHOOK
+(diagnose_usage,
+ "Define this hook if the availability of an address space depends on\n\
+command line options and some diagnostics shall be printed when the\n\
+address space is used.  This hook is called during parsing and allows\n\
+to emit a better diagnostic compared to the case where the address space\n\
+was not registered with @code{c_register_addr_space}.  @var{as} is\n\
+the address space as registered with @code{c_register_addr_space}.\n\
+@var{loc} is the location of the address space qualifier token.\n\
+Return true if the hook issued an error and false, otherwise.\n\
+The default implementation does nothing.",
+ bool, (addr_space_t as, location_t loc),
+ default_addr_space_diagnose_usage)
+
 HOOK_VECTOR_END (addr_space)
 
 #undef HOOK_PREFIX
Index: targhooks.c
===
--- targhooks.c	(revision 237587)
+++ targhooks.c	(working copy)
@@ -1291,6 +1291,14 @@ default_addr_space_debug (addr_space_t a
   return as;
 }
 
+bool
+default_addr_space_diagnose_usage (addr_space_t ARG_UNUSED (as),
+   location_t ARG_UNUSED (loc))
+{
+  return false;
+}
+	 
+
 /* The default hook for TARGET_ADDR_SPACE_CONVERT. This hook should never be
called for targets with only a generic address space.  */
 
Index: targhooks.h
===
--- targhooks.h	(revision 237587)
+++ targhooks.h	(working copy)
@@ -181,6 +181,7 @@ extern rtx default_addr_space_legitimize
 extern bool default_addr_space_subset_p (addr_space_t, addr_space_t);
 extern bool default_addr_space_zero_address_valid (addr_space_t);
 extern int default_addr_space_debug (addr_space_t);
+extern bool default_addr_space_diagnose_usage (addr_space_t, location_t);
 extern rtx default_addr_space_convert (rtx, tree, tree);
 extern unsigned int default_case_values_threshold (void);
 extern bool default_have_conditional_execution (void);
Index: c/c-parser.c
===
--- c/c-parser.c	(revision 237587)
+++ c/c-parser.c	(working copy)
@@ -300,6 +300,9 @@ c_lex_one_token (c_parser *parser, c_tok
 	else if (rid_code >= RID_FIRST_ADDR_SPACE
 		 && rid_code <= RID_LAST_ADDR_SPACE)
 	  {
+		addr_space_t as;
+		as = (addr_space_t) (rid_code - RID_FIRST_ADDR_SPACE);
+		targetm.addr_space.diagnose_usage (as, token->location);
 		token->id_kind = C_ID_ADDRSPACE;
 		token->keyword = rid_code;
 		break;
Index: doc/tm.texi.in
===
--- doc/tm.texi.in	(revision 237587)
+++ doc/tm.texi.in	(working copy)
@@ -7486,6 +7486,8 @@ c_register_addr_space ("__ea", ADDR_SPAC
 
 @hook TARGET_ADDR_SPACE_DEBUG
 
+@hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE
+
 @node Misc
 @section Miscellaneous Parameters
 @cindex parameters, miscellaneous
Index: doc/tm.texi
===
--- doc/tm.texi	(revision 237587)
+++ doc/tm.texi	(working copy)
@@ -10431,6 +10431,18 @@ Define 

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

[Martin Sebor]

Ping.  Jason, do you have any further comments or concerns with
the updated patch?

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00280.html

Thanks
Martin

On 07/06/2016 04:20 PM, Martin Sebor wrote:

On 06/23/2016 03:36 PM, Jason Merrill wrote:

On 06/20/2016 10:17 PM, Martin Sebor wrote:

+  && tree_int_cst_equal (lhs, null_pointer_node)
+  && !tree_int_cst_equal (rhs, integer_zero_node))


Not integer_zerop?


+"invalid conversion involving a null pointer");

...

+"invalid conversion from %qT to %qT",


The conversion isn't invalid, it just isn't a constant expression.


(Sorry for the delay following up on this review.  I got busy
with something else.)

I've adjusted the text of the diagnostics, though the first one
is also issued for conversions that are invalid even outside
constexpr, such as those that cast away constness, or those that
cast to incomplete type.  Without -fpermissve those are already
diagnosed by this point but I'm not sure how much trouble to go
to here to avoid diagnosing them again, or at all with
-fpermissve.


For
the null pointer to pointer conversion, does this properly allow
conversion to void* or to base*?


It didn't handle either but does now.  Thank you for calling it
out.  Surprisingly, a regression run including libstdc++ didn't
catch it.  I've added tests to exercise it.




+if (integer_zerop (op))

...

+ else if (!integer_zerop (op))


The second test seems redundant.


I have removed it.

Martin

Re: [PATCH] doc fix for c/71560 - union compound literal initializes wrong union field

[Martin Sebor]

Ping.  The updated patch at the link below corrects the issues
with the tags pointed out by Sandra in her review.

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00350.html

Thanks
Martin

On 07/07/2016 01:47 PM, Martin Sebor wrote:

On 07/03/2016 05:22 PM, Sandra Loosemore wrote:

On 07/01/2016 05:56 PM, Martin Sebor wrote:

The bug points out a couple of conformance problems in the GCC
manual where is discusses compound literals and casts to unions
and says that a compound literal is equivalent to a cast.  It
isn't because a compound literal is an lvalue but a cast yields
an rvalue.

The attached patch corrects this error and adds some clarifying
text to illustrate the differences.


This looks OK modulo some markup problems.


Thanks for the careful review!  After reading the descriptions
in the Texinfo manual I agree that the @code command is more
appropriate here than either @var or @samp and I've made the
changes in the updated patch.

I quickly reviewed the rest of the file for other uses of these
commands and they appear to be just as inconsistent with the
Texinfo recommendation as were mine.  They don't appear to make
a huge difference in the formatting of the HTML or PDF but it
would be nice to fix those up as well, if only for consistency.


I think it would be more appropriate to use @code rather than @samp
markup throughout this discussion, since foo, char*, etc are "entire
syntactic tokens", per the texinfo manual.


Attached is the updated patch.

Martin

[Fortran, Patch, PR70842, v1] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[Andre Vehreschild]

Hi all,

attached patch fixes the ICE and the wrong char array length mentioned
in comment #3 of the PR. The issue was that getting the _len component
is valid online for unlimited polymorphic pointers. But here this was
tried for polymorphic entity, which had to fail.

Bootstrapped and regtests ok on trunk, gcc-6-branch, gcc-5-branch,
gcc-4_9-branch. Ok for trunk and one week later for the other branches?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/testsuite/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/70842
* gfortran.dg/select_type_35.f03: New test.


gcc/fortran/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/70842
* simplify.c (gfc_simplify_len): Only for unlimited polymorphic
types replace the expression's _data ref with a _len ref.

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 95a8d10..e3f4d50 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -3816,8 +3816,11 @@ gfc_simplify_len (gfc_expr *e, gfc_expr *kind)
 }
   else if (e->expr_type == EXPR_VARIABLE && e->ts.type == BT_CHARACTER
 	   && e->symtree->n.sym
+	   && e->symtree->n.sym->ts.type != BT_DERIVED
 	   && e->symtree->n.sym->assoc && e->symtree->n.sym->assoc->target
-	   && e->symtree->n.sym->assoc->target->ts.type == BT_DERIVED)
+	   && e->symtree->n.sym->assoc->target->ts.type == BT_DERIVED
+	   && e->symtree->n.sym->assoc->target->symtree->n.sym
+	   && UNLIMITED_POLY (e->symtree->n.sym->assoc->target->symtree->n.sym))
 /* The expression in assoc->target points to a ref to the _data component
of the unlimited polymorphic entity.  To get the _len component the last
_data ref needs to be stripped and a ref to the _len component added.  */
diff --git a/gcc/testsuite/gfortran.dg/select_type_35.f03 b/gcc/testsuite/gfortran.dg/select_type_35.f03
new file mode 100644
index 000..92d2f27
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/select_type_35.f03
@@ -0,0 +1,41 @@
+! { dg-do run }
+!
+! Contributed by Nathanael Huebbe
+! Check fix for PR/70842
+
+program foo
+
+  TYPE, ABSTRACT :: t_Intermediate
+  END TYPE t_Intermediate
+
+  type, extends(t_Intermediate) :: t_Foo
+character(:), allocatable :: string
+  end type t_Foo
+
+  class(t_Foo), allocatable :: obj
+
+  allocate(obj)
+  obj%string = "blabarfoo"
+
+  call bar(obj)
+
+  deallocate(obj)
+contains
+  subroutine bar(me)
+class(t_Intermediate), target :: me
+
+class(*), pointer :: alias
+
+select type(me)
+  type is(t_Foo)
+  if (len(me%string) /= 9) call abort()
+end select
+
+alias => me
+select type(alias)
+  type is(t_Foo)
+if (len(alias%string) /= 9) call abort()
+end select
+  end subroutine bar
+end program foo
+

Re: [C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[Marek Polacek]

On Thu, Jul 14, 2016 at 04:50:16PM +0200, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, anticipated decls should be ignored from fuzzy
> lookups, unless the corresponding decl is declared first.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2016-07-13  Jakub Jelinek  
> 
>   PR c/71858
>   * c-decl.c (lookup_name_fuzzy): Ignore binding->invisible.
> 
>   * gcc.dg/spellcheck-identifiers.c (snprintf): Declare.
>   * gcc.dg/spellcheck-identifiers-2.c: New test.
>   * gcc.dg/diagnostic-token-ranges.c (nanl): Declare.
>   * c-c++-common/attributes-1.c: Adjust dg-prune-output.
> 
> --- gcc/c/c-decl.c.jj 2016-06-24 12:59:22.0 +0200
> +++ gcc/c/c-decl.c2016-07-13 22:40:23.410658411 +0200
> @@ -4021,7 +4021,7 @@ lookup_name_fuzzy (tree name, enum looku
>for (c_scope *scope = current_scope; scope; scope = scope->outer)
>  for (c_binding *binding = scope->bindings; binding; binding = 
> binding->prev)
>{
> - if (!binding->id)
> + if (!binding->id || binding->invisible)
> continue;
>   /* Don't use bindings from implicitly declared functions,
>  as they were likely misspellings themselves.  */

This is OK as long as David is fine with the testsuite part.  Thanks,

Marek

[PATCH] Tweak diagnostic-token.ranges.c testcase (PR testsuite/71865)

[Jakub Jelinek]

Hi!

As mentioned in the PR, this testcase behaves differently on
powerpc*/spu/s390* targets, because in non-iso modes they predefine
conditional macros like bool and that affects the behavior of the
suggestions.

We should certainly discuss what to do with the conditional macros,
but in the mean time IMHO it doesn't hurt to just avoid this
problem.

Tested on x86_64-linux and i686-linux, ok for trunk?

2016-07-14  Jakub Jelinek  

PR testsuite/71865
* gcc.dg/diagnostic-token-ranges.c: Add -std=c11 to dg-options.
(wide_string_literal_in_asm): Use __asm instead of asm, adjust
expected diagnostics.

--- gcc/testsuite/gcc.dg/diagnostic-token-ranges.c.jj   2016-07-14 
11:06:23.0 +0200
+++ gcc/testsuite/gcc.dg/diagnostic-token-ranges.c  2016-07-14 
14:47:50.399907380 +0200
@@ -1,4 +1,4 @@
-/* { dg-options "-fdiagnostics-show-caret -Wc++-compat" } */
+/* { dg-options "-fdiagnostics-show-caret -Wc++-compat -std=c11" } */
 
 /* Verify that various diagnostics show source code ranges.  */
 
@@ -68,11 +68,11 @@ foo (unknown_type param); /* { dg-error
 
 void wide_string_literal_in_asm (void)
 {
-  asm (L"nop"); /* { dg-error "wide string literal in 'asm'" } */
+  __asm (L"nop"); /* { dg-error "wide string literal in 'asm'" } */
 /*
 { dg-begin-multiline-output "" }
-   asm (L"nop");
-^~
+   __asm (L"nop");
+  ^~
 { dg-end-multiline-output "" }
 */
 }

Jakub

[C PATCH] For implicit function declaration suggestions only consider fns and fn pointers (PR c/71858)

[Jakub Jelinek]

Hi!

When implicit_decl_warning is called, we know we are interested
in a function or function pointer (or macro), C doesn't support
int () like C++, or var () when var doesn't have function pointer type.

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

2016-07-14  Jakub Jelinek  

PR c/71858
* c-common.h (enum lookup_name_fuzzy_kind): Add
FUZZY_LOOKUP_FUNCTION_NAME.

* c-decl.c (implicit_decl_warning): Use FUZZY_LOOKUP_FUNCTION_NAME
instead of FUZZY_LOOKUP_NAME.
(lookup_name_fuzzy): For FUZZY_LOOKUP_FUNCTION_NAME consider
FUNCTION_DECLs, {VAR,PARM}_DECLs function pointers and macros.

* gcc.dg/spellcheck-identifiers-3.c: New test.

--- gcc/c-family/c-common.h.jj  2016-06-24 12:59:21.0 +0200
+++ gcc/c-family/c-common.h 2016-07-14 10:07:18.526594783 +0200
@@ -994,6 +994,9 @@ enum lookup_name_fuzzy_kind {
   /* Names of types.  */
   FUZZY_LOOKUP_TYPENAME,
 
+  /* Names of function decls.  */
+  FUZZY_LOOKUP_FUNCTION_NAME,
+
   /* Any name.  */
   FUZZY_LOOKUP_NAME
 };
--- gcc/c/c-decl.c.jj   2016-07-13 22:40:23.0 +0200
+++ gcc/c/c-decl.c  2016-07-14 10:29:31.548376306 +0200
@@ -3090,7 +3090,7 @@ implicit_decl_warning (location_t loc, t
   bool warned;
   tree hint = NULL_TREE;
   if (!olddecl)
-   hint = lookup_name_fuzzy (id, FUZZY_LOOKUP_NAME);
+   hint = lookup_name_fuzzy (id, FUZZY_LOOKUP_FUNCTION_NAME);
 
   if (flag_isoc99)
if (hint)
@@ -4028,9 +4028,30 @@ lookup_name_fuzzy (tree name, enum looku
if (TREE_CODE (binding->decl) == FUNCTION_DECL)
  if (C_DECL_IMPLICIT (binding->decl))
continue;
-   if (kind == FUZZY_LOOKUP_TYPENAME)
- if (TREE_CODE (binding->decl) != TYPE_DECL)
-   continue;
+   switch (kind)
+ {
+ case FUZZY_LOOKUP_TYPENAME:
+   if (TREE_CODE (binding->decl) != TYPE_DECL)
+ continue;
+   break;
+
+ case FUZZY_LOOKUP_FUNCTION_NAME:
+   if (TREE_CODE (binding->decl) != FUNCTION_DECL)
+ {
+   /* Allow function pointers.  */
+   if ((VAR_P (binding->decl)
+|| TREE_CODE (binding->decl) == PARM_DECL)
+   && TREE_CODE (TREE_TYPE (binding->decl)) == POINTER_TYPE
+   && (TREE_CODE (TREE_TYPE (TREE_TYPE (binding->decl)))
+   == FUNCTION_TYPE))
+ break;
+   continue;
+ }
+   break;
+
+ default:
+   break;
+ }
bm.consider (binding->id);
   }
 
--- gcc/testsuite/gcc.dg/spellcheck-identifiers-3.c.jj  2016-07-14 
10:18:17.790090780 +0200
+++ gcc/testsuite/gcc.dg/spellcheck-identifiers-3.c 2016-07-14 
10:39:14.392829944 +0200
@@ -0,0 +1,45 @@
+/* PR c/71858 */
+/* Only consider function names, function pointers and macros for implicit 
function declarations.  */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-function-declaration -fdiagnostics-show-caret" } */
+
+void fn1abcd (void);
+
+void
+test_1 (int fn1bacd)
+{
+  fn1badc (); /* { dg-warning "3: implicit declaration of function .fn1badc.; 
did you mean .fn1abcd.?" } */
+  /* { dg-begin-multiline-output "" }
+   fn1badc ();
+   ^~~
+   fn1abcd
+   { dg-end-multiline-output "" } */
+}
+
+void fn2efgh (void);
+void (*fn2efhg) (void);
+
+void
+test_2 (void)
+{
+  fn2fehg (); /* { dg-warning "3: implicit declaration of function .fn2fehg.; 
did you mean .fn2efhg.?" } */
+  /* { dg-begin-multiline-output "" }
+   fn2fehg ();
+   ^~~
+   fn2efhg
+   { dg-end-multiline-output "" } */
+}
+
+void fn3ijkl (void);
+typedef int fn3ijlk;
+
+void
+test_3 (void)
+{
+  fn3jilk (); /* { dg-warning "3: implicit declaration of function .fn3jilk.; 
did you mean .fn3ijkl.?" } */
+  /* { dg-begin-multiline-output "" }
+   fn3jilk ();
+   ^~~
+   fn3ijkl
+   { dg-end-multiline-output "" } */
+}

Jakub

[C PATCH] Ignore invisible bindings for misspelling hints (PR c/71858)

[Jakub Jelinek]

Hi!

As mentioned in the PR, anticipated decls should be ignored from fuzzy
lookups, unless the corresponding decl is declared first.

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

2016-07-13  Jakub Jelinek  

PR c/71858
* c-decl.c (lookup_name_fuzzy): Ignore binding->invisible.

* gcc.dg/spellcheck-identifiers.c (snprintf): Declare.
* gcc.dg/spellcheck-identifiers-2.c: New test.
* gcc.dg/diagnostic-token-ranges.c (nanl): Declare.
* c-c++-common/attributes-1.c: Adjust dg-prune-output.

--- gcc/c/c-decl.c.jj   2016-06-24 12:59:22.0 +0200
+++ gcc/c/c-decl.c  2016-07-13 22:40:23.410658411 +0200
@@ -4021,7 +4021,7 @@ lookup_name_fuzzy (tree name, enum looku
   for (c_scope *scope = current_scope; scope; scope = scope->outer)
 for (c_binding *binding = scope->bindings; binding; binding = 
binding->prev)
   {
-   if (!binding->id)
+   if (!binding->id || binding->invisible)
  continue;
/* Don't use bindings from implicitly declared functions,
   as they were likely misspellings themselves.  */
--- gcc/testsuite/gcc.dg/spellcheck-identifiers.c.jj2016-06-24 
12:59:12.0 +0200
+++ gcc/testsuite/gcc.dg/spellcheck-identifiers.c   2016-07-14 
10:03:36.147466813 +0200
@@ -121,7 +121,7 @@ test_6 (enum foo f)
 }
 }
 
-/* Verify that we offer names of builtins as suggestions.  */
+int snprintf (char *, __SIZE_TYPE__, const char *, ...);
 
 void
 test_7 (int i, int j)
--- gcc/testsuite/gcc.dg/spellcheck-identifiers-2.c.jj  2016-07-14 
09:44:16.351537449 +0200
+++ gcc/testsuite/gcc.dg/spellcheck-identifiers-2.c 2016-07-14 
10:02:21.965426567 +0200
@@ -0,0 +1,33 @@
+/* PR c/71858 */
+/* Make sure anticipated builtins are not considered before they are declared. 
 */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-function-declaration -fdiagnostics-show-caret" } */
+
+int sscafn (const char *, const char *, ...);
+
+int
+test_1 (const char *p)
+{
+  int i;
+  return ssacnf (p, "%d", ); /* { dg-warning "10: implicit declaration of 
function .ssacnf.; did you mean .sscafn.?" } */
+  /* { dg-begin-multiline-output "" }
+   return ssacnf (p, "%d", );
+  ^~
+  sscafn
+   { dg-end-multiline-output "" } */
+}
+
+int scafn (const char *, ...);
+int scanf (const char *, ...);
+
+int
+test_2 (void)
+{
+  int i;
+  return sacnf ("%d", ); /* { dg-warning "10: implicit declaration of 
function .sacnf.; did you mean .scanf.?" } */
+  /* { dg-begin-multiline-output "" }
+   return sacnf ("%d", );
+  ^
+  scanf
+   { dg-end-multiline-output "" } */
+}
--- gcc/testsuite/gcc.dg/diagnostic-token-ranges.c.jj   2016-06-24 
12:59:12.0 +0200
+++ gcc/testsuite/gcc.dg/diagnostic-token-ranges.c  2016-07-14 
11:06:23.013803011 +0200
@@ -2,6 +2,8 @@
 
 /* Verify that various diagnostics show source code ranges.  */
 
+long double nanl (const char *);
+
 /* These ones merely use token ranges; they don't use tree ranges.  */
 
 void undeclared_identifier (void)
--- gcc/testsuite/c-c++-common/attributes-1.c.jj2016-06-23 
14:31:57.0 +0200
+++ gcc/testsuite/c-c++-common/attributes-1.c   2016-07-14 14:51:34.871006659 
+0200
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-prune-output "undeclared here \\(not in a function\\); did you mean 
.carg..|\[^\n\r\]* was not declared in this scope" } */
+/* { dg-prune-output "undeclared here \\(not in a function\\); did you mean 
.char..|\[^\n\r\]* was not declared in this scope" } */
 
 void* my_calloc(unsigned, unsigned) __attribute__((alloc_size(1,bar))); /* { 
dg-warning "outside range" } */
 void* my_realloc(void*, unsigned) __attribute__((alloc_size(bar))); /* { 
dg-warning "outside range" } */

Jakub

Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

[Segher Boessenkool]

On Thu, Jul 14, 2016 at 12:14:10PM +0930, Alan Modra wrote:
> The following has now been bootstrapped and regression tested on
> powerpc64le-linux.  OK for mainline?
> 
>   * gcc/config/rs6000/altivec.md (altivec_mov): Disparage
>   gpr alternatives.  Correct '*' placement on Y,r alternative.
>   Add '*' on operand 1 of r,r alternative.

Okay for mainline, thank you!


Segher

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[NightStrike]

On Thu, Jul 14, 2016 at 6:57 AM, Eric Gallager  wrote:
> On 7/13/16, Jeff Law  wrote:
>> On 06/27/2016 08:10 PM, Eric Gallager wrote:
>>> The last time I ran ./contrib/download_prerequisites, I already had
>>> previous symlinks set up from a previous run of the script, so `ln`
>>> followed the existing symlinks and created the new ones in the
>>> directories to which the symlinks pointed. This patch should fix that
>>> by removing the old symlinks before creating new ones. (For some
>>> reason the `-f` flag to `ln` that was already there wasn't enough for
>>> me.) Tested by running the script and ensuring that the new isl
>>> symlink pointed to the correct directory, and that there were no bad
>>> symlinks in the old isl directory. Could someone commit this trivial
>>> patch for me, or something like it? I don't have write access.
>> I'd really rather know why the "-f" flag didn't work for you.  The whole
>> point of -f is to remove the destination file first.
>>
>> Jeff
>>
>
> Reading my ln manpage, it describes the "-f" flag like this:
>
>
>  -fIf the target file already exists, then unlink it so that the
>link may occur.  (The -f option overrides any previous -i
>options.)
>
> Okay, so that seems like it should do what you say, but the manpage
> also describes a separate uppercase "-F" option:
>
>  -FIf the target file already exists and is a directory, then
>remove it so that the link may occur.  The -F option should be
>used with either -f or -i options.  If none is specified, -f is
>implied.  The -F option is a no-op unless -s option is speci-
>fied.
>
> So it seems to imply that "-f" will only remove the destination file
> if it's a regular file, while "-F" is needed if the destination file
> is a directory. The page also has this to say about "-F" later:
>
>  The -F option is FreeBSD extention and should not be used in portable
>  scripts.
>
> So this could be a BSD vs. GNU thing.

On GNU, -F means:

   -d, -F, --directory
  allow the superuser to attempt to hard link directories
(note: will probably fail due to system restrictions, even for the
superuser)

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[NightStrike]

On Wed, Jul 13, 2016 at 5:36 PM, Jeff Law  wrote:
> On 06/27/2016 08:10 PM, Eric Gallager wrote:
>>
>> The last time I ran ./contrib/download_prerequisites, I already had
>> previous symlinks set up from a previous run of the script, so `ln`
>> followed the existing symlinks and created the new ones in the
>> directories to which the symlinks pointed. This patch should fix that
>> by removing the old symlinks before creating new ones. (For some
>> reason the `-f` flag to `ln` that was already there wasn't enough for
>> me.) Tested by running the script and ensuring that the new isl
>> symlink pointed to the correct directory, and that there were no bad
>> symlinks in the old isl directory. Could someone commit this trivial
>> patch for me, or something like it? I don't have write access.
>
> I'd really rather know why the "-f" flag didn't work for you.  The whole
> point of -f is to remove the destination file first.
>
> Jeff
>

FWIW, it doesn't work for me, either:

$ mkdir d
$ ln -s d a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:48 a -> d
$ mkdir e
$ ln -sf e a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:48 a -> d

But adding the -n option does:

$ ln -sfn e a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:51 a -> e


So perhaps add -n?

Re: [PATCH, ARM 7/7] Enable atomics for ARMv8-M Mainline

[Thomas Preudhomme]

Hi Kyrill,

On Thursday 19 May 2016 17:18:29 Kyrill Tkachov wrote:
> Hi Thomas,
> 
> On 17/05/16 11:15, Thomas Preudhomme wrote:
> > Ping?
> > 
> > *** gcc/ChangeLog ***
> > 
> > 2015-12-17  Thomas Preud'homme  
> > 
> >  * config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M
> >  Mainline.
> > 
> > diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> > index
> > 347b5b0a5cc0bc1e3b5020c8124d968e76ce48a4..e154bd31b8084f9f45ad4409e7b38de6
> > 52538c51 100644
> > --- a/gcc/config/arm/arm.h
> > +++ b/gcc/config/arm/arm.h
> > @@ -266,7 +266,7 @@ extern void (*arm_lang_output_object_attributes_hook)
> > (void);
> > 
> >  || arm_arch7) && arm_arch_notm)
> >   
> >   /* Nonzero if this chip supports load-acquire and store-release.  */
> > 
> > -#define TARGET_HAVE_LDACQ  (TARGET_ARM_ARCH >= 8 && arm_arch_notm)
> > +#define TARGET_HAVE_LDACQ  (TARGET_ARM_ARCH >= 8 && TARGET_32BIT)
> 
> So this change is correct because ARMv8-M Mainline uses Thumb2
> and is therefore TARGET_32BIT.
> 
> This is ok but I'd like to see a follow up patch to enable the tests
> that exercise acquire-release instructions in the arm.exp testsuite
> for ARMv8-M Mainline so that we can be sure they get proper testsuite
> coverage.

I've respinned the patch because of the changes to atomic_loaddi output 
template in config/arm/sync.md. This patch now creates a new macro 
TARGET_HAVE_LDACQEXD to guard LDACQEXD and STLEXD instructions that are not 
available in ARMv8-M Mainline. It took advantage of the respin to also add the 
tests you were asking for.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/arm.h (TARGET_HAVE_LDACQ): Enable for ARMv8-M Mainline.
(TARGET_HAVE_LDACQD): New macro.
* config/arm/sync.md (atomic_loaddi): Use TARGET_HAVE_LDACQD rather
than TARGET_HAVE_LDACQ.
(arm_load_acquire_exclusivedi): Likewise.
(arm_store_release_exclusivedi): Likewise.


*** gcc/testsuite/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* gcc.target/arm/atomic-comp-swap-release-acquire.c: Rename into ...
* gcc.target/arm/atomic-comp-swap-release-acquire-1.c: This.
* gcc.target/arm/atomic-op-acq_rel.c: Rename into ...
* gcc.target/arm/atomic-op-acq_rel-1.c: This.
* gcc.target/arm/atomic-op-acquire.c: Rename into ...
* gcc.target/arm/atomic-op-acquire-1.c: This.
* gcc.target/arm/atomic-op-char.c: Rename into ...
* gcc.target/arm/atomic-op-char-1.c: This.
* gcc.target/arm/atomic-op-consume.c: Rename into ...
* gcc.target/arm/atomic-op-consume-1.c: This.
* gcc.target/arm/atomic-op-int.c: Rename into ...
* gcc.target/arm/atomic-op-int-1.c: This.
* gcc.target/arm/atomic-op-relaxed.c: Rename into ...
* gcc.target/arm/atomic-op-relaxed-1.c: This.
* gcc.target/arm/atomic-op-release.c: Rename into ...
* gcc.target/arm/atomic-op-release-1.c: This.
* gcc.target/arm/atomic-op-seq_cst.c: Rename into ...
* gcc.target/arm/atomic-op-seq_cst-1.c: This.
* gcc.target/arm/atomic-op-short.c: Rename into ...
* gcc.target/arm/atomic-op-short-1.c: This.
* gcc.target/arm/atomic-comp-swap-release-acquire-2.c: New test.
* gcc.target/arm/atomic-op-acq_rel-2.c: Likewise.
* gcc.target/arm/atomic-op-acquire-2.c: Likewise.
* gcc.target/arm/atomic-op-char-2.c: Likewise.
* gcc.target/arm/atomic-op-consume-2.c: Likewise.
* gcc.target/arm/atomic-op-int-2.c: Likewise.
* gcc.target/arm/atomic-op-relaxed-2.c: Likewise.
* gcc.target/arm/atomic-op-release-2.c: Likewise.
* gcc.target/arm/atomic-op-seq_cst-2.c: Likewise.
* gcc.target/arm/atomic-op-short-2.c: Likewise.


Testsuite shows no regression and atomic tests [1] are passing for ARMv8-M 
Mainline.

[1] gcc.dg/atomic*, g++.dg/ext/atomic*, gcc.target/arm/atomic*, 
gcc.target/arm/sync* and libstdc++-v3/testsuite/29_atomic/*


Best regards,

Thomasdiff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 317885cf7197b6755c4d9b5717afe61662626786..c7149d1f49738f9f01232cdcb610caca0e5f7e5d 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -261,7 +261,12 @@ extern void (*arm_lang_output_object_attributes_hook)(void);
 			 || arm_arch7) && arm_arch_notm)
 
 /* Nonzero if this chip supports load-acquire and store-release.  */
-#define TARGET_HAVE_LDACQ	(TARGET_ARM_ARCH >= 8 && arm_arch_notm)
+#define TARGET_HAVE_LDACQ	(TARGET_ARM_ARCH >= 8 && TARGET_32BIT)
+
+/* Nonzero if this chip supports LDAEXD and STLEXD.  */
+#define TARGET_HAVE_LDACQEXD	(TARGET_ARM_ARCH >= 8	\
+ && TARGET_32BIT	\
+ && arm_arch_notm)
 
 /* Nonzero if this chip provides the MOVW and MOVT instructions.  */
 #define TARGET_HAVE_MOVT	(arm_arch_thumb2 || arm_arch8)
diff --git 

Re: [PATCH][vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant

[Rainer Orth]

Hi Richard,

> On Thu, 14 Jul 2016, Kyrill Tkachov wrote:
>
>> Hi all,
>> 
>> On 07/07/16 17:16, Kyrill Tkachov wrote:
>> > 
>> > On 06/07/16 13:40, Kyrill Tkachov wrote:
>> > > 
>> > > On 06/07/16 13:31, Rainer Orth wrote:
>> > > > Hi Kyrill,
>> > > > 
>> > > > > On 05/07/16 12:24, Rainer Orth wrote:
>> > > > > > Marc Glisse  writes:
>> > > > > > 
>> > > > > > > On Tue, 5 Jul 2016, Kyrill Tkachov wrote:
>> > > > > > > 
>> > > > > > > > As for testing I've bootstrapped and tested the patch on 
>> > > > > > > > aarch64
>> > > > > > > > and
>> > > > > > > > x86_64 with synth_shift_p in vect_synth_mult_by_constant hacked
>> > > > > > > > to be
>> > > > > > > > always true to exercise the paths that synthesize the shift by
>> > > > > > > > additions. Marc, could you test this on the sparc targets you
>> > > > > > > > care about?
>> > > > > > > I don't have access to Sparc, you want Rainer here (added in 
>> > > > > > > Cc:).
>> > > > > > As is, the patch doesn't even build on current mainline:
>> > > > > > 
>> > > > > > /vol/gcc/src/hg/trunk/local/gcc/tree-vect-patterns.c:2151:56: 
>> > > > > > error:
>> > > > > > 'mult_variant' has not been declared
>> > > > > >target_supports_mult_synth_alg (struct algorithm *alg,
>> > > > > > mult_variant var,
>> > > > > > ^
>> > > > > > 
>> > > > > > enum mult_variant is only declared in expmed.c.
>> > > > > Ah, sorry I forgot to mention that this is patch 2/2.
>> > > > > It requires https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01144.html
>> > > > > which
>> > > > > is already approved
>> > > > > but I was planning to commit it together with this one.
>> > > > > Can you please try applying
>> > > > > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01144.html
>> > > > > as well as this?
>> > > > sure, that did the trick.  A sparc-sun-solaris2.12 bootstrap revealed
>> > > > that the patch fixes PR tree-optimization/70923 (you should mention 
>> > > > that
>> > > > in the ChangeLog or close it as a duplicate), with the same caveat as
>> > > > about Marc's latest patch for that:
>> > > 
>> > > Thanks! Much appreciated.
>> > > 
>> > > > +FAIL: gcc.dg/vect/vect-iv-9.c -flto -ffat-lto-objects
>> > > > scan-tree-dump-times vect "vectorized 1 loops" 1
>> > > > +FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect "vectorized 1
>> > > > loops" 1
>> > > > 
>> > > > The message appears twice, not once, on sparc, so the testcase should 
>> > > > be
>> > > > updated to accomodate that.
>> > > 
>> > > Ok.
>> > > 
>> > > > Besides, the new testcase FAILs:
>> > > > 
>> > > > +FAIL: gcc.dg/vect/pr65951.c -flto -ffat-lto-objects
>> > > > scan-tree-dump-times vect "vectorized 1 loops" 2
>> > > > +FAIL: gcc.dg/vect/pr65951.c scan-tree-dump-times vect "vectorized 1
>> > > > loops" 2
>> > > > 
>> > > > The dump contains
>> > > > 
>> > > > gcc.dg/vect/pr65951.c:14:3: note: not vectorized: no vectype for stmt:
>> > > > _4 = *_3;
>> > > > gcc.dg/vect/pr65951.c:12:1: note: vectorized 0 loops in function.
>> > > > gcc.dg/vect/pr65951.c:21:3: note: not vectorized: no vectype for stmt:
>> > > > _4 = *_3;
>> > > > gcc.dg/vect/pr65951.c:19:1: note: vectorized 0 loops in function.
>> > > > gcc.dg/vect/pr65951.c:55:15: note: not vectorized: control flow in 
>> > > > loop.
>> > > > gcc.dg/vect/pr65951.c:46:3: note: not vectorized: loop contains 
>> > > > function
>> > > > calls or data references that cannot be analyzed
>> > > > gcc.dg/vect/pr65951.c:41:15: note: not vectorized: control flow in 
>> > > > loop.
>> > > > gcc.dg/vect/pr65951.c:32:3: note: not vectorized: loop contains 
>> > > > function
>> > > > calls or data references that cannot be analyzed
>> > > > gcc.dg/vect/pr65951.c:26:1: note: vectorized 0 loops in function.
>> > > 
>> > > I see. I suppose SPARC doesn't have vector shifts operating on 64-bit
>> > > data?
>> > > I believe the testcase should be updated to use just "int" arrays rather
>> > > than "long long".
>> > > 
>> > > I'll respin the testcases
>> > 
>> > Ok, here's the patch with pr65951.c updated to use int rather than long 
>> > long
>> > arrays and vect-iv-9.c updated to scan for the
>> > "Vectorized 1 loops" string twice. I've verified by hand by building a
>> > sparc-sun-solaris2.10 cc1 that compiling with
>> > -mcpu=ultrasparc -mvis gives the right strings in the vectoriser dump.
>> > 
>> > So is this version ok?
>> > 
>> 
>> So richi was ok with the implementation part of the patch [1]
>> Are the testuite changes made since ok?
>> 
>> [1] https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00177.html
>> [2] https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00331.html
>
> Ok with me - I wondered if Rainer wanted to double-check.

I just ran a sparc-sun-solaris2.12 bootstrap with the patch(es) applied
and results look good: the remaining failures are unrelated and have
already been reported separately.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld 

Re: [PATCH] disable IPA-cp cloning for functions with target_clones attribute

[Martin Jambor]

Hi Jeff,

On Wed, Jul 13, 2016 at 08:46:35AM -0600, Jeff Law wrote:
> On 07/12/2016 03:31 AM, Martin Jambor wrote:
> > Hi,
> > 
> > On Fri, Jun 24, 2016 at 01:41:05PM -0700, Evgeny Stupachenko wrote:
> > > Hi,
> > > 
> > > Fix ICE when IPA-cp and target_clones are applied to the same function.
> > > Is the patch ok for trunk?
> > 
> > I can't approve anything but since I wrote most of IPA-CP, it may
> > count that I am fine with the patch.
> Martin, we can probably change that ;-)  Interested?

I have briefly discussed this with Honza and yes, I would be
interested in maintaining IPA-CP (which in practice comes down to
ipa-prop.[ch] and ipa-cp.c files now).

Even in that position I would coordinate closely with Honza whenever
it would come to more substantial changes.

Thanks for considering me for the maintainership,

Martin

Re: [PATCH, GCC/LRA] Teach LRA to not use same register value for multiple output operands of an insn

[Thomas Preudhomme]

On Thursday 14 July 2016 10:32:48 Thomas Preudhomme wrote:
> On Friday 08 July 2016 09:05:55 Mike Stump wrote:
> > On Jul 8, 2016, at 8:07 AM, Thomas Preudhomme
> 
>  wrote:
> > > While investigating the root cause a testsuite regression for the
> > > ARM/embedded-5-branch GCC in gcc.dg/vect/slp-perm-5.c, we found that the
> > > bug seems to also affect trunk.
> > 
> > Hum...  If in 6.x, and safe to back port to 6, a back port would be
> > nice...
> > I use LRA in 6.x, and seems like I'd be susceptible to this sort of thing,
> > but, I didn't test it.
> 
> It should affect 6.x as well yes since there is no special protection
> against it in the code being modified. However I only ever managed to
> reproduce this on the ARM/embedded-5-branch.

I've created PR71878 for this problem with more details on how to reproduce 
the issue. it only requires to backport a single commit to gcc-5-branch, build 
gcc for arm-none-eabi (make all-gcc is enough) and compile the testcase 
attached in the PR with the given options.

Please let me know if you need any more details.

Best regards,

Thomas

[PATCH] Fix PR71866

[Richard Biener]

The following fixes PR71866 and also includes some cleanup starting to
address the issue at a different level (we want to insert a & -1
as we didn't manage to simplify that during phi-translation - but
during insertion we _do_ simplify it and end up inserting nothing
but still report "progress", so we repeat that again and again).

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2016-07-14  Richard Biener  

PR tree-optimization/71866
* tree-ssa-pre.c (get_constant_for_value_id): Remove.
(do_hoist_insertion): Avoid endless recursion when we
didn't insert anything because we managed to simplify
things down to a constant or SSA name.
(fully_constant_expression): Re-write in terms of ...
* tree-ssa-sccvn.h (vn_nary_simplify): ... this.  Declare.
* tree-ssa-sccvn.c (vn_nary_simplify): New wrapper around
vn_nary_build_or_lookup_1.
(vn_nary_build_or_lookup_1): Added flag and renamed from ...
(vn_nary_build_or_lookup): ... this which now wraps it.

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

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 238287)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -1164,29 +1164,6 @@ get_or_alloc_expr_for_constant (tree con
   return newexpr;
 }
 
-/* Given a value id V, find the actual tree representing the constant
-   value if there is one, and return it. Return NULL if we can't find
-   a constant.  */
-
-static tree
-get_constant_for_value_id (unsigned int v)
-{
-  if (value_id_constant_p (v))
-{
-  unsigned int i;
-  bitmap_iterator bi;
-  bitmap exprset = value_expressions[v];
-
-  EXECUTE_IF_SET_IN_BITMAP (exprset, 0, i, bi)
-   {
- pre_expr expr = expression_for_id (i);
- if (expr->kind == CONSTANT)
-   return PRE_EXPR_CONSTANT (expr);
-   }
-}
-  return NULL;
-}
-
 /* Get or allocate a pre_expr for a piece of GIMPLE, and return it.
Currently only supports constants and SSA_NAMES.  */
 static pre_expr
@@ -1236,76 +1213,16 @@ fully_constant_expression (pre_expr e)
 case NARY:
   {
vn_nary_op_t nary = PRE_EXPR_NARY (e);
-   switch (TREE_CODE_CLASS (nary->opcode))
- {
- case tcc_binary:
- case tcc_comparison:
-   {
- /* We have to go from trees to pre exprs to value ids to
-constants.  */
- tree naryop0 = nary->op[0];
- tree naryop1 = nary->op[1];
- tree result;
- if (!is_gimple_min_invariant (naryop0))
-   {
- pre_expr rep0 = get_or_alloc_expr_for (naryop0);
- unsigned int vrep0 = get_expr_value_id (rep0);
- tree const0 = get_constant_for_value_id (vrep0);
- if (const0)
-   naryop0 = fold_convert (TREE_TYPE (naryop0), const0);
-   }
- if (!is_gimple_min_invariant (naryop1))
-   {
- pre_expr rep1 = get_or_alloc_expr_for (naryop1);
- unsigned int vrep1 = get_expr_value_id (rep1);
- tree const1 = get_constant_for_value_id (vrep1);
- if (const1)
-   naryop1 = fold_convert (TREE_TYPE (naryop1), const1);
-   }
- result = fold_binary (nary->opcode, nary->type,
-   naryop0, naryop1);
- if (result && is_gimple_min_invariant (result))
-   return get_or_alloc_expr_for_constant (result);
- /* We might have simplified the expression to a
-SSA_NAME for example from x_1 * 1.  But we cannot
-insert a PHI for x_1 unconditionally as x_1 might
-not be available readily.  */
- return e;
-   }
- case tcc_reference:
-   if (nary->opcode != REALPART_EXPR
-   && nary->opcode != IMAGPART_EXPR
-   && nary->opcode != VIEW_CONVERT_EXPR)
- return e;
-   /* Fallthrough.  */
- case tcc_unary:
-   {
- /* We have to go from trees to pre exprs to value ids to
-constants.  */
- tree naryop0 = nary->op[0];
- tree const0, result;
- if (is_gimple_min_invariant (naryop0))
-   const0 = naryop0;
- else
-   {
- pre_expr rep0 = get_or_alloc_expr_for (naryop0);
- unsigned int vrep0 = get_expr_value_id (rep0);
- const0 = get_constant_for_value_id (vrep0);
-   }
- result = NULL;
- if (const0)
-   {
- tree type1 = TREE_TYPE (nary->op[0]);
- const0 = fold_convert (type1, const0);
- result = fold_unary (nary->opcode, nary->type, const0);
-

Re: [patch,avr] minor tweaks for 8-bit operations

[Georg-Johann Lay]

On 14.07.2016 05:55, Senthil Kumar Selvaraj wrote:


Georg-Johann Lay writes:


This patch contains some unrelated tweaks

[...]

- Some patterns that match situations with zero_extend that can be performed
with less instructions / register pressure.


From my (admittedly limited) attempts at code size benchmarking, this
one will help a lot I think, considering ints are used everywhere and
they end up always taking 2 regs, even when one would do. Do you have any 
numbers on the code size improvement this provides?

Regards
Senthil



No, I usually propose such patches when I am coming across respective situation 
in generated asm or in a dump file and it's clear that the change won't reduce 
performance loss in other places.  My expectations on the overall gains are 
low, in particular if some subreg-lowering already split from one HI to two QI 
so that there is no zero_extend any more that could be caught.


For the QImoe plus, and, ior with const_int it might pay to add a "d" clobber 
if the register ends up in "l" regs.  The compiler sometimes reloads the whole 
stuff into d-regs, i.e. instead of


  LDI R20, -42
  ADD R10, R20

we get

  MOV R20, R10
  ADD R20, -42
  MOV R10, R20

I even came across situations where reload reloads the const_int to a "l" 
register which might cost up to 4 instructions for the constant alone!


Johann




- comparing HI against -1

Ok for trunk?

Johann


gcc/
Minor tweaks for QImode.

* config/avr/predicates.md (const_m255_to_m1_operand): New.
* config/avr/constraints.md (Cn8, Ca1, Co1, Yx2): New constraints.
* config/avr/avr.md (add3) : Make "r,0,r" more
expensive.
(*cmphi.zero-extend.0, *cmphi.zero-extend.1)
(*usum_widenqihi3, *udiff_widenqihi3)
(*addhi3_zero_extend.const): New combiner insns.
(andqi3, iorqi3): Provide "l" (NO_LD_REGS) alternative if
just 1 bit is affected.
* config/avr/avr.c (avr_out_bitop) : Don't access xop[3].
(avr_out_compare) [EQ,NE]: Tweak comparing d-regs against -1.

Re: [Ada] Another small tweak in LTO mode

[Jan Hubicka]

> This change makes it so that gigi uses a generic pointer type (ptr_type_node) 
> for pointers to Taft Amendment types, which are kind of opaque pointer types.
> 
> Tested on x86_64-suse-linux, applied on the mainline.
> 
> However, this isn't sufficient for LTO's type canonical merging code, because 
> the generic pointer type is the element type of an array instead of being 
> used 
> at top level, so the code issues the usual warning:
> 
> /home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.ads:7:13: warning: type of 
> 'lto19_pkg__proc' does not match original declaration [-Wlto-type-mismatch]
> /home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.adb:7:3: note: 
> 'lto19_pkg__proc' was previously declared here
> /home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.adb:7:3: note: code may be 
> misoptimized unless -fno-strict-aliasing is used
> 
> Jan, any idea on how to address this?

I am not quite sure I understand your explanation.  Can you, please, show me
how the types differ? So you have one type which contains ptr_type_node and
other which is array?

Honza

Re: [patch] Fix type merging deficiency during WPA

[Richard Biener]

On Wed, Jul 13, 2016 at 3:16 PM, Eric Botcazou  wrote:
>> As tree merging really replaces trees it has to error on the side of not
>> merging while canonical type merging has to error on the side of "merging"
>> to make types alias.
>
> OK, then the former won't be sufficient for Ada, there are known cases where
> producers and clients of a package cannot see the exact same tree for a type,
> so we definitely need optimistic merging here.

Yeah, as said such optimistic merging would need to happen during canoncial type
merging for example by completely ignoring TYPE_DOMAIN or DECL_FIELD_OFFSET ...
(a non-constant in one unit may be the same as a constant in another...).

But merging more trees is also good - though in this case I tend to
favor the approach
to have symbols merged first and only the prevailing 'tree' survive.

>> Btw, for the LTO_SET_PREVAIL can you introduce a LTO_SET_PREVAIL_EXPR
>> and use that for the fields that possibly can be expressions plus simply use
>> walk_tree for those (in case they are EXPR_P)?  Please split that part out
>> as well.
>
> Yes, I can do that.

Thanks.

> --
> Eric Botcazou

Re: [PATCH] Lift alignment restrictions from inlining register size memcpy

[Richard Biener]

On Thu, 14 Jul 2016, Georg-Johann Lay wrote:

> On 12.07.2016 11:38, Richard Biener wrote:
> > 
> > The following patch does $subject which is requested in a comment in
> > PR50417 as this restriction defeats the purpose of having memcpy
> > as a portable and efficient way to circumvent strict-aliasing violations
> > (or even as a portable and efficient way to do unaligned loads).
> 
> IIUC the original purpose of the PR is a complaint about execution performance
> in situations like, say, memcpy (int*, int*, 0x1000).
> 
> GCC 4.5 used int-wide chunks in movmem even if no alignment could be inferred
> from symbols like in
> 
> static int a[..], b[..];
> memcpy (a, b, 0x1000)
> 
> The more I think about it the more I tend to not changing the current
> behaviour, be conservative and treat memcpy like a function.
> 
> If the alignment is deduced from the pointer type, then this is clearly not
> what the standard says as you already pointed out in the PR.
> 
> Hence, if we want such an "optimization" it should be optional by means of a
> respective command option so that the user can explicitly request this ABI
> change for memcpy.

Yes, as said the patch wasn't for the original issue in the PR but
for the comment complaining about not expanding memcpy inline on 
GIMPLE.

The patch will make the misaligned access explicit (unless the compiler
is later able to prove otherwise).

> > Bootstrap / regtest running on x86_64-unknown-linux-gnu (quite pointless
> > as there is no change on that arch).
> > 
> > I have added a testcase that should exercise most relevant cases so
> > we can look for fallout on "interesting" targets.
> > 
> > Boostrap / regtest on strict-alignment platforms welcome.
> > 
> > I do expect that with -Os expanding unaligned-unaligned moves
> > might be a size pessimization compared to a libcall (or what
> > the targets block move expander does).  But the whole point is
> > to remove abstraction penalty so it isn't an easy stmt-local
> > decision to make.  Comments on this front welcome as well.
> > 
> > Unless I hear some positives I'll let the patch sit here as I
> > don't really care too much about those pesky targets (and
> > targets can choose to opt-in by providing movmisalign optabs
> > anyway so they don't go the store/extract_bit_field path).
> 
> As I said, my doubts are increasing...
> 
> If movmem sees no alignment (where 4.5 passed a bigger alignment) then it
> could just FAIL and assume that libcall provides a fast implementation.  This
> means inquiring the alignment at runtime and adding noticeable penalty for
> small number of byte...  but well, we have to love with that I think

Yes, and the patch addresses this by always expanding memcpy to
a load, store pair (the target specifices the largest quantity via 
MOVE_MAX, usually word_mode size but x86_64 for example allows
moves via xmm registers as well).

> ... and if it was secured by an option, -fstrict-align[ment] would be really
> confusing (to gcc people at least) and also to the users of back-ends that
> support -mstrict-align[ment].

Agreed, but as said, the patch is completely separate from the issue
in the PR (so it doesn't reference it either).

Richard.

> 
> Johann
> 
> 
> > Thanks,
> > Richard.
> > 
> > 2016-07-12  Richard Biener  
> > 
> > * gimple-fold.c (gimple_fold_builtin_memory_op): Lift alignment
> > restrictions from inlining register size memcpy.
> > 
> > * gcc.dg/torture/builtin-memcpy.c: New testcase.
> > 
> > Index: gcc/gimple-fold.c
> > ===
> > *** gcc/gimple-fold.c   (revision 238237)
> > --- gcc/gimple-fold.c   (working copy)
> > *** gimple_fold_builtin_memory_op (gimple_st
> > *** 705,718 
> >   if (type
> >   && TYPE_MODE (type) != BLKmode
> >   && (GET_MODE_SIZE (TYPE_MODE (type)) * BITS_PER_UNIT
> > ! == ilen * 8)
> > ! /* If the destination pointer is not aligned we must be able
> > !to emit an unaligned store.  */
> > ! && (dest_align >= GET_MODE_ALIGNMENT (TYPE_MODE (type))
> > ! || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), dest_align)
> > ! || (optab_handler (movmisalign_optab, TYPE_MODE (type))
> > ! != CODE_FOR_nothing)))
> > {
> >   tree srctype = type;
> >   tree desttype = type;
> >   if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type)))
> > --- 705,718 
> >   if (type
> >   && TYPE_MODE (type) != BLKmode
> >   && (GET_MODE_SIZE (TYPE_MODE (type)) * BITS_PER_UNIT
> > ! == ilen * 8))
> > {
> > + /* RTL expansion handles misaligned destination / source
> > +MEM_REFs either via target provided movmisalign or
> > +via extract/store_bit_field for targets that set
> > +   

Re: [PATCH] Lift alignment restrictions from inlining register size memcpy

[Georg-Johann Lay]

On 12.07.2016 11:38, Richard Biener wrote:


The following patch does $subject which is requested in a comment in
PR50417 as this restriction defeats the purpose of having memcpy
as a portable and efficient way to circumvent strict-aliasing violations
(or even as a portable and efficient way to do unaligned loads).


IIUC the original purpose of the PR is a complaint about execution performance 
in situations like, say, memcpy (int*, int*, 0x1000).


GCC 4.5 used int-wide chunks in movmem even if no alignment could be inferred 
from symbols like in


static int a[..], b[..];
memcpy (a, b, 0x1000)

The more I think about it the more I tend to not changing the current 
behaviour, be conservative and treat memcpy like a function.


If the alignment is deduced from the pointer type, then this is clearly not 
what the standard says as you already pointed out in the PR.


Hence, if we want such an "optimization" it should be optional by means of a 
respective command option so that the user can explicitly request this ABI 
change for memcpy.



Bootstrap / regtest running on x86_64-unknown-linux-gnu (quite pointless
as there is no change on that arch).

I have added a testcase that should exercise most relevant cases so
we can look for fallout on "interesting" targets.

Boostrap / regtest on strict-alignment platforms welcome.

I do expect that with -Os expanding unaligned-unaligned moves
might be a size pessimization compared to a libcall (or what
the targets block move expander does).  But the whole point is
to remove abstraction penalty so it isn't an easy stmt-local
decision to make.  Comments on this front welcome as well.

Unless I hear some positives I'll let the patch sit here as I
don't really care too much about those pesky targets (and
targets can choose to opt-in by providing movmisalign optabs
anyway so they don't go the store/extract_bit_field path).


As I said, my doubts are increasing...

If movmem sees no alignment (where 4.5 passed a bigger alignment) then it could 
just FAIL and assume that libcall provides a fast implementation.  This means 
inquiring the alignment at runtime and adding noticeable penalty for small 
number of byte...  but well, we have to love with that I think


... and if it was secured by an option, -fstrict-align[ment] would be really 
confusing (to gcc people at least) and also to the users of back-ends that 
support -mstrict-align[ment].



Johann



Thanks,
Richard.

2016-07-12  Richard Biener  

* gimple-fold.c (gimple_fold_builtin_memory_op): Lift alignment
restrictions from inlining register size memcpy.

* gcc.dg/torture/builtin-memcpy.c: New testcase.

Index: gcc/gimple-fold.c
===
*** gcc/gimple-fold.c   (revision 238237)
--- gcc/gimple-fold.c   (working copy)
*** gimple_fold_builtin_memory_op (gimple_st
*** 705,718 
  if (type
  && TYPE_MODE (type) != BLKmode
  && (GET_MODE_SIZE (TYPE_MODE (type)) * BITS_PER_UNIT
! == ilen * 8)
! /* If the destination pointer is not aligned we must be able
!to emit an unaligned store.  */
! && (dest_align >= GET_MODE_ALIGNMENT (TYPE_MODE (type))
! || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), dest_align)
! || (optab_handler (movmisalign_optab, TYPE_MODE (type))
! != CODE_FOR_nothing)))
{
  tree srctype = type;
  tree desttype = type;
  if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type)))
--- 705,718 
  if (type
  && TYPE_MODE (type) != BLKmode
  && (GET_MODE_SIZE (TYPE_MODE (type)) * BITS_PER_UNIT
! == ilen * 8))
{
+ /* RTL expansion handles misaligned destination / source
+MEM_REFs either via target provided movmisalign or
+via extract/store_bit_field for targets that set
+SLOW_UNALIGNED_ACCESS for the move.  For move
+quantities up to MOVE_MAX this should be always
+more efficient than a libcall to memcpy.  */
  tree srctype = type;
  tree desttype = type;
  if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type)))
*** gimple_fold_builtin_memory_op (gimple_st
*** 721,767 
  tree tem = fold_const_aggregate_ref (srcmem);
  if (tem)
srcmem = tem;
! else if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type))
!  && SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
!src_align)
!  && (optab_handler (movmisalign_optab,
!  

Re: [PATCH GCC]Improve loop-niter to handle possible infinite loop.

[Richard Biener]

On Wed, Jul 13, 2016 at 6:09 PM, Bin.Cheng  wrote:
> On Fri, Jul 1, 2016 at 11:33 AM, Richard Biener
>  wrote:
>> On Tue, Jun 28, 2016 at 8:18 AM, Bin Cheng  wrote:
>>> Hi,
>>> At the moment, loop niter analyzer depends on simple_iv to understand 
>>> control induction variable in order to do further niter analysis.  For 
>>> cases reported in PR57558 (comment #4), the control variable is not an SCEV 
>>> because it's converted from an smaller type and that type could 
>>> overflow/wrap.  As a result, niter information for such loops won't be 
>>> analyzed because number_of_iterations_exit exits immediately once simple_iv 
>>> fails.  As a matter of fact, niter analyzer can be improved by computing an 
>>> additional assumption under which the loop won't be infinite (or the 
>>> corresponding iv doesn't overflow).  This patch does so by changing both 
>>> scev and niter analyzer.  It introduces a new interface 
>>> simple_iv_with_niters which is used in niter analyzer.  The new interface 
>>> returns an IV as well as a possible niter expression, the expression 
>>> indicates the maximum number the IV can iterate before the returned 
>>> simple_iv becoming invalid.  Given below example:
>>>
>>>   short unsigned int i;
>>>   int _1;
>>>
>>>   :
>>>   goto ;
>>>
>>>   :
>>>   arr[_1] = -1;
>>>   i_6 = i_2 + 1;
>>>
>>>   :
>>>   # i_2 = PHI <1(2), i_6(3)>
>>>   _1 = (int) i_2;
>>>   if (_1 != 199)
>>> goto ;
>>>   else
>>> goto ;
>>>
>>>   :
>>>   return;
>>>
>>> When analyzing variable "_1", the old interface simple_iv returns false, 
>>> while the new interface returns <{1, 1}_loop, 65534>.  It means "_1" is a 
>>> valid SCEV as long as it doesn't iterate more than 65534 times.
>>> This patch also introduces a new interface in niter analyzer 
>>> number_of_iterations_exit_assumptions.  The new interface further derives 
>>> assumption from the result of simple_iv_with_niters, and the assumption can 
>>> be used by other optimizers.  As for this loop, it's an unexpected gain 
>>> because assumption (198 < 65534) is naturally TRUE.
>>> For loops that could be infinite, the assumption will be an expression.  
>>> This improvement is still good, for example, the next patch to will 
>>> vectorize such loops with help of this patch.
>>>
>>> This patch also changes how assumptions is handled in niter analyzer.  At 
>>> the moment, (non-true) assumptions are not supported unless 
>>> -funsafe-loop-optimizations are specified, after this patch, the new 
>>> interface exposes assumptions to niter user and let them make their own 
>>> decision.  In effect, this patch discards -funsafe-loop-optimizations on 
>>> GIMPLE level, which we think is not a very useful option anyway.  Next 
>>> patch will xfails tests for this option.  Well, the option is not totally 
>>> discarded because it requires RTL changes too.  I will follow up that after 
>>> gimple part change.
>>>
>>> Bootstrap and test on x86_64 and AArch64.  Is it OK?
>>
>> Please make simple_iv_with_niters accept NULL as iv_niters and pass
>> NULL from simple_iv to avoid useless work.
>>
>> You have chosen to make the flags per loop instead of say, flags on
>> the global loop state.  The patch itself doesn't set the flag
>> on any loop thus it doesn't really belong into this patch IMHO, so
>> maybe you can split it out.  We do already have a plethora
>> of "flags" (badly packed) in struct loop and while I see the interface
>> is sth very specific adding another 4 bytes doesn't look
>> too nice here (but maybe we don't care, struct loop isn't allocated
>> that much hopefully).  I'd like to see a better comment
>> before the flags part in cfgloop.h though noting that those are not
>> flags computed by the compiler but flags that are set
>> by the consumer that affect semantics of certain (document which)
>> APIs.  And that consumers are expected to re-set
>> flags back!  (failing to do that might be a source of hard to track down 
>> bugs?)
>>
>> Anyway, the _assumtions part of the patch is ok with the suggested change.
>>
> Hi Richard,
> According to your suggestion, I split the original patch into two, and
> this is the first part.  It improves scalar evolution and loop niter
> analyzer so that (possible) infinite loop can be handled.  As a bonus
> point, it also picks up normal loops which were missed before, for
> example, loop in the added test.
>
> Bootstrap and test on x86_64 ongoing, Is it OK?

Ok.

Thanks,
Richard.

> Thanks,
> bin
>
> 2016-07-13  Bin Cheng  
>
> * tree-scalar-evolution.c (simple_iv_with_niters): New funcion.
> (derive_simple_iv_with_niters): New function.
> (simple_iv): Rewrite using simple_iv_with_niters.
> * tree-scalar-evolution.h (simple_iv_with_niters): New decl.
> * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions): New
> function.
> (number_of_iterations_exit): Rewrite using above function.
> 

Re: [PATCH] Amend dump expectation in slsr-8.c (PR, tree-optimization/71490)

[Richard Biener]

On Thu, Jul 14, 2016 at 1:06 PM, Martin Liška  wrote:
> On 07/13/2016 07:21 PM, Jeff Law wrote:
>> Isn't that a code quality regression?  So instead shouldn't we be keeping 
>> the same expectation, but xfailing the test?
>>
>> jeff
>
> Hello.
>
> Disabling a pass before slsr makes the test to catch both opportunities.
> Is the patch fine?

No, this is still a code quality regression.  What happens is that for
some reason we fail to sink for GCC 6.

Richard.

> Thanks,
> Martin

[Ada] Another small tweak in LTO mode

[Eric Botcazou]

This change makes it so that gigi uses a generic pointer type (ptr_type_node) 
for pointers to Taft Amendment types, which are kind of opaque pointer types.

Tested on x86_64-suse-linux, applied on the mainline.

However, this isn't sufficient for LTO's type canonical merging code, because 
the generic pointer type is the element type of an array instead of being used 
at top level, so the code issues the usual warning:

/home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.ads:7:13: warning: type of 
'lto19_pkg__proc' does not match original declaration [-Wlto-type-mismatch]
/home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.adb:7:3: note: 
'lto19_pkg__proc' was previously declared here
/home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto19_pkg.adb:7:3: note: code may be 
misoptimized unless -fno-strict-aliasing is used

Jan, any idea on how to address this?


2016-07-14  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : Also use
the void pointer type if the designated type is incomplete and has no
full view in LTO mode.
: Adjust comment.
: Likewise.
* gcc-interface/trans.c (Call_to_gnu): Do not convert to the type of
the actual if it is a dummy type.


2016-07-14  Eric Botcazou  

* gnat.dg/lto19.adb: New test.
* gnat.dg/lto19_pkg.ad[sb]: New helper.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 238237)
+++ gcc-interface/decl.c	(working copy)
@@ -3928,10 +3928,19 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  }
 
 	/* If expansion is disabled, the equivalent type of a concurrent type
-	   is absent, so build a dummy pointer type.  */
+	   is absent, so we use the void pointer type.  */
 	else if (type_annotate_only && No (gnat_desig_equiv))
 	  gnu_type = ptr_type_node;
 
+	/* If the ultimately designated type is an incomplete type with no full
+	   view, we use the void pointer type in LTO mode to avoid emitting a
+	   dummy type in the GIMPLE IR.  We cannot do that in regular mode as
+	   the name of the dummy type in used by GDB for a global lookup.  */
+	else if (Ekind (gnat_desig_rep) == E_Incomplete_Type
+		 && No (Full_View (gnat_desig_rep))
+		 && flag_generate_lto)
+	  gnu_type = ptr_type_node;
+
 	/* Finally, handle the default case where we can just elaborate our
 	   designated type.  */
 	else
@@ -4017,7 +4026,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 case E_Access_Protected_Subprogram_Type:
 case E_Anonymous_Access_Protected_Subprogram_Type:
   /* If we are just annotating types and have no equivalent record type,
-	 just return ptr_void_type.  */
+	 just use the void pointer type.  */
   if (type_annotate_only && gnat_equiv_type == gnat_entity)
 	gnu_type = ptr_type_node;
 
@@ -4336,8 +4345,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 		: Empty;
 
 	/* If this is an incomplete type with no full view, it must be a Taft
-	   Amendment type, in which case we return a dummy type.  Otherwise,
-	   just get the type from its Etype.  */
+	   Amendment type or an incomplete type coming from a limited context,
+	   in which cases we return a dummy type.  Otherwise, we just get the
+	   type from its Etype.  */
 	if (No (full_view))
 	  {
 	if (kind == E_Incomplete_Type)
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 238237)
+++ gcc-interface/trans.c	(working copy)
@@ -4374,7 +4374,6 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
   Node_Id gnat_name = suppress_type_conversion
 			  ? Expression (gnat_actual) : gnat_actual;
   tree gnu_name = gnat_to_gnu (gnat_name), gnu_name_type;
-  tree gnu_actual;
 
   /* If it's possible we may need to use this expression twice, make sure
 	 that any side-effects are handled via SAVE_EXPRs; likewise if we need
@@ -4504,7 +4503,7 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
 	}
 
   /* Start from the real object and build the actual.  */
-  gnu_actual = gnu_name;
+  tree gnu_actual = gnu_name;
 
   /* If atomic access is required for an In or In Out actual parameter,
 	 build the atomic load.  */
@@ -4524,15 +4523,18 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
   /* Put back the conversion we suppressed above in the computation of the
 	 real object.  And even if we didn't suppress any conversion there, we
 	 may have suppressed a conversion to the Etype of the actual earlier,
-	 since the parent is a procedure call, so put it back here.  */
-  if (suppress_type_conversion
-	  && Nkind (gnat_actual) == N_Unchecked_Type_Conversion)
-	gnu_actual
-	  = unchecked_convert (gnat_to_gnu_type (Etype (gnat_actual)),
-			   gnu_actual, No_Truncation (gnat_actual));
+	 since the parent is a procedure call, so put it back here.  Note that
+	 we might have a dummy type here if the actual is the 

Re: [PATCH] Lift alignment restrictions from inlining register size memcpy

[Richard Biener]

On Thu, 14 Jul 2016, Eric Botcazou wrote:

> > Boostrap / regtest on strict-alignment platforms welcome.
> 
> Bootstrap/regtest on SPARC/Solaris is OK, modulo:
> 
> XPASS: gcc.dg/memmove-4.c scan-tree-dump-not optimized "memmove"
> FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen (" 0
> FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "memcpy (" 4
> 
> for both 32-bit and 64-bit.
> 
> > Unless I hear some positives I'll let the patch sit here as I
> > don't really care too much about those pesky targets (and
> > targets can choose to opt-in by providing movmisalign optabs
> > anyway so they don't go the store/extract_bit_field path).
> 
> The patch is a step forward but it doesn't fully solve the problem:
> 
> #include 
> #include 
> 
> uint32_t foo_noalign(const uint32_t *s) {
>   uint32_t v;
>   memcpy(, s, sizeof(v));
>   return v;
> }
> 
> uint32_t foo(const uint32_t *s) {
>   uint32_t v;
>   memcpy(, __builtin_assume_aligned(s, 4), sizeof(v));
>   return v;
> }
> 
> As discussed in the audit trail, the compiler ought to generate again 
> the same code on strict-alignment targets in both cases, as Clang 
> apparently and as GCC itself during most of its existence (until GCC 4.5 
> to be precise).

The patch wasn't supposed to address this issue.  It was supposed
to address the fact that the memcpy call is not optimized away
on strict-align targets 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417#c16).

I've commented on the original issue in that PR extensively (on what
is possible and what not within the constraints of the middle-end).
Iff alignment according to the pointer type passed to memory
functions is important the FEs need to extract said information
before it gets lost (and before casting it to the prototypes argument
type).

Richard.

Re: [PATCH 2/3] Run profile feedback tests with autofdo

[Bin.Cheng]

On Thu, Jul 14, 2016 at 12:06 PM, Bin.Cheng  wrote:
> On Thu, Jul 14, 2016 at 11:55 AM, Andi Kleen  wrote:
>>> After this patch, I got below test results with command line: make
>>> check-gcc RUNTESTFLAGS="tree-prof.exp" -k
>>
>> That is expected if you don't have autofdo. You would prefer to hide it?
>>
>>> Also I got unstable test result in tree-prof.exp if I run
>>> aforementioned command line with -jnum (parallelly).  Does the patch
>>> has problem in parallel testing?
>>
>> I haven't seen that. Unstable in what way?
> For GCC doesn't support FDO, it run below tests as you said:
>
> PASS: gcc.dg/tree-prof/20041218-1.c compilation,  -g
> UNSUPPORTED: gcc.dg/tree-prof/20041218-1.c: Cannot run create_gcov
> --binary /data/work/trunk/build/gcc/testsuite/gcc/20041218-1.gcda
>
> Normally, it doesn't create gcov data file, thus the next test is
> unsupported.  I guess in parallel test, the second test picks up gcov
> data files from other process, which results in random pass.
> Is it possible to not have these when fdo is supported?
Hmm, typo:  s/supported/not supported/.

Thanks,
bin

Re: [PATCH] Amend dump expectation in slsr-8.c (PR, tree-optimization/71490)

[Martin Liška]

On 07/13/2016 07:21 PM, Jeff Law wrote:
> Isn't that a code quality regression?  So instead shouldn't we be keeping the 
> same expectation, but xfailing the test?
> 
> jeff

Hello.

Disabling a pass before slsr makes the test to catch both opportunities.
Is the patch fine?

Thanks,
Martin
>From 59e3c47ca4fad03a8152776ad5100eed7b610883 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 14 Jul 2016 13:02:05 +0200
Subject: [PATCH] Amend dump expectation in slsr-8.c (PR
 tree-optimization/71490)

gcc/testsuite/ChangeLog:

2016-07-13  Martin Liska  

	* gcc.dg/tree-ssa/slsr-8.c: Disable -ftree-sink pass.
---
 gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c b/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
index 2bd60aa..557b798 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
@@ -1,7 +1,7 @@
 /* Verify straight-line strength reduction for simple pointer subtraction.  */
 
 /* { dg-do compile } */
-/* { dg-options "-O3 -fdump-tree-optimized" } */
+/* { dg-options "-O3 -fno-tree-sink -fdump-tree-optimized" } */
 
 int*
 f (int s, int *c)
-- 
2.8.4

Re: [PATCH 2/3] Run profile feedback tests with autofdo

[Bin.Cheng]

On Thu, Jul 14, 2016 at 11:55 AM, Andi Kleen  wrote:
>> After this patch, I got below test results with command line: make
>> check-gcc RUNTESTFLAGS="tree-prof.exp" -k
>
> That is expected if you don't have autofdo. You would prefer to hide it?
>
>> Also I got unstable test result in tree-prof.exp if I run
>> aforementioned command line with -jnum (parallelly).  Does the patch
>> has problem in parallel testing?
>
> I haven't seen that. Unstable in what way?
For GCC doesn't support FDO, it run below tests as you said:

PASS: gcc.dg/tree-prof/20041218-1.c compilation,  -g
UNSUPPORTED: gcc.dg/tree-prof/20041218-1.c: Cannot run create_gcov
--binary /data/work/trunk/build/gcc/testsuite/gcc/20041218-1.gcda

Normally, it doesn't create gcov data file, thus the next test is
unsupported.  I guess in parallel test, the second test picks up gcov
data files from other process, which results in random pass.
Is it possible to not have these when fdo is supported?

Thanks,
bin

>
> -Andi

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[Eric Gallager]

On 7/13/16, Jeff Law  wrote:
> On 06/27/2016 08:10 PM, Eric Gallager wrote:
>> The last time I ran ./contrib/download_prerequisites, I already had
>> previous symlinks set up from a previous run of the script, so `ln`
>> followed the existing symlinks and created the new ones in the
>> directories to which the symlinks pointed. This patch should fix that
>> by removing the old symlinks before creating new ones. (For some
>> reason the `-f` flag to `ln` that was already there wasn't enough for
>> me.) Tested by running the script and ensuring that the new isl
>> symlink pointed to the correct directory, and that there were no bad
>> symlinks in the old isl directory. Could someone commit this trivial
>> patch for me, or something like it? I don't have write access.
> I'd really rather know why the "-f" flag didn't work for you.  The whole
> point of -f is to remove the destination file first.
>
> Jeff
>

Reading my ln manpage, it describes the "-f" flag like this:


 -fIf the target file already exists, then unlink it so that the
   link may occur.  (The -f option overrides any previous -i
   options.)

Okay, so that seems like it should do what you say, but the manpage
also describes a separate uppercase "-F" option:

 -FIf the target file already exists and is a directory, then
   remove it so that the link may occur.  The -F option should be
   used with either -f or -i options.  If none is specified, -f is
   implied.  The -F option is a no-op unless -s option is speci-
   fied.

So it seems to imply that "-f" will only remove the destination file
if it's a regular file, while "-F" is needed if the destination file
is a directory. The page also has this to say about "-F" later:

 The -F option is FreeBSD extention and should not be used in portable
 scripts.

So this could be a BSD vs. GNU thing.

Re: [PATCH 2/3] Run profile feedback tests with autofdo

[Andi Kleen]

> After this patch, I got below test results with command line: make
> check-gcc RUNTESTFLAGS="tree-prof.exp" -k

That is expected if you don't have autofdo. You would prefer to hide it?

> Also I got unstable test result in tree-prof.exp if I run
> aforementioned command line with -jnum (parallelly).  Does the patch
> has problem in parallel testing?

I haven't seen that. Unstable in what way?

-Andi

Re: [PATCH] Lift alignment restrictions from inlining register size memcpy

[Eric Botcazou]

> Boostrap / regtest on strict-alignment platforms welcome.

Bootstrap/regtest on SPARC/Solaris is OK, modulo:

XPASS: gcc.dg/memmove-4.c scan-tree-dump-not optimized "memmove"
FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen (" 0
FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "memcpy (" 4

for both 32-bit and 64-bit.

> Unless I hear some positives I'll let the patch sit here as I
> don't really care too much about those pesky targets (and
> targets can choose to opt-in by providing movmisalign optabs
> anyway so they don't go the store/extract_bit_field path).

The patch is a step forward but it doesn't fully solve the problem:

#include 
#include 

uint32_t foo_noalign(const uint32_t *s) {
  uint32_t v;
  memcpy(, s, sizeof(v));
  return v;
}

uint32_t foo(const uint32_t *s) {
  uint32_t v;
  memcpy(, __builtin_assume_aligned(s, 4), sizeof(v));
  return v;
}

As discussed in the audit trail, the compiler ought to generate again the same 
code on strict-alignment targets in both cases, as Clang apparently and as GCC 
itself during most of its existence (until GCC 4.5 to be precise).

-- 
Eric Botcazou

Re: [PATCH][vectorizer][2/2] Hook up mult synthesis logic into vectorisation of mult-by-constant

[Richard Biener]

On Thu, 14 Jul 2016, Kyrill Tkachov wrote:

> Hi all,
> 
> On 07/07/16 17:16, Kyrill Tkachov wrote:
> > 
> > On 06/07/16 13:40, Kyrill Tkachov wrote:
> > > 
> > > On 06/07/16 13:31, Rainer Orth wrote:
> > > > Hi Kyrill,
> > > > 
> > > > > On 05/07/16 12:24, Rainer Orth wrote:
> > > > > > Marc Glisse  writes:
> > > > > > 
> > > > > > > On Tue, 5 Jul 2016, Kyrill Tkachov wrote:
> > > > > > > 
> > > > > > > > As for testing I've bootstrapped and tested the patch on aarch64
> > > > > > > > and
> > > > > > > > x86_64 with synth_shift_p in vect_synth_mult_by_constant hacked
> > > > > > > > to be
> > > > > > > > always true to exercise the paths that synthesize the shift by
> > > > > > > > additions. Marc, could you test this on the sparc targets you
> > > > > > > > care about?
> > > > > > > I don't have access to Sparc, you want Rainer here (added in Cc:).
> > > > > > As is, the patch doesn't even build on current mainline:
> > > > > > 
> > > > > > /vol/gcc/src/hg/trunk/local/gcc/tree-vect-patterns.c:2151:56: error:
> > > > > > 'mult_variant' has not been declared
> > > > > >target_supports_mult_synth_alg (struct algorithm *alg,
> > > > > > mult_variant var,
> > > > > > ^
> > > > > > 
> > > > > > enum mult_variant is only declared in expmed.c.
> > > > > Ah, sorry I forgot to mention that this is patch 2/2.
> > > > > It requires https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01144.html
> > > > > which
> > > > > is already approved
> > > > > but I was planning to commit it together with this one.
> > > > > Can you please try applying
> > > > > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01144.html
> > > > > as well as this?
> > > > sure, that did the trick.  A sparc-sun-solaris2.12 bootstrap revealed
> > > > that the patch fixes PR tree-optimization/70923 (you should mention that
> > > > in the ChangeLog or close it as a duplicate), with the same caveat as
> > > > about Marc's latest patch for that:
> > > 
> > > Thanks! Much appreciated.
> > > 
> > > > +FAIL: gcc.dg/vect/vect-iv-9.c -flto -ffat-lto-objects
> > > > scan-tree-dump-times vect "vectorized 1 loops" 1
> > > > +FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect "vectorized 1
> > > > loops" 1
> > > > 
> > > > The message appears twice, not once, on sparc, so the testcase should be
> > > > updated to accomodate that.
> > > 
> > > Ok.
> > > 
> > > > Besides, the new testcase FAILs:
> > > > 
> > > > +FAIL: gcc.dg/vect/pr65951.c -flto -ffat-lto-objects
> > > > scan-tree-dump-times vect "vectorized 1 loops" 2
> > > > +FAIL: gcc.dg/vect/pr65951.c scan-tree-dump-times vect "vectorized 1
> > > > loops" 2
> > > > 
> > > > The dump contains
> > > > 
> > > > gcc.dg/vect/pr65951.c:14:3: note: not vectorized: no vectype for stmt:
> > > > _4 = *_3;
> > > > gcc.dg/vect/pr65951.c:12:1: note: vectorized 0 loops in function.
> > > > gcc.dg/vect/pr65951.c:21:3: note: not vectorized: no vectype for stmt:
> > > > _4 = *_3;
> > > > gcc.dg/vect/pr65951.c:19:1: note: vectorized 0 loops in function.
> > > > gcc.dg/vect/pr65951.c:55:15: note: not vectorized: control flow in loop.
> > > > gcc.dg/vect/pr65951.c:46:3: note: not vectorized: loop contains function
> > > > calls or data references that cannot be analyzed
> > > > gcc.dg/vect/pr65951.c:41:15: note: not vectorized: control flow in loop.
> > > > gcc.dg/vect/pr65951.c:32:3: note: not vectorized: loop contains function
> > > > calls or data references that cannot be analyzed
> > > > gcc.dg/vect/pr65951.c:26:1: note: vectorized 0 loops in function.
> > > 
> > > I see. I suppose SPARC doesn't have vector shifts operating on 64-bit
> > > data?
> > > I believe the testcase should be updated to use just "int" arrays rather
> > > than "long long".
> > > 
> > > I'll respin the testcases
> > 
> > Ok, here's the patch with pr65951.c updated to use int rather than long long
> > arrays and vect-iv-9.c updated to scan for the
> > "Vectorized 1 loops" string twice. I've verified by hand by building a
> > sparc-sun-solaris2.10 cc1 that compiling with
> > -mcpu=ultrasparc -mvis gives the right strings in the vectoriser dump.
> > 
> > So is this version ok?
> > 
> 
> So richi was ok with the implementation part of the patch [1]
> Are the testuite changes made since ok?
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00177.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00331.html

Ok with me - I wondered if Rainer wanted to double-check.

Richard.

[PATCH] Improve doxygen comments for allocators in containers

[Jonathan Wakely]

PR libstdc++/70716
* include/bits/forward_list.h (forward_list): Update doxygen comments
to reflect allocator propagation semantics. Remove ambiguous
statements about data being lost.
* include/bits/stl_deque.h (deque): Likewise.
* include/bits/stl_list.h (list): Likewise.
* include/bits/stl_map.h (map): Likewise.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
Likewise.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.

See bugzilla for my rationale for removing the "Old data may be lost"
sentences.

Tested x86_64-linux, committed to trunk.

commit d481d9a260d5db67fe2f269490b5ad3610fb9a7e
Author: redi 
Date:   Thu Jul 14 10:02:10 2016 +

Improve doxygen comments for allocators in containers

PR libstdc++/70716
* include/bits/forward_list.h (forward_list): Update doxygen comments
to reflect allocator propagation semantics. Remove ambiguous
statements about data being lost.
* include/bits/stl_deque.h (deque): Likewise.
* include/bits/stl_list.h (list): Likewise.
* include/bits/stl_map.h (map): Likewise.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
Likewise.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238332 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/include/bits/forward_list.h 
b/libstdc++-v3/include/bits/forward_list.h
index 2e8d39f..3961509 100644
--- a/libstdc++-v3/include/bits/forward_list.h
+++ b/libstdc++-v3/include/bits/forward_list.h
@@ -566,8 +566,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  @param  __list  A %forward_list of identical element and allocator
*types.
*
-   *  All the elements of @a __list are copied, but unlike the copy
-   *  constructor, the allocator object is not copied.
+   *  All the elements of @a __list are copied.
+   *
+   *  Whether the allocator is copied depends on the allocator traits.
*/
   forward_list&
   operator=(const forward_list& __list);
@@ -579,7 +580,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*
*  The contents of @a __list are moved into this %forward_list
*  (without copying, if the allocators permit it).
-   *  @a __list is a valid, but unspecified %forward_list
+   *
+   *  Afterwards @a __list is a valid, but unspecified %forward_list
+   *
+   *  Whether the allocator is moved depends on the allocator traits.
*/
   forward_list&
   operator=(forward_list&& __list)
@@ -617,7 +621,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*
*  Note that the assignment completely changes the %forward_list and
*  that the number of elements of the resulting %forward_list is the
-   *  same as the number of elements assigned.  Old data is lost.
+   *  same as the number of elements assigned.
*/
   template>
@@ -636,7 +640,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  This function fills a %forward_list with @a __n copies of the
*  given value.  Note that the assignment completely changes the
*  %forward_list, and that the resulting %forward_list has __n
-   *  elements.  Old data is lost.
+   *  elements.
*/
   void
   assign(size_type __n, const _Tp& __val)
@@ -991,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  time.  Note that the global std::swap() function is
*  specialized such that std::swap(l1,l2) will feed to this
*  function.
+   *
+   *  Whether the allocators are swapped depends on the allocator traits.
*/
   void
   swap(forward_list& __list) noexcept
diff --git a/libstdc++-v3/include/bits/stl_deque.h 
b/libstdc++-v3/include/bits/stl_deque.h
index 66b8da6..7192f65 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -939,8 +939,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*  @brief  %Deque copy constructor.
*  @param  __x  A %deque of identical element and allocator types.
*
-   *  The newly-created %deque uses a copy of the allocation object used
-   *  by @a __x.
+   *  The newly-created %deque uses a copy of the allocator object used
+   *  by @a __x (unless the 

Re: [PATCH GCC]Resolve compilation time known alias checks in vectorizer

[Bin.Cheng]

On Thu, Jul 14, 2016 at 10:49 AM, Thomas Schwinge
 wrote:
> Hi!
>
> On Wed, 13 Jul 2016 16:09:21 +0100, "Bin.Cheng"  wrote:
>> Patch re-tested/applied on trunk as r238301.  As I mentioned
>> previously, gcc.dg/vect/vect-mask-store-move-1.c fails now because of
>> PR65206.
>
> Unless you intend to work on PR65206 (Richard's last comment was more
> than a year ago, on 2015-02-26), I suggest you XFAIL
> gcc.dg/vect/vect-mask-store-move-1.c giving a reference to PR65206 --
> otherwise it'll continue to FAIL, and a lot of people will waste time
> looking up what's going on, searching the web/mailing lists, and so on.
Will do that soon, and thanks very much for the suggestion.

Thanks,
bin
>
>
> Grüße
>  Thomas

Re: [PATCH GCC]Resolve compilation time known alias checks in vectorizer

[Thomas Schwinge]

Hi!

On Wed, 13 Jul 2016 16:09:21 +0100, "Bin.Cheng"  wrote:
> Patch re-tested/applied on trunk as r238301.  As I mentioned
> previously, gcc.dg/vect/vect-mask-store-move-1.c fails now because of
> PR65206.

Unless you intend to work on PR65206 (Richard's last comment was more
than a year ago, on 2015-02-26), I suggest you XFAIL
gcc.dg/vect/vect-mask-store-move-1.c giving a reference to PR65206 --
otherwise it'll continue to FAIL, and a lot of people will waste time
looking up what's going on, searching the web/mailing lists, and so on.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [PATCH, GCC/LRA] Teach LRA to not use same register value for multiple output operands of an insn

[Thomas Preudhomme]

On Friday 08 July 2016 09:05:55 Mike Stump wrote:
> On Jul 8, 2016, at 8:07 AM, Thomas Preudhomme 
 wrote:
> > While investigating the root cause a testsuite regression for the
> > ARM/embedded-5-branch GCC in gcc.dg/vect/slp-perm-5.c, we found that the
> > bug seems to also affect trunk.
> 
> Hum...  If in 6.x, and safe to back port to 6, a back port would be nice... 
> I use LRA in 6.x, and seems like I'd be susceptible to this sort of thing,
> but, I didn't test it.

It should affect 6.x as well yes since there is no special protection against 
it in the code being modified. However I only ever managed to reproduce this on 
the ARM/embedded-5-branch.

Best regards,

Thomas

Re: Fix PR44281 (bad RA with global regs)

[Dominik Vogt]

On Wed, Jul 13, 2016 at 07:43:13PM +0200, Bernd Schmidt wrote:
> On 07/13/2016 05:29 PM, Dominik Vogt wrote:
> 
> >Unfortunately this patch (or whatever got actually committed) has
> >broken the gcc.target/s390/pr679443.c test case, which is a bit
> >fishy (see code snippet below).  I assign most registers to global
> >variables and then use some complicated arithmetics with the goal
> >that the pointer stored in the first argument gets saved on the
> >stack and reloaded to a different register.  Before this patch the
> >test case just needed three registers to do its work (r2, r3, r4).
> >With the patch it currently causes an error in the reload pass
> >
> >  error: unable to find a register to spill
> 
> Might be useful to see the dump_reload output.

Attached.

> >If a fourth register is available, the ICE goes away, but the
> >pointer remains in r2, rendering the test case useless.
> 
> I don't think I quite understand what you're trying to do here,

Alias detection of the memory pointed to by the first register.
There was some hard to trigger bug where writing a bitfield in a
struct would also overwrite the unselected bits of the
corresponding word.  See here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443

> but it does look dodgy.

It is.  The problem is that I can't tell Gcc to move the address
to a different register directly, so I had to do some voodoo
to achieve that.  The test case seemed to be the most robust
approach ...

> Whatever this is testing would probably be
> better as a part of a unit test.o

I've spent a lot of time to port the test to Power but was unable
to reproduce the effect.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

;; Function foo (foo, funcdef_no=0, decl_uid=2002, cgraph_uid=0, symbol_order=9)


** Local #1: **

   Spilling non-eliminable hard regs: 15 35
New elimination table:
Can eliminate 34 to 15 (offset=160, prev_offset=0)
Can eliminate 34 to 11 (offset=160, prev_offset=0)
Can eliminate 32 to 15 (offset=160, prev_offset=0)
Can eliminate 32 to 11 (offset=160, prev_offset=0)
Can't eliminate 35 to 15 (offset=0, prev_offset=0)
Can't eliminate 35 to 11 (offset=0, prev_offset=0)
Can eliminate 13 to 13 (offset=0, prev_offset=0)
alt=0: Bad operand -- refuse
alt=1: Bad operand -- refuse
alt=2: Bad operand -- refuse
alt=3: Bad operand -- refuse
alt=4: Bad operand -- refuse
  alt=12,overall=0,losers=0,rld_nregs=0
 Choosing alt 12 in insn 4:  (0) d  (1) d {*movdi_64}
0 Non input pseudo reload: reject++
1 Matching alt: reject+=2
2 Non-pseudo reload: reject+=2
2 Non input pseudo reload: reject++
  alt=0,overall=24,losers=3,rld_nregs=4
0 Non input pseudo reload: reject++
1 Matching alt: reject+=2
2 Non input pseudo reload: reject++
  alt=1,overall=22,losers=3,rld_nregs=3
 Choosing alt 1 in insn 9:  (0) d  (1) 0  (2) T {divmodtidi3}
  Creating newreg=78 from oldreg=71, assigning class GENERAL_REGS to r78
9: 
r78:TI=zero_extend(r78:TI#8%[`*.LC0'])<<0x40|zero_extend(r78:TI#8/[`*.LC0'])
Inserting insn reload before:
   23: clobber r78:TI
   24: r78:TI#8=r67:DI
Inserting insn reload after:
   25: r71:TI=r78:TI

0 Non input pseudo reload: reject++
  alt=0,overall=613,losers=2,rld_nregs=2
0 Non pseudo reload: reject++
1 Non pseudo reload: reject++
  alt=1,overall=2,losers=0,rld_nregs=0
 Choosing alt 1 in insn 25:  (0) S  (1) d {movti}
0 Non pseudo reload: reject++
alt=0: Bad operand -- refuse
0 Non pseudo reload: reject++
alt=1: Bad operand -- refuse
0 Non pseudo reload: reject++
alt=2: Bad operand -- refuse
0 Non pseudo reload: reject++
alt=3: Bad operand -- refuse
0 Non pseudo reload: reject++
alt=4: Bad operand -- refuse
0 Non pseudo reload: reject++
  alt=12,overall=1,losers=0,rld_nregs=0
 Choosing alt 12 in insn 24:  (0) d  (1) d {*movdi_64}
alt=0: Bad operand -- refuse
alt=1: Bad operand -- refuse
alt=2: Bad operand -- refuse
alt=3: Bad operand -- refuse
alt=4: Bad operand -- refuse
  alt=12,overall=0,losers=0,rld_nregs=0
 Choosing alt 12 in insn 2:  (0) d  (1) d {*movdi_64}
  alt=0,overall=6,losers=1,rld_nregs=1
alt=2: Bad operand -- refuse
2 Spill pseudo into memory: reject+=3
alt=6,overall=15,losers=2 -- refuse
  alt=0,overall=6,losers=1,rld_nregs=1
alt=2: Bad operand -- refuse
2 Non pseudo reload: reject++
  alt=6,overall=1,losers=0,rld_nregs=0
  Commutative operand exchange in insn 12
 Choosing alt 6 in insn 12:  (0) d  (1) 0  (2) R {*addsi3}
alt=0: Bad operand 

Re: [PATCH, GCC/ARM testsuite] Fix pr42574.c selector syntax error

[Thomas Preudhomme]

On Thursday 14 July 2016 10:14:52 Kyrill Tkachov wrote:
> Hi Thomas,
> 
> On 14/07/16 10:12, Thomas Preudhomme wrote:
> > This patch fixes a syntax error in the dg-do selector of pr42574.c: it is
> > missing the target keyword, with the following boolean expression enclosed
> > in curly braces. Test fails to be run without this patch and successfully
> > pass with it. Patch is in attachment.
> > 
> > ChangeLog entry is as follows:
> > 
> > 
> > *** gcc/testsuite/ChangeLog ***
> > 
> > 2016-07-13  Thomas Preud'homme  
> > 
> >  * gcc.target/arm/pr42574.c: Add missing target keyword for the
> >  dg-do
> >  selector and enclose boolean expression in curly braces.
> > 
> > Is this ok for trunk?
> 
> Ok. I'd say this is an obvious change.

Err indeed, long time I did not have one.

Thanks.

Thomas

Re: [PATCH, GCC/ARM testsuite] Fix pr42574.c selector syntax error

[Kyrill Tkachov]

Hi Thomas,

On 14/07/16 10:12, Thomas Preudhomme wrote:

This patch fixes a syntax error in the dg-do selector of pr42574.c: it is
missing the target keyword, with the following boolean expression enclosed in
curly braces. Test fails to be run without this patch and successfully pass
with it. Patch is in attachment.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-07-13  Thomas Preud'homme  

 * gcc.target/arm/pr42574.c: Add missing target keyword for the dg-do
 selector and enclose boolean expression in curly braces.


Is this ok for trunk?


Ok. I'd say this is an obvious change.
Thanks,
Kyrill



Best regards,

Thomas

[PATCH, GCC/ARM testsuite] Fix pr42574.c selector syntax error

[Thomas Preudhomme]

This patch fixes a syntax error in the dg-do selector of pr42574.c: it is 
missing the target keyword, with the following boolean expression enclosed in 
curly braces. Test fails to be run without this patch and successfully pass 
with it. Patch is in attachment.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-07-13  Thomas Preud'homme  

* gcc.target/arm/pr42574.c: Add missing target keyword for the dg-do
selector and enclose boolean expression in curly braces.


Is this ok for trunk?

Best regards,

Thomasdiff --git a/gcc/testsuite/gcc.target/arm/pr42574.c b/gcc/testsuite/gcc.target/arm/pr42574.c
index e3476f37788a2b3144454aef04a9b45c0b4ac398..d3d6b5d32e5826abf1017b823a9e271383daf09d 100644
--- a/gcc/testsuite/gcc.target/arm/pr42574.c
+++ b/gcc/testsuite/gcc.target/arm/pr42574.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { arm_thumb1_ok && { ! arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb1_ok && { ! arm_thumb1_movt_ok } } } } */
 /* { dg-options "-mthumb -Os -fpic" }  */
 /* { dg-require-effective-target fpic } */
 /* Make sure the address of glob.c is calculated only once and using

Re: [PATCH v5] Allocate constant size dynamic stack space in the prologue

[Dominik Vogt]

On Wed, Jul 13, 2016 at 04:12:36PM -0600, Jeff Law wrote:
> On 07/11/2016 05:44 AM, Dominik Vogt wrote:
> >On Thu, Jul 07, 2016 at 12:57:16PM +0100, Dominik Vogt wrote:
> >>On Wed, Jul 06, 2016 at 02:01:06PM +0200, Bernd Schmidt wrote:
> >>>There's one thing I don't quite understand and which seems to have
> >>>changed since v1:
> >>>
> >>>On 07/04/2016 02:19 PM, Dominik Vogt wrote:
> @@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct 
> stack_vars_data *data)
> 
>   /* If there were any, allocate space.  */
>   if (large_size > 0)
> - large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
> -large_align, true);
> + {
> +   large_allocsize = GEN_INT (large_size);
> +   get_dynamic_stack_size (_allocsize, 0, large_align, NULL);
> + }
> }
> 
>   for (si = 0; si < n; ++si)
> @@ -1186,6 +1190,19 @@ expand_stack_vars (bool (*pred) (size_t), struct 
> stack_vars_data *data)
> /* Large alignment is only processed in the last pass.  */
> if (pred)
>   continue;
> +
> +   if (large_allocsize && ! large_allocation_done)
> + {
> +   /* Allocate space the virtual stack vars area in the
> +  prologue.  */
> +   HOST_WIDE_INT loffset;
> +
> +   loffset = alloc_stack_frame_space
> + (INTVAL (large_allocsize),
> +  PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT);
> +   large_base = get_dynamic_stack_base (loffset, large_align);
> +   large_allocation_done = true;
> + }
> gcc_assert (large_base != NULL);
> 
> >>>
> >>>Why is this code split between the two places here?
> >>
> >>This is a bugfix from v1 to v2.
> >>I think I had to move this code to the second loop so that the
> >>space for dynamically aligned variables is allocated at the "end"
> >>of the space for stack variables.  I cannot remember what the bug
> >>was, but maybe it was that the variables with fixed and static
> >>alignment ended up at the same address.
> >>
> >>Anyway, now that the new allocation strategy is used
> >>unconditionally, it should be possible to move the
> >>get_dynamic_stack_size call down to the second loop and simplify
> >>the code somewhat.  I'll look into that.
> >
> >Version 5 with some code moved from the first loop to the second.
> -ENOPATCH

Oops.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

* cfgexpand.c (expand_stack_vars): Implement synamic stack space
allocation in the prologue.
* explow.c (get_dynamic_stack_base): New function to return an address
expression for the dynamic stack base.
(get_dynamic_stack_size): New function to do the required dynamic stack
space size calculations.
(allocate_dynamic_stack_space): Use new functions.
(align_dynamic_address): Move some code from
allocate_dynamic_stack_space to new function.
* explow.h (get_dynamic_stack_base, get_dynamic_stack_size): Export.
gcc/testsuite/ChangeLog

* gcc.target/s390/warn-dynamicstack-1.c: New test.
* gcc.dg/stack-usage-2.c (foo3): Adapt expected warning.
stack-layout-dynamic-1.c: New test.
>From 254581388640af34bcff55105ec13555043b62e5 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Wed, 25 Nov 2015 09:31:19 +0100
Subject: [PATCH] Allocate constant size dynamic stack space in the
 prologue ...

... and place it in the virtual stack vars area, if the platform supports it.
On S/390 this saves adjusting the stack pointer twice and forcing the frame
pointer into existence.  It also removes the warning with -mwarn-dynamicstack
that is triggered by cfun->calls_alloca == 1.

This fixes a problem with the Linux kernel which aligns the page structure to
16 bytes at run time using inefficient code and issuing a bogus warning.
---
 gcc/cfgexpand.c|  22 +-
 gcc/explow.c   | 226 ++---
 gcc/explow.h   |   8 +
 gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c  |  14 ++
 gcc/testsuite/gcc.dg/stack-usage-2.c   |   4 +-
 .../gcc.target/s390/warn-dynamicstack-1.c  |  17 ++
 6 files changed, 207 insertions(+), 84 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/warn-dynamicstack-1.c

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index e4ddb3a..5046d61 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1053,6 +1053,7 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
   HOST_WIDE_INT large_size = 0, large_alloc = 0;
   rtx large_base = NULL;
   unsigned large_align = 0;
+  bool large_allocation_done = false;
   tree decl;
 
   /* Determine if there are any variables requiring "large" alignment.
@@ 

Re: Implement -Wswitch-fallthrough: aarch64 + arm

[Richard Earnshaw (lists)]

Where the comments just say "Fall through", or equivalent, and there's
no other explanation I think those comments are now redundant and should
be removed.

So remove:

   /* Fall through.  */

but keep things like:

  /* Fall through - if the lane index isn't a constant then
 the next case will error.  */

OK with that change.

R.

On 11/07/16 20:53, Marek Polacek wrote:
> 2016-07-11  Marek Polacek  
> 
>   PR c/7652
>   * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Add 
> gcc_fallthrough.
>   * config/aarch64/aarch64-simd.md: Likewise.
>   * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Likewise.
>   (aarch64_print_operand): Likewise.
>   (aarch64_rtx_costs): Likewise.
>   (aarch64_expand_compare_and_swap): Likewise.
>   (aarch64_gen_atomic_ldop): Likewise.
>   (aarch64_split_atomic_op): Likewise.
>   (aarch64_expand_vec_perm_const): Likewise.
>   * config/aarch64/predicates.md: Likewise.
>   * config/arm/arm-builtins.c (arm_expand_neon_args): Likewise.
>   * config/arm/arm.c (const_ok_for_op): Likewise.
>   (arm_rtx_costs_1): Likewise.
>   (thumb1_size_rtx_costs): Likewise.
>   (arm_size_rtx_costs): Likewise.
>   (arm_new_rtx_costs): Likewise.
>   (thumb2_reorg): Likewise.
>   (output_move_double): Likewise.
>   (output_move_neon): Likewise.
>   (arm_print_operand): Likewise.
>   (arm_expand_compare_and_swap): Likewise.
>   (arm_split_atomic_op): Likewise.
>   (arm_expand_vec_perm_const): Likewise.
>   * config/arm/neon.md: Likewise.
> 
> diff --git gcc/gcc/config/aarch64/aarch64-builtins.c 
> gcc/gcc/config/aarch64/aarch64-builtins.c
> index 6b90b2a..fe37ea2 100644
> --- gcc/gcc/config/aarch64/aarch64-builtins.c
> +++ gcc/gcc/config/aarch64/aarch64-builtins.c
> @@ -999,6 +999,7 @@ aarch64_simd_expand_args (rtx target, int icode, int 
> have_retval,
>   }
> /* Fall through - if the lane index isn't a constant then
>the next case will error.  */
> +   gcc_fallthrough ();
>   case SIMD_ARG_CONSTANT:
>  constant_arg:
> if (!(*insn_data[icode].operand[opc].predicate)
> diff --git gcc/gcc/config/aarch64/aarch64-simd.md 
> gcc/gcc/config/aarch64/aarch64-simd.md
> index a19d171..110a070 100644
> --- gcc/gcc/config/aarch64/aarch64-simd.md
> +++ gcc/gcc/config/aarch64/aarch64-simd.md
> @@ -2328,6 +2328,7 @@
>if (operands[5] == CONST0_RTX (mode))
>  break;
>/* Fall through, as may need to load into register.  */
> +  gcc_fallthrough ();
>  default:
>if (!REG_P (operands[5]))
>  operands[5] = force_reg (mode, operands[5]);
> @@ -2430,6 +2431,7 @@
> break;
>   }
>/* Fall through.  */
> +  gcc_fallthrough ();
>  default:
>if (!REG_P (operands[5]))
>   operands[5] = force_reg (mode, operands[5]);
> @@ -2441,6 +2443,7 @@
>  case UNLT:
>inverse = 1;
>/* Fall through.  */
> +  gcc_fallthrough ();
>  case GE:
>  case UNGE:
>  case ORDERED:
> @@ -2452,6 +2455,7 @@
>  case UNLE:
>inverse = 1;
>/* Fall through.  */
> +  gcc_fallthrough ();
>  case GT:
>  case UNGT:
>base_comparison = gen_aarch64_cmgt;
> @@ -2545,6 +2549,7 @@
>Swapping the operands to BSL will give the UNORDERED case.  */
>   swap_bsl_operands = 1;
>   /* Fall through.  */
> + gcc_fallthrough ();
>  case ORDERED:
>emit_insn (gen_aarch64_cmgt (tmp, operands[4], 
> operands[5]));
>emit_insn (gen_aarch64_cmge (mask, operands[5], 
> operands[4]));
> diff --git gcc/gcc/config/aarch64/aarch64.c gcc/gcc/config/aarch64/aarch64.c
> index 512ef10..3ecf244 100644
> --- gcc/gcc/config/aarch64/aarch64.c
> +++ gcc/gcc/config/aarch64/aarch64.c
> @@ -1833,6 +1833,7 @@ aarch64_expand_mov_immediate (rtx dest, rtx imm)
> return;
>   }
> /* FALLTHRU */
> +   gcc_fallthrough ();
>  
>   case SYMBOL_SMALL_ABSOLUTE:
>   case SYMBOL_TINY_ABSOLUTE:
> @@ -4541,6 +4542,7 @@ aarch64_print_operand (FILE *f, rtx x, int code)
> break;
>   }
> /* Fall through.  */
> +   gcc_fallthrough ();
>  
>   default:
> output_operand_lossage ("Unsupported operand for code '%c'", code);
> @@ -4713,6 +4715,7 @@ aarch64_print_operand (FILE *f, rtx x, int code)
>   }
>  
>/* Fall through */
> +  gcc_fallthrough ();
>  
>  case 0:
>/* Print a normal operand, if it's a general register, then we
> @@ -6192,6 +6195,7 @@ aarch64_rtx_costs (rtx x, machine_mode mode, int outer 
> ATTRIBUTE_UNUSED,
>   *cost += rtx_cost (SUBREG_REG (op0), VOIDmode, SET, 0, speed);
>  
> /* Fall through.  */
> +   gcc_fallthrough ();
>   case REG:
> /* The cost is one per vector-register copied.  */
> if (VECTOR_MODE_P (GET_MODE (op0)) 

Re: [v3 PATCH] Implement P0032R3, Homogeneous interface for variant, any and optional, for the parts concerning any and optional.

[Jonathan Wakely]

This change replaced a Tab with 8 spaces, but the lines after it still
use Tabs:

@@ -641,12 +634,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}

  template
-   void
+enable_if_t::value>
emplace(_Args&&... __args)
{

Might as well keep it consistent (and save 7 bytes! ;)

OK for trunk, thanks.