Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Richard Biener]

On Fri, 2 Mar 2018, Jakub Jelinek wrote:

> Hi!
> 
> If we need to use thunks for ICF to functions with warning or error
> attribute, their expansion will warn or error.  This patch just punts
> in those cases instead.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Looks ok but I wonder if marking the call in the thunk with no-warning
would work as well?

Richard.

> 2018-03-02  Jakub Jelinek  
> 
>   PR ipa/84628
>   * ipa-icf.c (sem_function::merge): Don't create wrappers for
>   functions with warning or error attributes.
> 
>   * gcc.dg/pr84628.c: New test.
> 
> --- gcc/ipa-icf.c.jj  2018-01-04 12:37:25.365487352 +0100
> +++ gcc/ipa-icf.c 2018-03-01 11:48:54.023107823 +0100
> @@ -1213,6 +1213,15 @@ sem_function::merge (sem_item *alias_ite
> if (dump_file)
>   fprintf (dump_file, "Wrappers are not created for noinline.\n");
>   }
> +  /* Calls in the thunks would warn or error if we create a wrapper
> +  for functions with warning or error attribute.  */
> +  else if (lookup_attribute ("warning", DECL_ATTRIBUTES (original->decl))
> +|| lookup_attribute ("error", DECL_ATTRIBUTES (original->decl)))
> + {
> +   if (dump_file)
> + fprintf (dump_file, "Wrappers are not created for error/warning "
> + "attribute.\n");
> + }
>else
>  create_wrapper = true;
>  
> --- gcc/testsuite/gcc.dg/pr84628.c.jj 2018-03-01 11:30:39.121021498 +0100
> +++ gcc/testsuite/gcc.dg/pr84628.c2018-03-01 11:28:41.383127588 +0100
> @@ -0,0 +1,8 @@
> +/* PR ipa/84628 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int f0 (void);
> +__attribute__((error ("err"))) void f1 (void) { f0 (); f0 (); }
> +__attribute__((error ("err"))) void f2 (void) { f0 (); f0 (); }
> +/* { dg-bogus "declared with attribute error" "" { target *-*-* } 0 } */
> 
>   Jakub
> 
> 

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

[PR84620] output symbolic entry_view as data2, not addr

[Alexandre Oliva]

Mark Wielaard is implementing support for LVU and IEPM in elfutils, and
he was surprised by the encoding of DW_AT_GNU_entry_view; so was I!
When GCC computes and outputs views internally (broken without internal
view resets), it outputs entry_view attributes as data: it knows the
view numbers.  However, when it uses the assembler to compute the views
symbolically, it has to output the view symbolically.

I'd chosen lbl_id to that end, without giving it much thought, but that
was no good: it's not just space-inefficient, it uses an addr encoding,
indirect in some cases, for something that's not a real label, but
rather a a small assembler data constant.  Oops.

Regstrapped on i686- and x86_64-linux-gnu.  Ok to install?


[IEPM] [PR debug/84620] use constant form for DW_AT_GNU_entry_view

When outputting entry views in symbolic mode, we used to use a lbl_id,
but that outputs the view as an addr, perhaps even in an indirect one,
which is all excessive and undesirable for a small assembler-computed
constant.

Introduce a new value class for symbolic views, so that we can output
the labels as constant data, using small forms that should suffice for
any symbolic views.

Ideally, we'd use uleb128, but then the compiler would have to defer
.debug_info offset computation to the assembler.  I'm not going there
for now, so a symbolic uleb128 assembler constant in an attribute is
not something GCC can deal with ATM.

for  gcc/ChangeLog

PR debug/84620
* dwarf2out.h (dw_val_class): Add dw_val_class_symview.
(dw_val_node): Add val_symbolic_view.
* dwarf2out.c (dw_val_equal_p): Handle symview.
(add_AT_symview): New.
(print_dw_val): Handle symview.
(attr_checksum, attr_checksum_ordered): Likewise.
(same_dw_val_p, size_of_die): Likewise.
(value_format, output_die): Likewise.
(add_high_low_attributes): Use add_AT_symview for entry_view.
---
 gcc/dwarf2out.c |   40 +++-
 gcc/dwarf2out.h |4 +++-
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 41bb11558f69..b52edee845f2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1434,6 +1434,8 @@ dw_val_equal_p (dw_val_node *a, dw_val_node *b)
   return a->v.val_die_ref.die == b->v.val_die_ref.die;
 case dw_val_class_fde_ref:
   return a->v.val_fde_index == b->v.val_fde_index;
+case dw_val_class_symview:
+  return strcmp (a->v.val_symbolic_view, b->v.val_symbolic_view) == 0;
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
@@ -3600,6 +3602,7 @@ static addr_table_entry *add_addr_table_entry (void *, 
enum ate_kind);
 static void remove_addr_table_entry (addr_table_entry *);
 static void add_AT_addr (dw_die_ref, enum dwarf_attribute, rtx, bool);
 static inline rtx AT_addr (dw_attr_node *);
+static void add_AT_symview (dw_die_ref, enum dwarf_attribute, const char *);
 static void add_AT_lbl_id (dw_die_ref, enum dwarf_attribute, const char *);
 static void add_AT_lineptr (dw_die_ref, enum dwarf_attribute, const char *);
 static void add_AT_macptr (dw_die_ref, enum dwarf_attribute, const char *);
@@ -5114,6 +5117,21 @@ add_AT_vms_delta (dw_die_ref die, enum dwarf_attribute 
attr_kind,
   add_dwarf_attr (die, );
 }
 
+/* Add a symbolic view identifier attribute value to a DIE.  */
+
+static inline void
+add_AT_symview (dw_die_ref die, enum dwarf_attribute attr_kind,
+   const char *view_label)
+{
+  dw_attr_node attr;
+
+  attr.dw_attr = attr_kind;
+  attr.dw_attr_val.val_class = dw_val_class_symview;
+  attr.dw_attr_val.val_entry = NULL;
+  attr.dw_attr_val.v.val_symbolic_view = xstrdup (view_label);
+  add_dwarf_attr (die, );
+}
+
 /* Add a label identifier attribute value to a DIE.  */
 
 static inline void
@@ -6457,6 +6475,9 @@ print_dw_val (dw_val_node *val, bool recurse, FILE 
*outfile)
   fprintf (outfile, "delta: @slotcount(%s-%s)",
   val->v.val_vms_delta.lbl2, val->v.val_vms_delta.lbl1);
   break;
+case dw_val_class_symview:
+  fprintf (outfile, "view: %s", val->v.val_symbolic_view);
+  break;
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
@@ -6828,6 +6849,7 @@ attr_checksum (dw_attr_node *at, struct md5_ctx *ctx, int 
*mark)
 
 case dw_val_class_fde_ref:
 case dw_val_class_vms_delta:
+case dw_val_class_symview:
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
@@ -7124,6 +7146,7 @@ attr_checksum_ordered (enum dwarf_tag tag, dw_attr_node 
*at,
   break;
 
 case dw_val_class_fde_ref:
+case dw_val_class_symview:
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
@@ -7624,6 +7647,9 @@ same_dw_val_p (const dw_val_node *v1, const dw_val_node 
*v2, int *mark)
 case dw_val_class_die_ref:
   return same_die_p (v1->v.val_die_ref.die, 

Re: [PR c++/84492] return stmt expr ending with overload

[Alexandre Oliva]

On Feb 28, 2018, Jason Merrill  wrote:

> On Wed, Feb 28, 2018 at 7:06 AM, Alexandre Oliva  wrote:
>> We ICEd when returning a stmt expr that ends with an overloaded
>> function.  It's ill-formed when we can't convert the function name to
>> the return type, but we should say that, not ICE.

> Hmm, what about the case where we could convert the function name to
> the return type?  I think it should still be ill-formed for a
> statement-expression to have an unresolved overload as its value.

I was (not :-) thinking in those terms; I suppose one might wish ({x;})
to be equivalent to (x), but one might also wish for stmt exprs to be
self-contained, and I suppose you prefer the latter, or that there's
consensus about how the stmt expr extension should be handled in this
regard, so...

> So finish_stmt_expr_expr should check type_unknown_p.

[PR c++/84492] stmt expr ending with overload

We ICEd when returning a stmt expr that ends with an overloaded
function, because instantiate_type did not know what to do with
STMT_EXPRs.  And it shouldn't have to: the expected type of a stmt
expr cannot be used to resolve its value: an unresolved overload
cannot supply the result of a stmt expr.  Catch that and report the
error in the stmt expr before we have a chance to instantiate it.

Regstrapped on i686- and x86_64-linux-gnu.  Ok?

for  gcc/cp/ChangeLog

PR c++/84492
* semantics.c (finish_stmt_expr_expr): Reject unresolved
overloads used as stmt expr values.

for  gcc/testsuite/ChangeLog

PR c++/84492
* g++.dg/pr84492.C: New.
---
 gcc/cp/semantics.c |9 -
 gcc/testsuite/g++.dg/pr84492.C |   40 
 2 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/pr84492.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 1ac1d23e7610..af401866b569 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2115,7 +2115,14 @@ finish_stmt_expr_expr (tree expr, tree stmt_expr)
 {
   tree type = TREE_TYPE (expr);
 
-  if (processing_template_decl)
+  if (type && type_unknown_p (type))
+   {
+ error ("a statement expression is an insufficient context"
+" for overload resolution");
+ TREE_TYPE (stmt_expr) = error_mark_node;
+ return error_mark_node;
+   }
+  else if (processing_template_decl)
{
  expr = build_stmt (input_location, EXPR_STMT, expr);
  expr = add_stmt (expr);
diff --git a/gcc/testsuite/g++.dg/pr84492.C b/gcc/testsuite/g++.dg/pr84492.C
new file mode 100644
index ..1a2922096d19
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84492.C
@@ -0,0 +1,40 @@
+// { dg-do compile }
+// { dg-options "-fpermissive" }
+
+template int foo()
+{
+  return ({ foo; }); // { dg-error "insufficient context" }
+}
+
+int bar()
+{
+  return ({ foo; }); // { dg-error "insufficient context" }
+}
+
+void bar(int);
+
+typedef void (*bart)(int);
+
+bart barf()
+{
+  return ({ bar; }); // { dg-error "insufficient context" }
+}
+
+bool bark()
+{
+  return ({ barf; }); // ok, no overload
+}
+
+template 
+class C
+{
+  static int f();
+  bool g()
+  {
+return ({ f; }); // ok, no overload
+  }
+  bool g(int)
+  {
+return ({ g; }); // { dg-error "insufficient context" }
+  }
+};


-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [C++] [PR84231] overload on cond_expr in template

[Alexandre Oliva]

On Feb 28, 2018, Jason Merrill  wrote:

> On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva  wrote:
>> +  if (processing_template_decl)
>> +result_type = cp_build_reference_type (result_type, !is_lvalue);

> If !is_lvalue, we don't want a reference type at all, as the result is
> a prvalue.  is_lvalue should probably rename to is_glvalue.

I ended up moving the above to the path in which we deal with lvalues
and xvalues.  I still renamed the variable as suggested, though I no
longer use it.

> The second argument to cp_build_reference_type should be xvalue_p (arg2).

I thought of adding a comment as to why testing just arg2 was correct,
but then moving the code kind of made it obvious, didn't it?

>> +  /* Except for type-dependent exprs, a REFERENCE_TYPE will
>> +indicate whether its result is an lvalue or so.

> "or not" ?

I meant "or so" as in "or other kinds of reference values".

>> +  if (processing_template_decl
>> + && !type_dependent_expression_p (CONST_CAST_TREE (ref)))
>> +   return clk_none;

> I think we want to return clk_class for a COND_EXPR of class type.

or array, like the default case, I suppose.

> Can we actually get here for a type-dependent expression?  I'd think
> we'd never get as far as asking whether a type-dependent expression is
> an lvalue, since in general we can't answer that question.

We shouldn't, indeed.  And AFAICT we don't; I've added an assert to make
sure.

[C++] [PR84231] overload on cond_expr in template

A non-type-dependent COND_EXPR within a template is reconstructed with
the original operands, after one with non-dependent proxies is built to
determine its result type.  This is problematic because the operands of
a COND_EXPR determined to be an rvalue may have been converted to denote
their rvalue nature.  The reconstructed one, however, won't have such
conversions, so lvalue_kind may not recognize it as an rvalue, which may
lead to e.g. incorrect overload resolution decisions.

If we mistake such a COND_EXPR for an lvalue, overload resolution might
regard a conversion sequence that binds it to a non-const reference as
viable, and then select that over one that binds it to a const
reference.  Only after template substitution would we rebuild the
COND_EXPR, realize it is an rvalue, and conclude the reference binding
is ill-formed, but at that point we'd have long discarded any alternate
candidates we could have used.

This patch modifies the logic that determines whether a
(non-type-dependent) COND_EXPR in a template is an lvalue, to rely on
its type, more specifically, on the presence of a REFERENCE_TYPE
wrapper.  In order to avoid a type bootstrapping problem, the
REFERENCE_TYPE that wraps the type of some such COND_EXPRs is
introduced earlier, so that we don't have to test for lvalueness of
the expression using the very code that we wish to change.


for  gcc/cp/ChangeLog

PR c++/84231
* tree.c (lvalue_kind): Use presence/absence of REFERENCE_TYPE
only while processing template decls.
* typeck.c (build_x_conditional_expr): Move wrapping of
reference type around type...
* call.c (build_conditional_expr_1): ... here.  Rename
is_lvalue to is_glvalue.
* parser.c (cp_parser_fold_expression): Catch REFERENCE_REF_P
INDIRECT_REF of COND_EXPR too.

for  gcc/testsuite/ChangeLog

PR c++/84231
* g++.dg/pr84231.C: New.
---
 gcc/cp/call.c  |   11 +++
 gcc/cp/parser.c|4 +++-
 gcc/cp/tree.c  |   15 +++
 gcc/cp/typeck.c|4 
 gcc/testsuite/g++.dg/pr84231.C |   29 +
 5 files changed, 54 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr84231.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 11fe28292fb1..6707aa2d3f02 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4782,7 +4782,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree 
arg2, tree arg3,
   tree arg3_type;
   tree result = NULL_TREE;
   tree result_type = NULL_TREE;
-  bool is_lvalue = true;
+  bool is_glvalue = true;
   struct z_candidate *candidates = 0;
   struct z_candidate *cand;
   void *p;
@@ -5037,7 +5037,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree 
arg2, tree arg3,
  return error_mark_node;
}
 
-  is_lvalue = false;
+  is_glvalue = false;
   goto valid_operands;
 }
   /* [expr.cond]
@@ -5155,6 +5155,9 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree 
arg2, tree arg3,
   && same_type_p (arg2_type, arg3_type))
 {
   result_type = arg2_type;
+  if (processing_template_decl)
+   result_type = cp_build_reference_type (result_type, xvalue_p (arg2));
+
   arg2 = mark_lvalue_use (arg2);
   arg3 = mark_lvalue_use (arg3);
   goto valid_operands;
@@ -5167,7 +5170,7 @@ build_conditional_expr_1 (location_t loc, tree 

Re: [PR c++/84593] ice on braced init with uninit ref field

[Alexandre Oliva]

On Feb 28, 2018, Jason Merrill  wrote:

> On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva  wrote:
>> Don't allow the initializer expr to be NULL in a ctor initializer
>> list, make it error_marker_node instead.

> I don't want error_mark_nodes in a CONSTRUCTOR, either.  When there
> isn't an NSDMI to worry about, we zero-initialize the reference, and
> it seems reasonable to continue doing that, by fixing
> build_zero_init_1 to return something non-null for a reference.

Like this?  Regstrapped on i686- and x86_64-linux-gnu.

[PR c++/84593] ice on braced init with uninit ref field

If an initializer expr is to be NULL in a ctor initializer list, we
ICE in picflag_from_initializer and elsewhere.

If we're missing an initializer for a reference field, we report the
error, but then build a zero initializer to avoid the ICE.

for  gcc/cp/ChangeLog

PR c++/84593
* init.c (build_zero_init_1): Zero-initialize references.

for  gcc/testsuite/ChangeLog

PR c++/84593
* g++.dg/cpp1y/pr84593.C: New.
---
 gcc/cp/init.c|5 -
 gcc/testsuite/g++.dg/cpp1y/pr84593.C |8 
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr84593.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index d0d14abdc9fa..ed28e9a46dbc 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -284,7 +284,10 @@ build_zero_init_1 (tree type, tree nelts, bool 
static_storage_p,
   else if (VECTOR_TYPE_P (type))
 init = build_zero_cst (type);
   else
-gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
+{
+  gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
+  init = fold (convert (type, integer_zero_node));
+}
 
   /* In all cases, the initializer is a constant.  */
   if (init)
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr84593.C 
b/gcc/testsuite/g++.dg/cpp1y/pr84593.C
new file mode 100644
index ..8aa869f19193
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr84593.C
@@ -0,0 +1,8 @@
+// PR c++/84593
+// { dg-do compile { target c++14 } }
+
+struct a {
+  int x;
+  int c = 0;
+  int 
+} c = {}; // { dg-error "uninitialized reference" }


-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH] Fix ICE on invalid inline asm with "X" constraint and non-zero CONST_VECTOR (PR inline-asm/84625)

[Uros Bizjak]

On Fri, Mar 2, 2018 at 8:47 AM, Jakub Jelinek  wrote:
> On Fri, Mar 02, 2018 at 08:19:40AM +0100, Uros Bizjak wrote:
>> On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak  wrote:
>> > On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek  wrote:
>> >> Hi!
>> >>
>> >> Assertions are only useful when inline asm is not involved, otherwise 
>> >> users
>> >> can write anything they want.
>>
>> IIRC, we can also handle { -1, -1, ... , -1 } in certain cases, but I
>> don't think it is worth to complicate here.
>
> We can handle that as whole instruction special-casing all ones
> CONST_VECTOR, sure, but as an operand in inline-asm?
>
> Even the { 0, 0, ... , 0 } case is weird, we print it just as 0, dunno
> where exactly it would make sense, but we were doing that in the past
> already.

Probably QImode/HImode vector zero can be represented as DImode
immediate in an integer move insn. Anyway, let's proceed with your
original patch.

Uros.

[PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Jakub Jelinek]

Hi!

If we need to use thunks for ICF to functions with warning or error
attribute, their expansion will warn or error.  This patch just punts
in those cases instead.

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

2018-03-02  Jakub Jelinek  

PR ipa/84628
* ipa-icf.c (sem_function::merge): Don't create wrappers for
functions with warning or error attributes.

* gcc.dg/pr84628.c: New test.

--- gcc/ipa-icf.c.jj2018-01-04 12:37:25.365487352 +0100
+++ gcc/ipa-icf.c   2018-03-01 11:48:54.023107823 +0100
@@ -1213,6 +1213,15 @@ sem_function::merge (sem_item *alias_ite
  if (dump_file)
fprintf (dump_file, "Wrappers are not created for noinline.\n");
}
+  /* Calls in the thunks would warn or error if we create a wrapper
+for functions with warning or error attribute.  */
+  else if (lookup_attribute ("warning", DECL_ATTRIBUTES (original->decl))
+  || lookup_attribute ("error", DECL_ATTRIBUTES (original->decl)))
+   {
+ if (dump_file)
+   fprintf (dump_file, "Wrappers are not created for error/warning "
+   "attribute.\n");
+   }
   else
 create_wrapper = true;
 
--- gcc/testsuite/gcc.dg/pr84628.c.jj   2018-03-01 11:30:39.121021498 +0100
+++ gcc/testsuite/gcc.dg/pr84628.c  2018-03-01 11:28:41.383127588 +0100
@@ -0,0 +1,8 @@
+/* PR ipa/84628 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int f0 (void);
+__attribute__((error ("err"))) void f1 (void) { f0 (); f0 (); }
+__attribute__((error ("err"))) void f2 (void) { f0 (); f0 (); }
+/* { dg-bogus "declared with attribute error" "" { target *-*-* } 0 } */

Jakub

Re: [PATCH] Fix ICE on invalid inline asm with "X" constraint and non-zero CONST_VECTOR (PR inline-asm/84625)

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 08:19:40AM +0100, Uros Bizjak wrote:
> On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak  wrote:
> > On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek  wrote:
> >> Hi!
> >>
> >> Assertions are only useful when inline asm is not involved, otherwise users
> >> can write anything they want.
> 
> IIRC, we can also handle { -1, -1, ... , -1 } in certain cases, but I
> don't think it is worth to complicate here.

We can handle that as whole instruction special-casing all ones
CONST_VECTOR, sure, but as an operand in inline-asm?

Even the { 0, 0, ... , 0 } case is weird, we print it just as 0, dunno
where exactly it would make sense, but we were doing that in the past
already.

Jakub

Re: [PATCH] Fix ICE on invalid inline asm with "X" constraint and non-zero CONST_VECTOR (PR inline-asm/84625)

[Uros Bizjak]

On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak  wrote:
> On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek  wrote:
>> Hi!
>>
>> Assertions are only useful when inline asm is not involved, otherwise users
>> can write anything they want.

IIRC, we can also handle { -1, -1, ... , -1 } in certain cases, but I
don't think it is worth to complicate here.

Uros.

Re: [PATCH] Fix ICE on invalid inline asm with "X" constraint and non-zero CONST_VECTOR (PR inline-asm/84625)

[Uros Bizjak]

On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek  wrote:
> Hi!
>
> Assertions are only useful when inline asm is not involved, otherwise users
> can write anything they want.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-03-02  Jakub Jelinek  
>
> PR inline-asm/84625
> * config/i386/i386.c (ix86_print_operand): Use conditional
> output_operand_lossage instead of gcc_assert if CONST_VECTOR is not
> zero vector.
>
> * gcc.target/i386/pr84625.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2018-02-26 20:49:57.345331383 +0100
> +++ gcc/config/i386/i386.c  2018-03-01 12:01:17.820587068 +0100
> @@ -18743,7 +18743,8 @@ ix86_print_operand (FILE *file, rtx x, i
>  since we can in fact encode that into an immediate.  */
>if (GET_CODE (x) == CONST_VECTOR)
> {
> - gcc_assert (x == CONST0_RTX (GET_MODE (x)));
> + if (x != CONST0_RTX (GET_MODE (x)))
> +   output_operand_lossage ("invalid vector immediate");
>   x = const0_rtx;
> }
>
> --- gcc/testsuite/gcc.target/i386/pr84625.c.jj  2018-03-01 12:00:06.254636914 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr84625.c 2018-03-01 12:14:54.044024998 
> +0100
> @@ -0,0 +1,12 @@
> +/* PR inline-asm/84625 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -msse2" } */
> +
> +typedef int V __attribute__((vector_size (16)));
> +
> +void
> +foo (void)
> +{
> +  asm volatile ("# %0" : : "X" ((V) { 1, 2, 3, 4 }));  // { dg-error 
> "invalid vector immediate" }
> +  asm volatile ("# %0" : : "" ((V) { 2, 3, 4, 5 }));   // { dg-error 
> "invalid vector immediate" }
> +}
>
> Jakub

Re: [PATCH][darwin] Work around missing LTO debug support for Mach-O, PR82005

[Mike Stump]

On Mar 1, 2018, at 1:56 AM, Dominique d'Humières  wrote:
> 
>> Le 1 mars 2018 à 09:37, Richard Biener  a écrit :
>> 
>> In the PR Dominique says "With the patch the failures (-m32/-m64) went 
>> down from 1059 to 467" which is a nice improvement.  I'm not set up
>> to bootstrap on darwin but I expect Dominque did so.
> 
> Indeed!
> 
>> 
>> So - ok for trunk?
> 
> From my pov yes.

Yes.

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Peter Bergner]

On 3/1/18 7:45 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 09:59:27PM -0600, Peter Bergner wrote:
>>  PR target/84534
>>  * gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
>> on powerpc64le*-*-linux*.
> 
> (wrong indent: should be a tab and no extra spaces).

Heh, that's just an artifact of me being lazy and cut/pasting the ChangeLog
entry into my mailer. :-)



> Okay for trunk, thanks!

Thanks, committed.

Peter

Re: [PR c++/84596] implicit conv in static assert

[Alexandre Oliva]

On Mar  1, 2018, Marek Polacek  wrote:

> Here's my take on this; Alex, sorry for interfering.

No worries, thanks a lot for taking care of this!

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH, rs6000] Fix PR84534: several powerpc test cases fail starting with r257915

[Segher Boessenkool]

On Wed, Feb 28, 2018 at 09:59:27PM -0600, Peter Bergner wrote:
> >> So should we go with my original idea above?  Or maybe we don't care
> >> that we XFAIL on some targets since we're just going to remove the
> >> test next release with the removal -maltivec=be?
> > 
> > It would be nice to have clean test results, which is all this patch is
> > about anyway, right?
> 
> Ok, this XFAILs the test case and shouldn't create any extra noise when
> it shouldn't.  I also added the comment about no longer counting xxlor
> insns.  Better?
> 
> Peter
> 
>   PR target/84534
>   * gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
> on powerpc64le*-*-linux*.

(wrong indent: should be a tab and no extra spaces).

Okay for trunk, thanks!


Segher

Re: [PATCH] i18n fixes in gimple-ssa-sprintf.c

[Martin Sebor]

On 03/01/2018 04:25 PM, Jakub Jelinek wrote:

Hi!

This patch fixes a couple of i18n bugs in gimple-ssa-sprintf.c.

One issue was incorrect format attribute for format_warning_at_substring,
which has ... and thus shouldn't use 0 for the last argument, but the first
non-named argument position.

Another one is that a couple of fmtwarn calls need plural form handling,
so I've introduced new substring-locations.[ch] entrypoints for that;
in order to be able to successfully extract the plural form translatable
strings from those, it can't use the const function pointer hack to shorten
the function name, nor can use the conditionals to pick the format strings.

Another thing is that the file had
#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
which has hidden a couple of issues, missing ATTRIBUTE_GCC_DIAG on the
const fn pointer and lots of missing casts to int for size_t arguments
passed as length to %.*s.

Also, if we use the const fn pointer hack to shorten the function name,
exgettext doesn't really work on it,  so I had to add G_(...) around a couple
of non-conditional format strings, the conditional ones already had it.
Though for those I got rid of the fmtstr temporaries which just caused
gcc not to see the format strings and be able to diagnose issues; plus is
bad for -Wformat-security too.


I've often wished -Wformat were smarter and be able to get at
the format strings in expressions like this.  With only a little
bit of help from the programmer it should be possible.  Just
declaring the pointer const should be enough for it to get them
from its initializer.  This would benefit not just -Wformat but
also functions like strlen that could be folded early on, well
before the strlen pass.  I'll look into it in stage 1.



Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
tree-ssa.exp=builtin-sprintf*'
with unpatched and patched compiler and diffed gcc/testsuite/gcc/gcc.log in
between the two to make sure no diagnostics differences.  And also run make
gcc.pot and verified all the strings I expected to be translatable to be
there, in the desired form (plural-form vs. normal).  Ok for trunk?


Thanks for working on this.  I would only request to do something
about the exceedingly long names of the new functions.  They make
some of the new warning messages even harder to read than before
by breaking up the strings across even more lines.  IIRC, that's
what I was trying to avoid with the pointer hack.  How about
adding a fmtwarn_n pointer like fmtwarn?  (There's little point
in having one without the other.)


--- gcc/gimple-ssa-sprintf.c.jj 2018-02-27 23:16:19.747948912 +0100
+++ gcc/gimple-ssa-sprintf.c2018-03-01 21:26:37.728861287 +0100
@@ -592,14 +592,12 @@ get_format_string (tree format, location
 /* The format_warning_at_substring function is not used here in a way
that makes using attribute format viable.  Suppress the warning.  */

-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
-


The comment above the #pragmas should be removed too.


 /* For convenience and brevity.  */

 static bool
   (* const fmtwarn) (const substring_loc &, location_t,
 const char *, int, const char *, ...)
+  ATTRIBUTE_GCC_DIAG (5, 6)
   = format_warning_at_substring;


So add

  static bool
(* const fmtwarn_n) (const substring_loc &, location_t,
 const char *, int, unsigned HOST_WIDE_INT,
 const char *, const char*, ...)
ATTRIBUTE_GCC_DIAG (5, 6)
= format_warning_at_substring_n;

and use the pointer instead?

Martin

Re: C++ PATCH to tweak cp_fully_fold (PR c++/84590)

[Jason Merrill]

Ok.

On Mar 1, 2018 4:38 PM, "Marek Polacek"  wrote:

> On Thu, Mar 01, 2018 at 02:29:47PM -0500, Jason Merrill wrote:
> > I think this should happen in the block with maybe_constant_value;
> > cp_fold_rvalue doesn't do this.
>
> This, then:
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-01  Marek Polacek  
>
> PR c++/84590
> * cp-gimplify.c (cp_fully_fold): Unwrap TARGET_EXPR or a
> CONSTRUCTOR
> wrapped in VIEW_CONVERT_EXPR.
>
> * c-c++-common/ubsan/shift-11.c: New test.
>
> diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> index 55a9d278dbe..0ddd435454c 100644
> --- gcc/cp/cp-gimplify.c
> +++ gcc/cp/cp-gimplify.c
> @@ -2037,7 +2037,17 @@ cp_fully_fold (tree x)
>/* FIXME cp_fold ought to be a superset of maybe_constant_value so we
> don't
>   have to call both.  */
>if (cxx_dialect >= cxx11)
> -x = maybe_constant_value (x);
> +{
> +  x = maybe_constant_value (x);
> +  /* Sometimes we are given a CONSTRUCTOR but the call above wraps it
> into
> +a TARGET_EXPR; undo that here.  */
> +  if (TREE_CODE (x) == TARGET_EXPR)
> +   x = TARGET_EXPR_INITIAL (x);
> +  else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
> +  && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
> +  && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
> +   x = TREE_OPERAND (x, 0);
> +}
>return cp_fold_rvalue (x);
>  }
>
> diff --git gcc/testsuite/c-c++-common/ubsan/shift-11.c
> gcc/testsuite/c-c++-common/ubsan/shift-11.c
> index e69de29bb2d..03a72e217a2 100644
> --- gcc/testsuite/c-c++-common/ubsan/shift-11.c
> +++ gcc/testsuite/c-c++-common/ubsan/shift-11.c
> @@ -0,0 +1,13 @@
> +/* PR c++/84590 */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=shift" } */
> +
> +struct S {
> +  int b;
> +};
> +
> +void
> +fn (void)
> +{
> +  struct S c1 = { 1 << -1 }; /* { dg-warning "left shift" } */
> +}
>
> Marek
>

Re: [PATCH] merge attributes from function template redeclarations (PR 84294)

[Martin Sebor]

On 03/01/2018 12:28 PM, Jason Merrill wrote:

On Wed, Feb 28, 2018 at 5:47 PM, Martin Sebor  wrote:

Attached is a patch for the failure to merge a subset of attributes
specified on redeclarations of a function template with those of
the first declaration (const, malloc, pure, noinline, noreturn,
and nothrow).  This was uncovered this morning while debugging
failures in tests I added just yesterday and although it's not
a regression I figured since I introduced the test failures and
the fix appears easy it might as well be taken care of now.

The test I added for this exposed a subtle bug in -Wreturn-type
where the warning triggers on a function template instantiated
on a noreturn function even though the middle end successfully
eliminates statements after the noreturn call.  This is not
a regression either so to avoid mission creep I just xfailed
the test and opened bug 84621 to remind us to fix it in
the future.


OK.  Incidentally, looking over duplicate_decls again, I noticed:

  /* [temp.expl.spec/14] We don't inline explicit
specialization
 just because the primary template says so.  */

  if (merge_attr)
{
  /* But still keep DECL_DISREGARD_INLINE_LIMITS in sync
with
 the always_inline attribute.  */
  if (DECL_DISREGARD_INLINE_LIMITS (olddecl)
  && !DECL_DISREGARD_INLINE_LIMITS (newdecl))
{
  if (DECL_DECLARED_INLINE_P (newdecl))
DECL_DISREGARD_INLINE_LIMITS (newdecl) = true;
  else
DECL_ATTRIBUTES (newdecl)
  = remove_attribute ("always_inline",
  DECL_ATTRIBUTES (newdecl));
}
}
  else
{
  DECL_DECLARED_INLINE_P (olddecl)
= DECL_DECLARED_INLINE_P (newdecl);

  DECL_DISREGARD_INLINE_LIMITS (olddecl)
= DECL_DISREGARD_INLINE_LIMITS (newdecl);

  DECL_UNINLINABLE (olddecl) = DECL_UNINLINABLE (newdecl);
}

The upper block here seems like dead code; here we're dealing with an
explicit specialization, so merge_attr should always be false.  Let's
drop the if block.



Done in r258121.  I also added an assert there just to be sure.

Martin

[PATCH] i18n fixes in gimple-ssa-sprintf.c

[Jakub Jelinek]

Hi!

This patch fixes a couple of i18n bugs in gimple-ssa-sprintf.c.

One issue was incorrect format attribute for format_warning_at_substring,
which has ... and thus shouldn't use 0 for the last argument, but the first
non-named argument position.

Another one is that a couple of fmtwarn calls need plural form handling,
so I've introduced new substring-locations.[ch] entrypoints for that;
in order to be able to successfully extract the plural form translatable
strings from those, it can't use the const function pointer hack to shorten
the function name, nor can use the conditionals to pick the format strings.

Another thing is that the file had
#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
which has hidden a couple of issues, missing ATTRIBUTE_GCC_DIAG on the
const fn pointer and lots of missing casts to int for size_t arguments
passed as length to %.*s.

Also, if we use the const fn pointer hack to shorten the function name,
exgettext doesn't really work on it, so I had to add G_(...) around a couple
of non-conditional format strings, the conditional ones already had it.
Though for those I got rid of the fmtstr temporaries which just caused
gcc not to see the format strings and be able to diagnose issues; plus is
bad for -Wformat-security too.

Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested
with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
tree-ssa.exp=builtin-sprintf*'
with unpatched and patched compiler and diffed gcc/testsuite/gcc/gcc.log in
between the two to make sure no diagnostics differences.  And also run make
gcc.pot and verified all the strings I expected to be translatable to be
there, in the desired form (plural-form vs. normal).  Ok for trunk?

2018-03-02  Jakub Jelinek  

* substring-locations.h (format_warning_va): Formatting fix for
ATTRIBUTE_GCC_DIAG.
(format_warning_at_substring): Fix up ATTRIBUTE_GCC_DIAG second
argument.
(format_warning_n_va, format_warning_at_substring_n): New prototypes.
* substring-locations.c: Include intl.h.
(format_warning_va): Turned into small wrapper around
format_warning_n_va, renamed to ...
(format_warning_n_va): ... this, add N and PLURAL_GMSGID arguments,
rename GMSGID to SINGULAR_GMSGID, if SINGULAR_GMSGID != PLURAL_GMSGID,
use ngettext.
(format_warning_at_substring_n): New function.
* gimple-ssa-sprintf.c: Remove GCC diagnostic ignored pragma.
(fmtwarn): Add ATTRIBUTE_GCC_DIAG.
(maybe_warn, format_directive, parse_directive): Use
format_warning_at_substring_n where appropriate, get rid of all the
fmtstr temporaries, move conditionals with G_() wrapped string literals
directly into fmtwarn arguments, cast dir.len to (int), wrap
direct string literal arguments of fmtwarn with G_(), formatting fixes.

--- gcc/substring-locations.h.jj2018-01-03 10:19:53.824533733 +0100
+++ gcc/substring-locations.h   2018-03-01 20:58:57.500660725 +0100
@@ -80,13 +80,29 @@ extern bool format_warning_va (const sub
   location_t param_loc,
   const char *corrected_substring,
   int opt, const char *gmsgid, va_list *ap)
-  ATTRIBUTE_GCC_DIAG (5,0);
+  ATTRIBUTE_GCC_DIAG (5, 0);
+
+extern bool format_warning_n_va (const substring_loc _loc,
+location_t param_loc,
+const char *corrected_substring,
+int opt, unsigned HOST_WIDE_INT n,
+const char *singular_gmsgid,
+const char *plural_gmsgid, va_list *ap)
+  ATTRIBUTE_GCC_DIAG (6, 0) ATTRIBUTE_GCC_DIAG (7, 0);
 
 extern bool format_warning_at_substring (const substring_loc _loc,
 location_t param_loc,
 const char *corrected_substring,
 int opt, const char *gmsgid, ...)
-  ATTRIBUTE_GCC_DIAG (5,0);
+  ATTRIBUTE_GCC_DIAG (5, 6);
+
+extern bool format_warning_at_substring_n (const substring_loc _loc,
+  location_t param_loc,
+  const char *corrected_substring,
+  int opt, unsigned HOST_WIDE_INT n,
+  const char *singular_gmsgid,
+  const char *plural_gmsgid, ...)
+  ATTRIBUTE_GCC_DIAG (6, 8) ATTRIBUTE_GCC_DIAG (7, 8);
 
 /* Implementation detail, for use when implementing
LANG_HOOKS_GET_SUBSTRING_LOCATION.  */
--- gcc/substring-locations.c.jj2018-01-03 10:19:55.240533971 +0100
+++ gcc/substring-locations.c   2018-03-01 19:46:46.887222408 +0100
@@ -20,14 +20,17 @@ along with GCC; see the file COPYING3.
 #include "config.h"
 #include 

Re: [PATCH] Fix combiner move_deaths DEBUG_INSN handling (PR target/84614)

[Segher Boessenkool]

Hi Jakub,

On Fri, Mar 02, 2018 at 12:13:51AM +0100, Jakub Jelinek wrote:
> prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
> testcase we get both -fcompare-debug failure and wrong-code with -g.
> 
> Instead of adding yet another two:
>   do
> insn = prev_real_insn (insn);
>   while (DEBUG_INSN_P (insn));
> loops, this patch introduces new functions that stop only at
> NONDEBUG_INSN_P.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
> cross to aarch64-linux on the testcase, ok for trunk?

Looks good to me, thanks!  (The non-combine parts are arguably obvious
and trivial cleanup).


Segher


> 2018-03-02  Jakub Jelinek  
> 
>   PR target/84614
>   * rtl.h (prev_real_nondebug_insn, next_real_nondebug_insn): New
>   prototypes.
>   * emit-rtl.c (next_real_insn, prev_real_insn): Fix up function
>   comments.
>   (next_real_nondebug_insn, prev_real_nondebug_insn): New functions.
>   * cfgcleanup.c (try_head_merge_bb): Use prev_real_nondebug_insn
>   instead of a loop around prev_real_insn.
>   * combine.c (move_deaths): Use prev_real_nondebug_insn instead of
>   prev_real_insn.
> 
>   * gcc.dg/pr84614.c: New test.

[PATCH] deprecate -finline-limit and make it an optimization option (PR 84603)

[Martin Sebor]

While testing my recent changes to the handling of attributes
on C++ templates I noticed that the -finline-limit=N option
is not recognized in attribute or pragma optimize.  In response
to the bug I raised, Richard you said the option is deprecated,
so I went ahead and documented the deprecation in the manual
and also added a deprecation warning.  I also added it to
Optimization options.  The attached patch reflects these
changes.

I also tried to put together a test to verify that the option
works as expected, both in attributes and in pragmas.  I wasn't
able to get it to work reliably or sensibly.

In C, #pragma optimize ("inline-limit=1") has a global effect
on all functions in the file, even those lexically before the
pragma.  In C++, the pragma has no effect.  Both of these
effects are contrary to my reading of the manual.

Attribute optimize ("inline-limit") behaves similarly, which
seems even more unexpected and even more contrary to the manual
which by referring to Function Specific Option Pragmas suggests
that both the pragma and especially the attribute apply
optimizations to just the functions they're specified for.

I don't expect this to be news to anyone here or easily fixable,
but I think the effects or limitations of the mechanism should
be made clear in the manual.  Ditto for #pragma GDD diagnostic
and its effect on middle-end warnings (or lack thereof).  With
the increasing number of such warnings that's increasingly
becoming a source of frustration for users.  If you agree I'll
put together a documentation patch to try to clarify this.

Martin
PR middle-end/84603 -  -finline-limit not accepted in attribute and #pragma optimize

gcc/testsuite/ChangeLog:

	PR middle-end/84603
	* gcc.dg/inline-40.c: New test.

gcc/ChangeLog:

	PR middle-end/84603
	* common.opt (-finline-limit): Add to Optimization options.  Add
	deprecation warning.
	* doc/invoke.texi: Document deprecation.

Index: gcc/common.opt
===
--- gcc/common.opt	(revision 258114)
+++ gcc/common.opt	(working copy)
@@ -1621,7 +1621,7 @@ finline-limit-
 Common RejectNegative Joined Alias(finline-limit=)
 
 finline-limit=
-Common RejectNegative Joined UInteger
+Common RejectNegative Joined UInteger Optimization Warn(%<-finline-limit%> is deprecated; use %<--param%> instead)
 -finline-limit=	Limit the size of inlined functions to .
 
 finline-atomics
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 258114)
+++ gcc/doc/invoke.texi	(working copy)
@@ -7854,6 +7854,8 @@ in default behavior.
 abstract measurement of function's size.  In no way does it represent a count
 of assembly instructions and as such its exact meaning might change from one
 release to an another.
+@code{-finline-limit} is deprecated in favor of
+the corresponding @option{--param @var{name}=@var{value}} options.
 
 @item -fno-keep-inline-dllexport
 @opindex fno-keep-inline-dllexport
Index: gcc/testsuite/gcc.dg/inline-40.c
===
--- gcc/testsuite/gcc.dg/inline-40.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/inline-40.c	(working copy)
@@ -0,0 +1,19 @@
+/* PR middle-end/84603 - -finline-limit not accepted in attribute
+   and #pragma optimize
+   { dg-do compile }
+   { dg-options "-Wall" }  */
+
+/* Verify that the options are accepted in both pragmas and attributes.  */
+#pragma GCC optimize ("inline-functions")
+void f0 (void);
+
+#pragma GCC optimize ("inline-limit=32")  /* { dg-bogus "bad option .-finline-limit=32." } */
+void f1 (void);
+
+void __attribute__ ((optimize ("inline-functions")))
+f2 (void);
+
+void __attribute__ ((optimize ("inline-limit=100")))   /* { dg-bogus "bad option .-finline-limit=100." } */
+f3 (void);
+
+

[committed] Fix gcc.dg/ubsan/bounds-3.c testcase (PR sanitizer/70875)

[Jakub Jelinek]

Hi!

Eric has reported this testcase fails on sparc64 at -O0.

The reason is that after reporting the upcoming UB it actually performs the
UB, out of bounds write and still expects the test to finish properly, which
sometimes just isn't the case.

Fixed by making the ubsan runtime failure fatal and expecting testsuite
failure instead.  Regtested on x86_64-linux and i686-linux, committed to
trunk as obvious.

2018-03-02  Jakub Jelinek  

PR sanitizer/70875
* gcc.dg/ubsan/bounds-3.c: Add -fno-sanitize-recover=bounds to
dg-options and dg-shouldfail "ubsan" directive.

--- gcc/testsuite/gcc.dg/ubsan/bounds-3.c.jj2016-05-06 15:09:06.361758948 
+0200
+++ gcc/testsuite/gcc.dg/ubsan/bounds-3.c   2018-03-01 17:44:13.722455985 
+0100
@@ -1,6 +1,7 @@
 /* PR sanitizer/70875 */
 /* { dg-do run } */
-/* { dg-options "-fsanitize=bounds" } */
+/* { dg-options "-fsanitize=bounds -fno-sanitize-recover=bounds" } */
+/* { dg-shouldfail "ubsan" } */
 
 int
 foo (int n, int k)

Jakub

[PATCH] Fix combiner move_deaths DEBUG_INSN handling (PR target/84614)

[Jakub Jelinek]

Hi!

prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
testcase we get both -fcompare-debug failure and wrong-code with -g.

Instead of adding yet another two:
  do
insn = prev_real_insn (insn);
  while (DEBUG_INSN_P (insn));
loops, this patch introduces new functions that stop only at
NONDEBUG_INSN_P.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
cross to aarch64-linux on the testcase, ok for trunk?

2018-03-02  Jakub Jelinek  

PR target/84614
* rtl.h (prev_real_nondebug_insn, next_real_nondebug_insn): New
prototypes.
* emit-rtl.c (next_real_insn, prev_real_insn): Fix up function
comments.
(next_real_nondebug_insn, prev_real_nondebug_insn): New functions.
* cfgcleanup.c (try_head_merge_bb): Use prev_real_nondebug_insn
instead of a loop around prev_real_insn.
* combine.c (move_deaths): Use prev_real_nondebug_insn instead of
prev_real_insn.

* gcc.dg/pr84614.c: New test.

--- gcc/rtl.h.jj2018-02-09 06:44:38.366804455 +0100
+++ gcc/rtl.h   2018-03-01 13:38:05.445681834 +0100
@@ -3277,6 +3277,8 @@ extern rtx_insn *next_nonnote_nondebug_i
 extern rtx_insn *next_nonnote_nondebug_insn_bb (rtx_insn *);
 extern rtx_insn *prev_real_insn (rtx_insn *);
 extern rtx_insn *next_real_insn (rtx);
+extern rtx_insn *prev_real_nondebug_insn (rtx_insn *);
+extern rtx_insn *next_real_nondebug_insn (rtx);
 extern rtx_insn *prev_active_insn (rtx_insn *);
 extern rtx_insn *next_active_insn (rtx_insn *);
 extern int active_insn_p (const rtx_insn *);
--- gcc/emit-rtl.c.jj   2018-02-19 22:57:06.508917827 +0100
+++ gcc/emit-rtl.c  2018-03-01 13:37:19.846688578 +0100
@@ -3597,7 +3597,7 @@ prev_nonnote_nondebug_insn_bb (rtx_insn
   return insn;
 }
 
-/* Return the next INSN, CALL_INSN or JUMP_INSN after INSN;
+/* Return the next INSN, CALL_INSN, JUMP_INSN or DEBUG_INSN after INSN;
or 0, if there is none.  This routine does not look inside
SEQUENCEs.  */
 
@@ -3616,7 +3616,7 @@ next_real_insn (rtx uncast_insn)
   return insn;
 }
 
-/* Return the last INSN, CALL_INSN or JUMP_INSN before INSN;
+/* Return the last INSN, CALL_INSN, JUMP_INSN or DEBUG_INSN before INSN;
or 0, if there is none.  This routine does not look inside
SEQUENCEs.  */
 
@@ -3630,6 +3630,42 @@ prev_real_insn (rtx_insn *insn)
break;
 }
 
+  return insn;
+}
+
+/* Return the next INSN, CALL_INSN or JUMP_INSN after INSN;
+   or 0, if there is none.  This routine does not look inside
+   SEQUENCEs.  */
+
+rtx_insn *
+next_real_nondebug_insn (rtx uncast_insn)
+{
+  rtx_insn *insn = safe_as_a  (uncast_insn);
+
+  while (insn)
+{
+  insn = NEXT_INSN (insn);
+  if (insn == 0 || NONDEBUG_INSN_P (insn))
+   break;
+}
+
+  return insn;
+}
+
+/* Return the last INSN, CALL_INSN or JUMP_INSN before INSN;
+   or 0, if there is none.  This routine does not look inside
+   SEQUENCEs.  */
+
+rtx_insn *
+prev_real_nondebug_insn (rtx_insn *insn)
+{
+  while (insn)
+{
+  insn = PREV_INSN (insn);
+  if (insn == 0 || NONDEBUG_INSN_P (insn))
+   break;
+}
+
   return insn;
 }
 
--- gcc/cfgcleanup.c.jj 2018-01-24 17:18:43.779392151 +0100
+++ gcc/cfgcleanup.c2018-03-01 13:39:13.972671695 +0100
@@ -2448,9 +2448,7 @@ try_head_merge_bb (basic_block bb)
   max_match--;
   if (max_match == 0)
return false;
-  do
-   e0_last_head = prev_real_insn (e0_last_head);
-  while (DEBUG_INSN_P (e0_last_head));
+  e0_last_head = prev_real_nondebug_insn (e0_last_head);
 }
 
   if (max_match == 0)
--- gcc/combine.c.jj2018-02-16 19:39:09.485062861 +0100
+++ gcc/combine.c   2018-03-01 13:46:45.292531080 +0100
@@ -13923,7 +13923,7 @@ move_deaths (rtx x, rtx maybe_kill_insn,
 FROM_LUID and TO_INSN.  If so, find it.  This is PR83304.  */
   if (!where_dead || DF_INSN_LUID (where_dead) >= DF_INSN_LUID (to_insn))
{
- rtx_insn *insn = prev_real_insn (to_insn);
+ rtx_insn *insn = prev_real_nondebug_insn (to_insn);
  while (insn
 && BLOCK_FOR_INSN (insn) == BLOCK_FOR_INSN (to_insn)
 && DF_INSN_LUID (insn) >= from_luid)
@@ -13935,7 +13935,7 @@ move_deaths (rtx x, rtx maybe_kill_insn,
  break;
}
 
- insn = prev_real_insn (insn);
+ insn = prev_real_nondebug_insn (insn);
}
}
 
--- gcc/testsuite/gcc.dg/pr84614.c.jj   2018-03-01 14:01:25.256546456 +0100
+++ gcc/testsuite/gcc.dg/pr84614.c  2018-03-01 13:59:30.657611490 +0100
@@ -0,0 +1,28 @@
+/* PR target/84614 */
+/* { dg-do run { target int128 } } */
+/* { dg-options "-Og -fno-split-wide-types -fno-tree-coalesce-vars -g 
--param=max-combine-insns=3 -fcompare-debug" } */
+
+unsigned __int128 a;
+
+unsigned __int128
+b (unsigned short c, unsigned int d)
+{
+  unsigned long long e;
+  __builtin_sub_overflow (0, d, );
+  e >>= c;
+  c ^= 65535;

[PATCH] Fix ICE on invalid inline asm with "X" constraint and non-zero CONST_VECTOR (PR inline-asm/84625)

[Jakub Jelinek]

Hi!

Assertions are only useful when inline asm is not involved, otherwise users
can write anything they want.

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

2018-03-02  Jakub Jelinek  

PR inline-asm/84625
* config/i386/i386.c (ix86_print_operand): Use conditional
output_operand_lossage instead of gcc_assert if CONST_VECTOR is not
zero vector.

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

--- gcc/config/i386/i386.c.jj   2018-02-26 20:49:57.345331383 +0100
+++ gcc/config/i386/i386.c  2018-03-01 12:01:17.820587068 +0100
@@ -18743,7 +18743,8 @@ ix86_print_operand (FILE *file, rtx x, i
 since we can in fact encode that into an immediate.  */
   if (GET_CODE (x) == CONST_VECTOR)
{
- gcc_assert (x == CONST0_RTX (GET_MODE (x)));
+ if (x != CONST0_RTX (GET_MODE (x)))
+   output_operand_lossage ("invalid vector immediate");
  x = const0_rtx;
}
 
--- gcc/testsuite/gcc.target/i386/pr84625.c.jj  2018-03-01 12:00:06.254636914 
+0100
+++ gcc/testsuite/gcc.target/i386/pr84625.c 2018-03-01 12:14:54.044024998 
+0100
@@ -0,0 +1,12 @@
+/* PR inline-asm/84625 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef int V __attribute__((vector_size (16)));
+
+void
+foo (void)
+{
+  asm volatile ("# %0" : : "X" ((V) { 1, 2, 3, 4 }));  // { dg-error "invalid 
vector immediate" }
+  asm volatile ("# %0" : : "" ((V) { 2, 3, 4, 5 }));   // { dg-error "invalid 
vector immediate" }
+}

Jakub

Re: [PATCH, rs6000] GCC 7 backport to remove non-ABI vec_vinsert4b and vec_vextract4b support

[Segher Boessenkool]

Hi Carl,

On Thu, Mar 01, 2018 at 11:07:21AM -0800, Carl Love wrote:
> The following patch is a partial backport of mainline commit 257748 to
> remove the vec_vextract4b and vec_vinsert4b support.  Note in GCC 7,
> vec_vextract4b is still used so only the external definitions,
> documentation and testcases are removed for vec_vextract4b.  All of the
> vec_vinsert4b support is removed.

> This patch has been tested on GCC 7:
> 
>   powerpc64le-unknown-linux-gnu (Power 8 LE)
>   powerpc64-unknown-linux-gnu (Power 8 BE)
> 
> with no regressions.

It's a p9 patch, in the future please test such on a p9 as well (or at
least with -mcpu=power9).

>   * config/rs6000/altivec.h: Remove vec_vextract4b and vec_vinsert4b.

Mention those removed things on the left:
* config/rs6000/altivec.h (vec_vextract4b, vec_vinsert4b): Delete.

>   * config/rs6000/vsx.md:  Remove define_expand vinsert4b, define_insn 
> *vinsert4b_internal,

Only one space after :, and this line is too long.

Patch looks fine, thanks!  Okay for 7.


Segher

[PATCH] libbacktrace: Support FreeBSD/DragonFlyBSD/NetBSD without /proc

[Bryan Drewery]

From: Bryan Drewery 

FreeBSD has had this patch against Rust's bundled libbacktrace for a
while which allows not having /proc mounted to get the process name.
I am open to refactoring this if there's a better place to handle
some of this, such as configure.ac or a bsd-compat.c file.

Authored by:Jan Beich 
---
 libbacktrace/fileline.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git libbacktrace/fileline.c libbacktrace/fileline.c
index e5673068379..6d56f89cfa9 100644
--- libbacktrace/fileline.c
+++ libbacktrace/fileline.c
@@ -39,9 +39,40 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #include 
 
+#if defined(__DragonFly__) || defined(__FreeBSD__) || defined(__NetBSD__)
+#include 
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
+#if !defined(HAVE_GETEXECNAME) && defined(KERN_PROC_PATHNAME)
+/* Return pathname of executable or 0 on failure. */
+#define HAVE_GETEXECNAME
+static char execname[PATH_MAX + 1];
+static const char *
+getexecname(void)
+{
+  size_t path_len = sizeof(execname);
+  int mib[] = {
+CTL_KERN,
+#if defined(__NetBSD__)
+KERN_PROC_ARGS,
+-1,
+KERN_PROC_PATHNAME,
+#else
+KERN_PROC,
+KERN_PROC_PATHNAME,
+-1,
+#endif
+  };
+  u_int miblen = sizeof(mib) / sizeof(mib[0]);
+  int rc = sysctl(mib, miblen, execname, _len, NULL, 0);
+  return rc ? NULL : execname;
+}
+#endif /* !HAVE_GETEXECNAME && KERN_PROC_PATHNAME */
+
 #ifndef HAVE_GETEXECNAME
 #define getexecname() NULL
 #endif
-- 
2.16.2

Re: [PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Jonathan Wakely]

On 1 March 2018 at 18:54, Marc Glisse wrote:
> On Thu, 1 Mar 2018, Tulio Magno Quites Machado Filho wrote:
>
>> In order to use the __float128 in C++ it's necessary to check if
>> it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
>> compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
>
>
> Shouldn't we ensure that _GLIBCXX_USE_FLOAT128 is undefined instead?

Yes, a better approach might be to add this to
libstdc++-v3/include/bits/c++config.h:

#define _GLIBCXX_USE_FLOAT128
#if !defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__)
#undef _GLIBCXX_USE_FLOAT128
#endif

Then change libstdc++-v3/acinclude.m4 so that instead of defining
_GLIBCXX_USE_FLOAT128 it does:

GLIBCXX_CONDITIONAL(ENABLE_FLOAT128, ...)

and then have libstdc++-v3/include/Makefile modify 
based on that, setting _GLIBCXX_USE_FLOAT128 to 0 or 1

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Jason Merrill]

Ok.

On Mar 1, 2018 4:40 PM, "Marek Polacek"  wrote:

> On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
> > On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek 
> wrote:
> > > On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> > >> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek 
> wrote:
> > >> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
> > >> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek 
> wrote:
> > >> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
> > >> >> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
> > >> >> >> > My recent change introducing cxx_constant_init caused this
> code
> > >> >> >> >
> > >> >> >> > template  class A {
> > >> >> >> >static const long b = 0;
> > >> >> >> >static const unsigned c = (b);
> > >> >> >> > };
> > >> >> >> >
> > >> >> >> > to be rejected.  The reason is that force_paren_expr turns
> "b" into "*(const
> > >> >> >> > long int &) ", where the former is not value-dependent but
> the latter is
> > >> >> >> > value-dependent.  So when we get to maybe_constant_init_1:
> > >> >> >> > 5147   if (!is_nondependent_static_init_expression (t))
> > >> >> >> > 5148 /* Don't try to evaluate it.  */;
> > >> >> >> > it's not evaluated and we get the non-constant initialization
> error.
> > >> >> >> > (Before we'd always evaluated the expression.)
> > >> >> >> >
> > >> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > >> >> >> >
> > >> >> >> > 2018-02-27  Marek Polacek  
> > >> >> >> >
> > >> >> >> > PR c++/84582
> > >> >> >> > * semantics.c (force_paren_expr): Avoid creating a static
> cast
> > >> >> >> > when processing a template.
> > >> >> >> >
> > >> >> >> > * g++.dg/cpp1z/static1.C: New test.
> > >> >> >> > * g++.dg/template/static37.C: New test.
> > >> >> >> >
> > >> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> > >> >> >> > index 35569d0cb0d..b48de2df4e2 100644
> > >> >> >> > --- gcc/cp/semantics.c
> > >> >> >> > +++ gcc/cp/semantics.c
> > >> >> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> > >> >> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> > >> >> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> > >> >> >> >   /* We can't bind a hard register variable to a
> reference.  */;
> > >> >> >> > -  else
> > >> >> >> > +  else if (!processing_template_decl)
> > >> >> >>
> > >> >> >> Hmm, this means that we forget about the parentheses in a
> template.  I'm
> > >> >> >> surprised that this didn't break anything in the testsuite.  In
> particular,
> > >> >> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch
> this issue.
> > >> >> >
> > >> >> > Thanks, you're right.  I'll use it.
> > >> >> >
> > >> >> >> Can we use PAREN_EXPR instead of the static_cast in a template?
> > >> >> >
> > >> >> > I don't think so, it would fix the issue you pointed out in
> auto-fn15.C but
> > >> >> > it wouldn't fix the original test.  The problem with using
> PAREN_EXPR in a
> > >> >> > template is that instantiate_non_dependent_expr will turn in
> into the
> > >> >> > static cast anyway; tsubst_copy_and_build has
> > >> >> > case PAREN_EXPR:
> > >> >> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t,
> 0;
> > >> >> > so it calls force_paren_expr and this time we're not in a
> template.  And
> > >> >> > then when calling cxx_constant_init we have the same issue.
> > >> >>
> > >> >> Then maybe we need something like fold_non_dependent_expr, which
> > >> >> checks for dependency before substitution and then immediately
> > >> >> evaluates the result.
> > >> >
> > >> > I hope you meant something like this.  Further testing also
> revealed that
> > >> > maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR
> (so that
> > >> > (fn1)(); in paren2.C is handled correctly), and that lvalue_kind
> should look
> > >> > into PAREN_EXPR so as to give the correct answer regarding
> lvalueness: we
> > >> > should accept
> > >> >
> > >> > template
> > >> > void foo (int i)
> > >> > {
> > >> >   ++(i);
> > >> > }
> > >> >
> > >> > Apologies if I'm on the wrong track.
> > >> >
> > >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > >> >
> > >> > 2018-02-28  Marek Polacek  
> > >> > Jason Merrill  
> > >> >
> > >> > PR c++/84582
> > >> > * semantics.c (force_paren_expr): Avoid creating the static
> cast
> > >> > when in a template.  Create a PAREN_EXPR when in a template.
> > >> > (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
> > >> > * typeck2.c (store_init_value): Call
> fold_non_dependent_expr instead
> > >> > of instantiate_non_dependent_expr.
> > >> > * tree.c (lvalue_kind): Handle PAREN_EXPR like
> NON_DEPENDENT_EXPR.
> > >> >
> > >> > * 

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Marek Polacek]

On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
> On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek  wrote:
> > On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> >> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek  wrote:
> >> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
> >> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  
> >> >> wrote:
> >> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
> >> >> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
> >> >> >> > My recent change introducing cxx_constant_init caused this code
> >> >> >> >
> >> >> >> > template  class A {
> >> >> >> >static const long b = 0;
> >> >> >> >static const unsigned c = (b);
> >> >> >> > };
> >> >> >> >
> >> >> >> > to be rejected.  The reason is that force_paren_expr turns "b" 
> >> >> >> > into "*(const
> >> >> >> > long int &) ", where the former is not value-dependent but the 
> >> >> >> > latter is
> >> >> >> > value-dependent.  So when we get to maybe_constant_init_1:
> >> >> >> > 5147   if (!is_nondependent_static_init_expression (t))
> >> >> >> > 5148 /* Don't try to evaluate it.  */;
> >> >> >> > it's not evaluated and we get the non-constant initialization 
> >> >> >> > error.
> >> >> >> > (Before we'd always evaluated the expression.)
> >> >> >> >
> >> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >> >> >> >
> >> >> >> > 2018-02-27  Marek Polacek  
> >> >> >> >
> >> >> >> > PR c++/84582
> >> >> >> > * semantics.c (force_paren_expr): Avoid creating a static cast
> >> >> >> > when processing a template.
> >> >> >> >
> >> >> >> > * g++.dg/cpp1z/static1.C: New test.
> >> >> >> > * g++.dg/template/static37.C: New test.
> >> >> >> >
> >> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> >> >> >> > index 35569d0cb0d..b48de2df4e2 100644
> >> >> >> > --- gcc/cp/semantics.c
> >> >> >> > +++ gcc/cp/semantics.c
> >> >> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> >> >> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> >> >> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> >> >> >> >   /* We can't bind a hard register variable to a reference.  
> >> >> >> > */;
> >> >> >> > -  else
> >> >> >> > +  else if (!processing_template_decl)
> >> >> >>
> >> >> >> Hmm, this means that we forget about the parentheses in a template.  
> >> >> >> I'm
> >> >> >> surprised that this didn't break anything in the testsuite.  In 
> >> >> >> particular,
> >> >> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this 
> >> >> >> issue.
> >> >> >
> >> >> > Thanks, you're right.  I'll use it.
> >> >> >
> >> >> >> Can we use PAREN_EXPR instead of the static_cast in a template?
> >> >> >
> >> >> > I don't think so, it would fix the issue you pointed out in 
> >> >> > auto-fn15.C but
> >> >> > it wouldn't fix the original test.  The problem with using PAREN_EXPR 
> >> >> > in a
> >> >> > template is that instantiate_non_dependent_expr will turn in into the
> >> >> > static cast anyway; tsubst_copy_and_build has
> >> >> > case PAREN_EXPR:
> >> >> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 
> >> >> > 0;
> >> >> > so it calls force_paren_expr and this time we're not in a template.  
> >> >> > And
> >> >> > then when calling cxx_constant_init we have the same issue.
> >> >>
> >> >> Then maybe we need something like fold_non_dependent_expr, which
> >> >> checks for dependency before substitution and then immediately
> >> >> evaluates the result.
> >> >
> >> > I hope you meant something like this.  Further testing also revealed that
> >> > maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR (so that
> >> > (fn1)(); in paren2.C is handled correctly), and that lvalue_kind should 
> >> > look
> >> > into PAREN_EXPR so as to give the correct answer regarding lvalueness: we
> >> > should accept
> >> >
> >> > template
> >> > void foo (int i)
> >> > {
> >> >   ++(i);
> >> > }
> >> >
> >> > Apologies if I'm on the wrong track.
> >> >
> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >> >
> >> > 2018-02-28  Marek Polacek  
> >> > Jason Merrill  
> >> >
> >> > PR c++/84582
> >> > * semantics.c (force_paren_expr): Avoid creating the static cast
> >> > when in a template.  Create a PAREN_EXPR when in a template.
> >> > (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
> >> > * typeck2.c (store_init_value): Call fold_non_dependent_expr 
> >> > instead
> >> > of instantiate_non_dependent_expr.
> >> > * tree.c (lvalue_kind): Handle PAREN_EXPR like 
> >> > NON_DEPENDENT_EXPR.
> >> >
> >> > * g++.dg/cpp1y/auto-fn15.C: Extend testing.
> >> > * g++.dg/cpp1z/static1.C: New test.
> >> > * g++.dg/template/static37.C: New test.
> >> >
> >> > 

Re: C++ PATCH to tweak cp_fully_fold (PR c++/84590)

[Marek Polacek]

On Thu, Mar 01, 2018 at 02:29:47PM -0500, Jason Merrill wrote:
> I think this should happen in the block with maybe_constant_value;
> cp_fold_rvalue doesn't do this.

This, then:

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

2018-03-01  Marek Polacek  

PR c++/84590
* cp-gimplify.c (cp_fully_fold): Unwrap TARGET_EXPR or a CONSTRUCTOR
wrapped in VIEW_CONVERT_EXPR.

* c-c++-common/ubsan/shift-11.c: New test.

diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index 55a9d278dbe..0ddd435454c 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -2037,7 +2037,17 @@ cp_fully_fold (tree x)
   /* FIXME cp_fold ought to be a superset of maybe_constant_value so we don't
  have to call both.  */
   if (cxx_dialect >= cxx11)
-x = maybe_constant_value (x);
+{
+  x = maybe_constant_value (x);
+  /* Sometimes we are given a CONSTRUCTOR but the call above wraps it into
+a TARGET_EXPR; undo that here.  */
+  if (TREE_CODE (x) == TARGET_EXPR)
+   x = TARGET_EXPR_INITIAL (x);
+  else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
+  && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
+  && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
+   x = TREE_OPERAND (x, 0);
+}
   return cp_fold_rvalue (x);
 }
 
diff --git gcc/testsuite/c-c++-common/ubsan/shift-11.c 
gcc/testsuite/c-c++-common/ubsan/shift-11.c
index e69de29bb2d..03a72e217a2 100644
--- gcc/testsuite/c-c++-common/ubsan/shift-11.c
+++ gcc/testsuite/c-c++-common/ubsan/shift-11.c
@@ -0,0 +1,13 @@
+/* PR c++/84590 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=shift" } */
+
+struct S {
+  int b;
+};
+
+void
+fn (void)
+{
+  struct S c1 = { 1 << -1 }; /* { dg-warning "left shift" } */
+}

Marek

[PR c++/84434] ICE with deduction guide

[Nathan Sidwell]

This crash was caused by unexpectedly seeing a USING_DECL.  Normally we 
want to make dependent using-decls visible to name lookup, so we know to 
defer things to instantiation time.  But here we're (a) explicitly 
looking inside uninstantiated templates and (b) want to know the ctors 
the template definitely has.  so we should ignore the dependent 
inherited ctor.


Before my name reworking, the lookup during the deduction guide 
generation never saw the using decl, as it never made it into the 
special CONSTRUCTOR_SLOT.


nathan
--
Nathan Sidwell
2018-03-01  Nathan Sidwell  

	PR c++/84434
	* name-lookup.c (member_vec_dedup): Remove manually peeled
	iteration.  Ignore dependent ctor inheritance.

	PR c++/84434
	* g++.dg/template/pr84434.C: New.

Index: cp/name-lookup.c
===
--- cp/name-lookup.c	(revision 258100)
+++ cp/name-lookup.c	(working copy)
@@ -1591,68 +1591,58 @@ member_vec_dedup (vec *memb
   if (!len)
 return;
 
-  tree current = (*member_vec)[0], name = OVL_NAME (current);
-  tree next = NULL_TREE, next_name = NULL_TREE;
-  for (unsigned jx, ix = 0; ix < len;
-   ix = jx, current = next, name = next_name)
+  tree name = OVL_NAME ((*member_vec)[0]);
+  for (unsigned jx, ix = 0; ix < len; ix = jx)
 {
+  tree current = NULL_TREE;
   tree to_type = NULL_TREE;
   tree to_using = NULL_TREE;
   tree marker = NULL_TREE;
-  if (IDENTIFIER_CONV_OP_P (name))
-	{
-	  marker = current;
-	  current = OVL_CHAIN (current);
-	  name = DECL_NAME (OVL_FUNCTION (marker));
-	  gcc_checking_assert (name == conv_op_identifier);
-	}
 
-  if (TREE_CODE (current) == USING_DECL)
+  for (jx = ix; jx < len; jx++)
 	{
-	  current = strip_using_decl (current);
-	  if (is_overloaded_fn (current))
-	current = NULL_TREE;
-	  else if (TREE_CODE (current) == USING_DECL)
+	  tree next = (*member_vec)[jx];
+	  if (jx != ix)
 	{
-	  to_using = current;
-	  current = NULL_TREE;
+	  tree next_name = OVL_NAME (next);
+	  if (next_name != name)
+		{
+		  name = next_name;
+		  break;
+		}
 	}
-	}
 
-  if (current && DECL_DECLARES_TYPE_P (current))
-	{
-	  to_type = current;
-	  current = NULL_TREE;
-	}
-
-  for (jx = ix + 1; jx < len; jx++)
-	{
-	  next = (*member_vec)[jx];
-	  next_name = OVL_NAME (next);
-	  if (next_name != name)
-	break;
-
-	  if (marker)
+	  if (IDENTIFIER_CONV_OP_P (name))
 	{
-	  gcc_checking_assert (OVL_FUNCTION (marker)
-   == OVL_FUNCTION (next));
+	  marker = next;
 	  next = OVL_CHAIN (next);
 	}
 
 	  if (TREE_CODE (next) == USING_DECL)
 	{
+	  if (IDENTIFIER_CTOR_P (name))
+		/* Dependent inherited ctor. */
+		continue;
+
 	  next = strip_using_decl (next);
-	  if (is_overloaded_fn (next))
-		next = NULL_TREE;
-	  else if (TREE_CODE (next) == USING_DECL)
+	  if (TREE_CODE (next) == USING_DECL)
 		{
 		  to_using = next;
-		  next = NULL_TREE;
+		  continue;
 		}
+
+	  if (is_overloaded_fn (next))
+		continue;
 	}
 
-	  if (next && DECL_DECLARES_TYPE_P (next))
-	to_type = next;
+	  if (DECL_DECLARES_TYPE_P (next))
+	{
+	  to_type = next;
+	  continue;
+	}
+
+	  if (!current)
+	current = next;
 	}
 
   if (to_using)
@@ -1671,13 +1661,15 @@ member_vec_dedup (vec *memb
 	current = stat_hack (current, to_type);
 	}
 
-  gcc_assert (current);
-  if (marker)
+  if (current)
 	{
-	  OVL_CHAIN (marker) = current;
-	  current = marker;
+	  if (marker)
+	{
+	  OVL_CHAIN (marker) = current;
+	  current = marker;
+	}
+	  (*member_vec)[store++] = current;
 	}
-  (*member_vec)[store++] = current;
 }
 
   while (store++ < len)
Index: testsuite/g++.dg/template/pr84434.C
===
--- testsuite/g++.dg/template/pr84434.C	(revision 0)
+++ testsuite/g++.dg/template/pr84434.C	(working copy)
@@ -0,0 +1,23 @@
+// PR c++/84434 ICE with deduction guide and dependent using decl
+// { dg-do compile { target c++17 } }
+
+template  class B {
+public:
+  template  B (U)  {}
+};
+
+template 
+struct scope_guard : B {
+  using base_type = B;
+
+  using base_type::base_type;
+
+   ~scope_guard() = default;
+};
+
+template 
+scope_guard (T) -> scope_guard;
+
+void Frob () {
+  scope_guard (1);
+}

[PATCH] RISC-V: Add and document the "-mno-relax" option

[Palmer Dabbelt]

From: Palmer Dabbelt 

RISC-V relies on aggressive linker relaxation to get good code size.  As
a result no text symbol addresses can be known until link time, which
means that alignment must be handled during the link.  This alignment
pass is essentially just another linker relaxation, so this has the
unfortunate side effect that linker relaxation is required for
correctness on many RISC-V targets.

The RISC-V assembler has supported an ".option norelax" for a long time
because there are situations in which linker relaxation is a bad idea --
the canonical example is when trying to materialize the initial value of
the global pointer into a register, which would otherwise be relaxed to
a NOP.  We've been relying on users who want to disable relaxation for
an entire link to pass "-Wl,--no-relax", but that still relies on the
linker relaxing R_RISCV_ALIGN to handle alignment despite it not being
strictly necessary.

This patch adds a GCC option, "-mno-relax", that disable linker
relaxation by adding ".option norelax" to the top of every generated
assembly file.  The assembler is smart enough to handle alignment at
assemble time for files that have never emitted a relaxable relocation,
so this is sufficient to really disable all relaxations in the linker,
which results in significantly faster link times for large objects.

This also has the side effect of allowing toolchains that don't support
linker relaxation (LLVM and the Linux module loader) to function
correctly.  Toolchains that don't support linker relaxation should
default to "-mno-relax" and error when presented with any R_RISCV_ALIGN
relocation as those need to be handled for correctness.

gcc/ChangeLog

2018-03-01  Palmer Dabbelt  

* config/riscv/riscv.opt (mrelax): New option.
* config/riscv/riscv.c (riscv_file_start): Emit ".option
"norelax" when riscv_mrelax is disabled.
* doc/invoke.texi (RISC-V): Document "-mrelax" and "-mno-relax".
---
 gcc/config/riscv/riscv.c   | 5 +
 gcc/config/riscv/riscv.opt | 5 +
 gcc/doc/invoke.texi| 8 +++-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index c38f6c394d54..3e81874de232 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3979,6 +3979,11 @@ riscv_file_start (void)
 
   /* Instruct GAS to generate position-[in]dependent code.  */
   fprintf (asm_out_file, "\t.option %spic\n", (flag_pic ? "" : "no"));
+
+  /* If the user specifies "-mno-relax" on the command line then disable linker
+ relaxation in the assembler.  */
+  if (! riscv_mrelax)
+fprintf (asm_out_file, "\t.option norelax\n");
 }
 
 /* Implement TARGET_ASM_OUTPUT_MI_THUNK.  Generate rtl rather than asm text
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 581a26bb5c1e..6f1d74fc6ed5 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -106,6 +106,11 @@ mexplicit-relocs
 Target Report Mask(EXPLICIT_RELOCS)
 Use %reloc() operators, rather than assembly macros, to load addresses.
 
+mrelax
+Target Bool Var(riscv_mrelax) Init(1)
+Take advantage of linker relaxations to reduce the number of instructions
+required to materalize symbol addresses.
+
 Mask(64BIT)
 
 Mask(MUL)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8d366c626bae..215fd428c3f2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1042,7 +1042,8 @@ See RS/6000 and PowerPC Options.
 -msave-restore  -mno-save-restore @gol
 -mstrict-align -mno-strict-align @gol
 -mcmodel=medlow -mcmodel=medany @gol
--mexplicit-relocs  -mno-explicit-relocs @gol}
+-mexplicit-relocs  -mno-explicit-relocs @gol
+-mrelax -mno-relax @gol}
 
 @emph{RL78 Options}
 @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
@@ -23102,6 +23103,11 @@ Use or do not use assembler relocation operators when 
dealing with symbolic
 addresses.  The alternative is to use assembler macros instead, which may
 limit optimization.
 
+@item -mrelax
+@itemx -mno-relax
+Take advantage of linker relaxations to reduce the number of instructions
+required to materalize symbol addresses.
+
 @end table
 
 @node RL78 Options
-- 
2.16.1

[og7] vector_length extension part 1: generalize function and variable names

[Cesar Philippidis]

Right now, I'm in the process of adding support for larger
vector_lengths in the nvptx BE. To reduce the size of the final patch,
I've separated all of the misc. function and variable renaming into this
patch. Once the nvptx BE is extended to support multiple CUDA
warps-sized vector lengths, in certain respect vectors will act like
workers with regards to state propagation and reductions (i.e., large
vectors will use shared-memory to propagate state between vector-single
to vector-partitioned modes and also for reductions). To that end, this
patch renames worker functions and variables from worker-something to
shared-something. Likewise, vector specific functions have been renamed
as warp-something.

This patch also introduces a new populate_offload_attrs function. At
present, that function is only used in nvptx_reorg, and it is actually
overkill for that. However, later one it will be used in other places,
including nvptx_validate_dims and the nvptx reduction handling code.

This patch has been committed to openacc-gcc-7-branch.

Cesar
2018-03-01  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx.c (PTX_VECTOR_LENGTH, PTX_WORKER_LENGTH,
	PTX_DEFAULT_RUNTIME_DIM): Move to the top of the file.
	(PTX_WARP_SIZE): Define.
	(PTX_CTA_SIZE): Define.
	(worker_bcast_size): Rename to oacc_bcast_size.
	(worker_bcast_align): Rename to oacc_bcast_align.
	(worker_bcast_sym): Rename to oacc_bcast_sym.
	(nvptx_option_override): Update usage of oacc_bcast_*.
	(nvptx_gen_wcast): Rename to nvptx_gen_warp_bcast.
	(struct wcast_data_t): Rename to broadcast_data_t.
	(nvptx_gen_wcast): Rename to nvptx_gen_shared_bcast.  Update to use
	oacc_bcast_* variables.
	(struct offload_attrs): New.
	(propagator_fn): Add bool argument.
	(nvptx_propagate): New bool argument.  Pass bool argument to fn.
	(vprop_gen): Rename to warp_prop_gen.  Update call to
	nvptx_gen_warp_bcast.
	(nvptx_vpropagate): Rename to nvptx_warp_propagate. Update call to
	nvptx_propagate.
	(wprop_gen): Rename to shared_prop_gen.  Update usage of oacc_bcast_*
	variables and call to nvptx_gen_shared_bcast.
	(nvptx_wpropagate): Rename to nvptx_shared_propagate.  Update usage
	of oacc_bcast_* variables and call to nvptx_propagate.
	(nvptx_wsync): Rename to nvptx_cta_sync.
	(nvptx_single): Update usage of oacc_bcast_* vars and calls to
	nvptx_gen_warp_bcast, nvptx_gen_shared_bcast and nvptx_cta_sync.
	(nvptx_process_pars): Likewise.
	(nvptx_neuter_pars): Whitespace.
	(populate_offload_attrs): New function.
	(nvptx_reorg): Use it to extract partitioning mask.
	(write_worker_buffer): Rename to write_shared_buffer.
	(nvptx_file_end): Update calls to write_shared_buffer.
	(nvptx_expand_worker_addr): Rename to nvptx_expand_shared_addr.
	(nvptx_expand_builtin): Update call to nvptx_expand_shared_addr.
	(nvptx_simt_vf): Return PTX_WARP_SIZE instead of PTX_VECTOR_LENGTH.
	(nvptx_get_worker_red_addr): Rename to nvptx_get_shared_red_addr.
	(nvptx_goacc_reduction_setup): Update call to
	nvptx_get_shared_red_addr.
	(nvptx_goacc_reduction_fini): Likewise.
	(nvptx_goacc_reduction_teardown): Likewise.


diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 1d510a7bb7d..b16cf59575c 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -77,6 +77,14 @@
 
 #define WORKAROUND_PTXJIT_BUG 1
 
+/* Define dimension sizes for known hardware.  */
+#define PTX_VECTOR_LENGTH 32
+//#define PTX_VECTOR_LENGTH 128
+#define PTX_WORKER_LENGTH 32
+#define PTX_DEFAULT_RUNTIME_DIM 0 /* Defer to runtime.  */
+#define PTX_WARP_SIZE 32
+#define PTX_CTA_SIZE 1024
+
 /* The various PTX memory areas an object might reside in.  */
 enum nvptx_data_area
 {
@@ -118,14 +126,15 @@ struct tree_hasher : ggc_cache_ptr_hash
 static GTY((cache)) hash_table *declared_fndecls_htab;
 static GTY((cache)) hash_table *needed_fndecls_htab;
 
-/* Buffer needed to broadcast across workers.  This is used for both
-   worker-neutering and worker broadcasting.  It is shared by all
-   functions emitted.  The buffer is placed in shared memory.  It'd be
-   nice if PTX supported common blocks, because then this could be
-   shared across TUs (taking the largest size).  */
-static unsigned worker_bcast_size;
-static unsigned worker_bcast_align;
-static GTY(()) rtx worker_bcast_sym;
+/* Buffer needed to broadcast across workers and vectors.  This is
+   used for both worker-neutering and worker broadcasting, and
+   vector-neutering and boardcasting when vector_length > 32.  It is
+   shared by all functions emitted.  The buffer is placed in shared
+   memory.  It'd be nice if PTX supported common blocks, because then
+   this could be shared across TUs (taking the largest size).  */
+static unsigned oacc_bcast_size;
+static unsigned oacc_bcast_align;
+static GTY(()) rtx oacc_bcast_sym;
 
 /* Buffer needed for worker reductions.  This has to be distinct from
the worker broadcast array, as both may be live concurrently.  */
@@ -198,9 +207,9 @@ nvptx_option_override (void)
   

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Martin Sebor]

On 02/27/2018 06:50 PM, Jeff Law wrote:

On 02/26/2018 05:47 PM, Martin Sebor wrote:

On 02/26/2018 12:13 PM, Jeff Law wrote:

On 02/24/2018 05:11 PM, Martin Sebor wrote:

Attached is an updated patch with a fix for a bad assumption
exposed by building the linux kernel.

On 02/19/2018 07:50 PM, Martin Sebor wrote:

PR 84468 points out a false positive in -Wstringop-truncation
in code like this:

  struct A { char a[4]; };

  void f (struct A *p, const struct A *q)
  {
if (p->a)
  strncpy (p->a, q->a, sizeof p->a - 1);   // warning here

p->a[3] = '\0';
  }

The warning is due to the code checking only the same basic block
as the one with the strncpy call for an assignment to the destination
to avoid it, but failing to check the successor basic block if there
is no subsequent statement in the current block.  (Eliminating
the conditional is being tracked in PR 21474.)

The attached test case adds logic to avoid this false positive.
I don't know under what circumstances there could be more than
one successor block here so I don't handle that case.

So this is feeling more and more like we need to go back to the ideas
behind checking the virtual operand chains.

The patch as-written does not properly handle the case where BB has
multiple outgoing edges.  For gcc-8 you could probably get away with
checking that you have precisely one outgoing edge without EDGE_ABNORMAL
set in its flags in addition to the checks you're already doing.

But again, it's feeling more and more like the right fix is to go back
and walk the virtual operands.


I intentionally kept the patch as simple as possible to minimize
risk at this late stage.

Attached is a more robust version that handles multiple outgoing
edges and avoids those with the EDGE_ABNORMAL bit set.  Retested
on x86_64 and with the Linux kernel.

Enhancing this code to handle more complex cases is on my to-do
list for stage 1 (e.g., to handle bug 84561 where MEM_REF defeats
the detection of the nul assignment).

I don't think handling multiple outgoing edges is advisable here.  To do
that you have to start thinking about post-dominator analysis at which
point you're better off walking the memory web via VUSE/VDEFs.

Just verify the block has a single outgoing edge and that the edge is
not marked with EDGE_ABNORMAL.  Don't bother with the recursive call.
Assuming you get a suitable block, then look inside.


I read you last reply as asking me to handle multiple edges.
The original patch handled just one edge and didn't bother
with EDGE_ABNORMAL because I wanted to keep it simple.  But
it sounds like you want me to go back to the first version
and just add a check for EDGE_ABNORMAL.  The attached patch
does that (plus it skips over any non-debug statements in
the successor block).  Besides the usual I retested it with
the Linux kernel.  There are just three instances of
the warning in my default configuration but I know there
are a lot more in more extensive builds.



I glanced over the tests and I didn't see any that would benefit from
handling multiple edges or the recursion (every one of the dg-bogus
markers should be immediately transferring control to the null
termination statement AFAICT).


I've added some more test cases involving C++ exceptions (and
found one false positive(*)) but I don't have a test to exercise
blocks with multiple outgoing edges.  For future reference, how
would I create one?

Martin

[*] From bug 84624:

char d[3];

void f ();

void g (const char *s)
{
  try
{
  f ();
}
  catch (...)
{
  __builtin_strncpy (d, s, sizeof d);   // bogus warning
}

  d[sizeof d - 1] = 0;   // because of this
}

The warning sees the following and triggers because the strncpy
call is followed by __cxa_end_catch().

   [count: 0]:
:
  _1 = __builtin_eh_pointer (1);
  __cxa_begin_catch (_1);
  __builtin_strncpy (, s_7(D), 3);
  __cxa_end_catch ();
  goto ; [100.00%]
Index: gcc/testsuite/g++.dg/warn/Wstringop-truncation-2.C
===
--- gcc/testsuite/g++.dg/warn/Wstringop-truncation-2.C	(nonexistent)
+++ gcc/testsuite/g++.dg/warn/Wstringop-truncation-2.C	(working copy)
@@ -0,0 +1,164 @@
+// PR tree-optimization/84468 - bogus -Wstringop-truncation despite
+// assignment after conditional strncpy
+// Compile with -g to verify the warning deals properly with debug
+// statements.
+// { dg-do compile }
+// { dg-options "-O2 -Wstringop-truncation -g" }
+
+extern "C" char* strncpy (char*, const char*, __SIZE_TYPE__);
+
+char d[3];
+
+void g ();
+
+void fnowarn1 (const char *s)
+{
+  // Update dummy but never actually use it so it's eliminated
+  // but causes debugging statements to be emitted for each
+  // modification.
+  int dummy = 0;
+
+  try
+{
+  g ();
+  strncpy (d, s, sizeof d);   // { dg-bogus "\\\[-Wstringop-truncation]" }
+  ++dummy;
+}
+  catch (...)
+{
+  ++dummy;
+  d[0] = 0;
+}
+
+  ++dummy;
+  d[sizeof d - 1] = 0;
+}
+

Re: [PATCH] PR fortran/51434 -- ICE in gfc_simplify_transfer

[Steve Kargl]

On Thu, Mar 01, 2018 at 09:44:57PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> > 2018-02-26  Steven G. Kargl  
> > 
> > PF fortran/51434
> > * simplify.c (gfc_simplify_transfer): Reduce mold.
> 
> I think this should be "Resolve" (at least that is what your
> patch shows).
> 
> OK for trunk, thanks for the patch!
> 

Yes, I noticed that typo.  I tried gfc_reduce_expr and
gfc_simplify_expr, but both gave the ICE.  gfc_resolve_expr
works.

-- 
Steve

Re: [PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Marc Glisse]

On Thu, 1 Mar 2018, Jakub Jelinek wrote:


Note ia64, pa and powerpcspe likely need to be fixed too to predefine
__SIZEOF_FLOAT128__=16 if they provide __float128.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540
(it only mentions ia64)

--
Marc Glisse

Re: [PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Jakub Jelinek]

On Thu, Mar 01, 2018 at 08:10:03PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 03:47:19PM -0300, Tulio Magno Quites Machado Filho 
> wrote:
> > In order to use the __float128 in C++ it's necessary to check if
> > it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
> > compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
> > 
> > 2018-03-01 Tulio Magno Quites Machado Filho 
> 
> Two spaces between date and name and name and email address.
> 
> > PR libstdc++/84654
> > * include/bits/std_abs.h: Avoid to use __float128 when the
> > compiler disabled it.
> > * include/std/type_traits: Likewise.
> 
> That is incorrect.  Only powerpc* defines __FLOAT128__ macro, but it isn't
> the only one with __float128 type, e.g. x86_64-linux provides __float128
> too, but doesn't define __FLOAT128__.
> 
> On x86_64-linux one can check for defined(__SIZEOF_FLOAT128__) instead.
> 
> One could argue that what powerpc does is wrong, defining __SIZEOF_*__ is
> consistent with all the other __SIZEOF_*__ macros.
> 
> Also (up to libstdc++ maintainers) I'd say that _GLIBCXX_USE_FLOAT128
> macro should depend on this macro, rather than uglifying all the uses.
> So, #undef somewhere _GLIBCXX_USE_FLOAT128 if __SIZEOF_FLOAT128__ is
> not defined.

Note ia64, pa and powerpcspe likely need to be fixed too to predefine
__SIZEOF_FLOAT128__=16 if they provide __float128.

Jakub

Re: [PATCH] PR fortran/51434 -- ICE in gfc_simplify_transfer

[Thomas Koenig]

Hi Steve,


2018-02-26  Steven G. Kargl  

PF fortran/51434
* simplify.c (gfc_simplify_transfer): Reduce mold.



I think this should be "Resolve" (at least that is what your
patch shows).

OK for trunk, thanks for the patch!

Regards

Thomas

Re: [PATCH][AArch64] Remove aarch64_frame_pointer_required

[Wilco Dijkstra]

Richard Sandiford wrote:
> But there's the third question of whether the frame pointer is available
> for general allocation.  By removing frame_pointer_required, we're saying
> that the frame pointer is always available for general use.  

Unlike on ARM/Thumb-2, the frame pointer is unfortunately never available for
general allocation on AArch64 - so we cannot use it for something actually 
useful.
A while back there were mid-end patches proposed to allow general allocation
of FP but those weren't accepted.

Wilco

Go patch committed: Don't crash on invalid self-referential type

[Ian Lance Taylor]

This patch to the Go frontend by Than McIntosh avoids a compiler crash
on an invalid self-referential type.  The compiler was crashing
partway through emitting an error for a bad self-referential struct
type (which refers to one of its own fields via an unsafe.Offset
expression).  The patch tweaks the offset logic to check for this
class of type error and exit cleanly.  This fixes
https://golang.org/issue/24180.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 258052)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-821960465883fbdd96568f2325f55ee4b05de1cb
+262d629b1592f681fef396166a671e46cdb31230
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 257954)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -8224,6 +8224,11 @@ Builtin_call_expression::do_numeric_cons
 return false;
   if (st->named_type() != NULL)
 st->named_type()->convert(this->gogo_);
+  if (st->is_error_type())
+{
+  go_assert(saw_errors());
+  return false;
+}
   int64_t offset;
   this->seen_ = true;
   bool ok = st->struct_type()->backend_field_offset(this->gogo_,

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Thu, Mar 1, 2018 at 11:00 AM, Jason Merrill  wrote:
> On Thu, Mar 1, 2018 at 9:41 AM, Jason Merrill  wrote:
>> On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini  
>> wrote:
>>> On 28/02/2018 20:20, Jason Merrill wrote:

 Hmm, the test seems wrong; the diagnostic talks about specializing the
 arguments, but the actual test is checking whether the enclosing scope
 is fully specialized.  It looks like you'll give the same error for

 template 
 struct A {
template 
static const U u;
 };

 template 
 template 
 const U* A::u = nullptr;

 which does specialize the argument; since we accept

 template 
 struct A {
template 
struct B;
 };

 template 
 template 
 struct A::B { };

 we ought to accept the above as well.

 So, we could reject the testcase with this error, but we would need to
 test for it using the same check as in process_partial_specialization.
>>>
>>> I see. Doing that seems relatively easy - I have a draft which appears to
>>> work - but then we have immediately to change the gcc_assert at the
>>> beginning of determine_specialization to let such specializations through
>>> (of course it still uses the wrong test!!).  I'm not sure about the best way
>>> to do that... But that seems also doable.
>>
>> That test is correct for functions, I think we just want to restrict
>> that block to functions.
>>
>>> The next problem is
>>> duplicate_decls which apparently misses a bit of code to understand that the
>>> new declaration does not conflict with the old one near line #1650... So,
>>> frankly, I think that even with your great guidance I would need a few
>>> iterations to get right the whole package and we are so damn close to the
>>> release. What do you think? Do you want to take this over, or maybe you see
>>> us restricting a bit what we'll have working in this area for 8.1.0?
>>
>> Yeah, I'll take it.
>
> Ah, needed to fix the code in start_decl that checks for a variable
> template specialization to consider that a specialization can be a
> template.

And this fixes the other testcase in comment 6.
commit 530608b73c7fc0345f8150ad124b57e180abfa11
Author: Jason Merrill 
Date:   Thu Mar 1 12:24:39 2018 -0500

PR c++/71569 - decltype of template.

* parser.c (cp_parser_decltype_expr): Handle missing template args.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 359460cd4d8..e1acb07d29e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13983,6 +13983,10 @@ cp_parser_decltype_expr (cp_parser *parser,
expr = cp_parser_lookup_name_simple (parser, expr,
 id_expr_start_token->location);
 
+  if (expr && TREE_CODE (expr) == TEMPLATE_DECL)
+   /* A template without args is not a complete id-expression.  */
+   expr = error_mark_node;
+
   if (expr
   && expr != error_mark_node
   && TREE_CODE (expr) != TYPE_DECL
@@ -14048,6 +14052,9 @@ cp_parser_decltype_expr (cp_parser *parser,
  expression.  */
   cp_parser_abort_tentative_parse (parser);
 
+  /* Commit to the tentative_firewall so we get syntax errors.  */
+  cp_parser_commit_to_tentative_parse (parser);
+
   /* Parse a full expression.  */
   expr = cp_parser_expression (parser, /*pidk=*/NULL, /*cast_p=*/false,
   /*decltype_p=*/true);
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype-33837.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype-33837.C
index fbbc6a14972..4a8f053234e 100644
--- a/gcc/testsuite/g++.dg/cpp0x/decltype-33837.C
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype-33837.C
@@ -2,6 +2,6 @@
 // PR c++/33837
 void foo()
 {
-  __decltype (A::foo()); // { dg-error "was not declared|expected" }
-  __decltype (B); // { dg-error "was not declared" }
+  __decltype (A::foo()); // { dg-error "A" }
+  __decltype (B); // { dg-error "B" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype43.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype43.C
index 4df95a1047c..7a1dcbf8744 100644
--- a/gcc/testsuite/g++.dg/cpp0x/decltype43.C
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype43.C
@@ -22,6 +22,6 @@ struct B
 int main()
 {
   int x = B::b(A::a(1));
-  int y = B::b(A::a(2)); // { dg-error "template 
argument" }
+  int y = B::b(A::a(2)); // { dg-error "template" 
}
   return x + y;
 }
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ59.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ59.C
new file mode 100644
index 000..da9710e1ce4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ59.C
@@ -0,0 +1,14 @@
+// PR c++/71569
+// { dg-do compile { target c++14 } }
+
+template 
+struct A {
+  template 
+  static U u;
+};
+
+int main()
+{
+  decltype(A::u) a;   // { dg-error "missing template arguments" }
+  

Re: [PATCH] Fix ICE caused by a missing check for DECL_LANG_SPECIFIC

[Jason Merrill]

On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune  wrote:
> Hi,
>
> It seems we have had a bug for some time that causes an ICE and prevents the
> MIPS16 library builds from completing but is likely unrelated to MIPS16.
> The problem is when we call target_reinit and library functions get created
> as shown in the call stack at the end of this message. The first builtin
> that triggers the problem happens to be one of the MIPS16 helpers but I
> don't think there is anything unique about it. The issue appeared after some
> refactoring work in r253600 where code testing DECL_CLASS_SCOPE_P and
> DECL_FRIEND_P was previously guarded by a check for DECL_LANG_SPECIFIC but
> not after.
>
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html
>
> I don’t know if this is the correct solution or whether we need to change the
> way builtins are initialised in the MIPS backend but I suspect this fix
> is the right way to go.
>
> Cc: Jason as author of the original change.
>
> Thanks,
> Matthew
>
> gcc/cp/
> * pt.c (type_dependent_expression_p): Add missing check for
> DECL_LANG_SPECIFIC.
> ---
>  gcc/cp/pt.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 7345119..c88304f 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -24635,6 +24635,7 @@ type_dependent_expression_p (tree expression)
>   type-dependent.  Checking this is important for functions with auto 
> return
>   type, which looks like a dependent type.  */
>if (TREE_CODE (expression) == FUNCTION_DECL
> +  && DECL_LANG_SPECIFIC (expression)
>&& !(DECL_CLASS_SCOPE_P (expression)
>&& dependent_type_p (DECL_CONTEXT (expression)))
>&& !(DECL_FRIEND_P (expression)

I think we want to go into this block when DECL_LANG_SPECIFIC is NULL.
Does this also fix the issue for you?
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e07d77bb87e..f67080fc279 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24641,7 +24641,8 @@ type_dependent_expression_p (tree expression)
   if (TREE_CODE (expression) == FUNCTION_DECL
   && !(DECL_CLASS_SCOPE_P (expression)
   && dependent_type_p (DECL_CONTEXT (expression)))
-  && !(DECL_FRIEND_P (expression)
+  && !(DECL_LANG_SPECIFIC (expression)
+  && DECL_FRIEND_P (expression)
   && (!DECL_FRIEND_CONTEXT (expression)
   || dependent_type_p (DECL_FRIEND_CONTEXT (expression
   && !DECL_LOCAL_FUNCTION_P (expression))

Re: C++ PATCH to tweak cp_fully_fold (PR c++/84590)

[Jason Merrill]

On Thu, Mar 1, 2018 at 2:12 PM, Marek Polacek  wrote:
> In this testcase we find ourselves in split_nonconstant_init:
>
>init = cp_fully_fold (init);
>code = push_stmt_list ();
>if (split_nonconstant_init_1 (dest, init))
>
> where initially INIT was a CONSTRUCTOR, but cp_fully_fold returned
> a TARGET_EXPR.  This confuses split_nonconstant_init_1 which only expects
> a CONSTRUCTOR or a VECTOR_CST.  Jason suggested stripping TARGET_EXPRs /
> VIEW_CONVERT_EXPRs, so here it is.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-01  Marek Polacek  
>
> PR c++/84590
> * cp-gimplify.c (cp_fully_fold): Unwrap TARGET_EXPR or a CONSTRUCTOR
> wrapped in VIEW_CONVERT_EXPR.
>
> * c-c++-common/ubsan/shift-11.c: New test.
>
> diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> index 55a9d278dbe..1fa9c466e6b 100644
> --- gcc/cp/cp-gimplify.c
> +++ gcc/cp/cp-gimplify.c
> @@ -2038,7 +2038,18 @@ cp_fully_fold (tree x)
>   have to call both.  */
>if (cxx_dialect >= cxx11)
>  x = maybe_constant_value (x);
> -  return cp_fold_rvalue (x);
> +  x = cp_fold_rvalue (x);
> +
> +  /* Sometimes we are given a CONSTRUCTOR but 
> cxx_eval_outermost_constant_expr
> + wraps it into a TARGET_EXPR; undo that here.  */
> +  if (TREE_CODE (x) == TARGET_EXPR)
> +x = TARGET_EXPR_INITIAL (x);
> +  else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
> +  && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
> +  && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
> +x = TREE_OPERAND (x, 0);

I think this should happen in the block with maybe_constant_value;
cp_fold_rvalue doesn't do this.

Jason

Re: [PATCH] merge attributes from function template redeclarations (PR 84294)

[Jason Merrill]

On Wed, Feb 28, 2018 at 5:47 PM, Martin Sebor  wrote:
> Attached is a patch for the failure to merge a subset of attributes
> specified on redeclarations of a function template with those of
> the first declaration (const, malloc, pure, noinline, noreturn,
> and nothrow).  This was uncovered this morning while debugging
> failures in tests I added just yesterday and although it's not
> a regression I figured since I introduced the test failures and
> the fix appears easy it might as well be taken care of now.
>
> The test I added for this exposed a subtle bug in -Wreturn-type
> where the warning triggers on a function template instantiated
> on a noreturn function even though the middle end successfully
> eliminates statements after the noreturn call.  This is not
> a regression either so to avoid mission creep I just xfailed
> the test and opened bug 84621 to remind us to fix it in
> the future.

OK.  Incidentally, looking over duplicate_decls again, I noticed:

  /* [temp.expl.spec/14] We don't inline explicit
specialization
 just because the primary template says so.  */

  if (merge_attr)
{
  /* But still keep DECL_DISREGARD_INLINE_LIMITS in sync
with
 the always_inline attribute.  */
  if (DECL_DISREGARD_INLINE_LIMITS (olddecl)
  && !DECL_DISREGARD_INLINE_LIMITS (newdecl))
{
  if (DECL_DECLARED_INLINE_P (newdecl))
DECL_DISREGARD_INLINE_LIMITS (newdecl) = true;
  else
DECL_ATTRIBUTES (newdecl)
  = remove_attribute ("always_inline",
  DECL_ATTRIBUTES (newdecl));
}
}
  else
{
  DECL_DECLARED_INLINE_P (olddecl)
= DECL_DECLARED_INLINE_P (newdecl);

  DECL_DISREGARD_INLINE_LIMITS (olddecl)
= DECL_DISREGARD_INLINE_LIMITS (newdecl);

  DECL_UNINLINABLE (olddecl) = DECL_UNINLINABLE (newdecl);
}

The upper block here seems like dead code; here we're dealing with an
explicit specialization, so merge_attr should always be false.  Let's
drop the if block.

Jason

C++ PATCH to tweak cp_fully_fold (PR c++/84590)

[Marek Polacek]

In this testcase we find ourselves in split_nonconstant_init:

   init = cp_fully_fold (init);
   code = push_stmt_list ();
   if (split_nonconstant_init_1 (dest, init))

where initially INIT was a CONSTRUCTOR, but cp_fully_fold returned
a TARGET_EXPR.  This confuses split_nonconstant_init_1 which only expects
a CONSTRUCTOR or a VECTOR_CST.  Jason suggested stripping TARGET_EXPRs /
VIEW_CONVERT_EXPRs, so here it is.

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

2018-03-01  Marek Polacek  

PR c++/84590
* cp-gimplify.c (cp_fully_fold): Unwrap TARGET_EXPR or a CONSTRUCTOR
wrapped in VIEW_CONVERT_EXPR.

* c-c++-common/ubsan/shift-11.c: New test.

diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
index 55a9d278dbe..1fa9c466e6b 100644
--- gcc/cp/cp-gimplify.c
+++ gcc/cp/cp-gimplify.c
@@ -2038,7 +2038,18 @@ cp_fully_fold (tree x)
  have to call both.  */
   if (cxx_dialect >= cxx11)
 x = maybe_constant_value (x);
-  return cp_fold_rvalue (x);
+  x = cp_fold_rvalue (x);
+
+  /* Sometimes we are given a CONSTRUCTOR but cxx_eval_outermost_constant_expr
+ wraps it into a TARGET_EXPR; undo that here.  */
+  if (TREE_CODE (x) == TARGET_EXPR)
+x = TARGET_EXPR_INITIAL (x);
+  else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
+  && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
+  && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
+x = TREE_OPERAND (x, 0);
+
+  return x;
 }
 
 /* c-common interface to cp_fold.  If IN_INIT, this is in a static initializer
diff --git gcc/testsuite/c-c++-common/ubsan/shift-11.c 
gcc/testsuite/c-c++-common/ubsan/shift-11.c
index e69de29bb2d..03a72e217a2 100644
--- gcc/testsuite/c-c++-common/ubsan/shift-11.c
+++ gcc/testsuite/c-c++-common/ubsan/shift-11.c
@@ -0,0 +1,13 @@
+/* PR c++/84590 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=shift" } */
+
+struct S {
+  int b;
+};
+
+void
+fn (void)
+{
+  struct S c1 = { 1 << -1 }; /* { dg-warning "left shift" } */
+}

Marek

Re: c-family PATCH to fix invalid shifting (PR c++/84639)

[Jason Merrill]

OK.

On Thu, Mar 1, 2018 at 9:14 AM, Marek Polacek  wrote:
> Here we were using pow2align as the right operand of <<.  But for invalid
> alignments pow2align can be -1 which makes the shifting invalid.  Fixed by
> moving the checking before using pow2align.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-01  Marek Polacek  
>
> PR c++/84639
> * c-attribs.c (common_handle_aligned_attribute): Don't use invalid
> alignment in computation.
>
> diff --git gcc/c-family/c-attribs.c gcc/c-family/c-attribs.c
> index 0261a45ec98..3ebb2d6000c 100644
> --- gcc/c-family/c-attribs.c
> +++ gcc/c-family/c-attribs.c
> @@ -1817,6 +1817,12 @@ common_handle_aligned_attribute (tree *node, tree 
> name, tree args, int flags,
>
>/* Log2 of specified alignment.  */
>int pow2align = check_user_alignment (align_expr, true);
> +  if (pow2align == -1
> +  || !check_cxx_fundamental_alignment_constraints (*node, pow2align, 
> flags))
> +{
> +  *no_add_attrs = true;
> +  return NULL_TREE;
> +}
>
>/* The alignment in bits corresponding to the specified alignment.  */
>unsigned bitalign = (1U << pow2align) * BITS_PER_UNIT;
> @@ -1826,10 +1832,7 @@ common_handle_aligned_attribute (tree *node, tree 
> name, tree args, int flags,
>unsigned curalign = 0;
>unsigned lastalign = 0;
>
> -  if (pow2align == -1
> -  || !check_cxx_fundamental_alignment_constraints (*node, pow2align, 
> flags))
> -*no_add_attrs = true;
> -  else if (is_type)
> +  if (is_type)
>  {
>if ((flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
> /* OK, modify the type in place.  */;
>
> Marek

Re: [PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Jakub Jelinek]

On Thu, Mar 01, 2018 at 03:47:19PM -0300, Tulio Magno Quites Machado Filho 
wrote:
> In order to use the __float128 in C++ it's necessary to check if
> it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
> compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
> 
> 2018-03-01 Tulio Magno Quites Machado Filho 

Two spaces between date and name and name and email address.

>   PR libstdc++/84654
>   * include/bits/std_abs.h: Avoid to use __float128 when the
>   compiler disabled it.
>   * include/std/type_traits: Likewise.

That is incorrect.  Only powerpc* defines __FLOAT128__ macro, but it isn't
the only one with __float128 type, e.g. x86_64-linux provides __float128
too, but doesn't define __FLOAT128__.

On x86_64-linux one can check for defined(__SIZEOF_FLOAT128__) instead.

One could argue that what powerpc does is wrong, defining __SIZEOF_*__ is
consistent with all the other __SIZEOF_*__ macros.

Also (up to libstdc++ maintainers) I'd say that _GLIBCXX_USE_FLOAT128
macro should depend on this macro, rather than uglifying all the uses.
So, #undef somewhere _GLIBCXX_USE_FLOAT128 if __SIZEOF_FLOAT128__ is
not defined.

Jakub

[PATCH, rs6000] GCC 7 backport to remove non-ABI vec_vinsert4b and vec_vextract4b support

[Carl Love]

GCC maintainers:

The following patch is a partial backport of mainline commit 257748 to
remove the vec_vextract4b and vec_vinsert4b support.  Note in GCC 7,
vec_vextract4b is still used so only the external definitions,
documentation and testcases are removed for vec_vextract4b.  All of the
vec_vinsert4b support is removed.

This patch has been tested on GCC 7:

  powerpc64le-unknown-linux-gnu (Power 8 LE)
  powerpc64-unknown-linux-gnu (Power 8 BE)

with no regressions.

Let me know if the patch looks OK or not. Thanks.

   Carl Love
-

gcc/ChangeLog
2018-02-28  Carl Love  

* config/rs6000/altivec.h: Remove vec_vextract4b and vec_vinsert4b.
* config/rs6000/rs6000-builtin.def: Remove macro expansion for
VINSERT4B_DI and VINSERT4B.
* config/rs6000/rs6000.c: Remove case statements for
P9V_BUILTIN_VINSERT4B, P9V_BUILTIN_VINSERT4B_DI,
and P9V_BUILTIN_VEC_VINSERT4B.
* config/rs6000/rs6000-c.c (altivec_expand_builtin): Remove entries for
P9V_BUILTIN_VEC_VEXTRACT4B and P9V_BUILTIN_VEC_VINSERT4B.
* config/rs6000/vsx.md:  Remove define_expand vinsert4b, define_insn 
*vinsert4b_internal,
define_insn "*vinsert4b_di_internal.
* doc/extend.texi: Remove vec_vextract4b, non ABI definitions for
vec_insert4b.

gcc/testsuite/ChangeLog
2018-02-28  Carl Love  

* gcc.target/powerpc/p9-vinsert4b-1.c: Remove test file for non-ABI
tests.
* gcc.target/powerpc/p9-vinsert4b-2.c: Remove test file for non-ABI
tests.
---
 gcc/config/rs6000/altivec.h   |  2 -
 gcc/config/rs6000/rs6000-builtin.def  |  3 --
 gcc/config/rs6000/rs6000-c.c  | 21 -
 gcc/config/rs6000/rs6000.c|  5 +--
 gcc/config/rs6000/vsx.md  | 52 +--
 gcc/doc/extend.texi   | 12 +-
 gcc/testsuite/gcc.target/powerpc/p9-vinsert4b-1.c | 39 -
 gcc/testsuite/gcc.target/powerpc/p9-vinsert4b-2.c | 30 -
 8 files changed, 3 insertions(+), 161 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/p9-vinsert4b-1.c
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/p9-vinsert4b-2.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index 3011a87..e04c3a5 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -398,8 +398,6 @@
 #define vec_vctzd __builtin_vec_vctzd
 #define vec_vctzh __builtin_vec_vctzh
 #define vec_vctzw __builtin_vec_vctzw
-#define vec_vextract4b __builtin_vec_vextract4b
-#define vec_vinsert4b __builtin_vec_vinsert4b
 #define vec_extract4b __builtin_vec_extract4b
 #define vec_insert4b __builtin_vec_insert4b
 #define vec_vprtyb __builtin_vec_vprtyb
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 46ae21a..00e8e60 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2034,8 +2034,6 @@ BU_P9V_AV_2 (VEXTUWRX, "vextuwrx",CONST,  
vextuwrx)
 
 /* Insert/extract 4 byte word into a vector.  */
 BU_P9V_VSX_2 (VEXTRACT4B,   "vextract4b",  CONST,  vextract4b)
-BU_P9V_VSX_3 (VINSERT4B,"vinsert4b",   CONST,  vinsert4b)
-BU_P9V_VSX_3 (VINSERT4B_DI, "vinsert4b_di",CONST,  vinsert4b_di)
 BU_P9V_VSX_3 (INSERT4B,"insert4b", CONST,  insert4b)
 BU_P9V_VSX_2 (EXTRACT4B,   "extract4b",CONST,  extract4b)
 
@@ -2090,7 +2088,6 @@ BU_P9V_OVERLOAD_2 (EXTRACT4B,  "extract4b")
 
 /* ISA 3.0 Vector scalar overloaded 3 argument functions */
 BU_P9V_OVERLOAD_3 (STXVL,  "stxvl")
-BU_P9V_OVERLOAD_3 (VINSERT4B,  "vinsert4b")
 BU_P9V_OVERLOAD_3 (INSERT4B,"insert4b")
 
 /* Overloaded CMPNE support was implemented prior to Power 9,
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index c3134fc..c6fd524 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -5109,27 +5109,6 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
   { P9V_BUILTIN_VEC_INSERT4B, P9V_BUILTIN_INSERT4B,
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V4SI,
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_INTSI },
-  { P9V_BUILTIN_VEC_VINSERT4B, P9V_BUILTIN_VINSERT4B,
-RS6000_BTI_V16QI, RS6000_BTI_V4SI,
-RS6000_BTI_V16QI, RS6000_BTI_UINTSI },
-  { P9V_BUILTIN_VEC_VINSERT4B, P9V_BUILTIN_VINSERT4B,
-RS6000_BTI_V16QI, RS6000_BTI_unsigned_V4SI,
-RS6000_BTI_V16QI, RS6000_BTI_UINTSI },
-  { P9V_BUILTIN_VEC_VINSERT4B, P9V_BUILTIN_VINSERT4B,
-RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V4SI,
-RS6000_BTI_unsigned_V16QI, RS6000_BTI_UINTSI },
-  { P9V_BUILTIN_VEC_VINSERT4B, P9V_BUILTIN_VINSERT4B_DI,
-RS6000_BTI_V16QI, RS6000_BTI_INTDI,
-RS6000_BTI_V16QI, RS6000_BTI_UINTDI },
-  { P9V_BUILTIN_VEC_VINSERT4B, 

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Jason Merrill]

On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek  wrote:
> On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek  wrote:
>> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
>> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  wrote:
>> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
>> >> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
>> >> >> > My recent change introducing cxx_constant_init caused this code
>> >> >> >
>> >> >> > template  class A {
>> >> >> >static const long b = 0;
>> >> >> >static const unsigned c = (b);
>> >> >> > };
>> >> >> >
>> >> >> > to be rejected.  The reason is that force_paren_expr turns "b" into 
>> >> >> > "*(const
>> >> >> > long int &) ", where the former is not value-dependent but the 
>> >> >> > latter is
>> >> >> > value-dependent.  So when we get to maybe_constant_init_1:
>> >> >> > 5147   if (!is_nondependent_static_init_expression (t))
>> >> >> > 5148 /* Don't try to evaluate it.  */;
>> >> >> > it's not evaluated and we get the non-constant initialization error.
>> >> >> > (Before we'd always evaluated the expression.)
>> >> >> >
>> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >> >> >
>> >> >> > 2018-02-27  Marek Polacek  
>> >> >> >
>> >> >> > PR c++/84582
>> >> >> > * semantics.c (force_paren_expr): Avoid creating a static cast
>> >> >> > when processing a template.
>> >> >> >
>> >> >> > * g++.dg/cpp1z/static1.C: New test.
>> >> >> > * g++.dg/template/static37.C: New test.
>> >> >> >
>> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> >> >> > index 35569d0cb0d..b48de2df4e2 100644
>> >> >> > --- gcc/cp/semantics.c
>> >> >> > +++ gcc/cp/semantics.c
>> >> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>> >> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>> >> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>> >> >> >   /* We can't bind a hard register variable to a reference.  */;
>> >> >> > -  else
>> >> >> > +  else if (!processing_template_decl)
>> >> >>
>> >> >> Hmm, this means that we forget about the parentheses in a template.  
>> >> >> I'm
>> >> >> surprised that this didn't break anything in the testsuite.  In 
>> >> >> particular,
>> >> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this 
>> >> >> issue.
>> >> >
>> >> > Thanks, you're right.  I'll use it.
>> >> >
>> >> >> Can we use PAREN_EXPR instead of the static_cast in a template?
>> >> >
>> >> > I don't think so, it would fix the issue you pointed out in auto-fn15.C 
>> >> > but
>> >> > it wouldn't fix the original test.  The problem with using PAREN_EXPR 
>> >> > in a
>> >> > template is that instantiate_non_dependent_expr will turn in into the
>> >> > static cast anyway; tsubst_copy_and_build has
>> >> > case PAREN_EXPR:
>> >> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
>> >> > so it calls force_paren_expr and this time we're not in a template.  And
>> >> > then when calling cxx_constant_init we have the same issue.
>> >>
>> >> Then maybe we need something like fold_non_dependent_expr, which
>> >> checks for dependency before substitution and then immediately
>> >> evaluates the result.
>> >
>> > I hope you meant something like this.  Further testing also revealed that
>> > maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR (so that
>> > (fn1)(); in paren2.C is handled correctly), and that lvalue_kind should 
>> > look
>> > into PAREN_EXPR so as to give the correct answer regarding lvalueness: we
>> > should accept
>> >
>> > template
>> > void foo (int i)
>> > {
>> >   ++(i);
>> > }
>> >
>> > Apologies if I'm on the wrong track.
>> >
>> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >
>> > 2018-02-28  Marek Polacek  
>> > Jason Merrill  
>> >
>> > PR c++/84582
>> > * semantics.c (force_paren_expr): Avoid creating the static cast
>> > when in a template.  Create a PAREN_EXPR when in a template.
>> > (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
>> > * typeck2.c (store_init_value): Call fold_non_dependent_expr 
>> > instead
>> > of instantiate_non_dependent_expr.
>> > * tree.c (lvalue_kind): Handle PAREN_EXPR like NON_DEPENDENT_EXPR.
>> >
>> > * g++.dg/cpp1y/auto-fn15.C: Extend testing.
>> > * g++.dg/cpp1z/static1.C: New test.
>> > * g++.dg/template/static37.C: New test.
>> >
>> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> > index 35569d0cb0d..722e3718a14 100644
>> > --- gcc/cp/semantics.c
>> > +++ gcc/cp/semantics.c
>> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>> >  expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>> >else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>> >  /* We 

Re: [PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Marc Glisse]

On Thu, 1 Mar 2018, Tulio Magno Quites Machado Filho wrote:


In order to use the __float128 in C++ it's necessary to check if
it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
compiler enabled its support too, e.g. -mfloat128 or -mno-float128.


Shouldn't we ensure that _GLIBCXX_USE_FLOAT128 is undefined instead?

By the way, __FLOAT128__ is power-only. x86 has __SIZEOF_FLOAT128__ 
instead (why did power pick a different name?).


--
Marc Glisse

[PATCH] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Tulio Magno Quites Machado Filho]

In order to use the __float128 in C++ it's necessary to check if
it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
compiler enabled its support too, e.g. -mfloat128 or -mno-float128.

2018-03-01 Tulio Magno Quites Machado Filho 

PR libstdc++/84654
* include/bits/std_abs.h: Avoid to use __float128 when the
compiler disabled it.
* include/std/type_traits: Likewise.
---
 libstdc++-v3/include/bits/std_abs.h  | 3 ++-
 libstdc++-v3/include/std/type_traits | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_abs.h 
b/libstdc++-v3/include/bits/std_abs.h
index 6e4551d..3ad1c2b 100644
--- a/libstdc++-v3/include/bits/std_abs.h
+++ b/libstdc++-v3/include/bits/std_abs.h
@@ -96,7 +96,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   abs(__GLIBCXX_TYPE_INT_N_3 __x) { return __x >= 0 ? __x : -__x; }
 #endif
 
-#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
+#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) \
+&& defined(__FLOAT128__)
   inline _GLIBCXX_CONSTEXPR
   __float128
   abs(__float128 __x)
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 711d6c5..4e2e4f7 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -342,7 +342,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct __is_floating_point_helper
 : public true_type { };
 
-#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
+#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) \
+&& defined(__FLOAT128__)
   template<>
 struct __is_floating_point_helper<__float128>
 : public true_type { };
-- 
2.9.5

[PATCH] [AArch64] Update L2 cache size on Falkor's prefetch tuning structure.

[Luis Machado]

Falkor's prefetch tuning structure still carries the L2 cache size value from
early support code. This patch updates it to match the specifications.

Even though the prefetcher is currently disabled for Falkor, we have a patch
waiting for GCC development to reopen that re-enables it, so i take it this
update should be trivial enough to go in before development reopens?

Thanks,
Luis

2018-03-01  Luis Machado  

* config/aarch64/aarch64.c (qdf24xx_prefetch_tune) : Set
to 512.
---
 gcc/config/aarch64/aarch64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2f98a21..5a732b1 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -564,7 +564,7 @@ static const cpu_prefetch_tune qdf24xx_prefetch_tune =
   4,   /* num_slots  */
   32,  /* l1_cache_size  */
   64,  /* l1_cache_line_size  */
-  1024,/* l2_cache_size  */
+  512, /* l2_cache_size  */
   -1   /* default_opt_level  */
 };
 
-- 
2.7.4

Avoid _VINFO_MASKS for bb vectorisation (PR 84634)

[Richard Sandiford]

We were computing _VINFO_MASKS even for bb vectorisation,
which is UB.

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

Richard


2018-03-01  Richard Sandiford  

gcc/
PR tree-optimization/84634
* tree-vect-stmts.c (vectorizable_store, vectorizable_load): Replace
masks and masked_loop_p with a single loop_masks, making sure it's
null for bb vectorization.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2018-02-20 09:39:34.536228161 +
+++ gcc/tree-vect-stmts.c   2018-03-01 18:29:15.280350088 +
@@ -6703,13 +6703,16 @@ vectorizable_store (gimple *stmt, gimple
 
   alignment_support_scheme = vect_supportable_dr_alignment (first_dr, false);
   gcc_assert (alignment_support_scheme);
-  bool masked_loop_p = (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo));
+  vec_loop_masks *loop_masks
+= (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
+   ? _VINFO_MASKS (loop_vinfo)
+   : NULL);
   /* Targets with store-lane instructions must not require explicit
  realignment.  vect_supportable_dr_alignment always returns either
  dr_aligned or dr_unaligned_supported for masked operations.  */
   gcc_assert ((memory_access_type != VMAT_LOAD_STORE_LANES
   && !mask
-  && !masked_loop_p)
+  && !loop_masks)
  || alignment_support_scheme == dr_aligned
  || alignment_support_scheme == dr_unaligned_supported);
 
@@ -6783,7 +6786,6 @@ vectorizable_store (gimple *stmt, gimple
 
   prev_stmt_info = NULL;
   tree vec_mask = NULL_TREE;
-  vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
   for (j = 0; j < ncopies; j++)
 {
 
@@ -6900,8 +6902,9 @@ vectorizable_store (gimple *stmt, gimple
}
 
  tree final_mask = NULL;
- if (masked_loop_p)
-   final_mask = vect_get_loop_mask (gsi, masks, ncopies, vectype, j);
+ if (loop_masks)
+   final_mask = vect_get_loop_mask (gsi, loop_masks, ncopies,
+vectype, j);
  if (vec_mask)
final_mask = prepare_load_store_mask (mask_vectype, final_mask,
  vec_mask, gsi);
@@ -6949,8 +6952,9 @@ vectorizable_store (gimple *stmt, gimple
  unsigned align, misalign;
 
  tree final_mask = NULL_TREE;
- if (masked_loop_p)
-   final_mask = vect_get_loop_mask (gsi, masks, vec_num * ncopies,
+ if (loop_masks)
+   final_mask = vect_get_loop_mask (gsi, loop_masks,
+vec_num * ncopies,
 vectype, vec_num * j + i);
  if (vec_mask)
final_mask = prepare_load_store_mask (mask_vectype, final_mask,
@@ -6960,7 +6964,7 @@ vectorizable_store (gimple *stmt, gimple
{
  tree scale = size_int (gs_info.scale);
  gcall *call;
- if (masked_loop_p)
+ if (loop_masks)
call = gimple_build_call_internal
  (IFN_MASK_SCATTER_STORE, 5, dataref_ptr, vec_offset,
   scale, vec_oprnd, final_mask);
@@ -7790,13 +7794,16 @@ vectorizable_load (gimple *stmt, gimple_
 
   alignment_support_scheme = vect_supportable_dr_alignment (first_dr, false);
   gcc_assert (alignment_support_scheme);
-  bool masked_loop_p = (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo));
+  vec_loop_masks *loop_masks
+= (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
+   ? _VINFO_MASKS (loop_vinfo)
+   : NULL);
   /* Targets with store-lane instructions must not require explicit
  realignment.  vect_supportable_dr_alignment always returns either
  dr_aligned or dr_unaligned_supported for masked operations.  */
   gcc_assert ((memory_access_type != VMAT_LOAD_STORE_LANES
   && !mask
-  && !masked_loop_p)
+  && !loop_masks)
  || alignment_support_scheme == dr_aligned
  || alignment_support_scheme == dr_unaligned_supported);
 
@@ -7956,7 +7963,6 @@ vectorizable_load (gimple *stmt, gimple_
   tree vec_mask = NULL_TREE;
   prev_stmt_info = NULL;
   poly_uint64 group_elt = 0;
-  vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
   for (j = 0; j < ncopies; j++)
 {
   /* 1. Create the vector or array pointer update chain.  */
@@ -8037,8 +8043,9 @@ vectorizable_load (gimple *stmt, gimple_
  vec_array = create_vector_array (vectype, vec_num);
 
  tree final_mask = NULL_TREE;
- if (masked_loop_p)
-   final_mask = vect_get_loop_mask (gsi, masks, ncopies, vectype, j);
+ if (loop_masks)
+   final_mask = vect_get_loop_mask (gsi, loop_masks, ncopies,
+vectype, j);
  if 

[PATCH, GCC/testsuite/ARM] Fix copysign_softfloat_1.c option directives

[Thomas Preudhomme]

gcc.target/arm/copysign_softfloat_1.c's use of arm_arch_v6t2 in
dg-add-option changes the architecture to -march=armv6t2. Since the test
only requires Thumb-2 capable architecture, we just need to add -mthumb
on the command line since arm_thumb2_ok guarantees by definition that
doing that is enough to select Thumb-2. This fixes warning on the
command line when having -mcpu=cortex-m3 in RUNTESTFLAGS for instance.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2018-03-01  Thomas Preud'homme  

Use loop->safelen rather than loop->force_vectorize

[Richard Sandiford]

...since the latter doesn't guarantee independence by itself.

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

Richard


2018-03-01  Richard Sandiford  

gcc/
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence)
(vect_analyze_data_ref_access): Use loop->safe_len rather than
loop->force_vectorize to check whether there is no alias.

gcc/testsuite/
* gcc.dg/vect/vect-alias-check-13.c: New test.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   2018-02-10 09:49:47.950776097 +
+++ gcc/tree-vect-data-refs.c   2018-03-01 18:17:41.631482331 +
@@ -466,7 +466,7 @@ vect_analyze_data_ref_dependence (struct
  return true;
}
 
- if (!loop->force_vectorize)
+ if (loop->safelen < 2)
{
  tree indicator = dr_zero_step_indicator (dra);
  if (TREE_CODE (indicator) != INTEGER_CST)
@@ -2720,7 +2720,7 @@ vect_analyze_data_ref_access (struct dat
   /* Allow references with zero step for outer loops marked
 with pragma omp simd only - it guarantees absence of
 loop-carried dependencies between inner loop iterations.  */
-  if (!loop->force_vectorize)
+  if (loop->safelen < 2)
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-13.c
===
--- /dev/null   2018-03-01 08:17:49.562264353 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-13.c 2018-03-01 
18:17:41.630484279 +
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+
+void
+f1 (int *x, long step1, int n)
+{
+  for (int i = 0; i < n; ++i)
+x[i * step1] += 1;
+}
+
+void
+f2 (int *x, long step2, int n)
+{
+#pragma GCC ivdep
+  for (int i = 0; i < n; ++i)
+x[i * step2] += 2;
+}
+
+/* { dg-final { scan-tree-dump {need run-time check that [^\n]*step1[^\n]* is 
nonzero} "vect" } } */
+/* { dg-final { scan-tree-dump-not {need run-time check that [^\n]*step2[^\n]* 
is nonzero} "vect" } } */
+/* { dg-final { scan-tree-dump-times {LOOP VECTORIZED} 2 "vect" } } */

Re: [PR c++/84596] implicit conv in static assert

[Jason Merrill]

On Thu, Mar 1, 2018 at 11:28 AM, Marek Polacek  wrote:
> On Wed, Feb 28, 2018 at 02:01:06PM -0500, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 8:57 AM, Marek Polacek  wrote:
>> > On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
>> >> Evaluation of constant expressions, such as those passed to
>> >> static_assert, ICEd when encountering IMPLICIT_CONV_EXPRs.
>> >>
>> >> Handle them like CONVERT_EXPR and NOP_EXPR.
>> >>
>> >> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
>> >>
>> >> for  gcc/cp/ChangeLog
>> >>
>> >>   PR c++/84596
>> >>   * constexpr.c (cxx_eval_constant_expression): Handle
>> >>   IMPLICIT_CONV_EXPR.
>> >>
>> >> for  gcc/testsuite/ChangeLog
>> >>
>> >>   PR c++/84596
>> >>   * g++.dg/cpp0x/pr84596.C: New.
>> >> ---
>> >>  gcc/cp/constexpr.c   |1 +
>> >>  gcc/testsuite/g++.dg/cpp0x/pr84596.C |7 +++
>> >>  2 files changed, 8 insertions(+)
>> >>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr84596.C
>> >>
>> >> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
>> >> index 4bbdbf434877..d38e2d83ae8c 100644
>> >> --- a/gcc/cp/constexpr.c
>> >> +++ b/gcc/cp/constexpr.c
>> >> @@ -4549,6 +4549,7 @@ cxx_eval_constant_expression (const constexpr_ctx 
>> >> *ctx, tree t,
>> >>  non_constant_p, overflow_p);
>> >>break;
>> >>
>> >> +case IMPLICIT_CONV_EXPR:
>> >>  case CONVERT_EXPR:
>> >>  case VIEW_CONVERT_EXPR:
>> >>  case NOP_EXPR:
>> >
>> > I don't think it's correct to handle template codes here; they shouldn't
>> > have gotten to cxx_eval_constant_expression in the first place.  Usually
>> > they're substituted in instantiate_non_dependent_expr_internal e.g. via
>> > calling fold_non_dependent_expr.  So I guess we need to find out how
>> > IMPLICIT_CONV_EXPR has gotten there.
>>
>> Agreed.
>
> Here's my take on this; Alex, sorry for interfering.
>
> The problem is that perform_implicit_conversion_flags in finish_static_assert
> produces "implicit_conv_expr " where "c" is a PARM_DECL.  Subsequent
> fold_non_dependent_expr is supposed to substitute that implicit_conv_expr but
> doesn't because the expression is not is_nondependent_constant_expression --
> a PARM_DECL is only considered a potentially constant expression if NOW is
> false, which it isn't.  But the require_potential_rvalue_constant_expression
> call that follows uses NOW = false.  So I think we need the following.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-01  Marek Polacek  
>
> PR c++/84596
> * constexpr.c (require_rvalue_constant_expression): New function.
> * cp-tree.h: Declare it.
> * semantics.c (finish_static_assert): Use it instead of
> require_potential_rvalue_constant_expression.
>
> * g++.dg/cpp0x/static_assert14.C: New test.

OK.

Jason

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

[Thomas Preudhomme]

Finally committed to gcc-7-branch, sorry for doing this so late. I've merged the 
two commits into one. Patch attached for reference.


Best regards,

Thomas

On 05/12/17 21:26, Mike Stump wrote:

On Dec 5, 2017, at 12:56 PM, Thomas Preudhomme  
wrote:


Thanks, I've tested after the two commits and it works both in tree and out of 
tree. It'll simplify comparing in tree results Vs out of tree for us, thanks a 
lot!

Would you consider a backport to stable branches if nobody complains after a 
week?


Yeah, back port is Ok.

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b211dec4ffb20359f50bbc695481977282eb0525..b78c5f59bfc1121cf61071e41bd11551a9ab7122 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,12 @@
+2017-02-27  Thomas Preud'homme  
+
+	Backport from mainline
+	2017-12-05  Matthew Gretton-Dann  
+	with follow-up r255433 commit.
+
+	* gcc.c-torture/unsorted/dump-noaddr.x: Generate dump files in
+	tmpdir.
+
 2018-02-26  Carl Love  
 
 	Backport from mainline: commit 257747 on 2018-02-16.
diff --git a/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.x b/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.x
index d14d494570944b2be82c2575204cdbf4b15721ca..e86f36a1861fc4dc46bd449d78403f510ec4b920 100644
--- a/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.x
+++ b/gcc/testsuite/gcc.c-torture/unsorted/dump-noaddr.x
@@ -9,14 +9,14 @@ proc dump_compare { src options } {
 
 # loop through all the options
 foreach option $option_list {
-	file delete -force dump1
-	file mkdir dump1
+	file delete -force $tmpdir/dump1
+	file mkdir $tmpdir/dump1
 	c-torture-compile $src "$option $options -dumpbase dump1/$dumpbase -DMASK=1 -x c --param ggc-min-heapsize=1 -fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr"
-	file delete -force dump2
-	file mkdir dump2
+	file delete -force $tmpdir/dump2
+	file mkdir $tmpdir/dump2
 	c-torture-compile $src "$option $options -dumpbase dump2/$dumpbase -DMASK=2 -x c -fdump-ipa-all -fdump-rtl-all -fdump-tree-all -fdump-noaddr"
-	foreach dump1 [lsort [glob -nocomplain dump1/*]] {
-	regsub dump1/ $dump1 dump2/ dump2
+	foreach dump1 [lsort [glob -nocomplain $tmpdir/dump1/*]] {
+	set dump2 "$tmpdir/dump2/[file tail $dump1]"
 	set dumptail "gcc.c-torture/unsorted/[file tail $dump1]"
 	regsub {\.\d+((t|r|i)\.[^.]+)$} $dumptail {.*\1} dumptail
 	set tmp [ diff "$dump1" "$dump2" ]
@@ -29,8 +29,8 @@ proc dump_compare { src options } {
 	}
 	}
 }
-file delete -force dump1
-file delete -force dump2
+file delete -force $tmpdir/dump1
+file delete -force $tmpdir/dump2
 }
 
 dump_compare $src $options

Re: [PR c++/84596] implicit conv in static assert

[Marek Polacek]

On Wed, Feb 28, 2018 at 02:01:06PM -0500, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 8:57 AM, Marek Polacek  wrote:
> > On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
> >> Evaluation of constant expressions, such as those passed to
> >> static_assert, ICEd when encountering IMPLICIT_CONV_EXPRs.
> >>
> >> Handle them like CONVERT_EXPR and NOP_EXPR.
> >>
> >> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
> >>
> >> for  gcc/cp/ChangeLog
> >>
> >>   PR c++/84596
> >>   * constexpr.c (cxx_eval_constant_expression): Handle
> >>   IMPLICIT_CONV_EXPR.
> >>
> >> for  gcc/testsuite/ChangeLog
> >>
> >>   PR c++/84596
> >>   * g++.dg/cpp0x/pr84596.C: New.
> >> ---
> >>  gcc/cp/constexpr.c   |1 +
> >>  gcc/testsuite/g++.dg/cpp0x/pr84596.C |7 +++
> >>  2 files changed, 8 insertions(+)
> >>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr84596.C
> >>
> >> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> >> index 4bbdbf434877..d38e2d83ae8c 100644
> >> --- a/gcc/cp/constexpr.c
> >> +++ b/gcc/cp/constexpr.c
> >> @@ -4549,6 +4549,7 @@ cxx_eval_constant_expression (const constexpr_ctx 
> >> *ctx, tree t,
> >>  non_constant_p, overflow_p);
> >>break;
> >>
> >> +case IMPLICIT_CONV_EXPR:
> >>  case CONVERT_EXPR:
> >>  case VIEW_CONVERT_EXPR:
> >>  case NOP_EXPR:
> >
> > I don't think it's correct to handle template codes here; they shouldn't
> > have gotten to cxx_eval_constant_expression in the first place.  Usually
> > they're substituted in instantiate_non_dependent_expr_internal e.g. via
> > calling fold_non_dependent_expr.  So I guess we need to find out how
> > IMPLICIT_CONV_EXPR has gotten there.
> 
> Agreed.

Here's my take on this; Alex, sorry for interfering.

The problem is that perform_implicit_conversion_flags in finish_static_assert
produces "implicit_conv_expr " where "c" is a PARM_DECL.  Subsequent
fold_non_dependent_expr is supposed to substitute that implicit_conv_expr but
doesn't because the expression is not is_nondependent_constant_expression --
a PARM_DECL is only considered a potentially constant expression if NOW is
false, which it isn't.  But the require_potential_rvalue_constant_expression
call that follows uses NOW = false.  So I think we need the following.

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

2018-03-01  Marek Polacek  

PR c++/84596
* constexpr.c (require_rvalue_constant_expression): New function.
* cp-tree.h: Declare it.
* semantics.c (finish_static_assert): Use it instead of
require_potential_rvalue_constant_expression.

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

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 4bbdbf43487..39e6cdfb33d 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -6047,7 +6047,8 @@ potential_rvalue_constant_expression (tree t)
 bool
 require_potential_constant_expression (tree t)
 {
-  return potential_constant_expression_1 (t, false, true, false, 
tf_warning_or_error);
+  return potential_constant_expression_1 (t, false, true, false,
+ tf_warning_or_error);
 }
 
 /* Cross product of the above.  */
@@ -6055,7 +6056,17 @@ require_potential_constant_expression (tree t)
 bool
 require_potential_rvalue_constant_expression (tree t)
 {
-  return potential_constant_expression_1 (t, true, true, false, 
tf_warning_or_error);
+  return potential_constant_expression_1 (t, true, true, false,
+ tf_warning_or_error);
+}
+
+/* Like above, but don't consider PARM_DECL a potential_constant_expression.  
*/
+
+bool
+require_rvalue_constant_expression (tree t)
+{
+  return potential_constant_expression_1 (t, true, true, true,
+ tf_warning_or_error);
 }
 
 /* Like potential_constant_expression, but don't consider possible constexpr
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 743dd340245..17d8c6d2650 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -7409,6 +7409,7 @@ extern bool is_static_init_expression(tree);
 extern bool potential_rvalue_constant_expression (tree);
 extern bool require_potential_constant_expression (tree);
 extern bool require_constant_expression (tree);
+extern bool require_rvalue_constant_expression (tree);
 extern bool require_potential_rvalue_constant_expression (tree);
 extern tree cxx_constant_value (tree, tree = NULL_TREE);
 extern tree cxx_constant_init  (tree, tree = NULL_TREE);
diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index 35569d0cb0d..87c5c669a55 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -8671,7 +8671,7 @@ finish_static_assert (tree condition, tree message, 
location_t location,
   else if (condition && condition != error_mark_node)
{
  error ("non-constant condition for static assertion");
-   

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Thu, Mar 1, 2018 at 9:41 AM, Jason Merrill  wrote:
> On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini  
> wrote:
>> On 28/02/2018 20:20, Jason Merrill wrote:
>>>
>>> Hmm, the test seems wrong; the diagnostic talks about specializing the
>>> arguments, but the actual test is checking whether the enclosing scope
>>> is fully specialized.  It looks like you'll give the same error for
>>>
>>> template 
>>> struct A {
>>>template 
>>>static const U u;
>>> };
>>>
>>> template 
>>> template 
>>> const U* A::u = nullptr;
>>>
>>> which does specialize the argument; since we accept
>>>
>>> template 
>>> struct A {
>>>template 
>>>struct B;
>>> };
>>>
>>> template 
>>> template 
>>> struct A::B { };
>>>
>>> we ought to accept the above as well.
>>>
>>> So, we could reject the testcase with this error, but we would need to
>>> test for it using the same check as in process_partial_specialization.
>>
>> I see. Doing that seems relatively easy - I have a draft which appears to
>> work - but then we have immediately to change the gcc_assert at the
>> beginning of determine_specialization to let such specializations through
>> (of course it still uses the wrong test!!).  I'm not sure about the best way
>> to do that... But that seems also doable.
>
> That test is correct for functions, I think we just want to restrict
> that block to functions.
>
>> The next problem is
>> duplicate_decls which apparently misses a bit of code to understand that the
>> new declaration does not conflict with the old one near line #1650... So,
>> frankly, I think that even with your great guidance I would need a few
>> iterations to get right the whole package and we are so damn close to the
>> release. What do you think? Do you want to take this over, or maybe you see
>> us restricting a bit what we'll have working in this area for 8.1.0?
>
> Yeah, I'll take it.

Ah, needed to fix the code in start_decl that checks for a variable
template specialization to consider that a specialization can be a
template.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1c44723705fb34f8b3ccc0493a2a79230bb5a7d9
Author: Jason Merrill 
Date:   Thu Mar 1 10:16:13 2018 -0500

PR c++/71569 - ICE with redundant args on member variable template.

* decl.c (start_decl): Handle partial specialization of member
variable template.
* pt.c (determine_specialization): Allow partial specialization
of member variable template without specializing enclosing class.
(process_partial_specialization): Improve error message.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f1be2292c59..db64d12c95a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5080,19 +5080,17 @@ start_decl (const cp_declarator *declarator,
  if (field == NULL_TREE
  || !(VAR_P (field) || variable_template_p (field)))
error ("%q+#D is not a static data member of %q#T", decl, context);
+ else if (variable_template_p (field)
+  && (DECL_LANG_SPECIFIC (decl)
+  && DECL_TEMPLATE_SPECIALIZATION (decl)))
+   /* OK, specialization was already checked.  */;
  else if (variable_template_p (field) && !this_tmpl)
{
- if (DECL_LANG_SPECIFIC (decl)
- && DECL_TEMPLATE_SPECIALIZATION (decl))
-   /* OK, specialization was already checked.  */;
- else
-   {
- error_at (DECL_SOURCE_LOCATION (decl),
-   "non-member-template declaration of %qD", decl);
- inform (DECL_SOURCE_LOCATION (field), "does not match "
- "member template declaration here");
- return error_mark_node;
-   }
+ error_at (DECL_SOURCE_LOCATION (decl),
+   "non-member-template declaration of %qD", decl);
+ inform (DECL_SOURCE_LOCATION (field), "does not match "
+ "member template declaration here");
+ return error_mark_node;
}
  else
{
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 73451195cd0..e07d77bb87e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2060,7 +2060,8 @@ determine_specialization (tree template_id,
   /* We shouldn't be specializing a member template of an
  unspecialized class template; we already gave an error in
  check_specialization_scope, now avoid crashing.  */
-  if (template_count && DECL_CLASS_SCOPE_P (decl)
+  if (!VAR_P (decl)
+  && template_count && DECL_CLASS_SCOPE_P (decl)
   && template_class_depth (DECL_CONTEXT (decl)) > 0)
 {
   gcc_assert (errorcount);
@@ -4840,10 +4841,13 @@ process_partial_specialization (tree decl)
 {
   if (!flag_concepts)
 error ("partial specialization %q+D does not specialize "
-  "any template arguments", decl);

Re: [Patch AArch64] Turn on frame pointer / partial fix for PR84521

[Richard Sandiford]

Ramana Radhakrishnan  writes:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the common
> parts of the code. This breaks an ABI decision that was made in GCC at
> the dawn of the port with respect to having a frame pointer at all
> times.  If we really want to turn this off lets have a discussion around
> that separately.
>
> For now turn this back on and I believe this will leave PR84521 latent
> again with -fomit-frame-pointer and (hopefully) make the ruby issue go
> away. I'm asking Sudi to pick that up.
>
> Bootstrapped and regression tested on AArch64-none-linux-gnu but I see
> one regression in gcc.c-torture/execute/960419-2.c which needs to be
> looked at next (PR84528, thanks Kyrill).
>
> Ok to put in and then look at PR84528 ?
>
> gcc/ChangeLog:
>
> 2018-02-23  Ramana Radhakrishnan  
>
> PR target/84521
>   * common/config/aarch64/aarch64-common.c
> (aarch_option_optimization_table[]): Switch
> off fomit-frame-pointer

If we're doing this, we might also want to change the default for
-momit-leaf-frame-pointer.  As things stand we'll create a frame
for things like:

  void f (void) { volatile int x = 1; }

but not use a frame pointer for it.

Thanks,
Richard

Re: [PATCH][AArch64][1/3] PR target/84164: Simplify subreg + redundant AND-immediate

[Kyrill Tkachov]

Ping.

Thanks,
Kyrill

On 19/02/18 11:35, Kyrill Tkachov wrote:

Ping.

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html

CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component that I'll 
need midend approval on.

Thanks everyone for your comments so far.
Kyrill

On 12/02/18 15:18, Kyrill Tkachov wrote:

Hi Richard,

On 08/02/18 20:29, Richard Sandiford wrote:

Thanks for doing this.

Kyrill  Tkachov  writes:

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 
2e7aa5c12952ab1a9b49b5adaf23710327e577d3..af06d7502cebac03cefc689b2646874b8397e767
 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -6474,6 +6474,18 @@ simplify_subreg (machine_mode outermode, rtx op,
return NULL_RTX;
  }
  +  /* Simplify (subreg:QI (and:SI (reg:SI) (const_int 0x)) 0)
+ into (subreg:QI (reg:SI) 0).  */
+  scalar_int_mode int_outermode, int_innermode;
+  if (!paradoxical_subreg_p (outermode, innermode)
+  && is_a  (outermode, _outermode)
+  && is_a  (innermode, _innermode)
+  && GET_CODE (op) == AND && CONST_INT_P (XEXP (op, 1))
+  && known_eq (subreg_lowpart_offset (outermode, innermode), byte)
+  && (~INTVAL (XEXP (op, 1)) & GET_MODE_MASK (int_outermode)) == 0
+  && validate_subreg (outermode, innermode, XEXP (op, 0), byte))
+return gen_rtx_SUBREG (outermode, XEXP (op, 0), byte);
+
/* A SUBREG resulting from a zero extension may fold to zero if
   it extracts higher bits that the ZERO_EXTEND's source bits.  */
if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode))

I think it'd be better to do this in simplify_truncation (shared
by the subreg code and the TRUNCATE code).  The return would then
be simplify_gen_unary (TRUNCATE, ...), which will become a subreg
if TRULY_NOOP_TRUNCATION.


Thanks, that does look cleaner.
Bootstrapped and tested on arm-none-linux-gnueabihf, aarch64-none-linux-gnu and 
x86_64-unknown-linux-gnu.
The other two patches are still needed to address the fallout.

Is this ok?

Thanks,
Kyrill

2018-02-12  Kyrylo Tkachov  

PR target/84164
* simplify-rtx.c (simplify_truncation): Simplify truncation of masking
operation.
* config/aarch64/aarch64.md (*aarch64_reg_3_neg_mask2):
Use simplify_gen_unary creating a SUBREG.
(*aarch64_reg_3_minus_mask): Likewise.
(*aarch64__reg_di3_mask2): Use const_int_operand predicate
for operand 3.

2018-02-12  Kyrylo Tkachov  

PR target/84164
* gcc.c-torture/compile/pr84164.c: New test.

Re: [C++ Patch/RFC] PR 71569 ("[6/7/8 regression] Crash: External definition of template member from template struct")

[Jason Merrill]

On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini  wrote:
> On 28/02/2018 20:20, Jason Merrill wrote:
>>
>> Hmm, the test seems wrong; the diagnostic talks about specializing the
>> arguments, but the actual test is checking whether the enclosing scope
>> is fully specialized.  It looks like you'll give the same error for
>>
>> template 
>> struct A {
>>template 
>>static const U u;
>> };
>>
>> template 
>> template 
>> const U* A::u = nullptr;
>>
>> which does specialize the argument; since we accept
>>
>> template 
>> struct A {
>>template 
>>struct B;
>> };
>>
>> template 
>> template 
>> struct A::B { };
>>
>> we ought to accept the above as well.
>>
>> So, we could reject the testcase with this error, but we would need to
>> test for it using the same check as in process_partial_specialization.
>
> I see. Doing that seems relatively easy - I have a draft which appears to
> work - but then we have immediately to change the gcc_assert at the
> beginning of determine_specialization to let such specializations through
> (of course it still uses the wrong test!!).  I'm not sure about the best way
> to do that... But that seems also doable.

That test is correct for functions, I think we just want to restrict
that block to functions.

> The next problem is
> duplicate_decls which apparently misses a bit of code to understand that the
> new declaration does not conflict with the old one near line #1650... So,
> frankly, I think that even with your great guidance I would need a few
> iterations to get right the whole package and we are so damn close to the
> release. What do you think? Do you want to take this over, or maybe you see
> us restricting a bit what we'll have working in this area for 8.1.0?

Yeah, I'll take it.

Jason

c-family PATCH to fix invalid shifting (PR c++/84639)

[Marek Polacek]

Here we were using pow2align as the right operand of <<.  But for invalid
alignments pow2align can be -1 which makes the shifting invalid.  Fixed by
moving the checking before using pow2align.

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

2018-03-01  Marek Polacek  

PR c++/84639
* c-attribs.c (common_handle_aligned_attribute): Don't use invalid
alignment in computation.

diff --git gcc/c-family/c-attribs.c gcc/c-family/c-attribs.c
index 0261a45ec98..3ebb2d6000c 100644
--- gcc/c-family/c-attribs.c
+++ gcc/c-family/c-attribs.c
@@ -1817,6 +1817,12 @@ common_handle_aligned_attribute (tree *node, tree name, 
tree args, int flags,
 
   /* Log2 of specified alignment.  */
   int pow2align = check_user_alignment (align_expr, true);
+  if (pow2align == -1
+  || !check_cxx_fundamental_alignment_constraints (*node, pow2align, 
flags))
+{
+  *no_add_attrs = true;
+  return NULL_TREE;
+}
 
   /* The alignment in bits corresponding to the specified alignment.  */
   unsigned bitalign = (1U << pow2align) * BITS_PER_UNIT;
@@ -1826,10 +1832,7 @@ common_handle_aligned_attribute (tree *node, tree name, 
tree args, int flags,
   unsigned curalign = 0;
   unsigned lastalign = 0;
 
-  if (pow2align == -1
-  || !check_cxx_fundamental_alignment_constraints (*node, pow2align, 
flags))
-*no_add_attrs = true;
-  else if (is_type)
+  if (is_type)
 {
   if ((flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
/* OK, modify the type in place.  */;

Marek

Re: [PATCH][AArch64] Remove aarch64_frame_pointer_required

[Richard Sandiford]

James Greenhalgh  writes:
> On Fri, Aug 04, 2017 at 01:41:22PM +0100, Wilco Dijkstra wrote:
>> To implement -fomit-leaf-frame-pointer, there are 2 places where we need
>> to check whether we have to use a frame chain (since register allocation
>> may allocate LR in a leaf function that omits the frame pointer, but if
>> LR is spilled we must emit a frame chain).  To simplify this do not force
>> frame_pointer_needed via aarch64_frame_pointer_required, but enable the
>> frame chain in aarch64_layout_frame.  Now aarch64_frame_pointer_required
>> can be removed and aarch64_can_eliminate is simplified.
>> 
>> OK for commit?
>
> I've thought about this for a while, I'm still not completely comfortable
> with the idea that we "lie" to the mid-end about the frame-pointer, and
> patch it up in the frame layout code, but I can see how we're moving from
> one lie which adds a ton of complexity, to a different lie which reduces
> complexity.
>
> It all still seems tenuous, but I think I understand the reasoning, and
> we've got a solid 6 months to figure out what breaks.

So this really is a few months later (sorry), but I'm not sure it's safe.
emit_frame_chain was introduced on the basis that:

The current frame code combines the separate concepts of a frame chain
(saving old FP,LR in a record and pointing new FP to it) and a frame
pointer used to access locals.

But there's the third question of whether the frame pointer is available
for general allocation.  By removing frame_pointer_required, we're saying
that the frame pointer is always available for general use.  This can be
forced with a crude test case like:

  void g (void);

  int
  f (void)
  {
register int x asm ("x29");
asm volatile ("mov %0, 1" : "=r" (x));
g ();
return 1;
  }

which at -O2 (with implicit -fno-omit-frame-pointer) generates:

f:
stp x29, x30, [sp, -16]!
mov x29, sp
#APP
// 7 "/tmp/foo.c" 1
mov x29, 1
// 0 "" 2
#NO_APP 
bl  g
mov w0, 1
ldp x29, x30, [sp], 16
ret

So we do initialise the frame pointer, but it's not reliable for
backtracing within g.  The same thing could happen in more realistic
functions with high register pressure.

(The above test would generate an error if frame_pointer_required
returned true.)

If we wanted to continue to use sp-based rather than fp-based
accesses with -fno-omit-frame-pointer where possible, we'd probably
need to do that in target-independent code rather than hide it in the
backend.

Thanks,
Richard

> OK (assuming this has been tested *recently* against aarch64-none-linux-gnu).
>
> Reviewed-By: James Greenhalgh 
>
> Thanks,
> James
>
>> 
>> ChangeLog:
>> 2017-08-03  Wilco Dijkstra  
>> 
>> gcc/
>>  * config/aarch64/aarch64.c (aarch64_frame_pointer_required)
>>  Remove.
>>  (aarch64_layout_frame): Initialise emit_frame_chain.
>>  (aarch64_can_eliminate): Remove omit leaf frame pointer code.
>>  (TARGET_FRAME_POINTER_REQUIRED): Remove define.

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Richard Biener]

On Thu, Mar 1, 2018 at 12:38 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
>>  wrote:
>>> GCC 6 and 7 would vectorise:
>>>
>>> void
>>> f (unsigned long incx, unsigned long incy,
>>>float *restrict dx, float *restrict dy)
>>> {
>>>   unsigned long ix = 0, iy = 0;
>>>   for (unsigned long i = 0; i < 512; ++i)
>>> {
>>>   dy[iy] += dx[ix];
>>>   ix += incx;
>>>   iy += incy;
>>> }
>>> }
>>>
>>> without first proving that incy is nonzero.  This is a regression from
>>> GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
>>> on whether incy is zero, but that's obviously too invasive to backport.
>>> This patch instead bails out for non-constant steps in the place that
>>> trunk would try a check for zeroness.
>>>
>>> I did wonder about trying to use range information to prove nonzeroness
>>> for SSA_NAMEs, but that would be entirely new code and didn't seem
>>> suitable for a release branch.
>>>
>>> Tested on aarch64-linux-gnu.  OK for GCC 7 and 6?  I'll add the testcase
>>> to trunk too.
>>
>> Given dist == 0 isn't it enough to test either DR_STEP (dra) or DR_STEP 
>> (drb)?
>> That seems what trunk is doing (just look at dr_zero_step_indicator of dra).
>> Even when not using range-info I think that using !
>> tree_expr_nonzero_p (DR_STEP (dra))
>> is more to the point of the issue we're fixing -- that also would catch
>> integer_zerop (DR_STEP (dra)) which trunk handles by failing as well but your
>> patch wouldn't so it looks like a more "complete" fix.
>
> OK.
>
>> Last but not least trunk and your patch guards all this by
>> !loop->force_vectorize.
>> But force_vectorize doesn't give any such guarantee that step isn't
>> zero so I wonder
>> why we deliberately choose to possibly miscompile stuff here?
>
> This was based on the pre-existing:
>
>   if (loop_vinfo && integer_zerop (step))
> {
>   GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) = NULL;
>   if (!nested_in_vect_loop_p (loop, stmt))
> return DR_IS_READ (dr);
>   /* Allow references with zero step for outer loops marked
>  with pragma omp simd only - it guarantees absence of
>  loop-carried dependencies between inner loop iterations.  */
>   if (!loop->force_vectorize)
> {
>   if (dump_enabled_p ())
> dump_printf_loc (MSG_NOTE, vect_location,
>  "zero step in inner loop of nest\n");
>   return false;
> }
> }
>
> AIUI #pragma omp simd really does guarantee that iterations of
> the loop can be executed concurrently (up to the limit given by
> safelen if present).  So something like:
>
>   #pragma omp simd
>   for (int i = 0; i < n; ++i)
> a[i * step] += 1;
>
> would be incorrect for step==0.  (#pragma ordered simd forces
> things to be executed in order where necessary.)

But then we should check safelen, not force_vectorize...

Richard.

> Thanks,
> Richard
>
>> Thus I'd like to see a simpler
>>
>> + if (! tree_expr_nonzero_p (DR_STEP (dra)))
>> +   {
>> + if (dump_enabled_p ())
>> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>> +"step could be zero.\n");
>> + return true;
>> +   }
>>
>> if you think that works out and also the force_vectorize guard removed from 
>> the
>> trunk version.
>>
>> OK with that change.
>>
>> Thanks,
>> Richard.
>>
>>> Richard
>>>
>>>
>>> 2018-02-28  Richard Sandiford  
>>>
>>> gcc/
>>> PR tree-optimization/84485
>>> * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
>>> true for zero dependence distances if either step is variable, and 
>>> if
>>> there is no metadata that guarantees correctness.
>>>
>>> gcc/testsuite/
>>> PR tree-optimization/84485
>>> * gcc.dg/vect/pr84485.c: New test.
>>>
>>> Index: gcc/tree-vect-data-refs.c
>>> ===
>>> --- gcc/tree-vect-data-refs.c   2017-07-27 18:08:43.779978373 +0100
>>> +++ gcc/tree-vect-data-refs.c   2018-02-28 14:16:36.621113244 +
>>> @@ -394,6 +394,16 @@ vect_analyze_data_ref_dependence (struct
>>> }
>>> }
>>>
>>> + if (!loop->force_vectorize
>>> + && (TREE_CODE (DR_STEP (dra)) != INTEGER_CST
>>> + || TREE_CODE (DR_STEP (drb)) != INTEGER_CST))
>>> +   {
>>> + if (dump_enabled_p ())
>>> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>>> +"step could be zero.\n");
>>> + return true;
>>> +   }
>>> +
>>>   continue;
>>> }
>>>
>>> Index: gcc/testsuite/gcc.dg/vect/pr84485.c
>>> 

[PATCH] Fix PR84427, PRE ANTIC iteration (again)

[Richard Biener]

This fixes another testcase that shows that our ANTIC iteration can
fail to converge.  The fix continues what we did with previous fixes,
avoid spuriously removing stuff from the expression side of the sets.
This time going full-in and allowing multiple expressions for the
same value in the sets.  I've added verification that the value-sets
never grow during iteration which barfed on some of the related
existing testcases and thus helped finishing this and fixing all
places where we end up somewhat randomly choosing one or another
expression to drop.

I've verified with a GIMPLE testcase that if at insertion time
we have multiple partially redundant expressions for the same value
we insert/hoist it only once.  So the only "bad" effect of the
patch is that the expression part of the ANTIC sets grows -- by
not throwing away random stuff we might also arrive at larger
(value) solutions for ANTIC which means we may catch previously
missed optimizations (or pessimizations as you know PRE...).

I'm not entirely happy with the timing but I'm quite confident in
the approach also (again) having heavily discussed this with Micha.

Re-boostrap and regtest running on x86_64-unknown-linux-gnu.

I managed to go into a different solution at the beginning asking
for that pred/phiblock->edge cleanup and decided to leave that in...

The new verification is guarded with flag_checking so if it would
trigger but wouldn't result in not converging a release build
should be not affected.

Richard.

2018-01-03  Richard Biener  

PR tree-optimization/84427
* tree-ssa-pre.c (bitmap_remove_expr_from_set): Remove.
(bitmap_set_subtract_values): Rewrite to handle multiple
exprs per value.
(clean): Likewise.
(prune_clobbered_mems): Likewise.
(phi_translate): Take edge instead of pred/phiblock.
(phi_translate_1): Likewise.
(phi_translate_set): Likewise.  Insert all translated
exprs for a value into the set, keeping possibly multiple
expressions per value.
(compute_antic_aux): Adjust for phi_translate changes.
When intersecting union the expressions and prune those
not in the final value set, keeping possibly multiple
expressions per value.  Do not use value-insertion
for unioning ANTIC_OUT U EXP_GEN - TMP_GEN but merge
all expressions.  Add verification that the value-sets
only shrink during iteration.
(compute_partial_antic_aux): Adjust for the phi_translate changes.
(do_pre_regular_insertion): Likewise.
(do_pre_partial_partial_insertion): Likewise.

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

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 258097)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -696,16 +696,6 @@ sccvn_valnum_from_value_id (unsigned int
   return NULL_TREE;
 }
 
-/* Remove an expression EXPR from a bitmapped set.  */
-
-static void
-bitmap_remove_expr_from_set (bitmap_set_t set, pre_expr expr)
-{
-  unsigned int val  = get_expr_value_id (expr);
-  bitmap_clear_bit (>values, val);
-  bitmap_clear_bit (>expressions, get_expression_id (expr));
-}
-
 /* Insert an expression EXPR into a bitmapped set.  */
 
 static void
@@ -805,20 +795,21 @@ bitmap_set_subtract_values (bitmap_set_t
 {
   unsigned int i;
   bitmap_iterator bi;
-  pre_expr to_remove = NULL;
+  unsigned to_remove = -1U;
+  bitmap_and_compl_into (>values, >values);
   FOR_EACH_EXPR_ID_IN_SET (a, i, bi)
 {
-  if (to_remove)
+  if (to_remove != -1U)
{
- bitmap_remove_expr_from_set (a, to_remove);
- to_remove = NULL;
+ bitmap_clear_bit (>expressions, to_remove);
+ to_remove = -1U;
}
   pre_expr expr = expression_for_id (i);
-  if (bitmap_bit_p (>values, get_expr_value_id (expr)))
-   to_remove = expr;
+  if (! bitmap_bit_p (>values, get_expr_value_id (expr)))
+   to_remove = i;
 }
-  if (to_remove)
-bitmap_remove_expr_from_set (a, to_remove);
+  if (to_remove != -1U)
+bitmap_clear_bit (>expressions, to_remove);
 }
 
 
@@ -1335,17 +1326,17 @@ get_representative_for (const pre_expr e
 
 
 static pre_expr
-phi_translate (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2,
-  basic_block pred, basic_block phiblock);
+phi_translate (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e);
 
 /* Translate EXPR using phis in PHIBLOCK, so that it has the values of
the phis in PRED.  Return NULL if we can't find a leader for each part
of the translated expression.  */
 
 static pre_expr
-phi_translate_1 (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2,
-basic_block pred, basic_block phiblock)
+phi_translate_1 (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e)
 {
+  basic_block pred = e->src;
+  basic_block phiblock = e->dest;
   switch (expr->kind)
 {
 

Re: [PATCH] Do not handled volatile arguments (PR sanitizer/82484).

[Jakub Jelinek]

On Thu, Mar 01, 2018 at 12:37:51PM +0100, Martin Liška wrote:
> Hi.
> 
> This is a bit forgotten patch. It handles volatile arguments, which should
> not be attempted copied into a function local variable.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready to be installed?
> Martin
> 
> gcc/ChangeLog:
> 
> 2017-10-11  Martin Liska  
> 
>   PR sanitizer/82484
>   * sanopt.c (sanitize_rewrite_addressable_params): Do not handle
>   volatile arguments.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-10-11  Martin Liska  
> 
>   PR sanitizer/82484
>   * gcc.dg/asan/pr82484.c: New test.

Ok, thanks.

Jakub

[Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Paul Richard Thomas]

Committed as 'obvious' in revision 258098.

Paul

2018-03-01  Paul Thomas  

PR fortran/84219
* target-memory.c (gfc_interpret_derived): Assert that BT_VOID
components are caf tokens.
(gfc_target_interpret_expr): Treat BT_VOID expressions as
integers.

2018-03-01  Paul Thomas  

PR fortran/84219
* gfortran.dg/coarray_47.f90: New test.

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Marek Polacek]

On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek  wrote:
> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek  wrote:
> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
> >> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
> >> >> > My recent change introducing cxx_constant_init caused this code
> >> >> >
> >> >> > template  class A {
> >> >> >static const long b = 0;
> >> >> >static const unsigned c = (b);
> >> >> > };
> >> >> >
> >> >> > to be rejected.  The reason is that force_paren_expr turns "b" into 
> >> >> > "*(const
> >> >> > long int &) ", where the former is not value-dependent but the 
> >> >> > latter is
> >> >> > value-dependent.  So when we get to maybe_constant_init_1:
> >> >> > 5147   if (!is_nondependent_static_init_expression (t))
> >> >> > 5148 /* Don't try to evaluate it.  */;
> >> >> > it's not evaluated and we get the non-constant initialization error.
> >> >> > (Before we'd always evaluated the expression.)
> >> >> >
> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >> >> >
> >> >> > 2018-02-27  Marek Polacek  
> >> >> >
> >> >> > PR c++/84582
> >> >> > * semantics.c (force_paren_expr): Avoid creating a static cast
> >> >> > when processing a template.
> >> >> >
> >> >> > * g++.dg/cpp1z/static1.C: New test.
> >> >> > * g++.dg/template/static37.C: New test.
> >> >> >
> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> >> >> > index 35569d0cb0d..b48de2df4e2 100644
> >> >> > --- gcc/cp/semantics.c
> >> >> > +++ gcc/cp/semantics.c
> >> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> >> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> >> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> >> >> >   /* We can't bind a hard register variable to a reference.  */;
> >> >> > -  else
> >> >> > +  else if (!processing_template_decl)
> >> >>
> >> >> Hmm, this means that we forget about the parentheses in a template.  I'm
> >> >> surprised that this didn't break anything in the testsuite.  In 
> >> >> particular,
> >> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to catch this 
> >> >> issue.
> >> >
> >> > Thanks, you're right.  I'll use it.
> >> >
> >> >> Can we use PAREN_EXPR instead of the static_cast in a template?
> >> >
> >> > I don't think so, it would fix the issue you pointed out in auto-fn15.C 
> >> > but
> >> > it wouldn't fix the original test.  The problem with using PAREN_EXPR in 
> >> > a
> >> > template is that instantiate_non_dependent_expr will turn in into the
> >> > static cast anyway; tsubst_copy_and_build has
> >> > case PAREN_EXPR:
> >> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0;
> >> > so it calls force_paren_expr and this time we're not in a template.  And
> >> > then when calling cxx_constant_init we have the same issue.
> >>
> >> Then maybe we need something like fold_non_dependent_expr, which
> >> checks for dependency before substitution and then immediately
> >> evaluates the result.
> >
> > I hope you meant something like this.  Further testing also revealed that
> > maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR (so that
> > (fn1)(); in paren2.C is handled correctly), and that lvalue_kind should look
> > into PAREN_EXPR so as to give the correct answer regarding lvalueness: we
> > should accept
> >
> > template
> > void foo (int i)
> > {
> >   ++(i);
> > }
> >
> > Apologies if I'm on the wrong track.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2018-02-28  Marek Polacek  
> > Jason Merrill  
> >
> > PR c++/84582
> > * semantics.c (force_paren_expr): Avoid creating the static cast
> > when in a template.  Create a PAREN_EXPR when in a template.
> > (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
> > * typeck2.c (store_init_value): Call fold_non_dependent_expr instead
> > of instantiate_non_dependent_expr.
> > * tree.c (lvalue_kind): Handle PAREN_EXPR like NON_DEPENDENT_EXPR.
> >
> > * g++.dg/cpp1y/auto-fn15.C: Extend testing.
> > * g++.dg/cpp1z/static1.C: New test.
> > * g++.dg/template/static37.C: New test.
> >
> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> > index 35569d0cb0d..722e3718a14 100644
> > --- gcc/cp/semantics.c
> > +++ gcc/cp/semantics.c
> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
> >  expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
> >else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
> >  /* We can't bind a hard register variable to a reference.  */;
> > -  else
> > +  else if (!processing_template_decl)
> >  {
> >cp_lvalue_kind kind = lvalue_kind (expr);
> >if ((kind & 

Re: [PATCH,MIPS,committed] Fix wrong use of XINT instead of INTVAL

[Maciej W. Rozycki]

Hi Matthew,

> This issue was caught with assert checking enabled but is not a
> functional bug as XINT(x, 0) happens to overlay INTVAL(x) anyway.

 There's an intriguing difference between XINT (x, 0) and XWINT (x, 0) 
involved here though, which does not appear to be documented in the 
manual, and certainly not in Section 13.3 "Access to Operands" where I'd 
expect it.  I gather it is a matter of the operand being treated as `int' 
vs HOST_WIDE_INT, and that is where the assertion comes from, as these 
data types will necessarily be different for most hosts and cause an issue 
here right away if the host is big-endian.

 Thanks for catching and fixing this!

  Maciej

[PATCH] Fix ICE caused by a missing check for DECL_LANG_SPECIFIC

[Matthew Fortune]

Hi,

It seems we have had a bug for some time that causes an ICE and prevents the
MIPS16 library builds from completing but is likely unrelated to MIPS16.
The problem is when we call target_reinit and library functions get created
as shown in the call stack at the end of this message. The first builtin
that triggers the problem happens to be one of the MIPS16 helpers but I
don't think there is anything unique about it. The issue appeared after some
refactoring work in r253600 where code testing DECL_CLASS_SCOPE_P and
DECL_FRIEND_P was previously guarded by a check for DECL_LANG_SPECIFIC but
not after.

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html

I don’t know if this is the correct solution or whether we need to change the
way builtins are initialised in the MIPS backend but I suspect this fix
is the right way to go.

Cc: Jason as author of the original change.

Thanks,
Matthew

gcc/cp/
* pt.c (type_dependent_expression_p): Add missing check for
DECL_LANG_SPECIFIC.
---
 gcc/cp/pt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7345119..c88304f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24635,6 +24635,7 @@ type_dependent_expression_p (tree expression)
  type-dependent.  Checking this is important for functions with auto return
  type, which looks like a dependent type.  */
   if (TREE_CODE (expression) == FUNCTION_DECL
+  && DECL_LANG_SPECIFIC (expression)
   && !(DECL_CLASS_SCOPE_P (expression)
   && dependent_type_p (DECL_CONTEXT (expression)))
   && !(DECL_FRIEND_P (expression)
-- 
2.2.1


...v3/include/bits/cpp_type_traits.h:408:32: internal compiler error: 
Segmentation fault
 __miter_base(_Iterator __it)
^
0xd77fff crash_signal
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/toplev.c:326
0xd77fff crash_signal
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/toplev.c:326
0x74aeb9 type_dependent_expression_p(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/pt.c:24293
0x6cda47 mangle_decl_string
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3740
0x6cdca8 get_mangled_id
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3782
0x6cdf50 mangle_decl(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3820
0x74aeb9 type_dependent_expression_p(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/pt.c:24293
0x6cda47 mangle_decl_string
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3740
0x6cdca8 get_mangled_id
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3782
0x6cdf50 mangle_decl(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/cp/mangle.c:3820
0x105af90 decl_assembler_name(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/tree.c:673
0xc7d1e8 build_libfunc_function(char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:736
0xc7d717 init_one_libfunc(char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:766
0xc7d79a set_optab_libfunc(optab_tag, machine_mode, char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:804
0x105af90 decl_assembler_name(tree_node*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/tree.c:673
0xc7d1e8 build_libfunc_function(char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:736
0xc7d717 init_one_libfunc(char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:766
0xc7d79a set_optab_libfunc(optab_tag, machine_mode, char const*)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/optabs-libfuncs.c:804
0x10d49bb mips_init_libfuncs

/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/config/mips/mips.c:13425
0xd7836c lang_dependent_init_target
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/toplev.c:1758
0xd7941c target_reinit()
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/toplev.c:1880
0x13e6f55 save_target_globals()
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/target-globals.c:86
0x10e0124 mips_set_compression_mode

/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/config/mips/mips.c:19518
0xa7ee1b invoke_set_current_function_hook
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/function.c:4783
0xa88aa7 invoke_set_current_function_hook
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/function.c:4918
0xa88aa7 allocate_struct_function(tree_node*, bool)
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/function.c:4893
0x10d49bb mips_init_libfuncs

/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/config/mips/mips.c:13425
0xd7836c lang_dependent_init_target
/scratch/mpf/overtest/64126/240294/shared/gcc/gcc/toplev.c:1758
0xd7941c target_reinit()

Re: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

[Martin Liška]

On 03/01/2018 12:45 PM, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
>> I've been running periodically UBSAN bootstrap and as the runtime errors are
>> not causing failure of compiler I haven't noticed the errors.
>> Thus I would like to disable UBSAN recovery. Apart from that I'm handling
>> issue in md5.c where in UBSAN bootstrap we want to do proper pointer 
>> alignment.
>> Doing that 2 will be remaining issues that will block the bootstrap:
>>
>> PR84634 and PR84635
>>
>> May I then install the patch? Jakub what do you think about it?
> 
> I actually prefer recovery where possible, that way we can get more runtime
> errors at once, rather than stopping at the first one.
> You always can and should grep the build logs.

Ok, you convinced me with Marek :)

> 
> As for md5.c, you only posted ChangeLog for it, not the actual patch.

Sorry, I'm attaching updated patch.

Martin

> 
>   Jakub
> 

>From ccf9285022df7a2c11c14e5dc388d668d18243eb Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 1 Mar 2018 12:13:34 +0100
Subject: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

config/ChangeLog:

2018-03-01  Martin Liska  

	PR bootstrap/64914
	* bootstrap-ubsan.mk: Define UBSAN_BOOTSTRAP.

libiberty/ChangeLog:

2018-03-01  Martin Liska  

	PR bootstrap/64914
	* md5.c: Use strict alignment with UBSAN_BOOTSTRAP.
---
 config/bootstrap-ubsan.mk | 6 +++---
 libiberty/md5.c   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/config/bootstrap-ubsan.mk b/config/bootstrap-ubsan.mk
index d2615e8f807..1d85fe1c836 100644
--- a/config/bootstrap-ubsan.mk
+++ b/config/bootstrap-ubsan.mk
@@ -1,8 +1,8 @@
 # This option enables -fsanitize=undefined for stage2 and stage3.
 
-STAGE2_CFLAGS += -fsanitize=undefined
-STAGE3_CFLAGS += -fsanitize=undefined
-POSTSTAGE1_LDFLAGS += -fsanitize=undefined -static-libubsan \
+STAGE2_CFLAGS += -fsanitize=undefined -DUBSAN_BOOTSTRAP
+STAGE3_CFLAGS += -fsanitize=undefined -DUBSAN_BOOTSTRAP
+POSTSTAGE1_LDFLAGS += -fsanitize=undefined -static-libubsan -DUBSAN_BOOTSTRAP \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/ \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/.libs
diff --git a/libiberty/md5.c b/libiberty/md5.c
index f106d2262ca..4dd5186a69a 100644
--- a/libiberty/md5.c
+++ b/libiberty/md5.c
@@ -231,7 +231,7 @@ md5_process_bytes (const void *buffer, size_t len, struct md5_ctx *ctx)
   /* Process available complete blocks.  */
   if (len > 64)
 {
-#if !_STRING_ARCH_unaligned
+#if !_STRING_ARCH_unaligned || defined UBSAN_BOOTSTRAP
 /* To check alignment gcc has an appropriate operator.  Other
compilers don't.  */
 # if __GNUC__ >= 2
-- 
2.16.1

Re: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

[Marek Polacek]

On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
> Hi.
> 
> I've been running periodically UBSAN bootstrap and as the runtime errors are
> not causing failure of compiler I haven't noticed the errors.
> Thus I would like to disable UBSAN recovery. Apart from that I'm handling

Uh, I don't like that at all, isn't it better to just grep for "runtime errors"
after the bootstrap has run?

Marek

Re: [PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

[Jakub Jelinek]

On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
> I've been running periodically UBSAN bootstrap and as the runtime errors are
> not causing failure of compiler I haven't noticed the errors.
> Thus I would like to disable UBSAN recovery. Apart from that I'm handling
> issue in md5.c where in UBSAN bootstrap we want to do proper pointer 
> alignment.
> Doing that 2 will be remaining issues that will block the bootstrap:
> 
> PR84634 and PR84635
> 
> May I then install the patch? Jakub what do you think about it?

I actually prefer recovery where possible, that way we can get more runtime
errors at once, rather than stopping at the first one.
You always can and should grep the build logs.

As for md5.c, you only posted ChangeLog for it, not the actual patch.

Jakub

[PATCH] Improve boostrap-ubsan config (PR bootstrap/64914).

[Martin Liška]

Hi.

I've been running periodically UBSAN bootstrap and as the runtime errors are
not causing failure of compiler I haven't noticed the errors.
Thus I would like to disable UBSAN recovery. Apart from that I'm handling
issue in md5.c where in UBSAN bootstrap we want to do proper pointer alignment.
Doing that 2 will be remaining issues that will block the bootstrap:

PR84634 and PR84635

May I then install the patch? Jakub what do you think about it?

Thanks,
Martin

config/ChangeLog:

2018-03-01  Martin Liska  

PR bootstrap/64914
* bootstrap-ubsan.mk: Define UBSAN_BOOTSTRAP macro and disable
recovery mode.

libiberty/ChangeLog:

2018-03-01  Martin Liska  

PR bootstrap/64914
* md5.c: Use strict alignment with UBSAN_BOOTSTRAP.
---
 config/bootstrap-ubsan.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/config/bootstrap-ubsan.mk b/config/bootstrap-ubsan.mk
index d2615e8f807..13bb2000bd5 100644
--- a/config/bootstrap-ubsan.mk
+++ b/config/bootstrap-ubsan.mk
@@ -1,8 +1,8 @@
 # This option enables -fsanitize=undefined for stage2 and stage3.
 
-STAGE2_CFLAGS += -fsanitize=undefined
-STAGE3_CFLAGS += -fsanitize=undefined
-POSTSTAGE1_LDFLAGS += -fsanitize=undefined -static-libubsan \
+STAGE2_CFLAGS += -fsanitize=undefined -fno-sanitize-recover=undefined -DUBSAN_BOOTSTRAP
+STAGE3_CFLAGS += -fsanitize=undefined -fno-sanitize-recover=undefined -DUBSAN_BOOTSTRAP
+POSTSTAGE1_LDFLAGS += -fsanitize=undefined -fno-sanitize-recover=undefined -static-libubsan -DUBSAN_BOOTSTRAP \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/ \
 		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ubsan/.libs

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Richard Sandiford]

Richard Biener  writes:
> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
>  wrote:
>> GCC 6 and 7 would vectorise:
>>
>> void
>> f (unsigned long incx, unsigned long incy,
>>float *restrict dx, float *restrict dy)
>> {
>>   unsigned long ix = 0, iy = 0;
>>   for (unsigned long i = 0; i < 512; ++i)
>> {
>>   dy[iy] += dx[ix];
>>   ix += incx;
>>   iy += incy;
>> }
>> }
>>
>> without first proving that incy is nonzero.  This is a regression from
>> GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
>> on whether incy is zero, but that's obviously too invasive to backport.
>> This patch instead bails out for non-constant steps in the place that
>> trunk would try a check for zeroness.
>>
>> I did wonder about trying to use range information to prove nonzeroness
>> for SSA_NAMEs, but that would be entirely new code and didn't seem
>> suitable for a release branch.
>>
>> Tested on aarch64-linux-gnu.  OK for GCC 7 and 6?  I'll add the testcase
>> to trunk too.
>
> Given dist == 0 isn't it enough to test either DR_STEP (dra) or DR_STEP (drb)?
> That seems what trunk is doing (just look at dr_zero_step_indicator of dra).
> Even when not using range-info I think that using !
> tree_expr_nonzero_p (DR_STEP (dra))
> is more to the point of the issue we're fixing -- that also would catch
> integer_zerop (DR_STEP (dra)) which trunk handles by failing as well but your
> patch wouldn't so it looks like a more "complete" fix.

OK.

> Last but not least trunk and your patch guards all this by
> !loop->force_vectorize.
> But force_vectorize doesn't give any such guarantee that step isn't
> zero so I wonder
> why we deliberately choose to possibly miscompile stuff here?

This was based on the pre-existing:

  if (loop_vinfo && integer_zerop (step))
{
  GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) = NULL;
  if (!nested_in_vect_loop_p (loop, stmt))
return DR_IS_READ (dr);
  /* Allow references with zero step for outer loops marked
 with pragma omp simd only - it guarantees absence of
 loop-carried dependencies between inner loop iterations.  */
  if (!loop->force_vectorize)
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
 "zero step in inner loop of nest\n");
  return false;
}
}

AIUI #pragma omp simd really does guarantee that iterations of
the loop can be executed concurrently (up to the limit given by
safelen if present).  So something like:

  #pragma omp simd
  for (int i = 0; i < n; ++i)
a[i * step] += 1;

would be incorrect for step==0.  (#pragma ordered simd forces
things to be executed in order where necessary.)

Thanks,
Richard

> Thus I'd like to see a simpler
>
> + if (! tree_expr_nonzero_p (DR_STEP (dra)))
> +   {
> + if (dump_enabled_p ())
> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +"step could be zero.\n");
> + return true;
> +   }
>
> if you think that works out and also the force_vectorize guard removed from 
> the
> trunk version.
>
> OK with that change.
>
> Thanks,
> Richard.
>
>> Richard
>>
>>
>> 2018-02-28  Richard Sandiford  
>>
>> gcc/
>> PR tree-optimization/84485
>> * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
>> true for zero dependence distances if either step is variable, and if
>> there is no metadata that guarantees correctness.
>>
>> gcc/testsuite/
>> PR tree-optimization/84485
>> * gcc.dg/vect/pr84485.c: New test.
>>
>> Index: gcc/tree-vect-data-refs.c
>> ===
>> --- gcc/tree-vect-data-refs.c   2017-07-27 18:08:43.779978373 +0100
>> +++ gcc/tree-vect-data-refs.c   2018-02-28 14:16:36.621113244 +
>> @@ -394,6 +394,16 @@ vect_analyze_data_ref_dependence (struct
>> }
>> }
>>
>> + if (!loop->force_vectorize
>> + && (TREE_CODE (DR_STEP (dra)) != INTEGER_CST
>> + || TREE_CODE (DR_STEP (drb)) != INTEGER_CST))
>> +   {
>> + if (dump_enabled_p ())
>> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>> +"step could be zero.\n");
>> + return true;
>> +   }
>> +
>>   continue;
>> }
>>
>> Index: gcc/testsuite/gcc.dg/vect/pr84485.c
>> ===
>> --- /dev/null   2018-02-26 10:26:41.624847060 +
>> +++ gcc/testsuite/gcc.dg/vect/pr84485.c 2018-02-28 14:16:36.620112862 +
>> @@ -0,0 +1,34 @@
>> +/* { dg-do run } */
>> +
>> +#include "tree-vect.h"
>> +
>> +#define N 256
>> +
>> +void __attribute__ ((noinline, noclone))
>> +f (unsigned long incx, 

[PATCH,MIPS,committed] Fix wrong use of XINT instead of INTVAL

[Matthew Fortune]

Hi,

This issue was caught with assert checking enabled but is not a
functional bug as XINT(x, 0) happens to overlay INTVAL(x) anyway.

Committed to trunk.

Thanks,
Matthew

gcc/
* config/mips/mips.c (mips_final_prescan_insn): Fix incorrect
XINT with INTVAL.
(mips_final_postscan_insn): Likewise.
---
 gcc/config/mips/mips.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 00cece2..aabd4b1 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -20426,7 +20426,7 @@ mips_final_prescan_insn (rtx_insn *insn, rtx *opvec,
int noperands)
   && GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE
   && XINT (PATTERN (insn), 1) == UNSPEC_CONSTTABLE)
 mips_set_text_contents_type (asm_out_file, "__pool_",
-XINT (XVECEXP (PATTERN (insn), 0, 0), 0),
+INTVAL (XVECEXP (PATTERN (insn), 0, 0)),
 FALSE);
 
   if (mips_need_noat_wrapper_p (insn, opvec, noperands))
@@ -20450,7 +20450,7 @@ mips_final_postscan_insn (FILE *file
ATTRIBUTE_UNUSED, rtx_insn *insn,
   && GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE
   && XINT (PATTERN (insn), 1) == UNSPEC_CONSTTABLE_END)
 mips_set_text_contents_type (asm_out_file, "__pend_",
-XINT (XVECEXP (PATTERN (insn), 0, 0), 0),
+INTVAL (XVECEXP (PATTERN (insn), 0, 0)),
 TRUE);
 }
 
-- 
2.2.1

[PATCH] Do not handled volatile arguments (PR sanitizer/82484).

[Martin Liška]

Hi.

This is a bit forgotten patch. It handles volatile arguments, which should
not be attempted copied into a function local variable.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin

gcc/ChangeLog:

2017-10-11  Martin Liska  

PR sanitizer/82484
* sanopt.c (sanitize_rewrite_addressable_params): Do not handle
volatile arguments.

gcc/testsuite/ChangeLog:

2017-10-11  Martin Liska  

PR sanitizer/82484
* gcc.dg/asan/pr82484.c: New test.
---
 gcc/sanopt.c| 4 +++-
 gcc/testsuite/gcc.dg/asan/pr82484.c | 5 +
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/asan/pr82484.c


diff --git a/gcc/sanopt.c b/gcc/sanopt.c
index cd94638c869..43743130a35 100644
--- a/gcc/sanopt.c
+++ b/gcc/sanopt.c
@@ -1143,7 +1143,9 @@ sanitize_rewrite_addressable_params (function *fun)
arg; arg = DECL_CHAIN (arg))
 {
   tree type = TREE_TYPE (arg);
-  if (TREE_ADDRESSABLE (arg) && !TREE_ADDRESSABLE (type)
+  if (TREE_ADDRESSABLE (arg)
+	  && !TREE_ADDRESSABLE (type)
+	  && !TREE_THIS_VOLATILE (arg)
 	  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
 	{
 	  TREE_ADDRESSABLE (arg) = 0;
diff --git a/gcc/testsuite/gcc.dg/asan/pr82484.c b/gcc/testsuite/gcc.dg/asan/pr82484.c
new file mode 100644
index 000..f8051bd300c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr82484.c
@@ -0,0 +1,5 @@
+/* PR sanitizer/82484 */
+/* { dg-do compile } */
+
+void foo(volatile int *ptr);
+void a (volatile int b) { foo(); }

[PATCH] Fix PR84645, -flto -g0 vs. -g issue

[Richard Biener]

The following fixes an ICE that occurs when with -flto you disable
debug at compile-time but enable it at link-time.  Then we end up
adding a second DW_AT_type to VLA DIEs - the following guards against
this.

Bootstrap and regtest running on x86_64-unknown-linux-gnu, testing in
progress.

Darwin support might be the vehicle exercising this -g0 vs. -g
combination a lot...

Richard.

2018-03-01  Richard Biener  

PR debug/84645
* dwarf2out.c (gen_variable_die): Properly handle late VLA
type annotation with LTO when debug was disabled at compile-time.

* gfortran.dg/lto/pr84645_0.f90: New testcase.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 258097)
+++ gcc/dwarf2out.c (working copy)
@@ -23527,10 +23527,12 @@ gen_variable_die (tree decl, tree origin
 
  /* ???  In LTRANS we cannot annotate early created variably
 modified type DIEs without copying them and adjusting all
-references to them.  Thus we dumped them again, also add a
-reference to them.  */
+references to them.  Thus we dumped them again.  Also add a
+reference to them but beware of -g0 compile and -g link
+in which case the reference will be already present.  */
  tree type = TREE_TYPE (decl_or_origin);
  if (in_lto_p
+ && ! get_AT (var_die, DW_AT_type)
  && variably_modified_type_p
   (type, decl_function_context (decl_or_origin)))
{
Index: gcc/testsuite/gfortran.dg/lto/pr84645_0.f90
===
--- gcc/testsuite/gfortran.dg/lto/pr84645_0.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/lto/pr84645_0.f90 (working copy)
@@ -0,0 +1,17 @@
+! { dg-lto-do link }
+! { dg-lto-options { { -flto -g0 } } }
+! { dg-extra-ld-options { -g } }
+program nml_test
+  implicit none
+  type t
+integer :: c1
+integer :: c2(3)
+  end type t
+  call test2(2) 
+contains
+  subroutine test2(n)
+integer :: n
+type(t) :: x12(n)
+namelist /nml2/ x12
+  end subroutine test2
+end program nml_test

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Richard Biener]

On Wed, Feb 28, 2018 at 6:35 PM, Jeff Law  wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law  wrote:
> [ ... snip ...]
>>>
>>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>>> we're building in presence of setjmp/longjmp were slightly inaccurate.
>>>
>>> In particular, a longjmp returns to the point immediately after the
>>> setjmp, not to the setjmp itself.  But our CFG building has the edge
>>> from the abnormal dispatcher going to the block containing the setjmp call.
>>
>> Yeah...  for SJLJ EH we get this right via __builtin_setjmp_receiver.
> Right.
>
> And as you noted in a follow-up we don't carry these abnormal edges from
> gimple to RTL.  As a result they are both inaccurate, but in subtly
> different ways.  I'd like to fix that wart, but probably not during this
> cycle.

Heh, keep pushing that back as well.  As you explained in the other mail
"perserving" the edges isn't so easy but that's still what we eventually
should do (because we can't really re-create them in the same optimistic
way we could at the beginning).  Maybe we can keep them and just
have a sweep "redirecting" those we kept to/from appropriate places.

> [ Another snip ]
>
>>> It's actually pretty easy to fix the CFG.  We  just need to recognize
>>> that a "returns twice" function returns not to the call, but to the
>>> point immediately after the call.  So if we have a call to a returns
>>> twice function that ends a block with a single successor, when we wire
>>> up the abnormal dispatcher, we target the single successor rather than
>>> the block containing the returns-twice call.
>>
>> Hmm, I think you need to check whether the successor has a single
>> predecessor, not whether we have a single successor (we always have
>> that unless setjmp also throws).  If you fix that you keep the CFG
>> "incorrect" if there are multiple predecessors so I think in addition
>> to properly creating the edges you have to work on the BB building
>> part to ensure that there's a single-predecessor block after
>> returns-twice function calls.  Note that currently we force returns-twice
>> to be the first (and only) stmt of a block -- your fix would relax this,
>> returns-twice no longer needs to start a new BB.
> The single successor test was strictly my paranoia WRT abnormal/EH edges.
>
> I don't immediately see why the CFG would be incorrect if the successor
> of the setjmp block has multiple preds.  But maybe it's something
> downstream that I'm not familiar with -- my worry all along with this
> work was the gimple->rtl conversion and block/edge discovery at that point.

Hmm, right, maybe extra paranoia from me here as well.  Note that I think
even with EH edges out of the setjmp the abnormal return wouldn't be
wrong to the successor given it isn't going to throw after the abnormal
return.

So I guess the proper action is to remove the successor check and
not replace it with a single-pedecessor-of-the-successor check.

> Verifying the successor has a single pred seems simple enough if done at
> the right time.  If it has multiple preds, then we can always fall back
> to the less accurate CFG that we've been building for a decade or more.
> The less precise CFG works, but the imprecision can impede more precise
> analysis as we've seen with this BZ.

As said I'd rather be consistent on what we do for this instead of doing
sth different depending on "context".  So let's drop those restrictions
on the surrounding CFG.

>
>
>> -   handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
>> -  _edge_call, false);
>> +   {
>> + bool target_after_setjmp = false;
>> +
>> + /* If the returns twice statement looks like a setjmp
>> +call at the end of a block with a single successor
>> +then we want the edge from the dispatcher to target
>> +that single successor.  That more accurately reflects
>> +actual control flow.  The more accurate CFG also
>> +results in fewer false positive warnings.  */
>> + if (gsi_stmt (gsi_last_nondebug_bb (bb)) == call_stmt
>> + && gimple_call_fndecl (call_stmt)
>> + && setjmp_call_p (gimple_call_fndecl (call_stmt))
>> + && single_succ_p (bb))
>> +   target_after_setjmp = true;
>> + handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
>> +_edge_call, false,
>> +target_after_setjmp);
>> +   }
>>
>> I don't exactly get the hops you jump through here -- I think it's
>> better to split the returns-twice (always last stmt of a block after
>> the fixing) and the setjmp-receiver (always first stmt of a block) cases.
>> So, remove 

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Richard Biener]

On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
 wrote:
> GCC 6 and 7 would vectorise:
>
> void
> f (unsigned long incx, unsigned long incy,
>float *restrict dx, float *restrict dy)
> {
>   unsigned long ix = 0, iy = 0;
>   for (unsigned long i = 0; i < 512; ++i)
> {
>   dy[iy] += dx[ix];
>   ix += incx;
>   iy += incy;
> }
> }
>
> without first proving that incy is nonzero.  This is a regression from
> GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
> on whether incy is zero, but that's obviously too invasive to backport.
> This patch instead bails out for non-constant steps in the place that
> trunk would try a check for zeroness.
>
> I did wonder about trying to use range information to prove nonzeroness
> for SSA_NAMEs, but that would be entirely new code and didn't seem
> suitable for a release branch.
>
> Tested on aarch64-linux-gnu.  OK for GCC 7 and 6?  I'll add the testcase
> to trunk too.

Given dist == 0 isn't it enough to test either DR_STEP (dra) or DR_STEP (drb)?
That seems what trunk is doing (just look at dr_zero_step_indicator of dra).
Even when not using range-info I think that using !
tree_expr_nonzero_p (DR_STEP (dra))
is more to the point of the issue we're fixing -- that also would catch
integer_zerop (DR_STEP (dra)) which trunk handles by failing as well but your
patch wouldn't so it looks like a more "complete" fix.

Last but not least trunk and your patch guards all this by
!loop->force_vectorize.
But force_vectorize doesn't give any such guarantee that step isn't
zero so I wonder
why we deliberately choose to possibly miscompile stuff here?

Thus I'd like to see a simpler

+ if (! tree_expr_nonzero_p (DR_STEP (dra)))
+   {
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"step could be zero.\n");
+ return true;
+   }

if you think that works out and also the force_vectorize guard removed from the
trunk version.

OK with that change.

Thanks,
Richard.

> Richard
>
>
> 2018-02-28  Richard Sandiford  
>
> gcc/
> PR tree-optimization/84485
> * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
> true for zero dependence distances if either step is variable, and if
> there is no metadata that guarantees correctness.
>
> gcc/testsuite/
> PR tree-optimization/84485
> * gcc.dg/vect/pr84485.c: New test.
>
> Index: gcc/tree-vect-data-refs.c
> ===
> --- gcc/tree-vect-data-refs.c   2017-07-27 18:08:43.779978373 +0100
> +++ gcc/tree-vect-data-refs.c   2018-02-28 14:16:36.621113244 +
> @@ -394,6 +394,16 @@ vect_analyze_data_ref_dependence (struct
> }
> }
>
> + if (!loop->force_vectorize
> + && (TREE_CODE (DR_STEP (dra)) != INTEGER_CST
> + || TREE_CODE (DR_STEP (drb)) != INTEGER_CST))
> +   {
> + if (dump_enabled_p ())
> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +"step could be zero.\n");
> + return true;
> +   }
> +
>   continue;
> }
>
> Index: gcc/testsuite/gcc.dg/vect/pr84485.c
> ===
> --- /dev/null   2018-02-26 10:26:41.624847060 +
> +++ gcc/testsuite/gcc.dg/vect/pr84485.c 2018-02-28 14:16:36.620112862 +
> @@ -0,0 +1,34 @@
> +/* { dg-do run } */
> +
> +#include "tree-vect.h"
> +
> +#define N 256
> +
> +void __attribute__ ((noinline, noclone))
> +f (unsigned long incx, unsigned long incy,
> +   float *restrict dx, float *restrict dy)
> +{
> +  unsigned long ix = 0, iy = 0;
> +  for (unsigned long i = 0; i < N; ++i)
> +{
> +  dy[iy] += dx[ix];
> +  ix += incx;
> +  iy += incy;
> +}
> +}
> +
> +float a = 0.0;
> +float b[N];
> +
> +int
> +main (void)
> +{
> +  check_vect ();
> +
> +  for (int i = 0; i < N; ++i)
> +b[i] = i;
> +  f (1, 0, b, );
> +  if (a != N * (N - 1) / 2)
> +__builtin_abort ();
> +  return 0;
> +}

Re: [PATCH][darwin] Work around missing LTO debug support for Mach-O, PR82005

[Dominique d'Humières]

> Le 1 mars 2018 à 09:37, Richard Biener  a écrit :
> 
> In the PR Dominique says "With the patch the failures (-m32/-m64) went 
> down from 1059 to 467" which is a nice improvement.  I'm not set up
> to bootstrap on darwin but I expect Dominque did so.

Indeed!

> 
> So - ok for trunk?

From my pov yes.

Thanks,

Dominique

> 
> Thanks,
> Richard.
> 

Re: [Patch, fortran] PR84538 - [8 Regression] Array of derived type elements incorrectly accessed in function

[Paul Richard Thomas]

Committed as revision 258097 with a corrections to a pre-existing,
garbled comment (Thanks Dominique!) and to the ChangeLog.

Paul

2018-03-01  Paul Thomas  

PR fortran/84538
* class.c (class_array_ref_detected): Remove the condition that
there be no reference after the array reference.
(find_intrinsic_vtab): Remove excess whitespace.
* trans-array.c (gfc_conv_scalarized_array_ref): Rename 'tmp'
as 'base and call build_class_array_ref earlier.

2018-03-01  Paul Thomas  

PR fortran/84538
* gfortran.dg/class_array_23.f03: New test.


On 27 February 2018 at 09:34, Paul Richard Thomas
 wrote:
> Hi All,
>
> The attached fixes this PR by dint of the change in class.c. The
> changes to trans-array.c are largely cosmetic but the move of the call
> to 'build_class_array_ref' ensures that all class array references go
> by this route.
>
> Boostrapped and regtested on FC27/x86_64 - OK to commit?
>
> Regards
>
> Paul
>
> 2018-02-27  Paul Thomas  
>
> PR fortran/84538
> * class.c (class_array_ref_detected): Remove the condition that
> there be no reference after the array reference.
> (find_intrinsic_vtab): Remove excess whitespace.
> * trans-array.c (gfc_conv_scalarized_array_ref): Rename 'tmp'
> as 'base and call build_class_array_ref earlier.
>
> 2018-02-27  Paul Thomas  
>
> PR fortran/84538
> * gfortran.dg/pr84523.f90: New test.



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[PATCH][darwin] Work around missing LTO debug support for Mach-O, PR82005

[Richard Biener]

This patch works around the lack of simple-object Mach-O support for
LTO debug.  It disables early debug generation for darwin (retaining
the debug setting for the fat part of the LTO objects) which should
result in roughly comparable debug for LTO than before the early LTO
debug support.  "roughly" meaning that we're not fully set up to
emit late dwarf without access to early DIEs and thus one may experience
extra ICEs - but I'd rather debug those, seeing what we can do, than
disabling debug info generation completely.

In the PR Dominique says "With the patch the failures (-m32/-m64) went 
down from 1059 to 467" which is a nice improvement.  I'm not set up
to bootstrap on darwin but I expect Dominque did so.

So - ok for trunk?

Thanks,
Richard.

2018-03-01  Richard Biener  

PR target/82005
* config/darwin.c (saved_debug_info_level): New static global.
(darwin_asm_lto_start): Disable debug info generation for LTO out.
(darwin_asm_lto_end): Restore debug info generation settings.

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 258061)
+++ gcc/config/darwin.c (working copy)
@@ -1933,6 +1933,7 @@ static GTY (()) vec