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

[Kugan Vivekanandarajah]

Hi Honza,

Here is a re-based version which also addresses the review comments.

On 21/07/16 22:54, Jan Hubicka wrote:
>> Maybe it is better to separate value range and alignment summary
>> writing/reading to different functions. Here is another updated
>> version which does this.
>
> Makes sense to me. Note that the alignment summary propagation can be either
> handled by doing bitwise constant propagation and/or extending our value 
> ranges
> by stride (as described in
> http://www.lighterra.com/papers/valuerangeprop/Patterson1995-ValueRangeProp.pdf
> I would like it to go eventually away in favour of more generic solution.
>
>> -/* If DEST_PLATS already has aggregate items, check that aggs_by_ref matches
>> +/* Propagate value range across jump function JFUNC that is associated with
>> +   edge CS and update DEST_PLATS accordingly.  */
>> +
>> +static bool
>> +propagate_vr_accross_jump_function (cgraph_edge *cs,
>> +ipa_jump_func *jfunc,
>> +struct ipcp_param_lattices *dest_plats)
>> +{
>> +  struct ipcp_param_lattices *src_lats;
>> +  ipcp_vr_lattice *dest_lat = _plats->m_value_range;
>> +
>> +  if (dest_lat->bottom_p ())
>> +return false;
>> +
>> +  if (jfunc->type == IPA_JF_PASS_THROUGH)
>> +{
>> +  struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
>> +  int src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
>> +  src_lats = ipa_get_parm_lattices (caller_info, src_idx);
>> +
>> +  if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
>> + return dest_lat->meet_with (src_lats->m_value_range);
>
> Clearly we can propagate thorugh expressions here (PLUS_EXPR). I have run
> into similar issue in loop code that builds simple generic expresisons
> (like (int)ssa_name+10) and it would be nice to have easy way to deterine
> their value range based on the knowledge of SSA_NAME's valur range.
>
> Bit this is fine for initial implementaiotn for sure.

Indeed. I will do this as a follow up.

>>
>> +/* Look up all VR information that we have discovered and copy it over
>> +   to the transformation summary.  */
>> +
>> +static void
>> +ipcp_store_vr_results (void)
>> +{
>> +  cgraph_node *node;
>> +
>> +  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
>> +  {
>> +ipa_node_params *info = IPA_NODE_REF (node);
>> +bool found_useful_result = false;
>> +
>> +if (!opt_for_fn (node->decl, flag_ipa_vrp))
>> +  {
>> + if (dump_file)
>> +  fprintf (dump_file, "Not considering %s for VR discovery "
>> +   "and propagate; -fipa-ipa-vrp: disabled.\n",
>> +   node->name ());
>> + continue;
>
> I belive you need to also prevent propagation through functions copmiled with
> -fno-ipa-vrp, not only prevent any transformations.

Do you mean the following, I was following other implementations.

@@ -2264,6 +2430,11 @@ propagate_constants_accross_call (struct
cgraph_edge *cs)
_plats->bits_lattice);
   ret |= propagate_aggs_accross_jump_function (cs, jump_func,
dest_plats);
+  if (opt_for_fn (callee->decl, flag_ipa_vrp))
+ret |= propagate_vr_accross_jump_function (cs,
+   jump_func, dest_plats);
+  else
+ret |= dest_plats->m_value_range.set_to_bottom ();

>> +/* Update value range of formal parameters as described in
>> +   ipcp_transformation_summary.  */
>> +
>> +static void
>> +ipcp_update_vr (struct cgraph_node *node)
>> +{
>> +  tree fndecl = node->decl;
>> +  tree parm = DECL_ARGUMENTS (fndecl);
>> +  tree next_parm = parm;
>> +  ipcp_transformation_summary *ts = ipcp_get_transformation_summary (node);
>> +  if (!ts || vec_safe_length (ts->m_vr) == 0)
>> +return;
>> +  const vec  = *ts->m_vr;
>> +  unsigned count = vr.length ();
>> +
>> +  for (unsigned i = 0; i < count; ++i, parm = next_parm)
>> +{
>> +  if (node->clone.combined_args_to_skip
>> +  && bitmap_bit_p (node->clone.combined_args_to_skip, i))
>> + continue;
>> +  gcc_checking_assert (parm);
>> +  next_parm = DECL_CHAIN (parm);
>> +  tree ddef = ssa_default_def (DECL_STRUCT_FUNCTION (node->decl), parm);
>> +
>> +  if (!ddef || !is_gimple_reg (parm))
>> + continue;
>> +
>> +  if (cgraph_local_p (node)
> The test of cgraph_local_p seems redundant here. The analysis phase should 
> not determine
> anything if function is reachable non-locally.

Removed it.

>> +/* Info about value ranges.  */
>> +
>> +struct GTY(()) ipa_vr
>> +{
>> +  /* The data fields below are valid only if known is true.  */
>> +  bool known;
>> +  enum value_range_type type;
>> +  tree min;
>> +  tree max;
> What is the point of representing range as trees rather than wide ints. Can 
> they
> be non-constant integer?

Changed to wide_int after adding that support.

LTO Bootstrapped and regression tested on x86_64-linux-gnu with no new
regressions, is this OK?

Thanks
Kugan
From c6687f60001695dd71316e894010a764cb15606a Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Tue, 23 Aug 2016 19:47:58 +1000
Subject: [PATCH 

Re: [PATCH] Fix avoid_constant_pool_reference (PR middle-end/77377)

[Richard Biener]

On August 29, 2016 9:43:50 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>Returning c from avoid_constant_pool_reference for constant pool
>references
>is only fine if the modes match and offset is zero, otherwise if the
>offset
>is sane, we can try to simplify it as subreg.  But, returning c for out
>of
>bounds offsets is always wrong, and especially if the mode doesn't
>match, it
>can results in all kinds of ICEs.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

>2016-08-29  Jakub Jelinek  
>
>   PR middle-end/77377
>   * simplify-rtx.c (avoid_constant_pool_reference): For out of bounds
>   constant pool reference return x instead of c.
>
>   * gcc.target/i386/pr77377.c: New test.
>
>--- gcc/simplify-rtx.c.jj  2016-08-12 17:33:46.0 +0200
>+++ gcc/simplify-rtx.c 2016-08-29 13:32:38.126859949 +0200
>@@ -251,15 +251,14 @@ avoid_constant_pool_reference (rtx x)
> /* If we're accessing the constant in a different mode than it was
>  originally stored, attempt to fix that up via subreg simplifications.
> If that fails we have no choice but to return the original memory.  */
>-  if ((offset != 0 || cmode != GET_MODE (x))
>-&& offset >= 0 && offset < GET_MODE_SIZE (cmode))
>+  if (offset == 0 && cmode == GET_MODE (x))
>+  return c;
>+  else if (offset >= 0 && offset < GET_MODE_SIZE (cmode))
> {
>   rtx tem = simplify_subreg (GET_MODE (x), c, cmode, offset);
>   if (tem && CONSTANT_P (tem))
> return tem;
> }
>-  else
>-return c;
> }
> 
>   return x;
>--- gcc/testsuite/gcc.target/i386/pr77377.c.jj 2016-08-29
>13:39:01.707328239 +0200
>+++ gcc/testsuite/gcc.target/i386/pr77377.c2016-08-29
>13:38:55.901396832 +0200
>@@ -0,0 +1,6 @@
>+/* PR middle-end/77377 */
>+/* { dg-do compile } */
>+/* { dg-options "-O3 -msse" } */
>+/* { dg-additional-options "-fpic" { target fpic } } */
>+
>+#include "../../c-c++-common/pr59037.c"
>
>   Jakub

Re: [PATCH] Fix dwarf2out ARRAY_TYPE handling (PR debug/77363)

[Richard Biener]

On August 29, 2016 9:53:32 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>In r231058 gen_type_die_with_usage has been changed to treat ARRAY_TYPE
>like
>VECTOR_TYPE and not to use type_main_variant in that case.  But as the
>following testcase shows, modified_type_die has similar condition and
>if
>those two don't agree, modified_type_die just fails the lookup if
>type_main_variant (type) != type, and we then fail to add DW_AT_type to
>the DW_TAG_typedef because of that.
>
>Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for
>trunk/6.2/5.5?

OK.

Thanks,
Richard.

>2016-08-29  Jakub Jelinek  
>
>   PR debug/77363
>   * dwarf2out.c (modified_type_die): Use lookup_type_die (type)
>   instead of lookup_type_die (type_main_variant (type)) even for array
>   types.
>
>   * g++.dg/debug/dwarf2/pr77363.C: New test.
>
>--- gcc/dwarf2out.c.jj 2016-08-29 12:35:49.0 +0200
>+++ gcc/dwarf2out.c2016-08-29 18:05:42.171597789 +0200
>@@ -11474,7 +11474,8 @@ modified_type_die (tree type, int cv_qua
>copy was created to help us keep track of typedef names) and
>that copy might have a different TYPE_UID from the original
>..._TYPE node.  */
>-  if (TREE_CODE (type) != VECTOR_TYPE)
>+  if (TREE_CODE (type) != VECTOR_TYPE
>+&& TREE_CODE (type) != ARRAY_TYPE)
>   return lookup_type_die (type_main_variant (type));
>   else
>   /* Vectors have the debugging information in the type,
>--- gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C.jj 2016-08-29
>18:26:09.218310766 +0200
>+++ gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C2016-08-29
>18:30:03.232579332 +0200
>@@ -0,0 +1,20 @@
>+// PR debug/77363
>+// { dg-options "-gdwarf-2 -dA -fno-merge-debug-strings" }
>+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\)
>DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type2\[^\n\r\]*
>DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
>+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\)
>DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type3\[^\n\r\]*
>DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
>+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\)
>DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type4\[^\n\r\]*
>DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
>+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\)
>DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type5\[^\n\r\]*
>DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]*
>DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
>+
>+typedef unsigned short type1;
>+typedef unsigned char type2;
>+typedef type2 type3[16];
>+typedef unsigned char type4[16];
>+typedef struct
>+{
>+  struct
>+  {
>+type3 a;
>+type4 b;
>+  } c;
>+} type5;
>+type5 var;
>
>   Jakub

Re: [PATCH] Fix compile time complexity of search_type_for_mask (PR tree-optimization/72866)

[Richard Biener]

On August 29, 2016 9:57:00 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>As the testcase shows, with deep chains of COND_EXPRs with the same
>SSA_NAMEs appearing more than once in the various operands we can
>hang in search_type_for_mask.  Similar check_bool_pattern function
>uses a hash_set to handle stmts that have been checked already, this
>patch
>uses a hash_map in which we cache the return values once we've handled
>some
>stmt already.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

>2016-08-29  Jakub Jelinek  
>
>   PR tree-optimization/72866
>   * tree-vect-patterns.c (search_type_for_mask): Turn into
>   a small wrapper, move all code to ...
>   (search_type_for_mask_1): ... this new function.  Add caching
>   and adjust recursive calls.
>
>   * gcc.dg/vect/pr72866.c: New test.
>
>--- gcc/tree-vect-patterns.c.jj2016-07-21 08:59:55.0 +0200
>+++ gcc/tree-vect-patterns.c   2016-08-29 19:26:12.807164641 +0200
>@@ -3459,13 +3459,11 @@ adjust_bool_stmts (hash_set  &
>   return gimple_assign_lhs (pattern_stmt);
> }
> 
>-/* Return the proper type for converting bool VAR into
>-   an integer value or NULL_TREE if no such type exists.
>-   The type is chosen so that converted value has the
>-   same number of elements as VAR's vector type.  */
>+/* Helper for search_type_for_mask.  */
> 
> static tree
>-search_type_for_mask (tree var, vec_info *vinfo)
>+search_type_for_mask_1 (tree var, vec_info *vinfo,
>+  hash_map )
> {
>   gimple *def_stmt;
>   enum vect_def_type dt;
>@@ -3490,6 +3488,10 @@ search_type_for_mask (tree var, vec_info
>   if (!is_gimple_assign (def_stmt))
> return NULL_TREE;
> 
>+  tree *c = cache.get (def_stmt);
>+  if (c)
>+return *c;
>+
>   rhs_code = gimple_assign_rhs_code (def_stmt);
>   rhs1 = gimple_assign_rhs1 (def_stmt);
> 
>@@ -3498,14 +3500,15 @@ search_type_for_mask (tree var, vec_info
> case SSA_NAME:
> case BIT_NOT_EXPR:
> CASE_CONVERT:
>-  res = search_type_for_mask (rhs1, vinfo);
>+  res = search_type_for_mask_1 (rhs1, vinfo, cache);
>   break;
> 
> case BIT_AND_EXPR:
> case BIT_IOR_EXPR:
> case BIT_XOR_EXPR:
>-  res = search_type_for_mask (rhs1, vinfo);
>-  res2 = search_type_for_mask (gimple_assign_rhs2 (def_stmt),
>vinfo);
>+  res = search_type_for_mask_1 (rhs1, vinfo, cache);
>+  res2 = search_type_for_mask_1 (gimple_assign_rhs2 (def_stmt),
>vinfo,
>+   cache);
>if (!res || (res2 && TYPE_PRECISION (res) > TYPE_PRECISION (res2)))
>   res = res2;
>   break;
>@@ -3517,8 +3520,9 @@ search_type_for_mask (tree var, vec_info
> 
> if (TREE_CODE (TREE_TYPE (rhs1)) == BOOLEAN_TYPE)
>   {
>-res = search_type_for_mask (rhs1, vinfo);
>-res2 = search_type_for_mask (gimple_assign_rhs2 (def_stmt),
>vinfo);
>+res = search_type_for_mask_1 (rhs1, vinfo, cache);
>+res2 = search_type_for_mask_1 (gimple_assign_rhs2 (def_stmt),
>+   vinfo, cache);
> if (!res || (res2 && TYPE_PRECISION (res) > TYPE_PRECISION
>(res2)))
>   res = res2;
> break;
>@@ -3526,12 +3530,18 @@ search_type_for_mask (tree var, vec_info
> 
> comp_vectype = get_vectype_for_scalar_type (TREE_TYPE (rhs1));
> if (comp_vectype == NULL_TREE)
>-  return NULL_TREE;
>+  {
>+res = NULL_TREE;
>+break;
>+  }
> 
> mask_type = get_mask_type_for_scalar_type (TREE_TYPE (rhs1));
> if (!mask_type
> || !expand_vec_cmp_expr_p (comp_vectype, mask_type))
>-  return NULL_TREE;
>+  {
>+res = NULL_TREE;
>+break;
>+  }
> 
> if (TREE_CODE (TREE_TYPE (rhs1)) != INTEGER_TYPE
> || !TYPE_UNSIGNED (TREE_TYPE (rhs1)))
>@@ -3544,9 +3554,21 @@ search_type_for_mask (tree var, vec_info
>   }
> }
> 
>+  cache.put (def_stmt, res);
>   return res;
> }
> 
>+/* Return the proper type for converting bool VAR into
>+   an integer value or NULL_TREE if no such type exists.
>+   The type is chosen so that converted value has the
>+   same number of elements as VAR's vector type.  */
>+
>+static tree
>+search_type_for_mask (tree var, vec_info *vinfo)
>+{
>+  hash_map cache;
>+  return search_type_for_mask_1 (var, vinfo, cache);
>+}
> 
> /* Function vect_recog_bool_pattern
> 
>--- gcc/testsuite/gcc.dg/vect/pr72866.c.jj 2016-08-29
>19:28:22.453646025 +0200
>+++ gcc/testsuite/gcc.dg/vect/pr72866.c2016-08-29 19:28:17.0
>+0200
>@@ -0,0 +1,19 @@
>+/* PR tree-optimization/72866 */
>+/* { dg-do compile } */
>+
>+unsigned int dl;
>+int rx, lb;
>+
>+void
>+fo (int jv, int be)
>+{
>+  const unsigned int xw = 16;
>+  unsigned int ya, wo;
>+
>+  for (ya = 0; ya < 2; ++ya)
>+for (wo = 0; wo < xw; ++wo)
>+  {
>+   

Go patch committed: add -fgo-c-header=FILE option

[Ian Lance Taylor]

This patch to the Go frontend adds a new option -fgo-c-header=FILE
that tells the Go frontend to create a C header file defining the
package scope constants and struct types.  This is a step toward
converting much of the runtime package from C to Go, in order to use
the new facilities in the master Go library, such as the concurrent
garbage collectors.  By having the Go compiler define these structs
and constants in C, we can ensure that the Go code and the C code are
operating on the same data structures during the transition from C to
Go.

This patch also adds a new option -fcompiling-runtime, to be used when
compiling the runtime package, although that option doesn't do
anything yet.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian


2016-08-29  Ian Lance Taylor  

* lang.opt (fgo-c-header, fgo-compiling-runtime): New options.
* go-c.h (struct go_create_gogo_args): Define.
(go_create_gogo): Change declaration to take struct pointer.
* go-lang.c (go_c_header): New static variable.
(go_langhook_init): Update call to go_create_gogo.
* gccgo.texi (Invoking gccgo): Document -fgo-c-header and
-fgo-compiling-runtime.
Index: gcc/go/gccgo.texi
===
--- gcc/go/gccgo.texi   (revision 239316)
+++ gcc/go/gccgo.texi   (working copy)
@@ -239,6 +239,17 @@ heap when possible.  In the future this
 Output escape analysis debugging information.  Larger values of
 @var{n} generate more information.
 
+@item -fgo-c-header=@var{file}
+@cindex @option{-fgo-c-header}
+Write top-level named Go struct definitions to @var{file} as C code.
+This is used when compiling the runtime package.
+
+@item -fgo-compiling-runtime
+@cindex @option{-fgo-compiling-runtime}
+Apply special rules for compiling the runtime package.  Implicit
+memory allocation is forbidden.  Some additional compiler directives
+are supported.
+
 @item -g
 @cindex @option{-g for gccgo}
 This is the standard @command{gcc} option (@pxref{Debugging Options, ,
Index: gcc/go/go-c.h
===
--- gcc/go/go-c.h   (revision 239002)
+++ gcc/go/go-c.h   (working copy)
@@ -31,11 +31,21 @@ extern int go_enable_optimize (const cha
 
 extern void go_add_search_path (const char*);
 
-extern void go_create_gogo (int int_type_size, int pointer_size,
-   const char* pkgpath, const char *prefix,
-   const char *relative_import_path,
-   bool check_divide_zero, bool check_divide_overflow,
-   int debug_escape_level);
+struct go_create_gogo_args
+{
+  int int_type_size;
+  int pointer_size;
+  const char* pkgpath;
+  const char *prefix;
+  const char *relative_import_path;
+  const char *c_header;
+  bool check_divide_by_zero;
+  bool check_divide_overflow;
+  bool compiling_runtime;
+  int debug_escape_level;
+};
+
+extern void go_create_gogo (const struct go_create_gogo_args*);
 
 extern void go_parse_input_files (const char**, unsigned int,
  bool only_check_syntax,
Index: gcc/go/go-lang.c
===
--- gcc/go/go-lang.c(revision 239002)
+++ gcc/go/go-lang.c(working copy)
@@ -83,6 +83,7 @@ struct GTY(()) language_function
 static const char *go_pkgpath = NULL;
 static const char *go_prefix = NULL;
 static const char *go_relative_import_path = NULL;
+static const char *go_c_header = NULL;
 
 /* Language hooks.  */
 
@@ -99,9 +100,18 @@ go_langhook_init (void)
  to, e.g., unsigned_char_type_node) but before calling
  build_common_builtin_nodes (because it calls, indirectly,
  go_type_for_size).  */
-  go_create_gogo (INT_TYPE_SIZE, POINTER_SIZE, go_pkgpath, go_prefix,
- go_relative_import_path, go_check_divide_zero,
- go_check_divide_overflow, go_debug_escape_level);
+  struct go_create_gogo_args args;
+  args.int_type_size = INT_TYPE_SIZE;
+  args.pointer_size = POINTER_SIZE;
+  args.pkgpath = go_pkgpath;
+  args.prefix = go_prefix;
+  args.relative_import_path = go_relative_import_path;
+  args.c_header = go_c_header;
+  args.check_divide_by_zero = go_check_divide_zero;
+  args.check_divide_overflow = go_check_divide_overflow;
+  args.compiling_runtime = go_compiling_runtime;
+  args.debug_escape_level = go_debug_escape_level;
+  go_create_gogo ();
 
   build_common_builtin_nodes ();
 
@@ -247,6 +257,10 @@ go_langhook_handle_option (
   go_relative_import_path = arg;
   break;
 
+case OPT_fgo_c_header_:
+  go_c_header = arg;
+  break;
+
 default:
   /* Just return 1 to indicate that the option is valid.  */
   break;
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 239708)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@

Re: [PATCH 3/4] (v2) Introduce class edit_context

[Trevor Saunders]

On Mon, Aug 29, 2016 at 02:53:43PM -0400, David Malcolm wrote:
> On Sun, 2016-08-28 at 11:13 -0400, Trevor Saunders wrote:
> > On Wed, Aug 24, 2016 at 09:13:51PM -0400, David Malcolm wrote:
> > > +
> > > +  const char *m_filename;
> > > +  char *m_content;
> > > +  size_t m_len;
> > > +  size_t m_alloc_sz;
> > > +  typed_splay_tree m_edited_lines;
> > > +  auto_vec m_line_start_index;
> > 
> > have you considered parsing lines when you read the file, and then
> > storing a vec where element I is line I in the file?  Its
> > more
> > allocations, but when you need to edit a line you'll only need to
> > copy
> > around that line instead of the whole rest of the file.
> 
> ...yes, though I'd put the content into class edited_line.  Unedited
> lines come from input.c's source cache; we can look up edited lines by
> number using the splay tree in class edited_file.   That ought to be
> much more efficient that my current "store the whole file in class
> edited_file" implementation, and this efficiency would help if we want
> to use class edit_context in diagnostic-show-locus.c for printing fix
> -it hints, to show the region of the line that's been touched by a fix
> -it
> (see https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01816.html )

yeah, that does sound even better.

> > > +class replace_event : public line_event
> > > +{
> > > + public:
> > > +  replace_event (int start, int finish, int len) : m_start
> > > (start),
> > > +m_finish (finish), m_delta (len - (finish + 1 - start)) {}
> > > +
> > > +  int get_effective_column (int orig_column) const FINAL OVERRIDE
> > > +  {
> > > +if (orig_column >= m_start)
> > > +  return orig_column += m_delta;
> > > +else
> > > +  return orig_column;
> > 
> > What happens when orig_column is within the text being replaced?
> 
> I think I want to rule that as invalid: that it's not valid to have
> overlapping "replace" fixits, and that (ideally) attempts to do so
> ought to be rejected within rich_location (they aren't yet rejected at
> the moment).

yeah, that is the simple solution ;)

> 
> > > +  }
> > > +
> > > + private:
> > > +  int m_start;
> > > +  int m_finish;
> > > +  int m_delta;
> > > +};
> > 
> > It seems like it would greatly simplify things to merge fixit_insert
> > and
> > fixit_replace so that an insertion is just a replacement where the
> > start
> > and end of the replaced text are the same.  That would also have the
> > nice effect of making fixit_replace smaller since you wouldn't need
> > the
> > vtable any more.
> 
> That occurred to me.  IIRC clang does this, but their source ranges are
> half-open, whereas ours are closed (I don't remember why, only that it
> made sense at the time...).  Maybe we could just put a bool into the
> combined class, and if an insert, then ignore the range's finish
> location.

yeah, that is a complication to be thought about.

> 
> > > +change_line (edit_context , int line_num)
> > 
> > I guess this is test only, put I'm not a fan of non const references.
> 
> Out of interest, how would you have written it?

probably just using a pointer.  the nonnull template in the GSL would be
nice, but I'm not sure if I care enough to backport it to C++98.

Trev

> 
> > Trev
> 
> Thank
> Dave

Re: [PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

[Mike Stump]

On Aug 29, 2016, at 12:41 PM, Jakub Jelinek  wrote:
> 
> This testcase expects to find DWARF extensions, but those are disabled by
> default on darwin/vxworks because broken tools there don't handle debug info
> very well.
> 
> I think the following patch (regtested on x86_64-linux and i686-linux)
> should fix it, but I have no access to darwin, so can't verify.
> 
> Ok for trunk?

Ok.  :-)

> 
> 2016-08-29  Jakub Jelinek  
> 
>   PR debug/77389
>   * g++.dg/debug/dwarf2/template-params-12f.C: Pass -gno-strict-dwarf
>   in dg-options.

Re: [PATCH] Eradicate MQ some more

[David Edelsohn]

On Mon, Aug 29, 2016 at 7:58 PM, Segher Boessenkool
 wrote:
> Nothing uses MQ anymore, but it still shows up in all the dump files.
> This patch removes it from CALL_REALLY_USED_REGISTERS so that that does
> not happen anymore (it is still a fixed register, there should be no
> functional change).
>
> Bootstrapped and regression tested on powerpc64-linux, -m32,-m64.  Is
> this okay for trunk?

Okay.  *sniff* ;-)

Thanks, David

Re: PR35503 - warn for restrict pointer

[David Malcolm]

On Mon, 2016-08-29 at 20:01 -0400, David Malcolm wrote:
> On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
> [...]
> > Assuming you have the location_t values available, you can create a
> > rich_location for the primary range, and then add secondary ranges
> > like
> > this:
> > 
> >   rich_location richloc (loc_of_arg1);
> 
> Oops, the above should be:
> 
> rich_location richloc (line_table, loc_of_arg1);
> 
> or:
> 
> gcc_rich_location (loc_of_arg1);
and this should be:

 gcc_rich_location richloc (loc_of_arg1);
> which does the same thing (#include "gcc-rich-location.h").

Clearly I need to sleep :)

> >   richloc.add_range (loc_of_arg3, false);  /* false here = don't
> > draw
> > a
> > caret, just the underline */
> >   richloc.add_range (loc_of_arg4, false);
> >   warning_at_rich_loc (, OPT_Wrestrict, etc...
> > 
> > See line-map.h for more information on rich_location.
> 
> [...]

Re: PR35503 - warn for restrict pointer

[David Malcolm]

On Mon, 2016-08-29 at 19:55 -0400, David Malcolm wrote:
[...]
> Assuming you have the location_t values available, you can create a
> rich_location for the primary range, and then add secondary ranges
> like
> this:
> 
>   rich_location richloc (loc_of_arg1);

Oops, the above should be:

rich_location richloc (line_table, loc_of_arg1);

or:

gcc_rich_location (loc_of_arg1);

which does the same thing (#include "gcc-rich-location.h").

>   richloc.add_range (loc_of_arg3, false);  /* false here = don't draw
> a
> caret, just the underline */
>   richloc.add_range (loc_of_arg4, false);
>   warning_at_rich_loc (, OPT_Wrestrict, etc...
> 
> See line-map.h for more information on rich_location.

[...]

[PATCH] Eradicate MQ some more

[Segher Boessenkool]

Nothing uses MQ anymore, but it still shows up in all the dump files.
This patch removes it from CALL_REALLY_USED_REGISTERS so that that does
not happen anymore (it is still a fixed register, there should be no
functional change).

Bootstrapped and regression tested on powerpc64-linux, -m32,-m64.  Is
this okay for trunk?


Segher


2016-08-29  Segher Boessenkool  

* config/rs6000/rs6000.h (CALL_REALLY_USED_REGISTERS): Do not
include MQ.

---
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 1609abd..4382190 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1120,7 +1120,7 @@ enum data_align { align_abi, align_opt, align_both };
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
-   1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, \
+   0, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, \
/* AltiVec registers.  */  \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
-- 
1.9.3

Re: PR35503 - warn for restrict pointer

[David Malcolm]

On Tue, 2016-08-30 at 03:23 +0530, Prathamesh Kulkarni wrote:
> On 29 August 2016 at 19:59, Marek Polacek  wrote:
> > On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
> > > Prathamesh Kulkarni wrote:
> > > > Attachment: pr35503-3.txt
> > > 
> > > I tried the patch - and it found a bug in our code; nice!
> > > 
> > > 
> > > (a) Regarding the [-Werror] output:
> > > 
> > >error: passing argument 24 to restrict qualified parameter
> > > aliases with argument 29 [-Werror]
> > > 
> > > Shouldn't that output "[-Werror=restrict]" instead of a bare "[
> > > -Werror]? Namely, instead of
> > > 
> > > + warning_at (loc, 0,
> > > + "passing argument %u to restrict qualified
> > > parameter aliases with "
> > > + "argument %u", param_pos + 1, i + 1);
> > > 
> > > I think one gets this with
> > > warning_at (loc, OPT_Wrestrict, ...
> > 
> > Yes, this needs to be fixed in the patch.
> Hi,
> Thanks for all the suggestions, I have tried to incorporate them in
> the attached version.
> To avoid duplicating the warnings for multiple aliased arguments,
> I am using TREE_VISITED to mark all the aliased arguments of the
> current
> arg, which makes diagnostic emitted only once per same set of
> aliases.
> Is using TREE_VISITED ok as in the patch ?
> 
> eg:
> void f(int *__restrict x, int *y, int *__restrict z, int *w);
> 
> void foo(int a, int b)
> {
>   f (, , , );
> }
> 
> Output:
> test-2.c: In function ‘foo’:
> test-2.c:5:6: warning: passing argument 1 to restrict-qualified
> parameter aliases with arguments 3, 4 [-Wrestrict]
>f (, , , );
>^~
> 
> Using EXPR_LOCATION (arg), helps underline the argument for both C
> and C++
> as in the example above. However in case of variadic functions, it
> appears C++FE doesn't set EXPR_LOCATION,
> so I am falling back to using input_location if EXPR_LOCATION is
> unknown.

You may be able to use EXPR_LOC_OR_LOC for this.

> However it gives the location correctly for non-variadic functions.
> For setting locations correctly I will try the approach suggested by
> Jason in
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01987.html
> 
> I was wondering how to underline all the aliased arguments ?
> I would like to see the output for above eg as:
> 
> test-2.c: In function ‘foo’:
> test-2.c:5:6: warning: passing argument 1 to restrict-qualified
> parameter aliases with arguments 3, 4 [-Wrestrict]
>f (, , , );
>^~~~   ~~
> 
> I would be grateful for suggestions for the same.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu.


The above came through email a bit mangled; presumably you mean:

   f (, , , );
  ^~  ~~  ~~ 

(hopefully Evolution won't mangle the above).

Assuming you have the location_t values available, you can create a
rich_location for the primary range, and then add secondary ranges like
this:

  rich_location richloc (loc_of_arg1);
  richloc.add_range (loc_of_arg3, false);  /* false here = don't draw a
caret, just the underline */
  richloc.add_range (loc_of_arg4, false);
  warning_at_rich_loc (, OPT_Wrestrict, etc...

See line-map.h for more information on rich_location.

Currently we can only have up to 3 ranges in a rich_location; I have a
patch in one of my working copies that fixes that so we can have an
arbitrary number; I'll try to dig that out as it's clearly relevant
here.

It's a good idea to have a testcase that verifies the underlines.

Use:

  /* { dg-options "-fdiagnostics-show-caret" } */

and then use:

  /* { dg-begin-multiline-output "" }
quote the expected output here, omitting trailing dg-directives
 { dg-end-multiline-output "" } */

e.g.
  /* { dg-begin-multiline-output "" }
   f (, , , );
  ^~  ~~  ~~ 
 { dg-end-multiline-output "" } */

Please use identifiers that are longer than one char in such a test, since 
otherwise there's a chance that we're not properly underlining all of the 
pertinent range (i.e. testing the start != finish case).

Hope the above is helpful
Dave

Re: [PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

[Dominique d'Humières]

Preliminary tests show that the patch fixes the issue.

Thanks,

Dominique

> Le 29 août 2016 à 21:41, Jakub Jelinek  a écrit :
> 
> Hi!
> 
> This testcase expects to find DWARF extensions, but those are disabled by
> default on darwin/vxworks because broken tools there don't handle debug info
> very well.
> 
> I think the following patch (regtested on x86_64-linux and i686-linux)
> should fix it, but I have no access to darwin, so can't verify.
> 
> Ok for trunk?
> 
> 2016-08-29  Jakub Jelinek  
> 
>   PR debug/77389
>   * g++.dg/debug/dwarf2/template-params-12f.C: Pass -gno-strict-dwarf
>   in dg-options.
> 
> --- gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C.jj
> 2016-08-12 11:12:46.0 +0200
> +++ gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C   2016-08-29 
> 12:39:54.562411107 +0200
> @@ -1,4 +1,4 @@
> -// { dg-options "-gdwarf-2 -dA" }
> +// { dg-options "-gdwarf-2 -gno-strict-dwarf -dA" }
> // { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
> DW_TAG_template_value_param" 1 } }
> // { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
> DW_TAG_template_value_param\[^\n\]*\n\[^\n\]* DW_AT_name\n\[^\n\]* 
> DW_AT_type\n\[^\n\]*\[^\n\]* DW_AT_location\n\[^\n\]* 
> DW_OP_addr\n\[^\n\]*_ZN1S1fEv\[^\n\]*\n\[^\n\]* DW_OP_stack_value\n\[^\n\]* 
> DW_OP_piece\n\[^\n\]*\n\[^\n\]* DW_OP_lit0\n\[^\n\]* 
> DW_OP_stack_value\n\[^\n\]* DW_OP_piece" 1 } }
> #include "template-params-12.H"
> 
>   Jakub

Re: PR35503 - warn for restrict pointer

[Prathamesh Kulkarni]

On 29 August 2016 at 19:59, Marek Polacek  wrote:
> On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
>> Prathamesh Kulkarni wrote:
>> > Attachment: pr35503-3.txt
>>
>> I tried the patch - and it found a bug in our code; nice!
>>
>>
>> (a) Regarding the [-Werror] output:
>>
>>error: passing argument 24 to restrict qualified parameter aliases with 
>> argument 29 [-Werror]
>>
>> Shouldn't that output "[-Werror=restrict]" instead of a bare "[-Werror]? 
>> Namely, instead of
>>
>> + warning_at (loc, 0,
>> + "passing argument %u to restrict qualified parameter 
>> aliases with "
>> + "argument %u", param_pos + 1, i + 1);
>>
>> I think one gets this with
>> warning_at (loc, OPT_Wrestrict, ...
>
> Yes, this needs to be fixed in the patch.
Hi,
Thanks for all the suggestions, I have tried to incorporate them in
the attached version.
To avoid duplicating the warnings for multiple aliased arguments,
I am using TREE_VISITED to mark all the aliased arguments of the current
arg, which makes diagnostic emitted only once per same set of aliases.
Is using TREE_VISITED ok as in the patch ?

eg:
void f(int *__restrict x, int *y, int *__restrict z, int *w);

void foo(int a, int b)
{
  f (, , , );
}

Output:
test-2.c: In function ‘foo’:
test-2.c:5:6: warning: passing argument 1 to restrict-qualified
parameter aliases with arguments 3, 4 [-Wrestrict]
   f (, , , );
   ^~

Using EXPR_LOCATION (arg), helps underline the argument for both C and C++
as in the example above. However in case of variadic functions, it
appears C++FE doesn't set EXPR_LOCATION,
so I am falling back to using input_location if EXPR_LOCATION is unknown.
However it gives the location correctly for non-variadic functions.
For setting locations correctly I will try the approach suggested by Jason in
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01987.html

I was wondering how to underline all the aliased arguments ?
I would like to see the output for above eg as:

test-2.c: In function ‘foo’:
test-2.c:5:6: warning: passing argument 1 to restrict-qualified
parameter aliases with arguments 3, 4 [-Wrestrict]
   f (, , , );
   ^~~~   ~~

I would be grateful for suggestions for the same.
Bootstrap+test in progress on x86_64-unknown-linux-gnu.

Thanks,
Prathamesh
>
> Marek
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 3feb910..abb92b3 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -13057,4 +13057,76 @@ diagnose_mismatched_attributes (tree olddecl, tree 
newdecl)
   return warned;
 }
 
+/* Warn if an argument at position param_pos is passed to a
+   restrict-qualified param, and it aliases with another argument.  */
+
+void
+warn_for_restrict (unsigned param_pos, vec *args)
+{
+  tree arg = (*args)[param_pos];
+  if (TREE_VISITED (arg))
+return;
+
+  location_t loc = (EXPR_LOCATION (arg) != UNKNOWN_LOCATION)
+  ? EXPR_LOCATION (arg)
+  : input_location;
+
+  if (operand_equal_p (arg, null_pointer_node, 0))
+return;
+
+  unsigned i;
+  tree current_arg;
+  auto_vec arg_positions;
+
+  FOR_EACH_VEC_ELT (*args, i, current_arg) 
+{
+  if (i == param_pos)
+   continue;
+
+  tree current_arg = (*args)[i];
+  if (operand_equal_p (arg, current_arg, 0))
+   {
+ TREE_VISITED (current_arg) = 1; 
+ arg_positions.safe_push (i);
+   }
+}
+
+  if (arg_positions.is_empty ())
+return;
+
+  struct obstack fmt_obstack;
+  gcc_obstack_init (_obstack);
+  char *fmt = (char *) obstack_alloc (_obstack, 0);
+
+  char num[32];
+  sprintf (num, "%u", param_pos + 1);
+
+  obstack_grow (_obstack, "passing argument ",
+   strlen ("passing argument "));
+  obstack_grow (_obstack, num, strlen (num));
+  obstack_grow (_obstack,
+   " to restrict-qualified parameter aliases with argument",
+   strlen (" to restrict-qualified parameter "
+   "aliases with argument"));
+
+  /* make argument plural and append space.  */
+  if (arg_positions.length () > 1)
+obstack_1grow (_obstack, 's');
+  obstack_1grow (_obstack, ' ');
+
+  unsigned pos;
+  FOR_EACH_VEC_ELT (arg_positions, i, pos)
+{
+  sprintf (num, "%u", pos + 1);
+  obstack_grow (_obstack, num, strlen (num));
+
+  if (i < arg_positions.length () - 1)
+   obstack_grow (_obstack, ", ",  strlen (", "));
+}
+
+  obstack_1grow (_obstack, 0);
+  warning_at (loc, OPT_Wrestrict, fmt);
+  obstack_free (_obstack, fmt);
+}
+
 #include "gt-c-family-c-common.h"
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index bc22baa..cdb762e 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -920,6 +920,7 @@ extern void c_parse_final_cleanups (void);
 
 extern void warn_for_omitted_condop (location_t, tree);
 extern void warn_for_memset (location_t, tree, tree, int);
+extern void warn_for_restrict 

Re: [PATCH 1/4] selftest: split out named_temp_file from temp_source_file

[Bernd Schmidt]

On 08/25/2016 03:13 AM, David Malcolm wrote:

Split out a new base class for temp_source_file, named_temp_file,
moving the deletion to the base class dtor, so that we can write
out temporary files in other ways in selftests.

gcc/ChangeLog:
* selftest.c (selftest::named_temp_file::named_temp_file): New
ctor.
(selftest::temp_source_file::~temp_source_file): Move to...
(selftest::named_temp_file::~named_temp_file): ...here.
(selftest::test_named_temp_file): New function.
(selftest::selftest_c_tests): Call test_named_temp_file.
* selftest.h (class named_temp_file): New class.
(class temp_source_file): Convert to a subclass of named_temp_file.


Ok.


+selftest::named_temp_file::named_temp_file (const char *suffix)


Any reason these aren't inside namespace selftest to shorten these 
declarations?



Bernd

[patch] Fix PR72715

[Cesar Philippidis]

It looks like the fortran FE has some preliminary support for do
concurrent loops, however it was not well tested, nor is do concurrent
supported by the OpenACC spec. This patch teaches the fortran FE to
error when an acc loop directive is applied to a do concurrent loop.

The reason why the existing do concurrent wasn't detected earlier is
because the only tests that utilized do concurrent loops contained other
expected failures, therefore the FE never successfully left the resolver
stage. And this ICE occurred as the loop was being translated into gimple.

There's one other questionably use of EXEC_DO_CONCURRENT that involves
the OpenACC cache directive. I've decided to leave gfc_exec_oacc_cache
alone for the time being because the OpenACC spec does not explicitly
define what it means by 'loop'. Then again, the user isn't required to
explicitly mark acc loops inside acc kernels regions, so perhaps it
would be better to leave the end user with more flexibility. On the
other hand, it's debatable whether do concurrent loops should even be
permitted inside acc offloaded regions.

I've applied this patch to gomp-4_0-branch. Is this OK for trunk, gcc-6
and gcc-5?

Cesar
2016-08-29  Cesar Philippidis  

	PR fortran/72715

	gcc/fortran/
	* openmp.c (resolve_oacc_nested_loops): Error on do concurrent loops.

	gcc/testsuite/
	* gfortran.dg/goacc/loop-3-2.f95: Error on do concurrent loops.
	* gfortran.dg/goacc/loop-3.f95: Likewise.
	* gfortran.dg/goacc/pr72715.f90: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index cea37ea..83c6419 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -4998,7 +4998,13 @@ resolve_oacc_nested_loops (gfc_code *code, gfc_code* do_code, int collapse,
 		 "at %L", _code->loc);
 	  break;
 	}
-  gcc_assert (do_code->op == EXEC_DO || do_code->op == EXEC_DO_CONCURRENT);
+  if (do_code->op == EXEC_DO_CONCURRENT)
+	{
+	  gfc_error ("!$ACC LOOP cannot be a DO CONCURRENT loop at %L",
+		 _code->loc);
+	  break;
+	}
+  gcc_assert (do_code->op == EXEC_DO);
   if (do_code->ext.iterator->var->ts.type != BT_INTEGER)
 	gfc_error ("!$ACC LOOP iteration variable must be of type integer at %L",
 		   _code->loc);
diff --git a/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95 b/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
index 9be74a8..c091084 100644
--- a/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
+++ b/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
@@ -27,9 +27,9 @@ subroutine test1
   !$acc end parallel
   !$acc end loop ! { dg-error "Unexpected" }
 
-  ! OpenACC supports Fortran 2008 do concurrent statement
+  ! OpenACC does not support Fortran 2008 do concurrent statement
   !$acc loop
-  do concurrent (i = 1:5)
+  do concurrent (i = 1:5) ! { dg-error "ACC LOOP cannot be a DO CONCURRENT loop" }
   end do
 
   !$acc loop
diff --git a/gcc/testsuite/gfortran.dg/goacc/loop-3.f95 b/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
index 30930f4..ed3e8d5 100644
--- a/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
+++ b/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
@@ -24,9 +24,9 @@ subroutine test1
   !$acc end parallel
   !$acc end loop ! { dg-error "Unexpected" }
 
-  ! OpenACC supports Fortran 2008 do concurrent statement
+  ! OpenACC does not support Fortran 2008 do concurrent statement
   !$acc loop
-  do concurrent (i = 1:5)
+  do concurrent (i = 1:5) ! { dg-error "ACC LOOP cannot be a DO CONCURRENT loop" }
   end do
 
   !$acc loop
diff --git a/gcc/testsuite/gfortran.dg/goacc/pr72715.f90 b/gcc/testsuite/gfortran.dg/goacc/pr72715.f90
new file mode 100644
index 000..68580f9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/pr72715.f90
@@ -0,0 +1,6 @@
+program p
+  integer :: i
+  !$acc loop
+  do concurrent (i=1:3) ! { dg-error "ACC LOOP cannot be a DO CONCURRENT loop" }
+  end do
+end program p

Re: [PATCH][msp430] Don't output __interrupt_vector sections for weak functions

[DJ Delorie]

Which results in a more user-obvious case, ignoring the interrupt
attribute or ignoring the weak attribute?  I would think that we never
want to compile and link successfully if we can't do what the user
wants, and omitting an interrupt handler is... bad.

I think this should either be a hard error, so the user must fix it
right away, or ignore the weak, which results in a linker error
(somehow? maybe?) if the user specifies two handlers for the same
interrupt.

[committed] Allow the use of ad-hoc locations for fix-it hints

[David Malcolm]

On Mon, 2016-08-29 at 13:43 -0400, David Malcolm wrote:
> On Mon, 2016-08-29 at 08:50 -0400, David Malcolm wrote:
> > On Mon, 2016-08-29 at 13:44 +0200, Marek Polacek wrote:
> > > On Mon, Aug 29, 2016 at 12:35:38PM +0200, Marek Polacek wrote:
> > > > On Mon, Aug 29, 2016 at 11:16:25AM +0200, Andreas Schwab wrote:
> > > > > On Aug 25 2016, Marek Polacek  wrote:
> > > > > 
> > > > > > * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> > > > > 
> > > > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11
> > > > >  expected multiline pattern lines 13-17 not found: "\s*r \+=
> > > > > !aaa
> > > > > == bbb;.*\n \^~\n   r \+= !aaa == bbb;.*\n   
> > > > >  \^~~~\n\(   \).*\n"
> > > > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11
> > > > > (test for excess errors)
> > > > > Excess errors:
> > > > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > > > applied" } */
> > > > >  ^~
> > > > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > > > applied" } */
> > > > > ^~~~
> > > > 
> > > > This has regressed with David's
> > > > 
> > > > commit 367964faf71a99ebd511dffb81075b58bff345a1
> > > > Author: dmalcolm  > > > >
> > > > Date:   Fri Aug 26 21:25:41 2016 +
> > > > 
> > > > Add validation and consolidation of fix-it hints
> > > > 
> > > > I don't know yet what exactly went wrong here.
> > > 
> > > So we reject printing fix-it hint because in
> > > reject_impossible_fixit:
> > > 
> > > 2187   if (where <= LINE_MAP_MAX_LOCATION_WITH_COLS)
> > > 2188 /* WHERE is a reasonable location for a fix-it; don't
> > > reject
> > > it.  */
> > > 2189 return false;
> > > 
> > > (gdb) p where
> > > $1 = 2147483652
> > > (gdb) p LINE_MAP_MAX_LOCATION_WITH_COLS
> > > $2 = 1610612736
> > > 
> > > so we set m_seen_impossible_fixit.
> > > 
> > > David, why is that happening?
> > 
> > Sorry about this; I believe I did my testing of my patch against a
> > tree
> > that didn't yet have your change.
> > 
> > (gdb) p /x 2147483652
> > $2 = 0x8004
> > 
> > so "where", the insertion-point, is an ad-hoc location (describing
> > a
> > range), and it looks like I somehow forgot to deal with that case
> > in
> > the validation code.
> > 
> > I'm working on a fix.  Sorry again.
> 
> The issue affected the C++ frontend, but not the C frontend.
> 
> The root cause was that a location expressing a packed range was
> passed to a make_location call as the "start" parameter.
> make_location was converting the caret to a pure location (stripping
> away the packed range), but wasn't doing this for the "start"
> parameter.
> This meant that caret != start, despite them being the same
> file/line/col, due to the latter containing packed range information.
> This was handled by make_location by creating an ad-hoc location, and
> fixit-validation doesn't yet handle ad-hoc locations for insertion
> fixits, only pure locations.
> 
> The following patch fixes the issue seen in this specific case by
> fixing make_location to avoid storing ranges for the endpoints of a
> range, and thus avoid generating ad-hoc locations.  If a location
> containing a range is passed as start or finish to make_location, it
> will use the start/finish of that range respectively.
> 
> I'm working on a followup fix to make the fixit-validation code
> better handle any ad-hoc locations that do make it through.

Currently the fix-it validator rejects ad-hoc locations.
Fix this by calling get_pure_location on the input locations to
add_fixit_insert/replace.  Doing so requires moving get_pure_location
from gcc to libcpp.

Successfully bootstrapped on x86_64-pc-linux-gnu.

Committed to trunk as r239843.

gcc/ChangeLog:
* diagnostic-show-locus.c
(selftest::test_one_liner_fixit_validation_adhoc_locations): New
function.
(selftest::test_diagnostic_show_locus_one_liner): Call it.
* input.c (get_pure_location): Move to libcpp/line-map.c.
* input.h (get_pure_location): Convert decl to an inline function
calling implementation in libcpp.

libcpp/ChangeLog:
* include/line-map.h (get_pure_location): New decl.
* line-map.c (get_pure_location): Move here, from gcc/input.c, adding
a line_maps * param.
(rich_location::add_fixit_insert): Call get_pure_location on "where".
(rich_location::add_fixit_replace): Call get_pure_location on the
end-points.
---
 gcc/diagnostic-show-locus.c | 70 +
 gcc/input.c | 22 --
 gcc/input.h |  6 +++-
 libcpp/include/line-map.h   |  6 
 libcpp/line-map.c   | 27 +
 5 files changed, 108 insertions(+), 23 deletions(-)

diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index f3f661e..ba52f24 100644
--- a/gcc/diagnostic-show-locus.c
+++ 

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

[Segher Boessenkool]

On Mon, Aug 29, 2016 at 10:19:25PM +0200, Steven Bosscher wrote:
> On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote:
> > This patch changes that so that that def is only added after
> > epilogue_completed.
> ...
> > Does this work on all other targets?
> 
> Guessing: not for targets where INCOMING_RETURN_ADDR_RTX is the stack 
> register?
> That'd be at least h8300, rl78, and rx.

The stack pointer is always added (earlier in this function):

  /* The always important stack pointer.  */
  bitmap_set_bit (entry_block_defs, STACK_POINTER_REGNUM);

so that isn't it.

History suggests it was a fix (or workaround) for a problem on ia64,
but I might well have that wrong.


Segher

Re: [PATCH] df: Keep return address register undefined until epilogue_completed

[Steven Bosscher]

On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote:
> This patch changes that so that that def is only added after
> epilogue_completed.
...
> Does this work on all other targets?

Guessing: not for targets where INCOMING_RETURN_ADDR_RTX is the stack register?
That'd be at least h8300, rl78, and rx.

Ciao!
Steven

[PATCH] Fix abi_tag23* test failure (PR c++/77379)

[Jakub Jelinek]

On Mon, Aug 29, 2016 at 12:42:28PM -0400, Jason Merrill wrote:
> Another missing ABI tag, sigh.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

> commit 1337a943a2d3926537b63d6e1f0d7f46ef10a06d
> Author: Jason Merrill 
> Date:   Fri Aug 26 15:12:52 2016 -0400
> 
>   PR c++/77379 - ABI tag on thunk
> 
>   * mangle.c (maybe_check_abi_tags): Add version parm, handle thunks.
>   (mangle_thunk): Add thunk parameter.
>   * method.c (finish_thunk): Pass it.
>   * cp-tree.h: Declare it.

> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/abi/abi-tag23.C
> +// { dg-final { scan-assembler "_ZThn16_N7Derived7get_fooB3barEv" } }

This unfortunately fails e.g. on i686-linux, because the symbol is
_ZThn8_N7Derived7get_fooB3barEv instead of
_ZThn16_N7Derived7get_fooB3barEv

The following patch accepts any negative offsets.  Tested on x86_64-linux
and i686-linux, ok for trunk?

2016-08-29  Jakub Jelinek  

PR c++/77379
* g++.dg/abi/abi-tag23.C: Adjust scan-assembler regex for differing
thunk offsets.
* g++.dg/abi/abi-tag23a.C: Likewise.

--- gcc/g++.dg/abi/abi-tag23.C.jj   2016-08-29 19:34:12.0 +0200
+++ gcc/g++.dg/abi/abi-tag23.C  2016-08-29 22:04:16.328873328 +0200
@@ -32,4 +32,4 @@ int main()
   Final().get_foo();
 }
 
-// { dg-final { scan-assembler "_ZThn16_N7Derived7get_fooB3barEv" } }
+// { dg-final { scan-assembler "_ZThn\[0-9]+_N7Derived7get_fooB3barEv" } }
--- gcc/g++.dg/abi/abi-tag23a.C.jj  2016-08-29 19:34:12.0 +0200
+++ gcc/g++.dg/abi/abi-tag23a.C 2016-08-29 22:04:55.053398520 +0200
@@ -32,4 +32,4 @@ int main()
   Final().get_foo();
 }
 
-// { dg-final { scan-assembler "_ZThn16_N7Derived7get_fooEv" } }
+// { dg-final { scan-assembler "_ZThn\[0-9]+_N7Derived7get_fooEv" } }


Jakub

Re: Implement -Wimplicit-fallthrough (version 7)

[Jason Merrill]

On Mon, Aug 29, 2016 at 7:58 AM, Marek Polacek  wrote:
> --- gcc/gcc/cp/parser.c
> +++ gcc/gcc/cp/parser.c
> @@ -5135,6 +5135,31 @@ cp_parser_primary_expression (cp_parser *parser,
> case RID_AT_SELECTOR:
>   return cp_parser_objc_expression (parser);
>
> +   case RID_ATTRIBUTE:
> + {
> +   /* This might be __attribute__((fallthrough));.  */
> +   tree attr = cp_parser_gnu_attributes_opt (parser);
> +   if (attr != NULL_TREE
> +   && is_attribute_p ("fallthrough", get_attribute_name (attr)))
> + {
> +   tree fn = build_call_expr_internal_loc (token->location,
> +   IFN_FALLTHROUGH,
> +   void_type_node, 0);
> +   return cp_expr (fn, token->location);
> + }
> +   else if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON))
> + {
> +   cp_parser_error (parser, "only attribute % "
> +"can be used");

Let's say "can be applied to a null statement".

> @@ -10585,15 +10610,26 @@ cp_parser_statement (cp_parser* parser, tree 
> in_statement_expr,
> }
>/* Look for an expression-statement instead.  */
>statement = cp_parser_expression_statement (parser, in_statement_expr);
> +
> +  /* Handle [[fallthrough]];.  */
> +  if (std_attrs != NULL_TREE
> + && is_attribute_p ("fallthrough", get_attribute_name (std_attrs))
> + && statement == NULL_TREE)
> +   {
> + tree fn = build_call_expr_internal_loc (statement_location,
> + IFN_FALLTHROUGH,
> + void_type_node, 0);

Let's use the 'statement' variable rather than a new variable fn so
that we set the call's location below.  Let's also warn here about
[[fallthrough]] on non-null expression statements.

> + finish_expr_stmt (fn);

Let's clear std_attrs here...

> +   }

>/* Set the line number for the statement.  */
>if (statement && STATEMENT_CODE_P (TREE_CODE (statement)))
>  SET_EXPR_LOCATION (statement, statement_location);
>
> -  /* Note that for now, we don't do anything with c++11 statements
> - parsed at this level.  */
> -  if (std_attrs != NULL_TREE)
> +  /* Allow "[[fallthrough]];", but warn otherwise.  */
> +  if (std_attrs != NULL_TREE
> +  && !is_attribute_p ("fallthrough", get_attribute_name (std_attrs)))

...so we don't need to check for fallthrough here.

> @@ -24114,6 +24164,16 @@ cp_parser_std_attribute (cp_parser *parser)
>  " use %");
>   TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
> }
> +  /* C++17 fallthrough attribute is equivalent to GNU's.  */
> +  else if (cxx_dialect >= cxx11

There's no point checking this, here or for attribute deprecated; if
we're in this function, we must be in C++11 or above.  Let's drop the
check in both places.

Jason

[PATCH] Fix compile time complexity of search_type_for_mask (PR tree-optimization/72866)

[Jakub Jelinek]

Hi!

As the testcase shows, with deep chains of COND_EXPRs with the same
SSA_NAMEs appearing more than once in the various operands we can
hang in search_type_for_mask.  Similar check_bool_pattern function
uses a hash_set to handle stmts that have been checked already, this patch
uses a hash_map in which we cache the return values once we've handled some
stmt already.

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

2016-08-29  Jakub Jelinek  

PR tree-optimization/72866
* tree-vect-patterns.c (search_type_for_mask): Turn into
a small wrapper, move all code to ...
(search_type_for_mask_1): ... this new function.  Add caching
and adjust recursive calls.

* gcc.dg/vect/pr72866.c: New test.

--- gcc/tree-vect-patterns.c.jj 2016-07-21 08:59:55.0 +0200
+++ gcc/tree-vect-patterns.c2016-08-29 19:26:12.807164641 +0200
@@ -3459,13 +3459,11 @@ adjust_bool_stmts (hash_set  &
   return gimple_assign_lhs (pattern_stmt);
 }
 
-/* Return the proper type for converting bool VAR into
-   an integer value or NULL_TREE if no such type exists.
-   The type is chosen so that converted value has the
-   same number of elements as VAR's vector type.  */
+/* Helper for search_type_for_mask.  */
 
 static tree
-search_type_for_mask (tree var, vec_info *vinfo)
+search_type_for_mask_1 (tree var, vec_info *vinfo,
+   hash_map )
 {
   gimple *def_stmt;
   enum vect_def_type dt;
@@ -3490,6 +3488,10 @@ search_type_for_mask (tree var, vec_info
   if (!is_gimple_assign (def_stmt))
 return NULL_TREE;
 
+  tree *c = cache.get (def_stmt);
+  if (c)
+return *c;
+
   rhs_code = gimple_assign_rhs_code (def_stmt);
   rhs1 = gimple_assign_rhs1 (def_stmt);
 
@@ -3498,14 +3500,15 @@ search_type_for_mask (tree var, vec_info
 case SSA_NAME:
 case BIT_NOT_EXPR:
 CASE_CONVERT:
-  res = search_type_for_mask (rhs1, vinfo);
+  res = search_type_for_mask_1 (rhs1, vinfo, cache);
   break;
 
 case BIT_AND_EXPR:
 case BIT_IOR_EXPR:
 case BIT_XOR_EXPR:
-  res = search_type_for_mask (rhs1, vinfo);
-  res2 = search_type_for_mask (gimple_assign_rhs2 (def_stmt), vinfo);
+  res = search_type_for_mask_1 (rhs1, vinfo, cache);
+  res2 = search_type_for_mask_1 (gimple_assign_rhs2 (def_stmt), vinfo,
+cache);
   if (!res || (res2 && TYPE_PRECISION (res) > TYPE_PRECISION (res2)))
res = res2;
   break;
@@ -3517,8 +3520,9 @@ search_type_for_mask (tree var, vec_info
 
  if (TREE_CODE (TREE_TYPE (rhs1)) == BOOLEAN_TYPE)
{
- res = search_type_for_mask (rhs1, vinfo);
- res2 = search_type_for_mask (gimple_assign_rhs2 (def_stmt), 
vinfo);
+ res = search_type_for_mask_1 (rhs1, vinfo, cache);
+ res2 = search_type_for_mask_1 (gimple_assign_rhs2 (def_stmt),
+vinfo, cache);
  if (!res || (res2 && TYPE_PRECISION (res) > TYPE_PRECISION 
(res2)))
res = res2;
  break;
@@ -3526,12 +3530,18 @@ search_type_for_mask (tree var, vec_info
 
  comp_vectype = get_vectype_for_scalar_type (TREE_TYPE (rhs1));
  if (comp_vectype == NULL_TREE)
-   return NULL_TREE;
+   {
+ res = NULL_TREE;
+ break;
+   }
 
  mask_type = get_mask_type_for_scalar_type (TREE_TYPE (rhs1));
  if (!mask_type
  || !expand_vec_cmp_expr_p (comp_vectype, mask_type))
-   return NULL_TREE;
+   {
+ res = NULL_TREE;
+ break;
+   }
 
  if (TREE_CODE (TREE_TYPE (rhs1)) != INTEGER_TYPE
  || !TYPE_UNSIGNED (TREE_TYPE (rhs1)))
@@ -3544,9 +3554,21 @@ search_type_for_mask (tree var, vec_info
}
 }
 
+  cache.put (def_stmt, res);
   return res;
 }
 
+/* Return the proper type for converting bool VAR into
+   an integer value or NULL_TREE if no such type exists.
+   The type is chosen so that converted value has the
+   same number of elements as VAR's vector type.  */
+
+static tree
+search_type_for_mask (tree var, vec_info *vinfo)
+{
+  hash_map cache;
+  return search_type_for_mask_1 (var, vinfo, cache);
+}
 
 /* Function vect_recog_bool_pattern
 
--- gcc/testsuite/gcc.dg/vect/pr72866.c.jj  2016-08-29 19:28:22.453646025 
+0200
+++ gcc/testsuite/gcc.dg/vect/pr72866.c 2016-08-29 19:28:17.0 +0200
@@ -0,0 +1,19 @@
+/* PR tree-optimization/72866 */
+/* { dg-do compile } */
+
+unsigned int dl;
+int rx, lb;
+
+void
+fo (int jv, int be)
+{
+  const unsigned int xw = 16;
+  unsigned int ya, wo;
+
+  for (ya = 0; ya < 2; ++ya)
+for (wo = 0; wo < xw; ++wo)
+  {
+   dl += (jv ? be : rx);
+   rx += ((lb == 0) + 1);
+  }
+}

Jakub

[PATCH] Fix dwarf2out ARRAY_TYPE handling (PR debug/77363)

[Jakub Jelinek]

Hi!

In r231058 gen_type_die_with_usage has been changed to treat ARRAY_TYPE like
VECTOR_TYPE and not to use type_main_variant in that case.  But as the
following testcase shows, modified_type_die has similar condition and if
those two don't agree, modified_type_die just fails the lookup if
type_main_variant (type) != type, and we then fail to add DW_AT_type to
the DW_TAG_typedef because of that.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/6.2/5.5?

2016-08-29  Jakub Jelinek  

PR debug/77363
* dwarf2out.c (modified_type_die): Use lookup_type_die (type)
instead of lookup_type_die (type_main_variant (type)) even for array
types.

* g++.dg/debug/dwarf2/pr77363.C: New test.

--- gcc/dwarf2out.c.jj  2016-08-29 12:35:49.0 +0200
+++ gcc/dwarf2out.c 2016-08-29 18:05:42.171597789 +0200
@@ -11474,7 +11474,8 @@ modified_type_die (tree type, int cv_qua
 copy was created to help us keep track of typedef names) and
 that copy might have a different TYPE_UID from the original
 ..._TYPE node.  */
-  if (TREE_CODE (type) != VECTOR_TYPE)
+  if (TREE_CODE (type) != VECTOR_TYPE
+ && TREE_CODE (type) != ARRAY_TYPE)
return lookup_type_die (type_main_variant (type));
   else
/* Vectors have the debugging information in the type,
--- gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C.jj  2016-08-29 
18:26:09.218310766 +0200
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C 2016-08-29 18:30:03.232579332 
+0200
@@ -0,0 +1,20 @@
+// PR debug/77363
+// { dg-options "-gdwarf-2 -dA -fno-merge-debug-strings" }
+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\) 
DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type2\[^\n\r\]* 
DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\) 
DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type3\[^\n\r\]* 
DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\) 
DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type4\[^\n\r\]* 
DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
+// { dg-final { scan-assembler "DIE \\(\[^\n\r\]*\\) 
DW_TAG_typedef\[^\n\r\]*\[\n\r]*\[^\n\r\]*type5\[^\n\r\]* 
DW_AT_name\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_file\[^\n\r\]*\[\n\r]*\[^\n\r\]* 
DW_AT_decl_line\[^\n\r\]*\[\n\r]*\[^\n\r\]* DW_AT_type" } }
+
+typedef unsigned short type1;
+typedef unsigned char type2;
+typedef type2 type3[16];
+typedef unsigned char type4[16];
+typedef struct
+{
+  struct
+  {
+type3 a;
+type4 b;
+  } c;
+} type5;
+type5 var;

Jakub

[C++ PATCH] Fix ICE with PARM_DECL with incomplete type (PR c++/77338)

[Jakub Jelinek]

Hi!

In r239289 you've done something similar for the VAR_DECL etc. case, but
for PARM_DECL we can still call is_really_empty_class on incomplete types
and ICE because TYPE_BINFO is NULL.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-08-29  Jakub Jelinek  

PR c++/77338
* constexpr.c (cxx_eval_constant_expression) : Only
call is_really_empty_class on complete types.

* g++.dg/cpp0x/decltype-77338.C: New test.

--- gcc/cp/constexpr.c.jj   2016-08-12 17:33:42.0 +0200
+++ gcc/cp/constexpr.c  2016-08-29 14:26:50.342319322 +0200
@@ -3747,7 +3747,8 @@ cxx_eval_constant_expression (const cons
/* Defer in case this is only used for its type.  */;
   else if (TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE)
/* Defer, there's no lvalue->rvalue conversion.  */;
-  else if (is_really_empty_class (TREE_TYPE (t)))
+  else if (COMPLETE_TYPE_P (TREE_TYPE (t))
+  && is_really_empty_class (TREE_TYPE (t)))
{
  /* If the class is empty, we aren't actually loading anything.  */
  r = build_constructor (TREE_TYPE (t), NULL);
--- gcc/testsuite/g++.dg/cpp0x/decltype-77338.C.jj  2016-08-29 
14:42:31.974306247 +0200
+++ gcc/testsuite/g++.dg/cpp0x/decltype-77338.C 2016-08-29 14:41:12.0 
+0200
@@ -0,0 +1,7 @@
+// PR c++/77338
+// { dg-do compile { target c++11 } }
+
+struct S;
+
+template 
+auto f (S s) -> decltype (s (s));  // { dg-error "no match for call to" }

Jakub

[PATCH] Fix avoid_constant_pool_reference (PR middle-end/77377)

[Jakub Jelinek]

Hi!

Returning c from avoid_constant_pool_reference for constant pool references
is only fine if the modes match and offset is zero, otherwise if the offset
is sane, we can try to simplify it as subreg.  But, returning c for out of
bounds offsets is always wrong, and especially if the mode doesn't match, it
can results in all kinds of ICEs.

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

2016-08-29  Jakub Jelinek  

PR middle-end/77377
* simplify-rtx.c (avoid_constant_pool_reference): For out of bounds
constant pool reference return x instead of c.

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

--- gcc/simplify-rtx.c.jj   2016-08-12 17:33:46.0 +0200
+++ gcc/simplify-rtx.c  2016-08-29 13:32:38.126859949 +0200
@@ -251,15 +251,14 @@ avoid_constant_pool_reference (rtx x)
   /* If we're accessing the constant in a different mode than it was
  originally stored, attempt to fix that up via subreg simplifications.
  If that fails we have no choice but to return the original memory.  */
-  if ((offset != 0 || cmode != GET_MODE (x))
- && offset >= 0 && offset < GET_MODE_SIZE (cmode))
+  if (offset == 0 && cmode == GET_MODE (x))
+   return c;
+  else if (offset >= 0 && offset < GET_MODE_SIZE (cmode))
 {
   rtx tem = simplify_subreg (GET_MODE (x), c, cmode, offset);
   if (tem && CONSTANT_P (tem))
 return tem;
 }
-  else
-return c;
 }
 
   return x;
--- gcc/testsuite/gcc.target/i386/pr77377.c.jj  2016-08-29 13:39:01.707328239 
+0200
+++ gcc/testsuite/gcc.target/i386/pr77377.c 2016-08-29 13:38:55.901396832 
+0200
@@ -0,0 +1,6 @@
+/* PR middle-end/77377 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -msse" } */
+/* { dg-additional-options "-fpic" { target fpic } } */
+
+#include "../../c-c++-common/pr59037.c"

Jakub

[PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

[Jakub Jelinek]

Hi!

This testcase expects to find DWARF extensions, but those are disabled by
default on darwin/vxworks because broken tools there don't handle debug info
very well.

I think the following patch (regtested on x86_64-linux and i686-linux)
should fix it, but I have no access to darwin, so can't verify.

Ok for trunk?

2016-08-29  Jakub Jelinek  

PR debug/77389
* g++.dg/debug/dwarf2/template-params-12f.C: Pass -gno-strict-dwarf
in dg-options.

--- gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C.jj  2016-08-12 
11:12:46.0 +0200
+++ gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C 2016-08-29 
12:39:54.562411107 +0200
@@ -1,4 +1,4 @@
-// { dg-options "-gdwarf-2 -dA" }
+// { dg-options "-gdwarf-2 -gno-strict-dwarf -dA" }
 // { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
DW_TAG_template_value_param" 1 } }
 // { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) 
DW_TAG_template_value_param\[^\n\]*\n\[^\n\]* DW_AT_name\n\[^\n\]* 
DW_AT_type\n\[^\n\]*\[^\n\]* DW_AT_location\n\[^\n\]* 
DW_OP_addr\n\[^\n\]*_ZN1S1fEv\[^\n\]*\n\[^\n\]* DW_OP_stack_value\n\[^\n\]* 
DW_OP_piece\n\[^\n\]*\n\[^\n\]* DW_OP_lit0\n\[^\n\]* 
DW_OP_stack_value\n\[^\n\]* DW_OP_piece" 1 } }
 #include "template-params-12.H"

Jakub

[C++ PATCH] Propagate CLASSTYPE_HAS_MUTABLE from bases to derived classes (PR c++/77375)

[Jakub Jelinek]

Hi!

The following testcase fails (foo is allocated in .rodata and modified)
because while we clear TREE_READONLY for classes with mutable members, we
don't do that if they only have bases with mutable members.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux.  Ok for
trunk?  What about release branches?

2016-08-29  Jakub Jelinek  

PR c++/77375
* class.c (check_bases): Set CLASSTYPE_HAS_MUTABLE if any 
TYPE_HAS_MUTABLE_P
for any bases.

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

--- gcc/cp/class.c.jj   2016-08-12 17:33:42.0 +0200
+++ gcc/cp/class.c  2016-08-29 11:54:10.387061502 +0200
@@ -1796,6 +1796,8 @@ check_bases (tree t,
   SET_CLASSTYPE_REF_FIELDS_NEED_INIT
(t, CLASSTYPE_REF_FIELDS_NEED_INIT (t)
 | CLASSTYPE_REF_FIELDS_NEED_INIT (basetype));
+  if (TYPE_HAS_MUTABLE_P (basetype))
+   CLASSTYPE_HAS_MUTABLE (t) = 1;
 
   /*  A standard-layout class is a class that:
  ...
--- gcc/testsuite/g++.dg/cpp0x/mutable1.C.jj2016-08-29 12:05:13.700212552 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/mutable1.C   2016-08-29 12:03:51.0 
+0200
@@ -0,0 +1,12 @@
+// PR c++/77375
+// { dg-do run { target c++11 } }
+
+struct Base { mutable int i; };
+struct Derived : Base {};
+const Derived foo{};
+
+int
+main ()
+{
+  foo.i = 42;
+}

Jakub

Re: [PATCH], Patch #7, Add PowerPC vector initialization tests

[Michael Meissner]

On Fri, Aug 26, 2016 at 08:24:40PM -0500, Segher Boessenkool wrote:
> On Fri, Aug 26, 2016 at 03:29:50PM -0400, Michael Meissner wrote:
> > These patches add more tests to the PowerPC vector initialization tests.  
> > Four
> > of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector
> > initializations for the different vector type (char, short, float, and 
> > double).
> > 
> > These other patches (#6, #7) test the code generated in paches #5 and #6.
> > 
> > I have run tese tests on a big endian power7 system (with both 32-bt and 
> > 64-bit
> > tests runs), a big endian power8 system (just 64-bit tests), and a little
> > endian power8 system.  There were no regressions.  As these tests ok to
> > install?
> 
> This is okay for trunk; one comment:
> 
> > +/* { dg-final { scan-assembler "mtvsrd" } } */
> 
> This also matches mtvsrdd; if you don't want that, you can avoid it by
> writing it as {\mmtvsrd\M} (the {} instead of "" to avoid toothpickeritus).

In this case, mtvsrd and mtvsrdd are both fine.  However, given the test has an
explicit -mcpu=power8, it should never see mtvsrdd.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[PTX] unbreak libgfortran

[Nathan Sidwell]

Libgfortran's configure tests cause it to think localtime_r doesn't exist, and 
then the build dies with an extern decl/static defn mismatch.


This hardwires the expected newlib reoutines, in the same manner as mips doesn.

nathan
2016-08-29  Nathan Sidwell  

	* configure.ac (nvptx-*): Hardwire newlib.
	* configure: Rebuilt.

Index: configure.ac
===
--- configure.ac	(revision 239820)
+++ configure.ac	(working copy)
@@ -276,6 +276,8 @@ AC_CHECK_MEMBERS([struct stat.st_blksize
 case "${host}--x${with_newlib}" in
   mips*--xyes)
 hardwire_newlib=1;;
+  nvptx*--xyes)
+hardwire_newlib=1;;
 esac
 
 # Check for library functions.
Index: configure
===
--- configure	(revision 239820)
+++ configure	(working copy)
@@ -10308,7 +10308,7 @@ _LT_EOF
 	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
 	  export_symbols_cmds='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	else
-	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
+	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	fi
 	aix_use_runtimelinking=no
 
@@ -14157,7 +14157,7 @@ _LT_EOF
 	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
 	  export_symbols_cmds_FC='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	else
-	  export_symbols_cmds_FC='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
+	  export_symbols_cmds_FC='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	fi
 	aix_use_runtimelinking=no
 
@@ -16471,6 +16471,8 @@ fi
 case "${host}--x${with_newlib}" in
   mips*--xyes)
 hardwire_newlib=1;;
+  nvptx*--xyes)
+hardwire_newlib=1;;
 esac
 
 # Check for library functions.

[PATCH, i386]: Fix PR77403, assemble failure of vinserti64x4 with -masm=intel

[Uros Bizjak]

2016-08-29  Uros Bizjak  

PR target/77403
* config/i386/sse.md (vec_set_lo_): Fix assembler
template for intel asm dialect.
(vec_set_hi_): Ditto.

testsuite/ChangeLog:

2016-08-29  Uros Bizjak  

PR target/77403
* gcc.target/i386/pr77403.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN and release branches.

Uros.
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 239825)
+++ config/i386/sse.md  (working copy)
@@ -12334,7 +12334,7 @@
   (const_int 12) (const_int 13)
   (const_int 14) (const_int 15)]]
   "TARGET_AVX512DQ"
-  "vinsert32x8\t{$0x0, %2, %1, 
%0|%0, %1, %2, $0x0}"
+  "vinsert32x8\t{$0x0, %2, %1, 
%0|%0, %1, %2, 0x0}"
   [(set_attr "type" "sselog")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
@@ -12351,7 +12351,7 @@
   (const_int 6) (const_int 7)]))
  (match_operand: 2 "nonimmediate_operand" "vm")))]
   "TARGET_AVX512DQ"
-  "vinsert32x8\t{$0x1, %2, %1, 
%0|%0, %1, %2, $0x1}"
+  "vinsert32x8\t{$0x1, %2, %1, 
%0|%0, %1, %2, 0x1}"
   [(set_attr "type" "sselog")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
@@ -12366,7 +12366,7 @@
(parallel [(const_int 4) (const_int 5)
   (const_int 6) (const_int 7)]]
   "TARGET_AVX512F"
-  "vinsert64x4\t{$0x0, %2, %1, 
%0|%0, %1, %2, $0x0}"
+  "vinsert64x4\t{$0x0, %2, %1, 
%0|%0, %1, %2, 0x0}"
   [(set_attr "type" "sselog")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
Index: testsuite/gcc.target/i386/pr77403.c
===
--- testsuite/gcc.target/i386/pr77403.c (nonexistent)
+++ testsuite/gcc.target/i386/pr77403.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target int128 } */
+/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target masm_intel } */
+/* { dg-options "-O -mavx512f -masm=intel" } */
+
+typedef __int128 V __attribute__((vector_size(64)));
+
+V v;
+
+void
+foo()
+{
+  v ^= (V){1};
+}

Re: [PATCH 3/4] (v2) Introduce class edit_context

[David Malcolm]

On Sun, 2016-08-28 at 11:13 -0400, Trevor Saunders wrote:
> On Wed, Aug 24, 2016 at 09:13:51PM -0400, David Malcolm wrote:
> > This version removes edit_context::apply_changes and related
> > functionality, retaining the ability to generate diffs.
> > 
> > It also improves error-handling (adding a selftest for this).
> > 
> > gcc/ChangeLog:
> > * Makefile.in (OBJS-libcommon): Add edit-context.o.
> > * diagnostic-color.c (color_dict): Add "diff-filename",
> > "diff-hunk", "diff-delete", and "diff-insert".
> > (parse_gcc_colors): Update default value of GCC_COLORS in
> > comment
> > to reflect above changes.
> > * edit-context.c: New file.
> > * edit-context.h: New file.
> > * selftest-run-tests.c (selftest::run_tests): Call
> > edit_context_c_tests.
> > * selftest.h (edit_context_c_tests): New decl.
> > ---
> >  gcc/Makefile.in  |1 +
> >  gcc/diagnostic-color.c   |8 +-
> >  gcc/edit-context.c   | 1347
> > ++
> >  gcc/edit-context.h   |   65 +++
> >  gcc/selftest-run-tests.c |1 +
> >  gcc/selftest.h   |1 +
> >  6 files changed, 1422 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/edit-context.c
> >  create mode 100644 gcc/edit-context.h
> > 
> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index f5f3339..506f0d4 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > @@ -1561,6 +1561,7 @@ OBJS = \
> >  # Objects in libcommon.a, potentially used by all host binaries
> > and with
> >  # no target dependencies.
> >  OBJS-libcommon = diagnostic.o diagnostic-color.o diagnostic-show
> > -locus.o \
> > +   edit-context.o \
> > pretty-print.o intl.o \
> > vec.o input.o version.o hash-table.o ggc-none.o memory
> > -block.o \
> > selftest.o
> > diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
> > index f76c87b..decbe84 100644
> > --- a/gcc/diagnostic-color.c
> > +++ b/gcc/diagnostic-color.c
> > @@ -168,6 +168,10 @@ static struct color_cap color_dict[] =
> >{ "range2", SGR_SEQ (COLOR_FG_BLUE), 6, false },
> >{ "locus", SGR_SEQ (COLOR_BOLD), 5, false },
> >{ "quote", SGR_SEQ (COLOR_BOLD), 5, false },
> > +  { "diff-filename", SGR_SEQ (COLOR_BOLD), 13, false },
> > +  { "diff-hunk", SGR_SEQ (COLOR_FG_CYAN), 9, false },
> > +  { "diff-delete", SGR_SEQ (COLOR_FG_RED), 11, false },
> > +  { "diff-insert", SGR_SEQ (COLOR_FG_GREEN), 11, false },
> >{ NULL, NULL, 0, false }
> >  };
> >  
> > @@ -196,7 +200,9 @@ colorize_stop (bool show_color)
> >  }
> >  
> >  /* Parse GCC_COLORS.  The default would look like:
> > -  
> >  GCC_COLORS='error=01;31:warning=01;35:note=01;36:range1=32:range2=
> > 34;locus=01:quote=01'
> > +   GCC_COLORS='error=01;31:warning=01;35:note=01;36:\
> > +   range1=32:range2=34:locus=01:quote=01:\
> > +   diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32'
> > No character escaping is needed or supported.  */
> >  static bool
> >  parse_gcc_colors (void)
> > diff --git a/gcc/edit-context.c b/gcc/edit-context.c
> > new file mode 100644
> > index 000..6b79b45
> > --- /dev/null
> > +++ b/gcc/edit-context.c
> > @@ -0,0 +1,1347 @@
> > +/* Determining the results of applying fix-its.
> > +   Copyright (C) 2016 Free Software Foundation, Inc.
> > +
> > +This file is part of GCC.
> > +
> > +GCC 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.
> > +
> > +GCC is distributed in the hope that it will be useful, but WITHOUT
> > ANY
> > +WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > +FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> > License
> > +for more details.
> > +
> > +You should have received a copy of the GNU General Public License
> > +along with GCC; see the file COPYING3.  If not see
> > +.  */
> > +
> > +#include "config.h"
> > +#include "system.h"
> > +#include "coretypes.h"
> > +#include "line-map.h"
> > +#include "edit-context.h"
> > +#include "pretty-print.h"
> > +#include "diagnostic-color.h"
> > +#include "selftest.h"
> > +
> > +/* This file implements a way to track the effect of fix-its,
> > +   via a class edit_context; the other classes are support classes
> > for
> > +   edit_context.
> > +
> > +   A complication here is that fix-its are expressed relative to
> > coordinates
> > +   in the file when it was parsed, before any changes have been
> > made, and
> > +   so if there's more that one fix-it to be applied, we have to
> > adjust
> > +   later fix-its to allow for the changes made by earlier ones. 
> >  This
> > +   is done by the various "get_effective_column" methods.
> > +
> > +   The "filename" params are required to outlive the edit_context
> > (no
> > +   copy of the underlying str is taken, just the ptr).  */
> > +
> > +/* Forward 

Re: [v3 PATCH] PR libstdc++/77395

[Ville Voutilainen]

On 29 August 2016 at 19:27, Ville Voutilainen
 wrote:
> Tested for is_constructible and tuple on Linux-x64, finishing testing
> the full suite on Linux-PPC64.

New patch, tested with the full suite on Linux-PPC64, tests adjusted
accordingly.

2016-08-29  Ville Voutilainen  

PR libstdc++/77395
* include/std/type_traits (is_constructible): Forward-declare...
(__is_base_to_derived_ref): ...and use here.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* testsuite/20_util/is_constructible/77395.cc: New.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/pair/cons/explicit_construct.cc: Likewise.
* testsuite/20_util/tuple/77395.cc: New.
* 
testsuite/28_regex/iterators/regex_token_iterator/ctors/char/dr2332_neg.cc:
Adjust.
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index baa4d1f..5085196 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1007,6 +1007,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   is_function<_From>>>::value>
 struct __is_base_to_derived_ref;
 
+  template
+struct is_constructible;
+
   // Detect whether we have a downcast situation during
   // reference binding.
   template
@@ -1017,7 +1020,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename remove_cv::type>::type __dst_t;
   typedef __and_<__not_>,
-is_base_of<__src_t, __dst_t>> type;
+is_base_of<__src_t, __dst_t>,
+__not_>> type;
   static constexpr bool value = type::value;
 };
 
diff --git a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
index 51aa6bb..2048e0d 100644
--- a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
@@ -18,7 +18,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "static assertion failed" "" { target *-*-* } 2255 }
+// { dg-error "static assertion failed" "" { target *-*-* } 2259 }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc 
b/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc
new file mode 100644
index 000..b1fe8a0
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc
@@ -0,0 +1,54 @@
+// { dg-do compile { target c++11 } }
+
+// 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 
+
+struct derived;
+struct base
+{
+  operator derived & () &;
+  operator derived const & () const &;
+  operator derived && () &&;
+};
+
+struct derived : base {};
+
+base::operator derived & () &
+{
+  return *static_cast(this);
+}
+
+base::operator derived const & () const &
+{
+  return *static_cast(this);
+}
+
+base::operator derived && () &&
+{
+  return std::move(*static_cast(this));
+}
+
+int main()
+{
+  base b;
+  derived&& d(static_cast(std::move(b)));
+  derived&& d2(std::move(b));
+  static_assert(std::is_constructible::value, "");
+}
diff --git 
a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
index d22ac96..4f0720a 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
@@ -47,4 +47,4 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 39 }
 // { dg-error "required from here" "" { target *-*-* } 41 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1920 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1924 }
diff --git 
a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
index 2c46dfa..8eea6b9 100644
--- 

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Toon Moene]

On 08/27/2016 10:15 PM, Janne Blomqvist wrote:


On Sat, Aug 27, 2016 at 9:50 PM, Paul Richard Thomas



 wrote:

Although we have said that we would commit on Monday if no review is
forthcoming, we would very much prefer that somebody takes a look. We
understand perfectly that a 4052 line patch is rather daunting.
However, even a cursory scan of the patch would be helpful.


To be honest, I had a nagging suspicion that DTIO would remain forever
on the TODO list, but as you and Jerry have pulled it off, my hat is
off to you!


At the last Fortran Standardization Committee meeting (Boulder, June) I 
opined that UDDTIO might be an unsolved F2003 issue in gfortran 
eternally, because there is no real *pressure* for a free compiler to be 
Standard Conformant.


Now the last major item on the F2003 list is "parameterized derived 
types". Compiler writers on the committee tell me that you need to 
overhaul most of the front end (and parts of the run-time library) to 
get that correct ...


Thanks Paul et al. for working on this daunting task !

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[committed] make_location: ensure end-points are pure locations

[David Malcolm]

On Mon, 2016-08-29 at 08:50 -0400, David Malcolm wrote:
> On Mon, 2016-08-29 at 13:44 +0200, Marek Polacek wrote:
> > On Mon, Aug 29, 2016 at 12:35:38PM +0200, Marek Polacek wrote:
> > > On Mon, Aug 29, 2016 at 11:16:25AM +0200, Andreas Schwab wrote:
> > > > On Aug 25 2016, Marek Polacek  wrote:
> > > > 
> > > > >   * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> > > > 
> > > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11
> > > >  expected multiline pattern lines 13-17 not found: "\s*r \+=
> > > > !aaa
> > > > == bbb;.*\n \^~\n   r \+= !aaa == bbb;.*\n   
> > > >  \^~~~\n\(   \).*\n"
> > > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11
> > > > (test for excess errors)
> > > > Excess errors:
> > > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > > applied" } */
> > > >  ^~
> > > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > > applied" } */
> > > > ^~~~
> > > 
> > > This has regressed with David's
> > > 
> > > commit 367964faf71a99ebd511dffb81075b58bff345a1
> > > Author: dmalcolm 
> > > Date:   Fri Aug 26 21:25:41 2016 +
> > > 
> > > Add validation and consolidation of fix-it hints
> > > 
> > > I don't know yet what exactly went wrong here.
> > 
> > So we reject printing fix-it hint because in
> > reject_impossible_fixit:
> > 
> > 2187   if (where <= LINE_MAP_MAX_LOCATION_WITH_COLS)
> > 2188 /* WHERE is a reasonable location for a fix-it; don't
> > reject
> > it.  */
> > 2189 return false;
> > 
> > (gdb) p where
> > $1 = 2147483652
> > (gdb) p LINE_MAP_MAX_LOCATION_WITH_COLS
> > $2 = 1610612736
> > 
> > so we set m_seen_impossible_fixit.
> > 
> > David, why is that happening?
> 
> Sorry about this; I believe I did my testing of my patch against a
> tree
> that didn't yet have your change.
> 
> (gdb) p /x 2147483652
> $2 = 0x8004
> 
> so "where", the insertion-point, is an ad-hoc location (describing a
> range), and it looks like I somehow forgot to deal with that case in
> the validation code.
> 
> I'm working on a fix.  Sorry again.

The issue affected the C++ frontend, but not the C frontend.

The root cause was that a location expressing a packed range was
passed to a make_location call as the "start" parameter.
make_location was converting the caret to a pure location (stripping
away the packed range), but wasn't doing this for the "start" parameter.
This meant that caret != start, despite them being the same
file/line/col, due to the latter containing packed range information.
This was handled by make_location by creating an ad-hoc location, and
fixit-validation doesn't yet handle ad-hoc locations for insertion
fixits, only pure locations.

The following patch fixes the issue seen in this specific case by
fixing make_location to avoid storing ranges for the endpoints of a
range, and thus avoid generating ad-hoc locations.  If a location
containing a range is passed as start or finish to make_location, it
will use the start/finish of that range respectively.

I'm working on a followup fix to make the fixit-validation code
better handle any ad-hoc locations that do make it through.

Successfully bootstrapped on x86_64-pc-linux-gnu; converts
the failures in g++.sum into passes.

Committed to trunk as r239831.

gcc/ChangeLog:
* input.c (make_location): Call get_start and get_finish
on the endpoints to avoid storing packed ranges or ad-hoc
ranges in them.
(selftest::test_make_location_nonpure_range_endpoints): New function.
(selftest::input_c_tests): Call it.
* input.h (get_start): New inline function.
---
 gcc/input.c | 66 +++--
 gcc/input.h |  8 
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/gcc/input.c b/gcc/input.c
index 2dcecfb..4ec218d 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -879,8 +879,8 @@ make_location (location_t caret, location_t start, 
location_t finish)
 {
   location_t pure_loc = get_pure_location (caret);
   source_range src_range;
-  src_range.m_start = start;
-  src_range.m_finish = finish;
+  src_range.m_start = get_start (start);
+  src_range.m_finish = get_finish (finish);
   location_t combined_loc = COMBINE_LOCATION_DATA (line_table,
   pure_loc,
   src_range,
@@ -1741,6 +1741,67 @@ test_builtins ()
   ASSERT_PRED1 (is_location_from_builtin_token, BUILTINS_LOCATION);
 }
 
+/* Regression test for make_location.
+   Ensure that we use the caret locations of the start/finish, rather
+   than storing a packed or ad-hoc range as the start/finish.  */
+
+static void
+test_make_location_nonpure_range_endpoints (const line_table_case _)
+{
+  /* Issue seen with testsuite/c-c++-common/Wlogical-not-parentheses-2.c
+ with C++ frontend.
+ 

Re: PR35503 - warn for restrict pointer (-Wrestrict)

[Jason Merrill]

On Mon, Aug 29, 2016 at 10:28 AM, Marek Polacek  wrote:
> On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
>> I tried this patch on my fork of gdb-binutils and got a few warnings
>> from it. Would it be possible to have the caret point to the argument
>> mentioned, instead of the function name? And also print the option
>> name? E.g., instead of the current:
>>
>> or32-opc.c: In function ‘or32_print_register’:
>> or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
>> parameter aliases with argument 3
>>sprintf (disassembled, "%sr%d", disassembled, regnum);
>>^~~
>>
>> could it look like:
>>
>> or32-opc.c: In function ‘or32_print_register’:
>> or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
>> parameter aliases with argument 3 [-Wrestrict]
>>sprintf (disassembled, "%sr%d", disassembled, regnum);
>> ^~~~
>>
>> instead?
>
> I didn't try to implement it, but I think this should be fairly easy to
> achieve in the C FE, because c_parser_postfix_expression_after_primary
> has arg_loc, which is a vector of parameter locations.

The C++ FE doesn't have this currently, but it could be added without
too much trouble: in cp_parser_parenthesized_expression_list, extract
the locations from the cp_expr return value of
cp_parser_assignment_expression, and then pass the locations back up
to cp_parser_postfix_expression.

Jason

[PATCH] df: Keep return address register undefined until epilogue_completed

[Segher Boessenkool]

For separate shrink-wrapping we need to find out which basic blocks
need what components set up by a prologue, so that we can move those
prologue pieces deeper into the function, so that those pieces are
executed less frequently, improving performance.

To do this, target code will normally look at the LIVE info: a block
needs a register set up if that register is in the IN, GEN, or KILL
sets.  This works fine for the callee-saved registers, since those
are not in entry_block_defs, but it does not work for the rs6000 link
register, because df_get_entry_block_def_set unconditinally adds the
register that is INCOMING_RETURN_ADDR_RTX (if it is a register).

This patch changes that so that that def is only added after
epilogue_completed.

With that, in the rs6000 backend we can use the same IN+GEN+KILL
condition to see whether LR is used (in the current patch set, only
KILL is used, which isn't correct; the backend can write to LR to
temporarily hold other values; a crazy idea, on modern hardware anyway,
but it does regardless).

Does this work on all other targets?  Should anything else be done?


Segher


2016-08-29  Segher Boessenkool  

* df-scan.c (df_get_entry_block_def_set): Do not add the
INCOMING_RETURN_ADDR_RTX register until epilogue_completed.

---
 gcc/df-scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 9cd647a..ea94f37 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -3567,7 +3567,7 @@ df_get_entry_block_def_set (bitmap entry_block_defs)
 }
 
 #ifdef INCOMING_RETURN_ADDR_RTX
-  if (REG_P (INCOMING_RETURN_ADDR_RTX))
+  if (REG_P (INCOMING_RETURN_ADDR_RTX) && epilogue_completed)
 bitmap_set_bit (entry_block_defs, REGNO (INCOMING_RETURN_ADDR_RTX));
 #endif
 
-- 
1.9.3

Re: [PATCH] Fix PR64078

[Bernd Edlinger]

Thanks!

Actually my patch missed to fix one combination: -m32 with -fpic

make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c --tool_opts
'-m32 -fpic'"

FAIL: c-c++-common/ubsan/object-size-9.c   -O2  execution test
FAIL: c-c++-common/ubsan/object-size-9.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test

The problem here is that the functions f2 and f3 access a stack-
based object out of bounds and that is inlined in main and
therefore smashes the return address of main in this case.

A possible fix could look like follows:

Index: object-size-9.c
===
--- object-size-9.c (revision 239794)
+++ object-size-9.c (working copy)
@@ -93,5 +93,9 @@
  #endif
f4 (12);
f5 (12);
+#ifdef __cplusplus
+  /* Stack may be smashed by f2/f3 above.  */
+  __builtin_exit (0);
+#endif
return 0;
  }


Do you think that this should be fixed too?


Bernd.


On 08/29/16 09:59, Tom de Vries wrote:
> On 17/09/15 20:08, Marek Polacek wrote:
>> On Thu, Sep 17, 2015 at 08:06:48PM +0200, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> On Thu, 17 Sep 2015 10:39:04, Jeff Law wrote:

 On 09/17/2015 09:00 AM, Marek Polacek wrote:
> On Wed, Sep 09, 2015 at 07:48:15PM +0200, Bernd Edlinger wrote:
>> Hi,
>>
>> On Wed, 9 Sep 2015 09:31:33, Jeff Law wrote:
>>> You could probably make the function static or change its
>>> visibility via
>>> a function attribute (there's a visibility attribute which can
>>> take the
>>> values default, hidden protected or internal). Default visibility
>>> essentially means the function can be overridden. I think
>>> changing it
>>> to "protected" might work. Note if we do that, we may need some
>>> kind of
>>> target selector on the test since not all targets support the
>>> various
>>> visibility attributes.
>>>
>>
>> Yes, it works both ways: static works, and __attribute__
>> ((visibility ("protected"))) works too:
>>
>> make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c
>> --target_board='unix{-fpic,-mcmodel=medium,-fpic\
>> -mcmodel=medium,-mcmodel=large,-fpic\ -mcmodel=large}'"
>>
>> has all tests passed, but..
>>
>> make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c
>> --target_board='unix{-fno-inline}'"
>>
>> still fails in the same way for all workarounds: inline, static,
>> and __attribute__ ((visibility ("protected"))).
>>
>> Maybe "static" would be preferable?
>
> Yeah, I'd go with static if that helps. I'd rather avoid playing games
> with visibility.
 Static is certainly easier and doesn't rely on targets implementing all
 the visibility capabilities. So static is probably the best approach.

>>>
>>> That's fine for me too, so is the original patch OK for trunk with
>>> s/inline/static/ ?
>>
>> Yes.
>>
>
> Hi,
>
> I've backported this fix to the 5 branch.
>
> Thanks,
> - Tom
>

C++ PATCH for c++/77379 (abi_tag on thunk)

[Jason Merrill]

Another missing ABI tag, sigh.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1337a943a2d3926537b63d6e1f0d7f46ef10a06d
Author: Jason Merrill 
Date:   Fri Aug 26 15:12:52 2016 -0400

PR c++/77379 - ABI tag on thunk

* mangle.c (maybe_check_abi_tags): Add version parm, handle thunks.
(mangle_thunk): Add thunk parameter.
* method.c (finish_thunk): Pass it.
* cp-tree.h: Declare it.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 72a128d..5bcb98b 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6802,7 +6802,7 @@ extern tree mangle_typeinfo_string_for_type   (tree);
 extern tree mangle_vtbl_for_type   (tree);
 extern tree mangle_vtt_for_type(tree);
 extern tree mangle_ctor_vtbl_for_type  (tree, tree);
-extern tree mangle_thunk   (tree, int, tree, tree);
+extern tree mangle_thunk   (tree, int, tree, tree, tree);
 extern tree mangle_conv_op_name_for_type   (tree);
 extern tree mangle_guard_variable  (tree);
 extern tree mangle_tls_init_fn (tree);
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index d8b5c45..d34743c 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -231,7 +231,7 @@ static void write_local_name (tree, const tree, const tree);
 static void dump_substitution_candidates (void);
 static tree mangle_decl_string (const tree);
 static int local_class_index (tree);
-static void maybe_check_abi_tags (tree, tree = NULL_TREE);
+static void maybe_check_abi_tags (tree, tree = NULL_TREE, int = 10);
 static bool equal_abi_tags (tree, tree);
 
 /* Control functions.  */
@@ -4024,10 +4024,13 @@ mangle_call_offset (const tree fixed_offset, const tree 
virtual_offset)
 
 tree
 mangle_thunk (tree fn_decl, const int this_adjusting, tree fixed_offset,
- tree virtual_offset)
+ tree virtual_offset, tree thunk)
 {
   tree result;
 
+  if (abi_version_at_least (11))
+maybe_check_abi_tags (fn_decl, thunk, 11);
+
   start_mangling (fn_decl);
 
   write_string ("_Z");
@@ -4142,7 +4145,7 @@ mangle_conv_op_name_for_type (const tree type)
guard variable for T.  */
 
 static void
-maybe_check_abi_tags (tree t, tree for_decl)
+maybe_check_abi_tags (tree t, tree for_decl, int ver)
 {
   if (DECL_ASSEMBLER_NAME_SET_P (t))
 return;
@@ -4153,9 +4156,14 @@ maybe_check_abi_tags (tree t, tree for_decl)
 
   tree newtags = get_abi_tags (t);
   if (newtags && newtags != oldtags
-  && abi_version_crosses (10))
+  && abi_version_crosses (ver))
 {
-  if (for_decl)
+  if (for_decl && DECL_THUNK_P (for_decl))
+   warning_at (DECL_SOURCE_LOCATION (t), OPT_Wabi,
+   "the mangled name of a thunk for %qD changes between "
+   "-fabi-version=%d and -fabi-version=%d",
+   t, flag_abi_version, warn_abi_version);
+  else if (for_decl)
warning_at (DECL_SOURCE_LOCATION (for_decl), OPT_Wabi,
"the mangled name of %qD changes between "
"-fabi-version=%d and -fabi-version=%d",
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 75342ae..957ea39 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -169,7 +169,7 @@ finish_thunk (tree thunk)
 virtual_offset = BINFO_VPTR_FIELD (virtual_offset);
   function = THUNK_TARGET (thunk);
   name = mangle_thunk (function, DECL_THIS_THUNK_P (thunk),
-  fixed_offset, virtual_offset);
+  fixed_offset, virtual_offset, thunk);
 
   /* We can end up with declarations of (logically) different
  covariant thunks, that do identical adjustments.  The two thunks
diff --git a/gcc/testsuite/g++.dg/abi/abi-tag23.C 
b/gcc/testsuite/g++.dg/abi/abi-tag23.C
new file mode 100644
index 000..5e310a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/abi-tag23.C
@@ -0,0 +1,35 @@
+// PR c++/77379
+// { dg-options "-fabi-version=0 -Wabi=10" }
+
+struct __attribute ((abi_tag ("bar"))) string { };
+
+struct Mother
+{
+  virtual ~Mother() {};
+  int bar;
+};
+
+struct Father
+{
+  virtual string get_foo()  = 0;
+};
+
+class Derived:
+  public Mother,
+  public Father
+{
+public:
+  string get_foo();// { dg-warning "mangled name" }
+};
+
+struct Final:
+public Derived
+{
+};
+
+int main()
+{
+  Final().get_foo();
+}
+
+// { dg-final { scan-assembler "_ZThn16_N7Derived7get_fooB3barEv" } }
diff --git a/gcc/testsuite/g++.dg/abi/abi-tag23a.C 
b/gcc/testsuite/g++.dg/abi/abi-tag23a.C
new file mode 100644
index 000..72aa037
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/abi-tag23a.C
@@ -0,0 +1,35 @@
+// PR c++/77379
+// { dg-options -fabi-version=10 }
+
+struct __attribute ((abi_tag ("bar"))) string { };
+
+struct Mother
+{
+  virtual ~Mother() {};
+  int bar;
+};
+
+struct Father
+{
+  virtual string get_foo()  = 0;
+};
+
+class Derived:
+  public Mother,
+  public Father
+{
+public:
+  string get_foo();
+};
+
+struct Final:
+  

Re: [PATCH] PR fortran/77372

[Steven G. Kargl]

On Mon, Aug 29, 2016 at 05:09:59PM +0200, Andreas Schwab wrote:
> On Aug 29 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> 
> > On Mon, Aug 29, 2016 at 11:10:41AM +0200, Andreas Schwab wrote:
> >> On Aug 26 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> >> 
> >> > 2016-08-25  Steven G. Kargl <ka...@gcc.gnu.org>
> >> >
> >> >  PR fortran/77372
> >> >  gfortran.dg/pr77372.f90: New test.
> >> 
> >> FAIL: gfortran.dg/pr77372.f90   -O  (test for excess errors)
> >> Excess errors:
> >> /usr/local/gcc/gcc-20160829/gcc/testsuite/gfortran.dg/pr77372.f90:3:7: 
> >> Fatal Error: Can't open module file 'ieee_arithmetic.mod' for reading at 
> >> (1): No such file or directory
> >> compilation terminated.
> >> 
> >
> > Does it FAIL if you move the test into the gfortran.dg/ieee
> > directory?
> 
> With that change it passes.

Thanks for checking.  Seems that some targets need 
ieee.exp to set up the path correctly.  I'll move
the test shortly.

-- 
steve

[v3 PATCH] PR libstdc++/77395

[Ville Voutilainen]

Tested for is_constructible and tuple on Linux-x64, finishing testing
the full suite on Linux-PPC64.

2016-08-29  Ville Voutilainen  

PR libstdc++/77395
* include/std/type_traits (is_constructible): Forward-declare...
(__is_base_to_derived_ref): ...and use here.
* testsuite/20_util/is_constructible/77395.cc: New.
* testsuite/20_util/tuple/77395.cc: Likewise.
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index baa4d1f..5085196 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1007,6 +1007,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   is_function<_From>>>::value>
 struct __is_base_to_derived_ref;
 
+  template
+struct is_constructible;
+
   // Detect whether we have a downcast situation during
   // reference binding.
   template
@@ -1017,7 +1020,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename remove_cv::type>::type __dst_t;
   typedef __and_<__not_>,
-is_base_of<__src_t, __dst_t>> type;
+is_base_of<__src_t, __dst_t>,
+__not_>> type;
   static constexpr bool value = type::value;
 };
 
diff --git a/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc 
b/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc
new file mode 100644
index 000..b1fe8a0
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc
@@ -0,0 +1,54 @@
+// { dg-do compile { target c++11 } }
+
+// 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 
+
+struct derived;
+struct base
+{
+  operator derived & () &;
+  operator derived const & () const &;
+  operator derived && () &&;
+};
+
+struct derived : base {};
+
+base::operator derived & () &
+{
+  return *static_cast(this);
+}
+
+base::operator derived const & () const &
+{
+  return *static_cast(this);
+}
+
+base::operator derived && () &&
+{
+  return std::move(*static_cast(this));
+}
+
+int main()
+{
+  base b;
+  derived&& d(static_cast(std::move(b)));
+  derived&& d2(std::move(b));
+  static_assert(std::is_constructible::value, "");
+}
diff --git a/libstdc++-v3/testsuite/20_util/tuple/77395.cc 
b/libstdc++-v3/testsuite/20_util/tuple/77395.cc
new file mode 100644
index 000..26501bf
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/tuple/77395.cc
@@ -0,0 +1,46 @@
+// { dg-do compile { target c++11 } }
+
+// 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 
+
+struct derived;
+struct base
+{
+operator derived & () &;
+operator derived const & () const &;
+operator derived && () &&;
+};
+
+struct derived : base {};
+
+base::operator derived & () & { return *static_cast(this); }
+base::operator derived const & () const & { return *static_cast(this); }
+base::operator derived && () && { return std::move(*static_cast(this)); }
+
+std::tuple test(base && b)
+{
+return std::tuple(std::move(b));
+}
+
+int main(int,char**)
+{
+auto d = std::get<0>(test(derived{}));
+return 0;
+}

Re: [PATCH, PR71602, 4/4] Make canonical_va_list_type more strict

[Tom de Vries]

On 29/08/16 17:51, Joseph Myers wrote:

On Wed, 24 Aug 2016, Tom de Vries wrote:


This patch fixes PR71602 by making canonical_va_list_type more strict.

Bootstrapped and reg-tested on x86_64.

OK for trunk, 6-branch?


ENOPATCH



Patch attached this time.

Thanks,
- Tom
Make canonical_va_list_type more strict

2016-08-22  Tom de Vries  

	PR C/71602
	* builtins.c (std_canonical_va_list_type): Strictly return non-null for
	va_list type only.
	* config/i386/i386.c (ix86_canonical_va_list_type): Same.
	* gimplify.c (gimplify_va_arg_expr): Handle _list.

	* c-common.c (build_va_arg): Handle more strict
	targetm.canonical_va_list_type.

	* c-c++-common/va-arg-va-list-type.c: New test.

---
 gcc/builtins.c   | 4 
 gcc/c-family/c-common.c  | 8 ++--
 gcc/config/i386/i386.c   | 8 
 gcc/gimplify.c   | 5 +
 gcc/testsuite/c-c++-common/va-arg-va-list-type.c | 9 +
 5 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index abc934b..101b1e3 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4089,10 +4089,6 @@ std_canonical_va_list_type (tree type)
 {
   tree wtype, htype;
 
-  if (INDIRECT_REF_P (type))
-type = TREE_TYPE (type);
-  else if (POINTER_TYPE_P (type) && POINTER_TYPE_P (TREE_TYPE (type)))
-type = TREE_TYPE (type);
   wtype = va_list_type_node;
   htype = type;
   /* Treat structure va_list types.  */
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 3b61e64..6cf2ffc 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5813,15 +5813,11 @@ build_va_arg (location_t loc, tree expr, tree type)
 {
   /* Case 1: Not an array type.  */
 
-  /* Take the address, to get ''.  */
+  /* Take the address, to get ''.  Note that  is not a va_list
+	 type.  */
   mark_addressable (expr);
   expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr);
 
-  /* Verify that  is still recognized as having va_list type.  */
-  tree canon_expr_type
-	= targetm.canonical_va_list_type (TREE_TYPE (expr));
-  gcc_assert (canon_expr_type != NULL_TREE);
-
   return build_va_arg_1 (loc, type, expr);
 }
 
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2639c8c..343efa0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -48565,14 +48565,6 @@ ix86_canonical_va_list_type (tree type)
 {
   tree wtype, htype;
 
-  /* Resolve references and pointers to va_list type.  */
-  if (TREE_CODE (type) == MEM_REF)
-type = TREE_TYPE (type);
-  else if (POINTER_TYPE_P (type) && POINTER_TYPE_P (TREE_TYPE(type)))
-type = TREE_TYPE (type);
-  else if (POINTER_TYPE_P (type) && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
-type = TREE_TYPE (type);
-
   if (TARGET_64BIT && va_list_type_node != NULL_TREE)
 {
   wtype = va_list_type_node;
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 288b472..6ce516a 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -11959,6 +11959,11 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
   if (have_va_type == error_mark_node)
 return GS_ERROR;
   have_va_type = targetm.canonical_va_list_type (have_va_type);
+  if (have_va_type == NULL_TREE
+  && TREE_CODE (valist) == ADDR_EXPR)
+/* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
+have_va_type
+  = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
   gcc_assert (have_va_type != NULL_TREE);
 
   /* Generate a diagnostic for requesting data of a type that cannot
diff --git a/gcc/testsuite/c-c++-common/va-arg-va-list-type.c b/gcc/testsuite/c-c++-common/va-arg-va-list-type.c
new file mode 100644
index 000..cdd97cf
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/va-arg-va-list-type.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+
+__builtin_va_list *pap;
+
+void
+fn1 (void)
+{
+  __builtin_va_arg (pap, double); /* { dg-error "first argument to 'va_arg' not of type 'va_list'" } */
+}

Re: [x86] Don't use builtins for unaligned load/store

[Marc Glisse]

On Mon, 29 Aug 2016, Uros Bizjak wrote:


On Mon, Aug 29, 2016 at 5:22 PM, Marc Glisse  wrote:

On Mon, 29 Aug 2016, Kirill Yukhin wrote:


On 29.08.2016 14:58, Marc Glisse wrote:


this patch gets rid of a few more builtins (well, I actually kept them,
since Ada users may still need them). I had to tweak the flags for
pr59539-2.c, otherwise the compiler thinks it is more efficient to split the
loads, reading 128 bits at a time. This still breaks one testcase:
avx512f-vmovdqu32-1.c. I don't think it really matters, and I'll just adapt
the scan-assembler-times regex if you agree, but from
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html it looks like
getting 32 instead of 64 might be on purpose, so I'd like your opinion on
that


32/64 matters only when you're using embedded masking.
if not - they are synonyms.



Then for the review, please consider that the patch now has this extra
piece:

* gcc.target/i386/avx512f-vmovdqu32-1.c: Relax expected asm.

-/* { dg-final { scan-assembler-times "vmovdqu32\[
\\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "vmovdqu\[36\]\[24\]\[
\\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */


"vmovdqu(32|64)..." please.


Apparently, I need to use (?:32|64) instead (not sure why it won't pass 
otherwise...)


There is an existing line above:
 /* { dg-final { scan-assembler-times "vmovdqu\[36\]\[24\]\[ 
\\t\]+\[^\{\n\]*\\)\[^\n\]*%zmm\[0-9\]+(?:\n|\[ \\t\]+#)" 1 } } */


I'll change it at the same time.


Patch is OK with the above change.


Thanks.

--
Marc Glisse

Re: [PATCH] avoid -Wmissing-format-attribute for functions that use literal formats

[Joseph Myers]

On Tue, 23 Aug 2016, Martin Sebor wrote:

> The attached patch refines the logic used to suggest the format
> attribute to filter out functions that use string literals and
> constants as formats.
> 
> This change has the effect of not suggesting the attribute for
> functions like the one below (since the attribute couldn't very
> be used with it):
> 
>   void g (char *d, __builtin_va_list va)
>   {
> vsprintf (d, "%i", va);
>   }
> 
> I started seeing the warnings after my recent changes to the
> Wformat-length patch and couldn't find a good way to suppress
> them other than via #pragma GCC diagnostic.

OK.

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

Re: [PATCH, PR71602, 4/4] Make canonical_va_list_type more strict

[Joseph Myers]

On Wed, 24 Aug 2016, Tom de Vries wrote:

> This patch fixes PR71602 by making canonical_va_list_type more strict.
> 
> Bootstrapped and reg-tested on x86_64.
> 
> OK for trunk, 6-branch?

ENOPATCH

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

Re: [PATCH, 3/4] Fix assert in build_va_arg, case 2b

[Joseph Myers]

On Wed, 24 Aug 2016, Tom de Vries wrote:

> Hi,
> 
> this patch fixes an assert in build_va_arg. Instead of testing for pointer
> equality, we use the same test as is used in std_canonical_va_list_type.
> 
> Bootstrapped and reg-tested on x86_64.
> 
> OK for trunk?

OK.

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

Re: [PATCH, 2/4] Replace error_at with assert in build_va_arg

[Joseph Myers]

On Wed, 24 Aug 2016, Tom de Vries wrote:

> Hi,
> 
> at the start of build_va_arg, we error out if there's an invalid va_list
> argument.
> 
> Therefore, the following checks on va_list type are not user errors, but
> internal errors.
> 
> This patch changes the user errors into internal errors.
> 
> Bootstrapped and reg-tested on x86_64.
> 
> OK for trunk?

OK.

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

Re: [PATCH, 1/4] Handle errors in both args of va_arg

[Joseph Myers]

On Wed, 24 Aug 2016, Tom de Vries wrote:

> This patch makes sure that both errors are given for the last example, by
> moving the error call from gimplify_va_arg_expr to build_va_arg.

OK.

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

Re: Make max_align_t respect _Float128

[Joseph Myers]

On Mon, 29 Aug 2016, Marek Polacek wrote:

> On Fri, Aug 26, 2016 at 02:51:38PM -0700, Paul Eggert wrote:
> > > Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__
> > > (the effect would be an extra union member
> > 
> > s/union/struct/. Though I've always wondered why it is a struct and not a
> > union. Maybe change it to union while we're doing an ABI change anyway?
>  
> Yeah, me too.  The initial implementation is here
>  but I don't see any
> comments wrt max_align_t being a struct or a union there.

I'm not aware of a specific reason for struct versus union (naming via a 
typedef without a struct tag, so that no identifiers from the tag 
namespace are used for C and so that the name for linkage purposes in C++ 
is max_align_t, is deliberate, however).

While the chance of any code's ABI being affected by the size of the type 
should be small, the minimum change is certainly the one that uses 
__i386__ and so doesn't affect the type at all except in the case where 
it's necessary to do so.

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

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

[Joseph Myers]

On Fri, 26 Aug 2016, Marek Polacek wrote:

> 2016-08-26  Marek Polacek  
> 
>   PR c/77292
>   * c-common.c (warn_logical_not_parentheses): Don't warn for
>   a comparison or a logical operator.
> 
>   * c-c++-common/Wlogical-not-parentheses-1.c: New test.

OK.

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

Re: [x86] Don't use builtins for unaligned load/store

[Uros Bizjak]

On Mon, Aug 29, 2016 at 5:22 PM, Marc Glisse  wrote:
> On Mon, 29 Aug 2016, Kirill Yukhin wrote:
>
>> On 29.08.2016 14:58, Marc Glisse wrote:
>>>
>>> this patch gets rid of a few more builtins (well, I actually kept them,
>>> since Ada users may still need them). I had to tweak the flags for
>>> pr59539-2.c, otherwise the compiler thinks it is more efficient to split the
>>> loads, reading 128 bits at a time. This still breaks one testcase:
>>> avx512f-vmovdqu32-1.c. I don't think it really matters, and I'll just adapt
>>> the scan-assembler-times regex if you agree, but from
>>> https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html it looks like
>>> getting 32 instead of 64 might be on purpose, so I'd like your opinion on
>>> that
>>
>> 32/64 matters only when you're using embedded masking.
>> if not - they are synonyms.
>
>
> Then for the review, please consider that the patch now has this extra
> piece:
>
> * gcc.target/i386/avx512f-vmovdqu32-1.c: Relax expected asm.
>
> -/* { dg-final { scan-assembler-times "vmovdqu32\[
> \\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-times "vmovdqu\[36\]\[24\]\[
> \\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */

"vmovdqu(32|64)..." please.

Patch is OK with the above change.

Thanks,
Uros.

Re: Implement -Wimplicit-fallthrough (version 7)

[Marek Polacek]

On Mon, Aug 29, 2016 at 10:41:57AM -0400, David Malcolm wrote:
> Thanks.  So presumably you have something like:
> 
> ... case something:
> 353   if (*(unsigned int *)c->var == UINT_MAX)
> 354{
> 355
> 356/* various code here */
> 357}
> 358
> 359 case var_zinteger:
> 360/* etc  */
> 
> and hence the new warning is complaining about the fallthrough to line
> 359.
 
>From the very beginning, my intent was to show *what* falls through *where*,
so I think the locations are precise as they are and I wouldn't want to
change them.

> If so, I agree that the fix-it as it's currently printed is misleading.
> 
> Insertion fix-its appear immediately before the text at the caret, so
> the result of applying the fix-its (using my -fdiagnostics-generate
> -patch patchkit) would be:
> 
> 359 __attribute__ ((fallthrough));case var_zinteger:
> 
> and:
> 
> 359 break;case var_zinteger:
> 
> It looks like the fix-it data is technically correct, but the end-result 
> doesn't resemble normal formatting.
> 
> In fact, -fdiagnostics-generate-patch doesn't know about "apply this OR apply 
> that", so the generated patch would probably look like this:
> 
> @@ -354,5 +354,5
>  }
> 
> - case var_zinteger:
> + __attribute__ ((fallthrough));break;case var_zinteger:
>  /* etc */
> 
> The text inserted by the fixits probably ought to be on lines to themselves, 
> with appropriate indentation, so that the generated patch would then look 
> something like this:
> 
> @@ -354,5 +354,6
>  }
> 
> + __attribute__ ((fallthrough));
>   case var_zinteger:
>  /* etc */
> 
> and:
> 
> @@ -354,5 +354,6
>  }
> 
> +break;
>   case var_zinteger:
>  /* etc */
> 
> 
> This is non-trivial for two reasons:
> 
> (a) there are various places in the fixit handling-code that aren't yet 
> expecting newlines in fixit text; in particular, printing the fix-its.
> Also, diagnostics_show_locus also will currently only print fixits on lines 
> that are touched by a range within the diagnostic.
> 
> (b) figuring out the appropriate indentation may be hard
> 
> These issues are fixable, but seem something of a digression.  I think the 
> best course of action here is for Marek to remove the fix-it hints for now, 
> so it doesn't block getting the warning into trunk, and for us to work on 
> adding the fixits as follow-up work once the less ambitious version of the 
> patch is approved.  I believe that the "note" diagnostics make sense to print 
> even without the fixit hints, so that those could be kept for now.
> 
> Marek, others: does this sound like a good course of action?

Yeah, I appreciate this isn't easy.  Given fix-it hints shouldn't be considered
a blocker for a patch like this, I can simply resort to what I had in the
early phase, that is say something like

q.c:7:8: warning: this statement may fall through [-Wimplicit-fallthrough]
   b++;
   ~^~
q.c:8:5: note: here
 case 1:
 ^~~~

and we can improve things incrementally.

Thanks,

Marek

Re: [x86] Don't use builtins for unaligned load/store

[Marc Glisse]

On Mon, 29 Aug 2016, Kirill Yukhin wrote:


On 29.08.2016 14:58, Marc Glisse wrote:
this patch gets rid of a few more builtins (well, I actually kept them, 
since Ada users may still need them). I had to tweak the flags for 
pr59539-2.c, otherwise the compiler thinks it is more efficient to split 
the loads, reading 128 bits at a time. This still breaks one testcase: 
avx512f-vmovdqu32-1.c. I don't think it really matters, and I'll just adapt 
the scan-assembler-times regex if you agree, but from 
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html it looks like 
getting 32 instead of 64 might be on purpose, so I'd like your opinion on 
that 

32/64 matters only when you're using embedded masking.
if not - they are synonyms.


Then for the review, please consider that the patch now has this extra 
piece:


* gcc.target/i386/avx512f-vmovdqu32-1.c: Relax expected asm.

-/* { dg-final { scan-assembler-times "vmovdqu32\[ 
\\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "vmovdqu\[36\]\[24\]\[ 
\\t\]+\[^\{\n\]*%zmm\[0-9\]+\[^\n\]*\\)(?:\n|\[ \\t\]+#)" 1 } } */

Thanks,

--
Marc Glisse

Re: [PATCH] PR fortran/77372

[Andreas Schwab]

On Aug 29 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:

> On Mon, Aug 29, 2016 at 11:10:41AM +0200, Andreas Schwab wrote:
>> On Aug 26 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>> 
>> > 2016-08-25  Steven G. Kargl <ka...@gcc.gnu.org>
>> >
>> >PR fortran/77372
>> >gfortran.dg/pr77372.f90: New test.
>> 
>> FAIL: gfortran.dg/pr77372.f90   -O  (test for excess errors)
>> Excess errors:
>> /usr/local/gcc/gcc-20160829/gcc/testsuite/gfortran.dg/pr77372.f90:3:7: Fatal 
>> Error: Can't open module file 'ieee_arithmetic.mod' for reading at (1): No 
>> such file or directory
>> compilation terminated.
>> 
>
> Does it FAIL if you move the test into the gfortran.dg/ieee
> directory?

With that change it passes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] PR fortran/77372

[Steve Kargl]

On Mon, Aug 29, 2016 at 11:10:41AM +0200, Andreas Schwab wrote:
> On Aug 26 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> 
> > 2016-08-25  Steven G. Kargl <ka...@gcc.gnu.org>
> >
> > PR fortran/77372
> > gfortran.dg/pr77372.f90: New test.
> 
> FAIL: gfortran.dg/pr77372.f90   -O  (test for excess errors)
> Excess errors:
> /usr/local/gcc/gcc-20160829/gcc/testsuite/gfortran.dg/pr77372.f90:3:7: Fatal 
> Error: Can't open module file 'ieee_arithmetic.mod' for reading at (1): No 
> such file or directory
> compilation terminated.
> 

Does it FAIL if you move the test into the gfortran.dg/ieee
directory?

-- 
Steve

Re: [x86] Don't use builtins for unaligned load/store

[Kirill Yukhin]

Hello,
On 29.08.2016 14:58, Marc Glisse wrote:

Hello,

this patch gets rid of a few more builtins (well, I actually kept 
them, since Ada users may still need them). I had to tweak the flags 
for pr59539-2.c, otherwise the compiler thinks it is more efficient to 
split the loads, reading 128 bits at a time. This still breaks one 
testcase: avx512f-vmovdqu32-1.c. I don't think it really matters, and 
I'll just adapt the scan-assembler-times regex if you agree, but from 
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html it looks like 
getting 32 instead of 64 might be on purpose, so I'd like your opinion 
on that 

32/64 matters only when you're using embedded masking.
if not - they are synonyms.

--
Thanks, K

[build] Add missing dummy command for gcov-iov.h

[Eric Botcazou]

Makefile.in contains a lengthy comment explaining the strategy for timestamp 
files associated with generated files; in particular, it explains that a dummy 
command is needed for 'make' not to think the generated file is unchanged.

We experienced strange rebuilds at installation time on a recent distribution 
and, after an in-depth investigation, traced it to a disconnect between gcov-
iov.h and its timestamp file s-iov.  Adding the missing dummy command got rid 
of the problem.

Tested on x86_64-suse-linux, applied on all active branches as obvious.


2016-08-29  Eric Botcazou  

* Makefile.in (gcov-iov.h): Add dummy recipe.

-- 
Eric BotcazouIndex: Makefile.in
===
--- Makefile.in	(revision 239761)
+++ Makefile.in	(working copy)
@@ -2775,7 +2775,7 @@ build/gcov-iov$(build_exeext): build/gcov-iov.o
 	+$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \
 		build/gcov-iov.o -o $@
 
-gcov-iov.h: s-iov
+gcov-iov.h: s-iov; @true
 s-iov: build/gcov-iov$(build_exeext) $(BASEVER) $(DEVPHASE)
 	build/gcov-iov$(build_exeext) '$(BASEVER_c)' '$(DEVPHASE_c)' \
 	> tmp-gcov-iov.h

Re: Implement -Wimplicit-fallthrough (version 7)

[David Malcolm]

On Mon, 2016-08-29 at 10:04 -0400, Eric Gallager wrote:
> On 8/29/16, David Malcolm  wrote:
> > On Mon, 2016-08-29 at 09:32 -0400, Eric Gallager wrote:
> > > On 8/29/16, Marek Polacek  wrote:
> > > > Tobias tried my latest version and reported some ICEs.  They
> > > > should
> > > > all be
> > > > fixed in this version (the only change since version 6 is the
> > > > cp/pt.c
> > > > hunk).
> > > > 
> > > > At this point I'd like to ask Jason and Joseph to review the
> > > > C/C++
> > > > parts
> > > > and someone to review the ME parts so that I can finally wrap
> > > > this
> > > > thing
> > > > up.  This warning found a couple of bugs in our codebase and I
> > > > suspect it
> > > > will find some in other codebases, too.
> > > > 
> > > > Does anyone have any concerns that I haven't addressed yet?
> > > > 
> > > > Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for
> > > > trunk?
> > > > 
> > > 
> > > 
> > > I tried v6 on my binutils-gdb fork, and it printed A LOT of
> > > warnings... After this patch goes in, the main question I'd have
> > > would
> > > be about the carets: it seems like it would make more sense for
> > > me
> > > for
> > > the location of the warning to be swapped with that of the fixit
> > > hint(s)? With the fixit pointing to the case label before the
> > > statement that's warned about, it makes it look like it's
> > > suggesting
> > > to put the fallthrough attribute or the break before the rest of
> > > the
> > > content of the case, which, with the break, could lead to dead
> > > code.
> > > I'd think it'd make more sense to point to after the body of the
> > > case
> > > statement instead...
> > 
> > Interesting.  Please can you post an example of the output that
> > you're
> > referring to?
> > 
> > I'm working on improvements to how we print fix-its, so I'm
> > wondering
> > if this is an issue with the fix-it data, or with the presentation
> > of
> > it.
> > 
> > Thanks
> > Dave
> > 
> 
> Sure, an example of the warning looks like this for me:
> 
> ./cli/cli-setshow.c: In function ‘do_setshow_command’:
> ./cli/cli-setshow.c:353:7: warning: this statement may fall through
> [-Wimplicit-fallthrough]
> if (*(unsigned int *)c->var == UINT_MAX)
>^
> ./cli/cli-setshow.c:359:2: note: insert ‘__attribute__
> ((fallthrough));’ to silence this warning
>   case var_zinteger:
>   ^~~~
>   __attribute__ ((fallthrough));
> ./cli/cli-setshow.c:359:2: note: insert ‘break;’ to avoid fall
> -through
>   case var_zinteger:
>   ^~~~
>   break;

Thanks.  So presumably you have something like:

... case something:
353   if (*(unsigned int *)c->var == UINT_MAX)
354{
355
356/* various code here */
357}
358
359 case var_zinteger:
360/* etc  */

and hence the new warning is complaining about the fallthrough to line
359.

If so, I agree that the fix-it as it's currently printed is misleading.

Insertion fix-its appear immediately before the text at the caret, so
the result of applying the fix-its (using my -fdiagnostics-generate
-patch patchkit) would be:

359 __attribute__ ((fallthrough));case var_zinteger:

and:

359 break;case var_zinteger:

It looks like the fix-it data is technically correct, but the end-result 
doesn't resemble normal formatting.

In fact, -fdiagnostics-generate-patch doesn't know about "apply this OR apply 
that", so the generated patch would probably look like this:

@@ -354,5 +354,5
 }

- case var_zinteger:
+ __attribute__ ((fallthrough));break;case var_zinteger:
 /* etc */

The text inserted by the fixits probably ought to be on lines to themselves, 
with appropriate indentation, so that the generated patch would then look 
something like this:

@@ -354,5 +354,6
 }

+ __attribute__ ((fallthrough));
  case var_zinteger:
 /* etc */

and:

@@ -354,5 +354,6
 }

+break;
  case var_zinteger:
 /* etc */


This is non-trivial for two reasons:

(a) there are various places in the fixit handling-code that aren't yet 
expecting newlines in fixit text; in particular, printing the fix-its.
Also, diagnostics_show_locus also will currently only print fixits on lines 
that are touched by a range within the diagnostic.

(b) figuring out the appropriate indentation may be hard

These issues are fixable, but seem something of a digression.  I think the best 
course of action here is for Marek to remove the fix-it hints for now, so it 
doesn't block getting the warning into trunk, and for us to work on adding the 
fixits as follow-up work once the less ambitious version of the patch is 
approved.  I believe that the "note" diagnostics make sense to print even 
without the fixit hints, so that those could be kept for now.

Marek, others: does this sound like a good course of action?


Dave

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

[Segher Boessenkool]

On Mon, Aug 29, 2016 at 11:31:51AM +0200, Bernd Schmidt wrote:
> On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
> >+@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 
> >(sbitmap)
> >+Emit prologue insns for the components indicated by the parameter.
> >+@end deftypefn
> >+
> >+@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 
> >(sbitmap)
> >+Emit epilogue insns for the components indicated by the parameter.
> >+@end deftypefn
> 
> How do these actually know where to save/restore registers? The frame 
> pointer may have been eliminated, and SP isn't necessarily constant 
> during the function. Seems like you'd have to calculate CFA reg/offset 
> much like dwarf2out does and pass it to this hook.

There are many other reasons why separate shrink-wrapping can not be
done for a certain function, too; some target-specific.

The generic code (patch 8/9) does

+  /* We don't handle "strange" functions.  */
+  if (cfun->calls_alloca
+  || cfun->calls_setjmp
+  || cfun->can_throw_non_call_exceptions
+  || crtl->calls_eh_return
+  || crtl->has_nonlocal_goto
+  || crtl->saves_all_registers)
+return;
+
+  /* Ask the target what components there are.  If it returns NULL, don't
+ do anything.  */
+  sbitmap components = targetm.shrink_wrap.get_separate_components ();

and the rs6000 version of TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS
(path 9/9) then does

+  rs6000_stack_t *info = rs6000_stack_info ();
+
+  if (!(info->savres_strategy & SAVE_INLINE_GPRS)
+  || !(info->savres_strategy & REST_INLINE_GPRS)
+  || WORLD_SAVE_P (info))
+return NULL;

and also checks for each component if it can access the save slot with
just one instruction.  It can handle both the stack pointer (r1) and
the hard frame pointer (r31); it uses the same logic as the "ordinary"
prologue/epilogue would.


Segher

Re: PR35503 - warn for restrict pointer

[Marek Polacek]

On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
> Prathamesh Kulkarni wrote:
> > Attachment: pr35503-3.txt
> 
> I tried the patch - and it found a bug in our code; nice!
> 
> 
> (a) Regarding the [-Werror] output:
> 
>error: passing argument 24 to restrict qualified parameter aliases with 
> argument 29 [-Werror]
> 
> Shouldn't that output "[-Werror=restrict]" instead of a bare "[-Werror]? 
> Namely, instead of
> 
> + warning_at (loc, 0,
> + "passing argument %u to restrict qualified parameter 
> aliases with "
> + "argument %u", param_pos + 1, i + 1);
> 
> I think one gets this with
> warning_at (loc, OPT_Wrestrict, ...
 
Yes, this needs to be fixed in the patch.

Marek

Re: PR35503 - warn for restrict pointer (-Wrestrict)

[Marek Polacek]

On Mon, Aug 29, 2016 at 09:20:53AM -0400, Eric Gallager wrote:
> I tried this patch on my fork of gdb-binutils and got a few warnings
> from it. Would it be possible to have the caret point to the argument
> mentioned, instead of the function name? And also print the option
> name? E.g., instead of the current:
> 
> or32-opc.c: In function ‘or32_print_register’:
> or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
> parameter aliases with argument 3
>sprintf (disassembled, "%sr%d", disassembled, regnum);
>^~~
> 
> could it look like:
> 
> or32-opc.c: In function ‘or32_print_register’:
> or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
> parameter aliases with argument 3 [-Wrestrict]
>sprintf (disassembled, "%sr%d", disassembled, regnum);
> ^~~~
> 
> instead?

I didn't try to implement it, but I think this should be fairly easy to
achieve in the C FE, because c_parser_postfix_expression_after_primary
has arg_loc, which is a vector of parameter locations.

Marek

[testsuite] XFAIL gcc.dg/ipa/iinline-attr.c on Visium

[Eric Botcazou]

The test doesn't pass because of missing support for attribute __optimize__ in 
the Visium back-end.

Tested on visium-elf, applied on the mainline and 6 branch.


2016-08-29  Eric Botcazou  

* gcc.dg/ipa/iinline-attr.c: XFAIL on Visium.

-- 
Eric BotcazouIndex: gcc.dg/ipa/iinline-attr.c
===
--- gcc.dg/ipa/iinline-attr.c	(revision 239761)
+++ gcc.dg/ipa/iinline-attr.c	(working copy)
@@ -23,4 +23,5 @@ int test (void)
   return 0;
 }
 
-/* { dg-final { scan-ipa-dump "hooray\[^\\n\]*inline copy in test"  "inline"  } } */
+/* { dg-final { scan-ipa-dump "hooray\[^\\n\]*inline copy in test" "inline" { xfail visium-*-* } } } */
+/* Missing back-end support for attribute __optimize__ on Visium.  */

Re: PR35503 - warn for restrict pointer

[Tobias Burnus]

Prathamesh Kulkarni wrote:
> Attachment: pr35503-3.txt

I tried the patch - and it found a bug in our code; nice!


(a) Regarding the [-Werror] output:

   error: passing argument 24 to restrict qualified parameter aliases with 
argument 29 [-Werror]

Shouldn't that output "[-Werror=restrict]" instead of a bare "[-Werror]? 
Namely, instead of

+   warning_at (loc, 0,
+   "passing argument %u to restrict qualified parameter 
aliases with "
+   "argument %u", param_pos + 1, i + 1);

I think one gets this with
warning_at (loc, OPT_Wrestrict, ...


 * * *

(b) I get:


file.cc:5582:41: error: passing argument 24 to restrict qualified parameter 
aliases with argument 29 [-Werror]
out, out2);
 ^
file.cc:5582:41: error: passing argument 29 to restrict qualified parameter 
aliases with argument 24 [-Werror]


Thus, the message is kind of shown twice, one for 24 and once for 29;
but only one has a "^" possition, pointing after the 31st argument.


(i) I had expected that the message is shown only once. The issue here that
both the 24th and the 29th argument have the restrict qualifier. A simple

+  if (i < param_pos)
+   continue;

in warn_for_restrict would have silenced the second call, but would have
missed the output if only the 29th argument had the qualifier and not
also the 24th argument. Thus, one needs some more logic.


(ii) It would be great if the "^" wouldn't point to the end of the
argument list but to the one of the aliasing arguments - or even better
to "^~~" to the first argument and to "~" to the second.

I have to admit that I don't know how to use rich_location, but I am sure
digging in the source would help; possibly, also David or Marek can give
you a hint.

Cheers,

Tobias

Re: PR35503 - warn for restrict pointer

[Marek Polacek]

On Sun, Aug 28, 2016 at 06:32:59PM +0530, Prathamesh Kulkarni wrote:
> On 26 August 2016 at 21:25, Jason Merrill  wrote:
> > On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
> >  wrote:
> >> However with C++FE it appears TYPE_RESTRICT is not set for the
> >> parameters (buf and fmt)
> >> and hence the warning doesn't get emitted for C++.
> >> C FE sets TYPE_RESTRICT for them. I am not sure how to workaround this
> >> issue, and would be grateful for suggestions.
> >
> > In the C++ FE you can see TYPE_RESTRICT on the types of the
> > DECL_ARGUMENTS of the function.
> Thanks for the suggestions, I could indeed see TYPE_RESTRICT set on
> DECL_ARGUMENTS.
> The attached patch warns for both C and C++ with -Wrestrict, and I
> have put it under -Wall.
> I suppose we don't want to warn for null pointer args ?
> for eg:
> void f(int *restrict x, int *y);
> 
> void foo(void)
> {
>   f(NULL, NULL) ?
> }
> 
> However I suppose warning for pointer constants other than zero is desirable ?
> I am not sure whether restrict is valid for obj-c/obj-c++, so I have
> just kept it to C and C++
> in the patch. Should the warning also be included for obj-c and obj-c++ FE's ?
> Boostrapped and tested on x86_64-unknown-linux-gnu.
> OK to commit ?
> 
> Thanks,
> Prathamesh
> >
> > Jason

> 2016-08-28  Prathamesh Kulkarni  
> 
>   PR c/35503
>   * doc/invoke.texi: Document -Wrestrict.
> c-family/
>   * c-common.c (warn_for_restrict): New function.
>   * c-common.h (warn_for_restrict): Declare it.
>   * c.opt: New option -Wrestrit.

Typo.

> c/
>   * c-parser.c (c_parser_postfix_expression_after_primary): Call
>   warn_for_restrict.
> cp/
>   * parser.c (cp_parser_postfix_expression): Likewise.

This is a ChangeLog entry in another directory, so Likewise wouldn't work here.

> testsuite/
>   * c-c++-common/pr35503.c: New test-case.
> 
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 3feb910..ec8778f 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -13057,4 +13057,27 @@ diagnose_mismatched_attributes (tree olddecl, tree 
> newdecl)
>return warned;
>  }
>  
> +/* Warn if an argument at position param_pos is passed to a
> +   restrict-qualified param, and it aliases with another argument.  */
> +
> +void
> +warn_for_restrict (location_t loc, unsigned param_pos, vec 
> *args)
> +{
> +  tree arg = (*args)[param_pos];
> +  if (operand_equal_p (arg, null_pointer_node, 0))
> +return;
> +
> +  for (unsigned i = 0; i < args->length (); ++i)

Use FOR_EACH_VEC_ELT?

> +{
> +  if (i == param_pos)
> + continue;
> +
> +  tree current_arg = (*args)[i];
> +  if (operand_equal_p (arg, current_arg, 0))
> + warning_at (loc, 0,
> + "passing argument %u to restrict qualified parameter 
> aliases with "

I think this should be "restrict-qualified".

> + "argument %u", param_pos + 1, i + 1);
> +}
> +}
> +
>  #include "gt-c-family-c-common.h"
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index bc22baa..0526ad5 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -920,6 +920,7 @@ extern void c_parse_final_cleanups (void);
>  
>  extern void warn_for_omitted_condop (location_t, tree);
>  extern void warn_for_memset (location_t, tree, tree, int);
> +extern void warn_for_restrict (location_t, unsigned, vec *);
>  
>  /* These macros provide convenient access to the various _STMT nodes.  */
>  
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index a5358ed..a029a86 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1012,6 +1012,11 @@ Wduplicate-decl-specifier
>  C ObjC Var(warn_duplicate_decl_specifier) Warning LangEnabledBy(C ObjC,Wall)
>  Warn when a declaration has duplicate const, volatile, restrict or _Atomic 
> specifier.
>  
> +Wrestrict
> +C C++ Var(warn_restrict) Warning LangEnabledBy(C C++,Wall)
> +Warn when an argument passed to a restrict-qualified parameter aliases with
> +another argument.
> +
>  ansi
>  C ObjC C++ ObjC++
>  A synonym for -std=c89 (for C) or -std=c++98 (for C++).
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index fe0c95f..54e1e87 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -8369,6 +8369,17 @@ c_parser_postfix_expression_after_primary (c_parser 
> *parser,
> warn_for_memset (expr_loc, arg0, arg2, literal_zero_mask);
>   }
>  
> +   if (TREE_CODE (expr.value) == FUNCTION_DECL && warn_restrict)
> + {
> +   unsigned param_pos = 0;
> +   for (tree t = TYPE_ARG_TYPES (TREE_TYPE (expr.value)); t; t = 
> TREE_CHAIN (t), param_pos++) 
> + {
> +   tree type = TREE_VALUE (t);
> +   if (POINTER_TYPE_P (type) && TYPE_RESTRICT (type))
> + warn_for_restrict (expr_loc, param_pos, exprlist);  
> + 

Re: Implement -Wimplicit-fallthrough (version 7)

[Eric Gallager]

On 8/29/16, David Malcolm  wrote:
> On Mon, 2016-08-29 at 09:32 -0400, Eric Gallager wrote:
>> On 8/29/16, Marek Polacek  wrote:
>> > Tobias tried my latest version and reported some ICEs.  They should
>> > all be
>> > fixed in this version (the only change since version 6 is the
>> > cp/pt.c
>> > hunk).
>> >
>> > At this point I'd like to ask Jason and Joseph to review the C/C++
>> > parts
>> > and someone to review the ME parts so that I can finally wrap this
>> > thing
>> > up.  This warning found a couple of bugs in our codebase and I
>> > suspect it
>> > will find some in other codebases, too.
>> >
>> > Does anyone have any concerns that I haven't addressed yet?
>> >
>> > Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for
>> > trunk?
>> >
>>
>>
>> I tried v6 on my binutils-gdb fork, and it printed A LOT of
>> warnings... After this patch goes in, the main question I'd have
>> would
>> be about the carets: it seems like it would make more sense for me
>> for
>> the location of the warning to be swapped with that of the fixit
>> hint(s)? With the fixit pointing to the case label before the
>> statement that's warned about, it makes it look like it's suggesting
>> to put the fallthrough attribute or the break before the rest of the
>> content of the case, which, with the break, could lead to dead code.
>> I'd think it'd make more sense to point to after the body of the case
>> statement instead...
>
> Interesting.  Please can you post an example of the output that you're
> referring to?
>
> I'm working on improvements to how we print fix-its, so I'm wondering
> if this is an issue with the fix-it data, or with the presentation of
> it.
>
> Thanks
> Dave
>

Sure, an example of the warning looks like this for me:

./cli/cli-setshow.c: In function ‘do_setshow_command’:
./cli/cli-setshow.c:353:7: warning: this statement may fall through
[-Wimplicit-fallthrough]
if (*(unsigned int *)c->var == UINT_MAX)
   ^
./cli/cli-setshow.c:359:2: note: insert ‘__attribute__
((fallthrough));’ to silence this warning
  case var_zinteger:
  ^~~~
  __attribute__ ((fallthrough));
./cli/cli-setshow.c:359:2: note: insert ‘break;’ to avoid fall-through
  case var_zinteger:
  ^~~~
  break;

Eric

Re: Implement -Wimplicit-fallthrough (version 7)

[David Malcolm]

On Mon, 2016-08-29 at 09:32 -0400, Eric Gallager wrote:
> On 8/29/16, Marek Polacek  wrote:
> > Tobias tried my latest version and reported some ICEs.  They should
> > all be
> > fixed in this version (the only change since version 6 is the
> > cp/pt.c
> > hunk).
> > 
> > At this point I'd like to ask Jason and Joseph to review the C/C++
> > parts
> > and someone to review the ME parts so that I can finally wrap this
> > thing
> > up.  This warning found a couple of bugs in our codebase and I
> > suspect it
> > will find some in other codebases, too.
> > 
> > Does anyone have any concerns that I haven't addressed yet?
> > 
> > Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for
> > trunk?
> > 
> 
> 
> I tried v6 on my binutils-gdb fork, and it printed A LOT of
> warnings... After this patch goes in, the main question I'd have
> would
> be about the carets: it seems like it would make more sense for me
> for
> the location of the warning to be swapped with that of the fixit
> hint(s)? With the fixit pointing to the case label before the
> statement that's warned about, it makes it look like it's suggesting
> to put the fallthrough attribute or the break before the rest of the
> content of the case, which, with the break, could lead to dead code.
> I'd think it'd make more sense to point to after the body of the case
> statement instead...

Interesting.  Please can you post an example of the output that you're
referring to?

I'm working on improvements to how we print fix-its, so I'm wondering
if this is an issue with the fix-it data, or with the presentation of
it.

Thanks
Dave

Re: Implement -Wimplicit-fallthrough (version 7)

[Eric Gallager]

On 8/29/16, Marek Polacek  wrote:
> Tobias tried my latest version and reported some ICEs.  They should all be
> fixed in this version (the only change since version 6 is the cp/pt.c
> hunk).
>
> At this point I'd like to ask Jason and Joseph to review the C/C++ parts
> and someone to review the ME parts so that I can finally wrap this thing
> up.  This warning found a couple of bugs in our codebase and I suspect it
> will find some in other codebases, too.
>
> Does anyone have any concerns that I haven't addressed yet?
>
> Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for trunk?
>


I tried v6 on my binutils-gdb fork, and it printed A LOT of
warnings... After this patch goes in, the main question I'd have would
be about the carets: it seems like it would make more sense for me for
the location of the warning to be swapped with that of the fixit
hint(s)? With the fixit pointing to the case label before the
statement that's warned about, it makes it look like it's suggesting
to put the fallthrough attribute or the break before the rest of the
content of the case, which, with the break, could lead to dead code.
I'd think it'd make more sense to point to after the body of the case
statement instead...

Eric

Re: Make max_align_t respect _Float128

[Marek Polacek]

On Fri, Aug 26, 2016 at 02:51:38PM -0700, Paul Eggert wrote:
> > Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__
> > (the effect would be an extra union member
> 
> s/union/struct/. Though I've always wondered why it is a struct and not a
> union. Maybe change it to union while we're doing an ABI change anyway?
 
Yeah, me too.  The initial implementation is here
 but I don't see any
comments wrt max_align_t being a struct or a union there.

Marek

Re: PR35503 - warn for restrict pointer (-Wrestrict)

[Eric Gallager]

On 8/28/16, Prathamesh Kulkarni  wrote:
> On 26 August 2016 at 21:25, Jason Merrill  wrote:
>> On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
>>  wrote:
>>> However with C++FE it appears TYPE_RESTRICT is not set for the
>>> parameters (buf and fmt)
>>> and hence the warning doesn't get emitted for C++.
>>> C FE sets TYPE_RESTRICT for them. I am not sure how to workaround this
>>> issue, and would be grateful for suggestions.
>>
>> In the C++ FE you can see TYPE_RESTRICT on the types of the
>> DECL_ARGUMENTS of the function.
> Thanks for the suggestions, I could indeed see TYPE_RESTRICT set on
> DECL_ARGUMENTS.
> The attached patch warns for both C and C++ with -Wrestrict, and I
> have put it under -Wall.
> I suppose we don't want to warn for null pointer args ?
> for eg:
> void f(int *restrict x, int *y);
>
> void foo(void)
> {
>   f(NULL, NULL) ?
> }
>
> However I suppose warning for pointer constants other than zero is desirable
> ?
> I am not sure whether restrict is valid for obj-c/obj-c++, so I have
> just kept it to C and C++
> in the patch. Should the warning also be included for obj-c and obj-c++ FE's
> ?
> Boostrapped and tested on x86_64-unknown-linux-gnu.
> OK to commit ?
>
> Thanks,
> Prathamesh
>


I tried this patch on my fork of gdb-binutils and got a few warnings
from it. Would it be possible to have the caret point to the argument
mentioned, instead of the function name? And also print the option
name? E.g., instead of the current:

or32-opc.c: In function ‘or32_print_register’:
or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
parameter aliases with argument 3
   sprintf (disassembled, "%sr%d", disassembled, regnum);
   ^~~

could it look like:

or32-opc.c: In function ‘or32_print_register’:
or32-opc.c:956:3: warning: passing argument 1 to restrict qualified
parameter aliases with argument 3 [-Wrestrict]
   sprintf (disassembled, "%sr%d", disassembled, regnum);
^~~~

instead?
Just an idea. Either way, I hope this patch goes in.
Thanks,
Eric

Re: Add fixit hint for -Wlogical-not-parentheses

[David Malcolm]

On Mon, 2016-08-29 at 13:44 +0200, Marek Polacek wrote:
> On Mon, Aug 29, 2016 at 12:35:38PM +0200, Marek Polacek wrote:
> > On Mon, Aug 29, 2016 at 11:16:25AM +0200, Andreas Schwab wrote:
> > > On Aug 25 2016, Marek Polacek  wrote:
> > > 
> > > > * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> > > 
> > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11 
> > >  expected multiline pattern lines 13-17 not found: "\s*r \+= !aaa
> > > == bbb;.*\n \^~\n   r \+= !aaa == bbb;.*\n   
> > >  \^~~~\n\(   \).*\n"
> > > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11
> > > (test for excess errors)
> > > Excess errors:
> > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > applied" } */
> > >  ^~
> > >r += !aaa == bbb; /* { dg-warning "logical not is only
> > > applied" } */
> > > ^~~~
> > 
> > This has regressed with David's
> > 
> > commit 367964faf71a99ebd511dffb81075b58bff345a1
> > Author: dmalcolm 
> > Date:   Fri Aug 26 21:25:41 2016 +
> > 
> > Add validation and consolidation of fix-it hints
> > 
> > I don't know yet what exactly went wrong here.
> 
> So we reject printing fix-it hint because in reject_impossible_fixit:
> 
> 2187   if (where <= LINE_MAP_MAX_LOCATION_WITH_COLS)
> 2188 /* WHERE is a reasonable location for a fix-it; don't reject
> it.  */
> 2189 return false;
> 
> (gdb) p where
> $1 = 2147483652
> (gdb) p LINE_MAP_MAX_LOCATION_WITH_COLS
> $2 = 1610612736
> 
> so we set m_seen_impossible_fixit.
> 
> David, why is that happening?

Sorry about this; I believe I did my testing of my patch against a tree
that didn't yet have your change.

(gdb) p /x 2147483652
$2 = 0x8004

so "where", the insertion-point, is an ad-hoc location (describing a
range), and it looks like I somehow forgot to deal with that case in
the validation code.

I'm working on a fix.  Sorry again.

Dave

[PTX] fix build

[Nathan Sidwell]

I've committed this to fix trunk build breakage for PTX targets.

nathan
2016-08-29  Nathan Sidwell  

* config/nvptx/nvptx.c: #include tree-vrp.h.

Index: config/nvptx/nvptx.c
===
--- config/nvptx/nvptx.c(revision 239819)
+++ config/nvptx/nvptx.c(working copy)
@@ -60,6 +60,7 @@
 #include "internal-fn.h"
 #include "gimple-iterator.h"
 #include "stringpool.h"
+#include "tree-vrp.h"
 #include "tree-ssa-operands.h"
 #include "tree-ssanames.h"
 #include "gimplify.h"

Ping! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

[Fritz Reese]

https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html
On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese  wrote:
> This patch extends the GNU Fortran front-end to add support for
> DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
> -fdec-static, allowing explicit control of variable storage. AUTOMATIC
> local variables are placed on the stack, whereas STATIC variables are
> placed in static storage.

Patch still pending review.

> Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
> and critique welcome. Ok for trunk?
...
>
> 08-17-2016  Fritz Reese  
>
> gcc/fortran/
> * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
> * options.c (set_dec_flags): Set -fdec-static with -fdec.
> * gfortran.h (symbol_attribute): New attribute AUTOMATIC.
> * gfortran.h (gfc_add_automatic): New prototype.
> * match.h (gfc_match_automatic, gfc_match_static): New functions.
> * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
> * symbol.c (gfc_add_automatic): Ditto.
> * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
> * parse.c (decode_specification_statement, decode_statement): Ditto.
> * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
> resolve_symbol): Support for automatic attribute.
> * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
> Ditto.
> * trans-decl.c (gfc_finish_var_decl): Ditto.
>
> gcc/testsuite/gfortran.dg/
> * dec_static_1.f90, dec_static_2.f90: New testcases.

---
Fritz Reese

[committed] Re: [PATCH, Fortran] Fix compare logic for anonymous structure types

[Fritz Reese]

https://gcc.gnu.org/ml/fortran/2016-08/msg00145.html
On Wed, Aug 24, 2016 at 5:32 PM, Fritz Reese  wrote:
> https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html
>
> On Wed, Aug 24, 2016 at 5:14 PM, Fritz Reese  wrote:
>> With a few recent notes by others, I have identified that the
>> comparison logic I used in interface.c (compare_components,
>> gfc_compare_derived_types) was faulty in a few ways.
> (snip)
>> tl;dr: The attached patch fixes PR 77327 and another bug which is
>> demonstrated in the included testcase.

FYI-
Committed the patch (as attached) as r239819. Note that PR 77327 is
exhibited by the existing testcase gfortran.dg/import4.f90.

Nb. there was one final typo fixed before committing since the
previously posted version:


--- a/gcc/testsuite/gfortran.dg/dec_structure_13.f90
+++ b/gcc/testsuite/gfortran.dg/dec_structure_13.f90
@@ -37,7 +37,7 @@ subroutine sub1 ()
   call sub0(u) ! regression: Type mismatch in argument
 end subroutine

-subroutine sub3(u)
+subroutine sub2(u)
   structure /tu/
 union
   map


---
Fritz Reese


2016-08-29  Fritz Reese  

Fix, reorganize, and clarify comparisons of anonymous types/components.

PR fortran/77327
* interface.c (is_anonymous_component, is_anonymous_dt): New functions.
* interface.c (compare_components, gfc_compare_derived_types): Use new
functions.

* gfortran.dg/dec_structure_13.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 17500c9..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -387,26 +387,46 @@ gfc_match_end_interface (void)
 }
 
 
+/* Return whether the component was defined anonymously.  */
+
+static bool
+is_anonymous_component (gfc_component *cmp)
+{
+  /* Only UNION and MAP components are anonymous.  In the case of a MAP,
+ the derived type symbol is FL_STRUCT and the component name looks like mM*.
+ This is the only case in which the second character of a component name is
+ uppercase.  */
+  return cmp->ts.type == BT_UNION
+|| (cmp->ts.type == BT_DERIVED
+&& cmp->ts.u.derived->attr.flavor == FL_STRUCT
+&& cmp->name[0] && cmp->name[1] && ISUPPER (cmp->name[1]));
+}
+
+
+/* Return whether the derived type was defined anonymously.  */
+
+static bool
+is_anonymous_dt (gfc_symbol *derived)
+{
+  /* UNION and MAP types are always anonymous. Otherwise, only nested STRUCTURE
+ types can be anonymous.  For anonymous MAP/STRUCTURE, we have FL_STRUCT
+ and the type name looks like XX*.  This is the only case in which the
+ second character of a type name is uppercase.  */
+  return derived->attr.flavor == FL_UNION
+|| (derived->attr.flavor == FL_STRUCT
+&& derived->name[0] && derived->name[1] && ISUPPER (derived->name[1]));
+}
+
+
 /* Compare components according to 4.4.2 of the Fortran standard.  */
 
 static int
 compare_components (gfc_component *cmp1, gfc_component *cmp2,
 gfc_symbol *derived1, gfc_symbol *derived2)
 {
-  gfc_symbol *d1, *d2;
-  bool anonymous = false;
-
-  /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
- which should not be compared.  */
-  d1 = cmp1->ts.u.derived;
-  d2 = cmp2->ts.u.derived;
-  if (   (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
-  && ISUPPER (cmp1->name[1]))
-  || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
-  && ISUPPER (cmp2->name[1])))
-anonymous = true;
-
-  if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
+  /* Compare names, but not for anonymous components such as UNION or MAP.  */
+  if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
+  && strcmp (cmp1->name, cmp2->name) != 0)
 return 0;
 
   if (cmp1->attr.access != cmp2->attr.access)
@@ -512,22 +532,12 @@ int
 gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
 {
   gfc_component *cmp1, *cmp2;
-  bool anonymous = false;
 
   if (derived1 == derived2)
 return 1;
 
   gcc_assert (derived1 && derived2);
 
-  /* MAP and anonymous STRUCTURE types have internal names of the form
- mM* and sS* (we can get away this this because source names are converted
- to lowerase). Compare anonymous type names specially because each
- gets a unique name when it is declared. */
-  anonymous = (derived1->name[0] == derived2->name[0]
-  && derived1->name[1] && derived2->name[1] && derived2->name[2]
-  && derived1->name[1] == (char) TOUPPER (derived1->name[0])
-  && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
-
   /* Special case for comparing derived types across namespaces.  If the
  true names and module names are the same and the module name is
  nonnull, then they are equal.  */
@@ -541,7 +551,9 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
  because they can be 

Implement -Wimplicit-fallthrough (version 7): add gcc_fallthrough()

[Marek Polacek]

A rebased version, nothing has really changed since the last time.

2016-08-29  Marek Polacek  

PR c/7652
* Makefile.in (insn-attrtab.o-warn, insn-dfatab.o-warn,
insn-latencytab.o-warn, insn-output.o-warn, insn-emit.o-warn): Add
-Wno-switch-fallthrough.
* builtins.c (expand_builtin_int_roundingfn_2): Add gcc_fallthrough.
(expand_builtin): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorized_libmass): Likewise.
* convert.c (convert_to_real_1): Likewise.
(convert_to_integer_1): Likewise.
* final.c (output_alternate_entry_point): Likewise.
* genattrtab.c (make_canonical): Likewise.
(write_test_expr): Likewise.
* genpreds.c (validate_exp): Likewise.
* gimple-ssa-strength-reduction.c
(find_candidates_dom_walker::before_dom_children): Likewise.
* godump.c (go_format_type): Likewise.
* reload1.c (elimination_effects): Likewise.
* resource.c (mark_referenced_resources): Likewise.
(mark_set_resources): Likewise.
* tree-ssa-loop-ivopts.c (find_deriving_biv_for_expr): Likewise.
* varasm.c (output_addressed_constants): Likewise.
gcc/c-family/
* c-common.c (resolve_overloaded_builtin): Add gcc_fallthrough.
gcc/c/
* c-decl.c (pop_scope): Add gcc_fallthrough.
* c-typeck.c (composite_type): Likewise.
gcc/gcc/cp/
* error.c (dump_type): Add gcc_fallthrough.
(dump_decl): Likewise.
(dump_expr): Likewise.
* parser.c (cp_parser_storage_class_specifier_opt): Likewise.
(cp_parser_skip_to_end_of_template_parameter_list): Likewise.
(cp_parser_cache_defarg): Likewise.
(cp_parser_omp_for_cond): Likewise.
* semantics.c (finish_decltype_type): Likewise.
* typeck.c (structural_comptypes): Likewise.
(cp_build_binary_op): Likewise.
(cp_build_modify_expr): Likewise.
gcc/fortran/
* arith.c (eval_intrinsic): Add gcc_fallthrough.
* frontend-passes.c (optimize_op): Likewise.
(gfc_expr_walker): Likewise.
* parse.c (next_fixed): Likewise.
* primary.c (match_variable): Likewise.
* trans-array.c: Likewise.
* trans-expr.c (flatten_array_ctors_without_strlen): Likewise.
libstdc++-v3/
* libsupc++/hash_bytes.cc: Add [[gnu::fallthrough]].

diff --git gcc/gcc/Makefile.in gcc/gcc/Makefile.in
index 8d7cc51..f2e9a43 100644
--- gcc/gcc/Makefile.in
+++ gcc/gcc/Makefile.in
@@ -218,6 +218,11 @@ libgcov-merge-tool.o-warn = -Wno-error
 gimple-match.o-warn = -Wno-unused
 generic-match.o-warn = -Wno-unused
 dfp.o-warn = -Wno-strict-aliasing
+insn-attrtab.o-warn = -Wno-implicit-fallthrough
+insn-dfatab.o-warn = -Wno-implicit-fallthrough
+insn-latencytab.o-warn = -Wno-implicit-fallthrough
+insn-output.o-warn = -Wno-implicit-fallthrough
+insn-emit.o-warn = -Wno-implicit-fallthrough
 
 # All warnings have to be shut off in stage1 if the compiler used then
 # isn't gcc; configure determines that.  WARN_CFLAGS will be either
diff --git gcc/gcc/builtins.c gcc/gcc/builtins.c
index b981bcd..9da37dc 100644
--- gcc/gcc/builtins.c
+++ gcc/gcc/builtins.c
@@ -2588,7 +2588,7 @@ expand_builtin_int_roundingfn_2 (tree exp, rtx target)
 {
 CASE_FLT_FN (BUILT_IN_IRINT):
   fallback_fn = BUILT_IN_LRINT;
-  /* FALLTHRU */
+  gcc_fallthrough ();
 CASE_FLT_FN (BUILT_IN_LRINT):
 CASE_FLT_FN (BUILT_IN_LLRINT):
   builtin_optab = lrint_optab;
@@ -2596,7 +2596,7 @@ expand_builtin_int_roundingfn_2 (tree exp, rtx target)
 
 CASE_FLT_FN (BUILT_IN_IROUND):
   fallback_fn = BUILT_IN_LROUND;
-  /* FALLTHRU */
+  gcc_fallthrough ();
 CASE_FLT_FN (BUILT_IN_LROUND):
 CASE_FLT_FN (BUILT_IN_LLROUND):
   builtin_optab = lround_optab;
@@ -5905,6 +5905,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget, 
machine_mode mode,
 CASE_FLT_FN (BUILT_IN_ILOGB):
   if (! flag_unsafe_math_optimizations)
break;
+  gcc_fallthrough ();
 CASE_FLT_FN (BUILT_IN_ISINF):
 CASE_FLT_FN (BUILT_IN_FINITE):
 case BUILT_IN_ISFINITE:
diff --git gcc/gcc/c-family/c-common.c gcc/gcc/c-family/c-common.c
index 001070d..3bbe951 100644
--- gcc/gcc/c-family/c-common.c
+++ gcc/gcc/c-family/c-common.c
@@ -11592,6 +11592,7 @@ resolve_overloaded_builtin (location_t loc, tree 
function,
gcc_unreachable ();
}
/* Fallthrough to the normal processing.  */
+   gcc_fallthrough ();
   }
 case BUILT_IN_ATOMIC_EXCHANGE_N:
 case BUILT_IN_ATOMIC_COMPARE_EXCHANGE_N:
@@ -11600,6 +11601,7 @@ resolve_overloaded_builtin (location_t loc, tree 
function,
   {
fetch_op = false;
/* Fallthrough to further processing.  */
+   gcc_fallthrough ();
   }
 case BUILT_IN_ATOMIC_ADD_FETCH_N:
 case BUILT_IN_ATOMIC_SUB_FETCH_N:
@@ -11616,6 +11618,7 @@ resolve_overloaded_builtin (location_t loc, tree 
function,
   {
 

Implement -Wimplicit-fallthrough (version 7)

[Marek Polacek]

Tobias tried my latest version and reported some ICEs.  They should all be
fixed in this version (the only change since version 6 is the cp/pt.c hunk).

At this point I'd like to ask Jason and Joseph to review the C/C++ parts
and someone to review the ME parts so that I can finally wrap this thing
up.  This warning found a couple of bugs in our codebase and I suspect it
will find some in other codebases, too.

Does anyone have any concerns that I haven't addressed yet?

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

2016-08-29  Marek Polacek  
Jakub Jelinek  

PR c/7652
gcc/
* common.opt (Wimplicit-fallthrough): New option.
* doc/extend.texi: Document statement attributes and the fallthrough
attribute.
* doc/invoke.texi: Document -Wimplicit-fallthrough.
* gimple.h (gimple_call_internal_p): New function.
* gimplify.c (struct gimplify_ctx): Add in_switch_expr.
(struct label_entry): New struct.
(find_label_entry): New function.
(case_label_p): New function.
(collect_fallthrough_labels): New function.
(last_stmt_in_scope): New function.
(should_warn_for_implicit_fallthrough): New function.
(warn_implicit_fallthrough_r): New function.
(maybe_warn_implicit_fallthrough): New function.
(expand_FALLTHROUGH_r): New function.
(expand_FALLTHROUGH): New function.
(gimplify_switch_expr): Call maybe_warn_implicit_fallthrough and
expand_FALLTHROUGH for the innermost GIMPLE_SWITCH.
(gimplify_label_expr): New function.
(gimplify_case_label_expr): Set location.
(gimplify_expr): Call gimplify_label_expr.
* internal-fn.c (expand_FALLTHROUGH): New function.
* internal-fn.def (FALLTHROUGH): New internal function.
* langhooks.c (lang_GNU_OBJC): New function.
* langhooks.h (lang_GNU_OBJC): Declare.
* system.h (gcc_fallthrough): Define.
* tree-core.h: Add FALLTHROUGH_LABEL_P comment.
* tree.h (FALLTHROUGH_LABEL_P): Define.
gcc/c-family/
* c-common.c (c_common_attribute_table): Add fallthrough attribute.
(handle_fallthrough_attribute): New function.
gcc/c/
* c-parser.c (struct c_token): Add flags field.
(c_lex_one_token): Pass it to c_lex_with_flags.
(c_parser_declaration_or_fndef): Turn __attribute__((fallthrough));
into IFN_FALLTHROUGH.
(c_parser_label): Set FALLTHROUGH_LABEL_P on labels.
(c_parser_statement_after_labels): Handle RID_ATTRIBUTE.
gcc/cp/
* constexpr.c (cxx_eval_internal_function): Handle IFN_FALLTHROUGH.
(potential_constant_expression_1): Likewise.
* constraint.cc (function_concept_check_p): Check fn for null.
* parser.c (cp_parser_primary_expression): Handle RID_ATTRIBUTE.
(cp_parser_statement): Handle fallthrough attribute.
(cp_parser_label_for_labeled_statement): Set FALLTHROUGH_LABEL_P on
labels.
(cp_parser_std_attribute): Handle fallthrough attribute.
(cp_parser_check_std_attribute): Detect duplicated fallthrough
attribute.
* pt.c (tsubst_copy_and_build): Handle internal functions.
(instantiation_dependent_scope_ref_p): Return if the expression is
null.
gcc/testsuite/
* c-c++-common/Wimplicit-fallthrough-1.c: New test.
* c-c++-common/Wimplicit-fallthrough-10.c: New test.
* c-c++-common/Wimplicit-fallthrough-11.c: New test.
* c-c++-common/Wimplicit-fallthrough-12.c: New test.
* c-c++-common/Wimplicit-fallthrough-13.c: New test.
* c-c++-common/Wimplicit-fallthrough-14.c: New test.
* c-c++-common/Wimplicit-fallthrough-15.c: New test.
* c-c++-common/Wimplicit-fallthrough-16.c: New test.
* c-c++-common/Wimplicit-fallthrough-17.c: New test.
* c-c++-common/Wimplicit-fallthrough-18.c: New test.
* c-c++-common/Wimplicit-fallthrough-19.c: New test.
* c-c++-common/Wimplicit-fallthrough-2.c: New test.
* c-c++-common/Wimplicit-fallthrough-3.c: New test.
* c-c++-common/Wimplicit-fallthrough-4.c: New test.
* c-c++-common/Wimplicit-fallthrough-5.c: New test.
* c-c++-common/Wimplicit-fallthrough-6.c: New test.
* c-c++-common/Wimplicit-fallthrough-7.c: New test.
* c-c++-common/Wimplicit-fallthrough-8.c: New test.
* c-c++-common/Wimplicit-fallthrough-9.c: New test.
* c-c++-common/attr-fallthrough-1.c: New test.
* c-c++-common/attr-fallthrough-2.c: New test.
* g++.dg/warn/Wimplicit-fallthrough-1.C: New test.
* g++.dg/warn/Wimplicit-fallthrough-2.C: New test.
* g++.dg/cpp0x/fallthrough1.C: New test.
* g++.dg/cpp0x/fallthrough2.C: New test.
* g++.dg/cpp1z/fallthrough1.C: New test.
* gcc.dg/Wimplicit-fallthrough-1.c: New test.
* 

[x86] Don't use builtins for unaligned load/store

[Marc Glisse]

Hello,

this patch gets rid of a few more builtins (well, I actually kept them, 
since Ada users may still need them). I had to tweak the flags for 
pr59539-2.c, otherwise the compiler thinks it is more efficient to split 
the loads, reading 128 bits at a time. This still breaks one testcase: 
avx512f-vmovdqu32-1.c. I don't think it really matters, and I'll just 
adapt the scan-assembler-times regex if you agree, but from 
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html it looks like 
getting 32 instead of 64 might be on purpose, so I'd like your opinion on 
that


movqp(%rip), %rax
vmovdqu64   (%rax), %zmm0
vmovdqa64   %zmm0, x(%rip)
kmovw   m(%rip), %k1
vmovdqa64   x(%rip), %zmm0
vmovdqu32   (%rax), %zmm0{%k1}
vmovdqa64   %zmm0, x(%rip)
kmovw   m(%rip), %k1
vmovdqu32   (%rax), %zmm0{%k1}{z}
vmovdqa64   %zmm0, x(%rip)
vmovdqa64   x(%rip), %zmm0
-   vmovdqu32   %zmm0, (%rax)
+   vmovdqu64   %zmm0, (%rax)
movqp(%rip), %rax
vmovdqa64   x(%rip), %zmm0
kmovw   m(%rip), %k1
vmovdqu32   %zmm0, (%rax){%k1}

The changes in the signature of functions don't seem to matter, gcc 
apparently ignores the aligned attribute for that purpose. The last change 
(_mm_load_ps) is for consistency.


Bootstrap+regtest on x86_64-pc-linux-gnu, with only the above regression.

2016-08-29  Marc Glisse  

gcc/
* config/i386/avx512fintrin.h (__m512_u, __m512i_u, __m512d_u):
New types.
(_mm512_loadu_pd, _mm512_storeu_pd, _mm512_loadu_ps,
_mm512_storeu_ps, _mm512_loadu_si512, _mm512_storeu_si512):
Replace builtin with vector extension.
* config/i386/avxintrin.h (__m256_u, __m256i_u, __m256d_u):
New types.
(_mm256_loadu_pd, _mm256_storeu_pd, _mm256_loadu_ps,
_mm256_storeu_ps, _mm256_loadu_si256, _mm256_storeu_si256):
Replace builtin with vector extension.
* config/i386/emmintrin.h (__m128i_u, __m128d_u): New types.
(_mm_loadu_pd, _mm_storeu_pd, _mm_loadu_si128, _mm_storeu_si128):
Replace builtin with vector extension.
* config/i386/xmmintrin.h (__m128_u): New type.
(_mm_loadu_ps, _mm_storeu_ps): Replace builtin with vector extension.
(_mm_load_ps, _mm_store_ps): Simplify.

testsuite/
* gcc.target/i386/pr59539-2.c: Adapt options.

--
Marc GlisseIndex: gcc/config/i386/avx512fintrin.h
===
--- gcc/config/i386/avx512fintrin.h	(revision 239797)
+++ gcc/config/i386/avx512fintrin.h	(working copy)
@@ -52,6 +52,11 @@
 typedef long long __m512i __attribute__ ((__vector_size__ (64), __may_alias__));
 typedef double __m512d __attribute__ ((__vector_size__ (64), __may_alias__));
 
+/* Unaligned version of the same type.  */
+typedef float __m512_u __attribute__ ((__vector_size__ (64), __may_alias__, __aligned__ (1)));
+typedef long long __m512i_u __attribute__ ((__vector_size__ (64), __may_alias__, __aligned__ (1)));
+typedef double __m512d_u __attribute__ ((__vector_size__ (64), __may_alias__, __aligned__ (1)));
+
 typedef unsigned char  __mmask8;
 typedef unsigned short __mmask16;
 
@@ -5674,10 +5679,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm512_loadu_pd (void const *__P)
 {
-  return (__m512d) __builtin_ia32_loadupd512_mask ((const double *) __P,
-		   (__v8df)
-		   _mm512_undefined_pd (),
-		   (__mmask8) -1);
+  return *(__m512d_u *)__P;
 }
 
 extern __inline __m512d
@@ -5703,8 +5705,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm512_storeu_pd (void *__P, __m512d __A)
 {
-  __builtin_ia32_storeupd512_mask ((double *) __P, (__v8df) __A,
-   (__mmask8) -1);
+  *(__m512d_u *)__P = __A;
 }
 
 extern __inline void
@@ -5719,10 +5720,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm512_loadu_ps (void const *__P)
 {
-  return (__m512) __builtin_ia32_loadups512_mask ((const float *) __P,
-		  (__v16sf)
-		  _mm512_undefined_ps (),
-		  (__mmask16) -1);
+  return *(__m512_u *)__P;
 }
 
 extern __inline __m512
@@ -5748,8 +5746,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm512_storeu_ps (void *__P, __m512 __A)
 {
-  __builtin_ia32_storeups512_mask ((float *) __P, (__v16sf) __A,
-   (__mmask16) -1);
+  *(__m512_u *)__P = __A;
 }
 
 extern __inline void
@@ -5791,10 +5788,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm512_loadu_si512 (void const *__P)
 {
-  return (__m512i) __builtin_ia32_loaddqusi512_mask ((const int *) __P,
-		 (__v16si)
-		 _mm512_setzero_si512 (),
-		 (__mmask16) -1);
+  return *(__m512i_u *)__P;
 }
 
 extern __inline __m512i
@@ -5820,8 +5814,7 @@
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 

Re: Add fixit hint for -Wlogical-not-parentheses

[Marek Polacek]

On Mon, Aug 29, 2016 at 12:35:38PM +0200, Marek Polacek wrote:
> On Mon, Aug 29, 2016 at 11:16:25AM +0200, Andreas Schwab wrote:
> > On Aug 25 2016, Marek Polacek  wrote:
> > 
> > >   * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> > 
> > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11  expected 
> > multiline pattern lines 13-17 not found: "\s*r \+= !aaa == bbb;.*\n 
> > \^~\n   r \+= !aaa == bbb;.*\n\^~~~\n\(   \).*\n"
> > FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11 (test for 
> > excess errors)
> > Excess errors:
> >r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
> >  ^~
> >r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
> > ^~~~
> 
> This has regressed with David's
> 
> commit 367964faf71a99ebd511dffb81075b58bff345a1
> Author: dmalcolm 
> Date:   Fri Aug 26 21:25:41 2016 +
> 
> Add validation and consolidation of fix-it hints
> 
> I don't know yet what exactly went wrong here.

So we reject printing fix-it hint because in reject_impossible_fixit:

2187   if (where <= LINE_MAP_MAX_LOCATION_WITH_COLS)
2188 /* WHERE is a reasonable location for a fix-it; don't reject it.  */
2189 return false;

(gdb) p where
$1 = 2147483652
(gdb) p LINE_MAP_MAX_LOCATION_WITH_COLS
$2 = 1610612736

so we set m_seen_impossible_fixit.

David, why is that happening?

Marek

Re: [PATCH build/doc] Replacing libiberty with gnulib

[Joseph Myers]

On Sun, 28 Aug 2016, ayush goel wrote:

> > > +AUTOCONF_VERSION="2.69"
> > > +AUTOMAKE_VERSION="1.15"
> > > +ACLOCAL_VERSION="$AUTOMAKE_VERSION"
> > > +
> >
> > Is there a reason these need to be different from what the rest
> > of the toolchain uses?
> 
> Not really, these were just the newer version.
> On the other hand is there a specific reason we are using older
> versions of these tools, despite newer versions being available.

Upgrading and testing in a range of different configurations, for all the 
packages sharing the toplevel code, is quite tricky (though it's libtool 
that's the most problematic and where we know that on any upgrade we need 
to revert a libtool change for sysroot handling that conflicts with GCC 
sysroot handling).

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

Re: [RFC] ipa bitwise constant propagation

[Christophe Lyon]

On 26 August 2016 at 19:22, Prathamesh Kulkarni
 wrote:
> On 26 August 2016 at 21:53, Rainer Orth  wrote:
>> Hi Prathamesh,
>>
>>> The attached version passes bootstrap+test on
>>> x86_64-unknown-linux-gnu, ppc64le-linux-gnu,
>>> and with c,c++,fortran on armv8l-linux-gnueabihf.
>>> Cross-tested on arm*-*-* and aarch64*-*-*.
>>> Verified the patch survives lto-bootstrap on x86_64-unknown-linux-gnu.
>>> Ok to commit ?
>> [...]
>>> testsuite/
>>>   * gcc.dg/ipa/propbits-1.c: New test-case.
>>>   * gcc.dg/ipa/propbits-2.c: Likewise.
>>>   * gcc.dg/ipa/propbits-3.c: Likewise.
>> [...]
>>> diff --git a/gcc/testsuite/gcc.dg/ipa/propbits-2.c 
>>> b/gcc/testsuite/gcc.dg/ipa/propbits-2.c
>>> new file mode 100644
>>> index 000..3a960f0
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.dg/ipa/propbits-2.c
>>> @@ -0,0 +1,41 @@
>>> +/* x's mask should be meet(0xc, 0x3) == 0xf  */
>>> +
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -fno-early-inlining -fdump-ipa-cp" } */
>>> +
>>> +extern int pass_test ();
>>> +extern int fail_test ();
>>> +
>>> +__attribute__((noinline))
>>> +static int f1(int x)
>>> +{
>>> +  if ((x & ~0xf) == 0)
>>> +return pass_test ();
>>> +  else
>>> +return fail_test ();
>>> +}
>>> +
>>> +__attribute__((noinline))
>>> +static int f2(int y)
>>> +{
>>> +  return f1(y & 0x03);
>>> +}
>>> +
>>> +__attribute__((noinline))
>>> +static int f3(int z)
>>> +{
>>> +  return f1(z & 0xc);
>>> +}
>>> +
>>> +extern int a;
>>> +extern int b;
>>> +
>>> +int main(void)
>>> +{
>>> +  int k = f2(a);
>>> +  int l = f3(b);
>>> +  return k + l;
>>> +}
>>> +
>>> +/* { dg-final { scan-ipa-dump "Adjusting mask for param 0 to 0xf" "cp" } } 
>>> */
>>> +/* { dg-final { scan-dump-tree-not "fail_test" "optimized" } } */
>>
>> This testcase thoroughly broke make check-gcc:
> Oops, sorry for the breakage. I am not sure how this missed my testing :/
> I obtained test results using test_summary script with and without patch,
> and compared the results with compare_tests which apparently showed no
> regressions...
> Thanks for the fix.
>

Hmmm that's weird indeed.

> Thanks,
> Prathamesh
>>
>> At first, runtest errors out with
>>
>> ERROR: (DejaGnu) proc "scan-dump-tree-not fail_test optimized" does not 
>> exist.

I do see this message in gcc.log (and in gcc.sum), but...
>>
>> The resulting incomplete gcc.sum files confuse dg-extract-results.py
>>
>> testsuite/gcc6/gcc.sum.sep: no recognised summary line
>> testsuite/gcc6/gcc.log.sep: no recognised summary line
>>
 I do not see this...

>> and cause it to emit en empty gcc.sum, effectively losing all gcc
>> testresults in mail-report.log.
and gcc.sum looks quite good (except for the ERROR: message
which is not noticed by the comparison tools).

It could be an effect of a different 'make -j' value, resulting
in different split of gcc.sum.sep, thus making the error
un-noticed.

Christophe

>> This cannot have been tested in any reasonable way.
>>
>> Once you fix the typo (scan-dump-tree-not -> scan-tree-dump-not), at
>> least we get a complete gcc.sum again, but the testcase still shows up as
>>
>> UNRESOLVED: gcc.dg/ipa/propbits-2.c scan-tree-dump-not optimized "fail_test"
>>
>> and gcc.log shows
>>
>> gcc.dg/ipa/propbits-2.c: dump file does not exist
>>
>> Adding -fdump-tree-optimized creates the necessary dump and finally lets
>> the test pass.
>>
>> Here's the resulting patch.  Unless there are objections, I plan to
>> commit it soon.
>>
>> Rainer
>>
>>
>> 2016-08-26  Rainer Orth  
>>
>> * gcc.dg/ipa/propbits-2.c: Add -fdump-tree-optimized to dg-options.
>> Fix typo.
>>
>>
>>
>> --
>> -
>> Rainer Orth, Center for Biotechnology, Bielefeld University
>>

Re: Add fixit hint for -Wlogical-not-parentheses

[Marek Polacek]

On Mon, Aug 29, 2016 at 11:16:25AM +0200, Andreas Schwab wrote:
> On Aug 25 2016, Marek Polacek  wrote:
> 
> > * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> 
> FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11  expected 
> multiline pattern lines 13-17 not found: "\s*r \+= !aaa == bbb;.*\n   
>   \^~\n   r \+= !aaa == bbb;.*\n\^~~~\n\(   \).*\n"
> FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11 (test for 
> excess errors)
> Excess errors:
>r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
>  ^~
>r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
> ^~~~

This has regressed with David's

commit 367964faf71a99ebd511dffb81075b58bff345a1
Author: dmalcolm 
Date:   Fri Aug 26 21:25:41 2016 +

Add validation and consolidation of fix-it hints

I don't know yet what exactly went wrong here.

Marek

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Paul Richard Thomas]

Hi Janne, Andre, Jerry and All,

I am perfectly happy to adopt Janne's suggestion for
st_set_(dtio_)nml_var. Do the changes to the IO structures have any
impact? These are in:

fnode, st_parameter_dt & gfc_unit

I don't think that these should be visible but I want expert opinion
before making that assumption :-)

Cheers


Paul

On 29 August 2016 at 10:46, Janne Blomqvist  wrote:
> On Mon, Aug 29, 2016 at 11:15 AM, Andre Vehreschild  wrote:
>> Hi all,
>>
>>> Anyway, a small nit I found was the function st_set_nml_var in
>>> libgfortran. This is an exported function, and thus part of the ABI.
>>> So you cannot add arguments to it, as that would break backwards
>>> compatibility.
>>
>> Please explain the above. I was of the opinion, that when we change
>> something significantly the global ABI version gets bumped. Given that
>> we are doing gcc-7 currently and there have been some changes, that ABI
>> version should have been bumped already with respect to gcc-6.
>
> We strive very(?) hard to retain ABI compatibility for libgfortran, as
> having to recompile everything is a huge PITA for our users. As a
> result we have been able avoid bumping the SO major version number
> since GCC 4.3 IIRC.
>
> There is a long laundry-list of cleanups that could be done once we do
> bump the SO major version:
> https://gcc.gnu.org/wiki/LibgfortranAbiCleanup
>
> Probably when (if?) the new array descriptor is merged we have to do
> said bump, as that one is used everywhere and retaining compatibility
> with the old descriptor seems to be a huge undertaking.
>
>> I am asking that stupid question mostly, because during extending
>> coarray stuff to support allocatable components in derived typed
>> coarrays the API of the caf-library has to be modified and carrying
>> along the old signatures just causes useless garbage being carried
>> forward. (Opencoarrays is working on supporting the same renovated API.
>> Other users of that API are not known to me.) So what is the best way
>> to resolve this?
>
> I haven't involved myself in the coarray stuff, but AFAIU the corray
> lib hasn't been considered stable, in order that the developers can
> more quickly iterate on the design without having to be bogged down by
> ABI compatibility considerations.
>
> --
> Janne Blomqvist



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [MPX] Fix for PR77267

[Ilya Enkovich]

2016-08-25 12:27 GMT+03:00 Alexander Ivchenko :
> The attached patched fixes the usage of MPX in presence of
> "-Wl,-as-needed" option. 'make checked' on MPX-enabled machine.
>
> "--push-state" and "--pop-state" are not supported by gold at the
> moment. But that's OK because using MPX with gold only recommended in
> static build.

What will happen if compiler is configured to use gold by default?
Also is there any chance
we may use old linker with no push-state/pop-state support? I wonder
if you need to make
a new configure check and emit a warning similar to what is done for
"-z bndplt" option.

Thanks,
Ilya

>
> Would that be OK for trunk?
>
> diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
> index dd79ec6..1928b4e 100644
> --- a/gcc/config/i386/linux-common.h
> +++ b/gcc/config/i386/linux-common.h
> @@ -70,7 +70,9 @@ along with GCC; see the file COPYING3.  If not see
>  %{mmpx:%{fcheck-pointer-bounds:\
>  %{static:--whole-archive -lmpx --no-whole-archive" LIBMPX_LIBS "}\
>  %{!static:%{static-libmpx:" LD_STATIC_OPTION " --whole-archive}\
> --lmpx %{static-libmpx:--no-whole-archive " LD_DYNAMIC_OPTION \
> +%{!fuse-ld=gold:--push-state --no-as-needed} -lmpx\
> +%{!fuse-ld=gold:--pop-state} %{static-libmpx:--no-whole-archive "\
> +LD_DYNAMIC_OPTION \
>  LIBMPX_LIBS ""
>  #else
>  #define LIBMPX_SPEC "\
> @@ -84,7 +86,8 @@ along with GCC; see the file COPYING3.  If not see
>  %{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers:\
>  %{static:-lmpxwrappers}\
>  %{!static:%{static-libmpxwrappers:" LD_STATIC_OPTION " --whole-archive}\
> --lmpxwrappers %{static-libmpxwrappers:--no-whole-archive "\
> +%{!fuse-ld=gold:--push-state --no-as-needed} -lmpxwrappers\
> +%{!fuse-ld=gold:--pop-state} %{static-libmpxwrappers:--no-whole-archive 
> "\
>  LD_DYNAMIC_OPTION "}"
>  #else
>  #define LIBMPXWRAPPERS_SPEC "\
> .

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

[Bernd Schmidt]

On 08/01/2016 03:42 AM, Segher Boessenkool wrote:

+@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 
(sbitmap)
+Emit prologue insns for the components indicated by the parameter.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 
(sbitmap)
+Emit epilogue insns for the components indicated by the parameter.
+@end deftypefn


How do these actually know where to save/restore registers? The frame 
pointer may have been eliminated, and SP isn't necessarily constant 
during the function. Seems like you'd have to calculate CFA reg/offset 
much like dwarf2out does and pass it to this hook.



Bernd

Re: [PATCH] report supported function classes correctly on *-musl

[Bernd Schmidt]

On 07/20/2016 03:39 PM, Szabolcs Nagy wrote:

All function classes listed in gcc/coretypes.h are supported by musl.

Most of the optimizations based on these function classes are not
relevant for standard conform c code, but this is required to get
rid of some test system noise.

gcc/
2016-07-20  Szabolcs Nagy  

* config/linux.c (linux_libc_has_function): Return true on musl.


Also ok I guess.


Bernd

Re: [PATCH] disable ifunc on *-musl by default

[Bernd Schmidt]

On 07/20/2016 03:37 PM, Szabolcs Nagy wrote:

Musl libc does not support gnu ifunc, so disable it by default.
(not disabled on s390-* since that has no musl support yet.)

gcc/
2016-07-20  Szabolcs Nagy  

* config.gcc (*-*-*musl*): Disable gnu-indirect-function.


Ok I suppose? I'm assuming you know best.


Bernd

Re: [PATCH] Fix PR69047

[Andreas Schwab]

On Aug 26 2016, Richard Biener  wrote:

> Index: gcc/testsuite/gcc.dg/pr69047.c
> ===
> --- gcc/testsuite/gcc.dg/pr69047.c(revision 0)
> +++ gcc/testsuite/gcc.dg/pr69047.c(working copy)
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fdump-tree-cddce1" } */
> +
> +__UINT8_TYPE__
> +f(__UINT16_TYPE__ b)
> +{
> +  __UINT8_TYPE__ a;
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +  __builtin_memcpy(, , sizeof a);
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +  __builtin_memcpy(, (char *) + sizeof a, sizeof a);
> +#else
> +  a = b;
> +#endif
> +  return a;
> +}
> +
> +/* { dg-final { scan-tree-dump "_\[0-9\]+ = \\(\[^)\]+\\) b" "cddce1" } } */
>

On m68k:

FAIL: gcc.dg/pr69047.c scan-tree-dump cddce1 "_[0-9]+ = \\([^)]+\\) b"

$ cat pr69047.c.037t.cddce1 

;; Function f (f, funcdef_no=0, decl_uid=1432, cgraph_uid=0, symbol_order=0)

f (short unsigned int b)
{
  unsigned char a;
  unsigned char _2;

  :
  _2 = BIT_FIELD_REF ;
  return _2;

}


Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Add fixit hint for -Wlogical-not-parentheses

[Andreas Schwab]

On Aug 25 2016, Marek Polacek  wrote:

>   * c-c++-common/Wlogical-not-parentheses-2.c: New test.

FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11  expected 
multiline pattern lines 13-17 not found: "\s*r \+= !aaa == bbb;.*\n 
\^~\n   r \+= !aaa == bbb;.*\n\^~~~\n\(   \).*\n"
FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11 (test for excess 
errors)
Excess errors:
   r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
 ^~
   r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
^~~~

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] PR fortran/77372

[Andreas Schwab]

On Aug 26 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:

> 2016-08-25  Steven G. Kargl <ka...@gcc.gnu.org>
>
>   PR fortran/77372
>   gfortran.dg/pr77372.f90: New test.

FAIL: gfortran.dg/pr77372.f90   -O  (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20160829/gcc/testsuite/gfortran.dg/pr77372.f90:3:7: Fatal 
Error: Can't open module file 'ieee_arithmetic.mod' for reading at (1): No such 
file or directory
compilation terminated.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH 1/2] DWARF: process all TYPE_DECL nodes when iterating on scopes

[Pierre-Marie de Rodat]

Here is another attempt to solve the original issue. This time, with a 
proper testcase. ;-)


Rebased against trunk, boostrapped and regtested on x86_64-linux.

gcc/

* dwarf2out.c (process_scope_var): Relocate DIEs for TYPE_DECL
nodes that are not stubs.
(gen_decl_die): For TYPE_DECLs that have the same scope as their
type, relocate the type DIE if it was generated without a scope.

gcc/testsuite/

* gnat.dg/debug9.adb: New testcase.

--
Pierre-Marie de Rodat
>From 7b629a631b532d561ed66c0dc973dfbf1f5d Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Tue, 5 Jan 2016 15:32:34 +0100
Subject: [PATCH] DWARF: process all TYPE_DECL nodes when iterating on scopes

In Ada, it is possible to have nested subprograms in the following
configuration:

 procedure Parent is
type T;
[...]
procedure Child (Value : T) is
begin
   [...]
end Child;
 begin
[...]
 end Parent;

If we generate debugging information for Child first before Parent, the
debug info for T will be generated at global scope since the DIE for
Parent does not exist yet.  It is when generating debug info for Parent
that we are supposed to relocate it.  This change enhances the
relocation machinery to handle the above case.

gcc/

	* dwarf2out.c (process_scope_var): Relocate DIEs for TYPE_DECL
	nodes that are not stubs.
	(gen_decl_die): For TYPE_DECLs that have the same scope as their
	type, relocate the type DIE if it was generated without a scope.

gcc/testsuite/

	* gnat.dg/debug9.adb: New testcase.
---
 gcc/dwarf2out.c  | 18 --
 gcc/testsuite/gnat.dg/debug9.adb | 53 
 2 files changed, 69 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/debug9.adb

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 45eb684..2e3ca71 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23248,6 +23248,8 @@ process_scope_var (tree stmt, tree decl, tree origin, dw_die_ref context_die)
   else if (TREE_CODE (decl_or_origin) == TYPE_DECL
&& TYPE_DECL_IS_STUB (decl_or_origin))
 die = lookup_type_die (TREE_TYPE (decl_or_origin));
+  else if (TREE_CODE (decl_or_origin) == TYPE_DECL)
+die = lookup_decl_die (decl_or_origin);
   else
 die = NULL;
 
@@ -23732,8 +23734,20 @@ gen_decl_die (tree decl, tree origin, struct vlr_context *ctx,
   if (is_redundant_typedef (decl))
 	gen_type_die (TREE_TYPE (decl), context_die);
   else
-	/* Output a DIE to represent the typedef itself.  */
-	gen_typedef_die (decl, context_die);
+	{
+	  /* Output a DIE to represent the typedef itself.  */
+	  gen_typedef_die (decl, context_die);
+
+	  /* The above may create a typedef in the proper scope, but the
+	 underlying type itself could have been created earlier, at a point
+	 when the scope was not available yet.  If it's the case, relocate
+	 it.  This is analogous to what is done in process_scope_var,
+	 except we deal with a TYPE and not a DECL, here.  */
+	  dw_die_ref type_die = lookup_type_die (TREE_TYPE (decl));
+	  if (type_die != NULL && type_die->die_parent == NULL
+	  && DECL_CONTEXT (decl) == TYPE_CONTEXT (TREE_TYPE (decl)))
+	add_child_die (context_die, type_die);
+	}
   break;
 
 case LABEL_DECL:
diff --git a/gcc/testsuite/gnat.dg/debug9.adb b/gcc/testsuite/gnat.dg/debug9.adb
new file mode 100644
index 000..dd14210
--- /dev/null
+++ b/gcc/testsuite/gnat.dg/debug9.adb
@@ -0,0 +1,53 @@
+--  The aim of this test is to check that Ada types appear in the proper
+--  context in the debug info.
+-- 
+--  Checking this directly would be really tedious just scanning for assembly
+--  lines, so instead we rely on DWARFv4's .debug_types sections, which must be
+--  created only for global-scope types. Checking the number of .debug_types is
+--  some hackish way to check that types are output in the proper context (i.e.
+--  at global or local scope).
+--
+--  { dg-options "-g -gdwarf-4 -cargs -fdebug-types-section -dA" }
+--  { dg-final { scan-assembler-times "\\(DIE \\(0x\[a-f0-9\]*\\) DW_TAG_type_unit\\)" 0 } }
+
+procedure Debug9 is
+   type Array_Type is array (Natural range <>) of Integer;
+   type Record_Type (L1, L2 : Natural) is record
+  I1 : Integer;
+  A1 : Array_Type (1 .. L1);
+  I2 : Integer;
+  A2 : Array_Type (1 .. L2);
+  I3 : Integer;
+   end record;
+
+   function Get (L1, L2 : Natural) return Record_Type is
+  Result : Record_Type (L1, L2);
+   begin
+  Result.I1 := 1;
+  for I in Result.A1'Range loop
+ Result.A1 (I) := I;
+  end loop;
+  Result.I2 := 2;
+  for I in Result.A2'Range loop
+ Result.A2 (I) := I;
+  end loop;
+  Result.I3 := 3;
+  return Result;
+   end Get;
+
+   R1 : Record_Type := Get (0, 0);
+   R2 : Record_Type := Get (1, 0);
+   R3 : Record_Type := Get (0, 1);
+   R4 : Record_Type := Get (2, 2);
+
+   

Re: [PATCH] selftest.h: mark failure functions with ATTRIBUTE_NORETURN.

[Bernd Schmidt]

On 08/26/2016 08:20 PM, David Malcolm wrote:


Is this revised version OK for trunk?



LGTM.


Bernd

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Janne Blomqvist]

On Mon, Aug 29, 2016 at 11:15 AM, Andre Vehreschild  wrote:
> Hi all,
>
>> Anyway, a small nit I found was the function st_set_nml_var in
>> libgfortran. This is an exported function, and thus part of the ABI.
>> So you cannot add arguments to it, as that would break backwards
>> compatibility.
>
> Please explain the above. I was of the opinion, that when we change
> something significantly the global ABI version gets bumped. Given that
> we are doing gcc-7 currently and there have been some changes, that ABI
> version should have been bumped already with respect to gcc-6.

We strive very(?) hard to retain ABI compatibility for libgfortran, as
having to recompile everything is a huge PITA for our users. As a
result we have been able avoid bumping the SO major version number
since GCC 4.3 IIRC.

There is a long laundry-list of cleanups that could be done once we do
bump the SO major version:
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup

Probably when (if?) the new array descriptor is merged we have to do
said bump, as that one is used everywhere and retaining compatibility
with the old descriptor seems to be a huge undertaking.

> I am asking that stupid question mostly, because during extending
> coarray stuff to support allocatable components in derived typed
> coarrays the API of the caf-library has to be modified and carrying
> along the old signatures just causes useless garbage being carried
> forward. (Opencoarrays is working on supporting the same renovated API.
> Other users of that API are not known to me.) So what is the best way
> to resolve this?

I haven't involved myself in the coarray stuff, but AFAIU the corray
lib hasn't been considered stable, in order that the developers can
more quickly iterate on the design without having to be bogged down by
ABI compatibility considerations.

-- 
Janne Blomqvist

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Andre Vehreschild]

Hi all,

> Anyway, a small nit I found was the function st_set_nml_var in
> libgfortran. This is an exported function, and thus part of the ABI.
> So you cannot add arguments to it, as that would break backwards
> compatibility.

Please explain the above. I was of the opinion, that when we change
something significantly the global ABI version gets bumped. Given that
we are doing gcc-7 currently and there have been some changes, that ABI
version should have been bumped already with respect to gcc-6. IMO the
library can't be linked to old objects that use the original
st_set_nml_var() signature anyway. So when there are no other users of
st_set... then why not replace the function signature by a more
suitable one? Or is this function still in use?

I am asking that stupid question mostly, because during extending
coarray stuff to support allocatable components in derived typed
coarrays the API of the caf-library has to be modified and carrying
along the old signatures just causes useless garbage being carried
forward. (Opencoarrays is working on supporting the same renovated API.
Other users of that API are not known to me.) So what is the best way
to resolve this?

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [PATCH] Fix PR64078

[Tom de Vries]

On 17/09/15 20:08, Marek Polacek wrote:

On Thu, Sep 17, 2015 at 08:06:48PM +0200, Bernd Edlinger wrote:

Hi,

On Thu, 17 Sep 2015 10:39:04, Jeff Law wrote:


On 09/17/2015 09:00 AM, Marek Polacek wrote:

On Wed, Sep 09, 2015 at 07:48:15PM +0200, Bernd Edlinger wrote:

Hi,

On Wed, 9 Sep 2015 09:31:33, Jeff Law wrote:

You could probably make the function static or change its visibility via
a function attribute (there's a visibility attribute which can take the
values default, hidden protected or internal). Default visibility
essentially means the function can be overridden. I think changing it
to "protected" might work. Note if we do that, we may need some kind of
target selector on the test since not all targets support the various
visibility attributes.



Yes, it works both ways: static works, and __attribute__ ((visibility 
("protected"))) works too:

make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c 
--target_board='unix{-fpic,-mcmodel=medium,-fpic\ -mcmodel=medium,-mcmodel=large,-fpic\ 
-mcmodel=large}'"

has all tests passed, but..

make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c
--target_board='unix{-fno-inline}'"

still fails in the same way for all workarounds: inline, static, and __attribute__ 
((visibility ("protected"))).

Maybe "static" would be preferable?


Yeah, I'd go with static if that helps. I'd rather avoid playing games
with visibility.

Static is certainly easier and doesn't rely on targets implementing all
the visibility capabilities. So static is probably the best approach.



That's fine for me too, so is the original patch OK for trunk with 
s/inline/static/ ?


Yes.



Hi,

I've backported this fix to the 5 branch.

Thanks,
- Tom

Re: [PATCH, fortran] PR 77261 gfortran.dg/random_3.f90 failure

[Paul Richard Thomas]

Dear Janne,

That's fine for trunk.

Thanks for the patch.

Paul

On 29 August 2016 at 09:05, Janne Blomqvist  wrote:
> PING?
>
> FWIW, Rainer Orth confirmed that the fixed testcase now passes on 
> Solaris/SPARC.
>
> On Tue, Aug 23, 2016 at 4:40 PM, Janne Blomqvist
>  wrote:
>> Hi,
>>
>> the attached patch fixes PR 77261. The problem is that with the new
>> PRNG, the random sequence for real(16) and lesser kinds is not the
>> same. And then on targets that have real(16) but not real(10) the
>> testcase fails. Fixed by essentially running the tests only when
>> real(10) is available.
>>
>> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>>
>> 2016-08-23  Janne Blomqvist  
>>
>> PR fortran/77261
>> * gfortran.dg/random_3.f90: Run testcase only when real(10) is
>> available.
>>
>>
>> --
>> Janne Blomqvist
>
>
>
> --
> Janne Blomqvist



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

[PING v3] Unreviewed GCC-6 patches

[Jakub Sejdak]

Hi!

I would like to ping a couple of unreviewed patches for GCC-6 branch
(they are already in trunk):

- Backport new Phoenix-RTOS OS name to config.sub
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01441.html

- Backport support for Phoenix-RTOS targets in GCC's config for ARM platform.
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01442.html

- Backport support for Phoenix-RTOS targets in libgcc's config for ARM platform.
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01440.html

Thanks,
Kuba Sejdak

-- 
Jakub Sejdak
Software Engineer
Phoenix Systems (www.phoesys.com)
+48 608 050 163

[patch, libgomp, OpenACC] Additional enter/exit data map handling

[Chung-Lin Tang]

Hi Jakub,
this patch is a port of some changes from gomp-4_0-branch,
including adding additional map type handling in OpenACC enter/exit data
directives, and some pointer set handling changes. Updated
testsuite case are also included.

Tested on trunk to ensure no regressions, is this okay for trunk?

Thanks,
Chung-Lin

2016-08-29  Cesar Philippidis  
Thomas Schwinge  
Chung-Lin Tang  

libgomp/
* oacc-parallel.c (find_pset): Adjust and rename from...
(find_pointer): ...this function.
(GOACC_enter_exit_data): Handle GOMP_MAP_TO and GOMP_MAP_ALLOC,
adjust find_pointer calls into find_pset, adjust pointer map handling,
add acc_is_present guards to calls to gomp_acc_insert_pointer and
gomp_acc_remove_pointer.

* testsuite/libgomp.oacc-c-c++-common/data-2.c: Update test.
* testsuite/libgomp.oacc-c-c++-common/enter-data.c: New test.
* testsuite/libgomp.oacc-fortran/data-2.f90: Update test.
Index: oacc-parallel.c
===
--- oacc-parallel.c	(revision 239814)
+++ oacc-parallel.c	(working copy)
@@ -38,15 +38,23 @@
 #include 
 #include 
 
+/* Returns the number of mappings associated with the pointer or pset. PSET
+   have three mappings, whereas pointer have two.  */
+
 static int
-find_pset (int pos, size_t mapnum, unsigned short *kinds)
+find_pointer (int pos, size_t mapnum, unsigned short *kinds)
 {
   if (pos + 1 >= mapnum)
 return 0;
 
   unsigned char kind = kinds[pos+1] & 0xff;
 
-  return kind == GOMP_MAP_TO_PSET;
+  if (kind == GOMP_MAP_TO_PSET)
+return 3;
+  else if (kind == GOMP_MAP_POINTER)
+return 2;
+
+  return 0;
 }
 
 static void goacc_wait (int async, int num_waits, va_list *ap);
@@ -298,7 +306,9 @@ GOACC_enter_exit_data (int device, size_t mapnum,
 
   if (kind == GOMP_MAP_FORCE_ALLOC
 	  || kind == GOMP_MAP_FORCE_PRESENT
-	  || kind == GOMP_MAP_FORCE_TO)
+	  || kind == GOMP_MAP_FORCE_TO
+	  || kind == GOMP_MAP_TO
+	  || kind == GOMP_MAP_ALLOC)
 	{
 	  data_enter = true;
 	  break;
@@ -312,31 +322,39 @@ GOACC_enter_exit_data (int device, size_t mapnum,
 		  kind);
 }
 
+  /* In c, non-pointers and arrays are represented by a single data clause.
+ Dynamically allocated arrays and subarrays are represented by a data
+ clause followed by an internal GOMP_MAP_POINTER.
+
+ In fortran, scalars and not allocated arrays are represented by a
+ single data clause. Allocated arrays and subarrays have three mappings:
+ 1) the original data clause, 2) a PSET 3) a pointer to the array data.
+  */
+
   if (data_enter)
 {
   for (i = 0; i < mapnum; i++)
 	{
 	  unsigned char kind = kinds[i] & 0xff;
 
-	  /* Scan for PSETs.  */
-	  int psets = find_pset (i, mapnum, kinds);
+	  /* Scan for pointers and PSETs.  */
+	  int pointer = find_pointer (i, mapnum, kinds);
 
-	  if (!psets)
+	  if (!pointer)
 	{
 	  switch (kind)
 		{
-		case GOMP_MAP_POINTER:
-		  gomp_acc_insert_pointer (1, [i], [i],
-	[i]);
+		case GOMP_MAP_ALLOC:
+		  acc_present_or_create (hostaddrs[i], sizes[i]);
 		  break;
 		case GOMP_MAP_FORCE_ALLOC:
 		  acc_create (hostaddrs[i], sizes[i]);
 		  break;
-		case GOMP_MAP_FORCE_PRESENT:
+		case GOMP_MAP_TO:
 		  acc_present_or_copyin (hostaddrs[i], sizes[i]);
 		  break;
 		case GOMP_MAP_FORCE_TO:
-		  acc_present_or_copyin (hostaddrs[i], sizes[i]);
+		  acc_copyin (hostaddrs[i], sizes[i]);
 		  break;
 		default:
 		  gomp_fatal (" GOACC_enter_exit_data UNHANDLED kind 0x%.2x",
@@ -346,12 +364,16 @@ GOACC_enter_exit_data (int device, size_t mapnum,
 	}
 	  else
 	{
-	  gomp_acc_insert_pointer (3, [i], [i], [i]);
+	  if (!acc_is_present (hostaddrs[i], sizes[i]))
+		{
+		  gomp_acc_insert_pointer (pointer, [i],
+	   [i], [i]);
+		}
 	  /* Increment 'i' by two because OpenACC requires fortran
 		 arrays to be contiguous, so each PSET is associated with
 		 one of MAP_FORCE_ALLOC/MAP_FORCE_PRESET/MAP_FORCE_TO, and
 		 one MAP_POINTER.  */
-	  i += 2;
+	  i += pointer - 1;
 	}
 	}
 }
@@ -360,19 +382,15 @@ GOACC_enter_exit_data (int device, size_t mapnum,
   {
 	unsigned char kind = kinds[i] & 0xff;
 
-	int psets = find_pset (i, mapnum, kinds);
+	int pointer = find_pointer (i, mapnum, kinds);
 
-	if (!psets)
+	if (!pointer)
 	  {
 	switch (kind)
 	  {
-	  case GOMP_MAP_POINTER:
-		gomp_acc_remove_pointer (hostaddrs[i], (kinds[i] & 0xff)
-	 == GOMP_MAP_FORCE_FROM,
-	 async, 1);
-		break;
 	  case GOMP_MAP_DELETE:
-		acc_delete (hostaddrs[i], sizes[i]);
+		if (acc_is_present (hostaddrs[i], sizes[i]))
+		  acc_delete (hostaddrs[i], sizes[i]);
 		break;
 	  case GOMP_MAP_FORCE_FROM:
 		acc_copyout (hostaddrs[i], sizes[i]);
@@ -385,10 +403,14 @@ GOACC_enter_exit_data (int device, size_t mapnum,
 	  }
 	else
 	  {
-	

Re: [PATCH, testsuite]: Use -gdwarf-2 for g++.dg/other/anon5.C

[Tom de Vries]

On 01/02/16 23:10, Jeff Law wrote:

On 02/01/2016 03:05 PM, Uros Bizjak wrote:

Hello!

This test case fails for targets, where dwarf-4 is unsupported (e.g.
CentOS 5.11) with

/usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
handles version 2 information.

We can use -gdwarf-2 here, and still get correct linker error message
on Cent OS 5.11 and Fedora 23.

2016-02-01  Uros Bizjak  

 * g++.dg/other/anon5.C (dg-opetions): Use -gdwarf-2 instead of -g.

OK.


Hi,

Backported testcase fix to 5 branch.

Thanks,
- Tom

Re: [PATCH, fortran] PR 77261 gfortran.dg/random_3.f90 failure

[Janne Blomqvist]

PING?

FWIW, Rainer Orth confirmed that the fixed testcase now passes on Solaris/SPARC.

On Tue, Aug 23, 2016 at 4:40 PM, Janne Blomqvist
 wrote:
> Hi,
>
> the attached patch fixes PR 77261. The problem is that with the new
> PRNG, the random sequence for real(16) and lesser kinds is not the
> same. And then on targets that have real(16) but not real(10) the
> testcase fails. Fixed by essentially running the tests only when
> real(10) is available.
>
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
> 2016-08-23  Janne Blomqvist  
>
> PR fortran/77261
> * gfortran.dg/random_3.f90: Run testcase only when real(10) is
> available.
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist