C++ PATCH for c++/71274 (deprecated warning without use)

[Jason Merrill]

In this testcase we were giving a deprecated declaration warning
without the deprecated declaration ever having been used, because we
called mark_used when checking whether the variable is constant.  What
we really want from mark_used is the instantiation semantics, so let's
split that out.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit e74031296c8c49986ffb0ec08765f09a79f5f81f
Author: Jason Merrill 
Date:   Thu Jul 21 17:27:19 2016 -0400

PR c++/71274 - deprecated warning without use.

* decl2.c (maybe_instantiate_decl): Split out from mark_used.
(decl_constant_var_p): Use it instead.

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 22f9ede..2ff6f53 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -81,6 +81,7 @@ static tree get_guard_bits (tree);
 static void determine_visibility_from_class (tree, tree);
 static bool determine_hidden_inline (tree);
 static bool decl_defined_p (tree);
+static void maybe_instantiate_decl (tree);
 
 /* A list of static class variables.  This is needed, because a
static class variable can be declared inside the class without
@@ -4217,7 +4218,7 @@ decl_constant_var_p (tree decl)
  in the case of a constexpr variable, we can't treat it as a
  constant until its initializer is complete in case it's used in
  its own initializer.  */
-  mark_used (decl);
+  maybe_instantiate_decl (decl);
   return DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl);
 }
 
@@ -5057,6 +5058,38 @@ possibly_inlined_p (tree decl)
   return true;
 }
 
+/* Normally, we can wait until instantiation-time to synthesize DECL.
+   However, if DECL is a static data member initialized with a constant
+   or a constexpr function, we need it right now because a reference to
+   such a data member or a call to such function is not value-dependent.
+   For a function that uses auto in the return type, we need to instantiate
+   it to find out its type.  For OpenMP user defined reductions, we need
+   them instantiated for reduction clauses which inline them by hand
+   directly.  */
+
+static void
+maybe_instantiate_decl (tree decl)
+{
+  if (DECL_LANG_SPECIFIC (decl)
+  && DECL_TEMPLATE_INFO (decl)
+  && (decl_maybe_constant_var_p (decl)
+ || (TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_OMP_DECLARE_REDUCTION_P (decl))
+ || undeduced_auto_decl (decl))
+  && !DECL_DECLARED_CONCEPT_P (decl)
+  && !uses_template_parms (DECL_TI_ARGS (decl)))
+{
+  /* Instantiating a function will result in garbage collection.  We
+must treat this situation as if we were within the body of a
+function so as to avoid collecting live data only referenced from
+the stack (such as overload resolution candidates).  */
+  ++function_depth;
+  instantiate_decl (decl, /*defer_ok=*/false,
+   /*expl_inst_class_mem_p=*/false);
+  --function_depth;
+}
+}
+
 /* Mark DECL (either a _DECL or a BASELINK) as "used" in the program.
If DECL is a specialization or implicitly declared class member,
generate the actual definition.  Return false if something goes
@@ -5151,24 +5184,7 @@ mark_used (tree decl, tsubst_flags_t complain)
  it to find out its type.  For OpenMP user defined reductions, we need
  them instantiated for reduction clauses which inline them by hand
  directly.  */
-  if (DECL_LANG_SPECIFIC (decl)
-  && DECL_TEMPLATE_INFO (decl)
-  && (decl_maybe_constant_var_p (decl)
- || (TREE_CODE (decl) == FUNCTION_DECL
- && DECL_OMP_DECLARE_REDUCTION_P (decl))
- || undeduced_auto_decl (decl))
-  && !DECL_DECLARED_CONCEPT_P (decl)
-  && !uses_template_parms (DECL_TI_ARGS (decl)))
-{
-  /* Instantiating a function will result in garbage collection.  We
-must treat this situation as if we were within the body of a
-function so as to avoid collecting live data only referenced from
-the stack (such as overload resolution candidates).  */
-  ++function_depth;
-  instantiate_decl (decl, /*defer_ok=*/false,
-   /*expl_inst_class_mem_p=*/false);
-  --function_depth;
-}
+  maybe_instantiate_decl (decl);
 
   if (processing_template_decl || in_template_function ())
 return true;
diff --git a/gcc/testsuite/g++.dg/warn/deprecated-11.C 
b/gcc/testsuite/g++.dg/warn/deprecated-11.C
new file mode 100644
index 000..5652290
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/deprecated-11.C
@@ -0,0 +1,7 @@
+// PR c++/71274
+// { dg-options -Wdeprecated-declarations }
+
+struct foo
+{
+   __attribute__ ((deprecated)) static const int a;
+};

C++ PATCH for c++/69223 (ICE with deduced return type)

[Jason Merrill]

Here when we deduced the return type for a lambda to an uninstantiated
class template specialization, we built the new RESULT_DECL, and
called layout_decl, before we called complete_type_or_else, so the
RESULT_DECL wasn't properly laid out.

Tested x86_64-pc-linux-gnu, applying to trunk, 6, 5.
commit f0113b081c53fa70be614f6d1f63953a3919b85f
Author: Jason Merrill 
Date:   Thu Jul 21 18:20:17 2016 -0400

PR c++/69223 - ICE with deduced template return type.

* semantics.c (apply_deduced_return_type): Call
complete_type_or_else before building the new RESULT_DECL.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 19daeff..63063b8 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9279,6 +9279,10 @@ apply_deduced_return_type (tree fco, tree return_type)
   if (TREE_TYPE (result) == return_type)
 return;
 
+  if (!processing_template_decl && !VOID_TYPE_P (return_type)
+  && !complete_type_or_else (return_type, NULL_TREE))
+return;
+
   /* We already have a DECL_RESULT from start_preparsed_function.
  Now we need to redo the work it and allocate_struct_function
  did to reflect the new type.  */
@@ -9294,8 +9298,6 @@ apply_deduced_return_type (tree fco, tree return_type)
 
   if (!processing_template_decl)
 {
-  if (!VOID_TYPE_P (TREE_TYPE (result)))
-   complete_type_or_else (TREE_TYPE (result), NULL_TREE);
   bool aggr = aggregate_value_p (result, fco);
 #ifdef PCC_STATIC_STRUCT_RETURN
   cfun->returns_pcc_struct = aggr;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
new file mode 100644
index 000..68ac29c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
@@ -0,0 +1,15 @@
+// PR c++/69223
+// { dg-do compile { target c++11 } }
+
+template  struct A
+{
+  T x[20];
+};
+
+int main()
+{
+  auto l = [](const A& i){ return i; };
+  A a;
+
+  l(a);
+}

C++ PATCH for c++/71630 (extern variable template)

[Jason Merrill]

instantiate_decl's setting of pattern_defined never got adjusted for
variable templates; it was still checking DECL_IN_AGGR_P to decide
whether a static data member temploid is defined, which doesn't make
sense for namespace-scope variable templates.

Tested x86_64-pc-linux-gnu, applying to trunk, 5, 6.
commit 735ad45cb16c7703e1f5ec427c24b6809adb8ebb
Author: Jason Merrill 
Date:   Thu Jul 21 17:06:42 2016 -0400

PR c++/71630 - extern variable template

* pt.c (instantiate_decl): Fix pattern_defined for namespace scope
variable templates.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d7f3808..5e29d99 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21853,7 +21853,10 @@ instantiate_decl (tree d, int defer_ok,
   else
 {
   deleted_p = false;
-  pattern_defined = ! DECL_IN_AGGR_P (code_pattern);
+  if (DECL_CLASS_SCOPE_P (code_pattern))
+   pattern_defined = ! DECL_IN_AGGR_P (code_pattern);
+  else
+   pattern_defined = ! DECL_EXTERNAL (code_pattern);
 }
 
   /* We may be in the middle of deferred access check.  Disable it now.  */
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ53.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ53.C
new file mode 100644
index 000..3e30d67
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ53.C
@@ -0,0 +1,10 @@
+// PR c++/71630
+// { dg-do compile { target c++14 } }
+
+template 
+extern T pi;
+
+int main()
+{
+  return pi;
+}

C++ PATCH for c++/71913 (copy elision choices)

[Jason Merrill]

71913 is a case where unsafe_copy_elision_p was being too
conservative. We can allow copy elision in a new expression; the only
way we could end up initializing a base subobject without knowing it
would be through a placement new, in which case we would already be
using the wrong (complete object) constructor, so copy elision doesn't
make it any worse.

The second patch is for a case where we weren't being conservative
enough; we need to beware of tail padding even when the copy
constructor is trivial.

Tested x86_64-pc-linux-gnu, applying to trunk.  71913 patch also
applied to 6 branch.
commit 32e2ba606cd8993bd3de82708711ae26fc251d0a
Author: Jason Merrill 
Date:   Thu Jul 21 16:55:56 2016 -0400

PR c++/71913 - missing copy elision with new.

* call.c (unsafe_copy_elision_p): It's OK to elide when
initializing an unknown object.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index d917d9a..061e708 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7275,10 +7275,11 @@ unsafe_copy_elision_p (tree target, tree exp)
   if (TREE_CODE (exp) != TARGET_EXPR)
 return false;
   tree type = TYPE_MAIN_VARIANT (TREE_TYPE (exp));
-  if (type == CLASSTYPE_AS_BASE (type))
+  /* It's safe to elide the copy for a class with no tail padding.  */
+  if (tree_int_cst_equal (TYPE_SIZE (type), CLASSTYPE_SIZE (type)))
 return false;
-  if (!is_base_field_ref (target)
-  && resolves_to_fixed_type_p (target, NULL))
+  /* It's safe to elide the copy if we aren't initializing a base object.  */
+  if (!is_base_field_ref (target))
 return false;
   tree init = TARGET_EXPR_INITIAL (exp);
   /* build_compound_expr pushes COMPOUND_EXPR inside TARGET_EXPR.  */
diff --git a/gcc/testsuite/g++.dg/init/elide5.C 
b/gcc/testsuite/g++.dg/init/elide5.C
new file mode 100644
index 000..0a9978c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/elide5.C
@@ -0,0 +1,27 @@
+// PR c++/71913
+// { dg-do link { target c++11 } }
+
+void* operator new(unsigned long, void* p) { return p; }
+
+struct IndirectReturn {
+  IndirectReturn() {}
+  // Undefined so we get a link error if the indirect return value is copied
+  IndirectReturn(const IndirectReturn&);
+  IndirectReturn& operator=(const IndirectReturn&) = delete;
+  ~IndirectReturn() {}
+};
+
+IndirectReturn foo() { return IndirectReturn(); }
+
+void bar(void* ptr) {
+  new (ptr) IndirectReturn(foo());
+}
+
+alignas (alignof (IndirectReturn))
+unsigned char c[sizeof(IndirectReturn)];
+
+int main()
+{
+  bar(c);
+}
+
commit 5d549fb4e1ee815daa678bd369a2650055d61311
Author: Jason Merrill 
Date:   Thu Jul 21 15:57:35 2016 -0400

* call.c (build_over_call): Check unsafe_copy_elision_p even for
trivial constructors.
* method.c (do_build_copy_constructor): Don't copy tail padding
even in a trivial constructor.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f929fb2..d917d9a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7271,6 +7271,9 @@ is_base_field_ref (tree t)
 static bool
 unsafe_copy_elision_p (tree target, tree exp)
 {
+  /* Copy elision only happens with a TARGET_EXPR.  */
+  if (TREE_CODE (exp) != TARGET_EXPR)
+return false;
   tree type = TYPE_MAIN_VARIANT (TREE_TYPE (exp));
   if (type == CLASSTYPE_AS_BASE (type))
 return false;
@@ -7726,9 +7729,8 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
  else if (trivial)
return force_target_expr (DECL_CONTEXT (fn), arg, complain);
}
-  else if (trivial
-  || (TREE_CODE (arg) == TARGET_EXPR
-  && !unsafe_copy_elision_p (fa, arg)))
+  else if ((trivial || TREE_CODE (arg) == TARGET_EXPR)
+  && !unsafe_copy_elision_p (fa, arg))
{
  tree to = cp_stabilize_reference (cp_build_indirect_ref (fa,
   RO_NULL,
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index cd8faaf..63aa53e 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -542,14 +542,32 @@ do_build_copy_constructor (tree fndecl)
   if (!inh)
 parm = convert_from_reference (parm);
 
-  if (trivial
-  && is_empty_class (current_class_type))
-/* Don't copy the padding byte; it might not have been allocated
-   if *this is a base subobject.  */;
-  else if (trivial)
+  if (trivial)
 {
-  tree t = build2 (INIT_EXPR, void_type_node, current_class_ref, parm);
-  finish_expr_stmt (t);
+  if (is_empty_class (current_class_type))
+   /* Don't copy the padding byte; it might not have been allocated
+  if *this is a base subobject.  */;
+  else if (tree_int_cst_equal (TYPE_SIZE (current_class_type),
+  CLASSTYPE_SIZE (current_class_type)))
+   {
+ tree t = build2 (INIT_EXPR, void_type_node, current_class_ref, parm);
+ finish_expr_stmt (t);
+   }
+  else
+   {
+ /* We must only copy the 

Go patch committed: accept a, a, a = 1, 2, 3

[Ian Lance Taylor]

The Go frontend was incorrectly rejecting
a, a, a = 1, 2, 3
This was a misfire of the code that detects and rejects
a, a, a := 1, 2, 3
The former is valid, albeit not very useful, Go.  This patch fixes the
problem.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

A test for this has been sent to the master testsuite in
https://golang.org/cl/25143.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 238266)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-5ea5c078829ae83bccb598772fff7c1a04e23e65
+4c88f31a83ca28963d29d6dc9fcdb2e9b093610c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/parse.cc
===
--- gcc/go/gofrontend/parse.cc  (revision 236804)
+++ gcc/go/gofrontend/parse.cc  (working copy)
@@ -2106,6 +2106,8 @@ Parse::simple_var_decl_or_assignment(con
 
   std::set uniq_idents;
   uniq_idents.insert(name);
+  std::string dup_name;
+  Location dup_loc;
 
   // We've seen one identifier.  If we see a comma now, this could be
   // "a, *p = 1, 2".
@@ -2145,8 +2147,10 @@ Parse::simple_var_decl_or_assignment(con
  id = this->gogo_->pack_hidden_name(id, is_id_exported);
  ins = uniq_idents.insert(id);
  if (!ins.second && !Gogo::is_sink_name(id))
-   error_at(id_location, "multiple assignments to %s",
-Gogo::message_name(id).c_str());
+   {
+ dup_name = Gogo::message_name(id);
+ dup_loc = id_location;
+   }
  til.push_back(Typed_identifier(id, NULL, location));
}
 
@@ -2182,6 +2186,9 @@ Parse::simple_var_decl_or_assignment(con
   go_assert(this->peek_token()->is_op(OPERATOR_COLONEQ));
   const Token* token = this->advance_token();
 
+  if (!dup_name.empty())
+error_at(dup_loc, "multiple assignments to %s", dup_name.c_str());
+
   if (p_range_clause != NULL && token->is_keyword(KEYWORD_RANGE))
 {
   this->range_clause_decl(, p_range_clause);

Re: [PATCH], Add PowerPC vec_extract tests

[Michael Meissner]

On Thu, Jul 21, 2016 at 06:17:24PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 21, 2016 at 05:15:26PM -0400, Michael Meissner wrote:
> > I am preparing to submit patches to enhance vec_extract for 64-bit power8 
> > and
> > power9 systems shortly.  As part of my work, I added executable tests to 
> > test
> > all vector types, and doing both constant and variable vector extracts from
> > each vector type.
> > 
> > Because these are just new tests and not compiler changes, I verified that 
> > the
> > new tests run correctly with a current bootstrapped compiler on both a big
> > endian power7 system and a little endian power8 system.  Can I install these
> > tests on the trunk?
> 
> > --- gcc/testsuite/gcc.target/powerpc/vec-extract.h  (revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/vec-extract.h  (working copy)
> > @@ -0,0 +1,1125 @@
> > +#include 
> 
> Do you use anything from this header?
> 
> It's okay for trunk, either way.  Thanks,

Not currently, but the first versions of the test did do tracing.  I removed
including stdio.h from vec-extract.h and checked it in.  I did keep stdlib.h
and stddef.h for abort and size_t/ssize_t declarations.

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

Re: [libstdc++] Add C++17clamp

[NightStrike]

On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> Here is an implementation of P0025
> An algorithm to "clamp" a value between a pair of boundary values.
>
> Testing is almost finished - looks good so far.
>
> OK if testing passes?
>
> I didn't see a feature test in any of the SD-6 papers or P0025.
>

This is not an efficient implementation.  See here:

https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html

Which I derived from this SO answer (which is sadly not the accepted
answer at this time):

http://stackoverflow.com/a/16659263

I suggest using the very efficient method that requires a temporary.

Re: [PATCH], Add PowerPC vec_extract tests

[Segher Boessenkool]

On Thu, Jul 21, 2016 at 05:15:26PM -0400, Michael Meissner wrote:
> I am preparing to submit patches to enhance vec_extract for 64-bit power8 and
> power9 systems shortly.  As part of my work, I added executable tests to test
> all vector types, and doing both constant and variable vector extracts from
> each vector type.
> 
> Because these are just new tests and not compiler changes, I verified that the
> new tests run correctly with a current bootstrapped compiler on both a big
> endian power7 system and a little endian power8 system.  Can I install these
> tests on the trunk?

> --- gcc/testsuite/gcc.target/powerpc/vec-extract.h(revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/vec-extract.h(working copy)
> @@ -0,0 +1,1125 @@
> +#include 

Do you use anything from this header?

It's okay for trunk, either way.  Thanks,


Segher

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

To that end, the attached patch adds the checker under its own new
pass.  The pass runs very early without optimization, and relatively
late with it to benefit from the passes above.  With optimization
the pass also can (but doesn't yet) fold the return value from these
functions into a constant.  In the Linux kernel, it folds 88 snprintf
calls (I didn't find any instances where the whole call could be
folded into a string constant).

So I haven't dug into the patch yet, but what (if any) interaction is
there between the early and late passes?  Do they both emit warnings, or
is it more that the early passe builds a candidate set which is refined
by the later pass, or something totally different?


Thanks for the feedback.

The pass only runs once.  Without optimization, it's invoked early,
does its thing, and is never invoked again.  With optimization,
it's also invoked early but returns without doing anything, only
to to invoked again much later on to do real work.  I wasn't sure
where among all the passes might be the best spot to insert it so
I put in the same place as Aldy's -Walloca patch because it relies
on the same prior passes.


I tested the patch with LTO but due to bug 71907 no warnings are
issued.  Once the bug is resolved I'll re-test it and see about
adding test cases to verify it.

Note Richi checked in a patch a couple days ago to stream the abstract
origins, which is supposed to fix 71907.


Thanks for the heads up.  I'll give it a whirl.


Onward to looking at the patch :-)


Re-reading it again myself I see a few typos, commented out chunks
of code left over from debugging, and missing comments.  I'll clean
this up in the next update along with other requested changes.

Martin

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

Hi,

based on the discussion here, I have updated my patch again...

This is the rest of the patch, which removes outdated function names,
and creates built-in definitions for vfork, getcontext, savectx.
These built-ins have the return_twice attribute but not the
leaf attribute, because we do not really know, what these functions
do.

The reason for ceating the builtin functions is, that I would like
to get a warning about conflicting builtin definition if someone
accidentally picks the name of one of these less well known special
functions, which are _not_ reserved names in most environments.

I do not define builtins (without __builtin_ prefix) for setjmp and
sigsetjmp because these are like wildcards, and they fall in the
well-known category anyways.

I still retain the handling of these functions in special_function_p
because even in a free standing environment, returning
ECF_RETURNS_TWICE is on the safe side.



Is it OK for trunk after boot-strap and regression-testing?


Thanks
Bernd.
2016-07-21  Bernd Edlinger  

PR middle-end/71876
* builtin-attrs.def (ATTR_RT_NOTHROW_LIST): New return twice
no leaf attribute.
* builtins.def (BUILT_IN_GETCONTEXT, BUILT_IN_SAVECTX,
BUILT_IN_VFORK): New builtins using ATTR_RT_NOTHROW_LIST.
* calls.c (special_function_p): Remove special handling of
"setjmp_syscall", "qsetjmp", "longjmp", "siglongjmp" and the
prefix "__x".  Recognize "savectx", "vfork" and "getcontext" only
without prefix.  Remove potentially unsafe ECF_LEAF and ECF_NORETURN.
Index: gcc/builtin-attrs.def
===
--- gcc/builtin-attrs.def	(revision 238611)
+++ gcc/builtin-attrs.def	(working copy)
@@ -131,6 +131,8 @@ DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHROW_LIST, AT
 			ATTR_NULL, ATTR_NOTHROW_LIST)
 DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHROW_LEAF_LIST, ATTR_NORETURN,\
 			ATTR_NULL, ATTR_NOTHROW_LEAF_LIST)
+DEF_ATTR_TREE_LIST (ATTR_RT_NOTHROW_LIST, ATTR_RETURNS_TWICE,\
+			ATTR_NULL, ATTR_NOTHROW_LIST)
 DEF_ATTR_TREE_LIST (ATTR_RT_NOTHROW_LEAF_LIST, ATTR_RETURNS_TWICE,\
 			ATTR_NULL, ATTR_NOTHROW_LEAF_LIST)
 DEF_ATTR_TREE_LIST (ATTR_COLD_NOTHROW_LEAF_LIST, ATTR_COLD,\
Index: gcc/builtins.def
===
--- gcc/builtins.def	(revision 238611)
+++ gcc/builtins.def	(working copy)
@@ -796,6 +796,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED32, "finit
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED64, "finited64", BT_FN_INT_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED128, "finited128", BT_FN_INT_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FPCLASSIFY, "fpclassify", BT_FN_INT_INT_INT_INT_INT_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_GETCONTEXT, "getcontext", BT_FN_INT_PTR, ATTR_RT_NOTHROW_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_ISFINITE, "isfinite", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
 DEF_GCC_BUILTIN(BUILT_IN_ISINF_SIGN, "isinf_sign", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC)
@@ -836,6 +837,7 @@ DEF_GCC_BUILTIN(BUILT_IN_PREFETCH, "prefet
 DEF_LIB_BUILTIN(BUILT_IN_REALLOC, "realloc", BT_FN_PTR_PTR_SIZE, ATTR_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_RETURN, "return", BT_FN_VOID_PTR, ATTR_NORETURN_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_RETURN_ADDRESS, "return_address", BT_FN_PTR_UINT, ATTR_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_SAVECTX, "savectx", BT_FN_VOID_PTR, ATTR_RT_NOTHROW_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_SAVEREGS, "saveregs", BT_FN_PTR_VAR, ATTR_NULL)
 DEF_GCC_BUILTIN(BUILT_IN_SETJMP, "setjmp", BT_FN_INT_PTR, ATTR_RT_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_STRFMON, "strfmon", BT_FN_SSIZE_STRING_SIZE_CONST_STRING_VAR, ATTR_FORMAT_STRFMON_NOTHROW_3_4)
@@ -849,6 +851,7 @@ DEF_GCC_BUILTIN(BUILT_IN_VA_END, "va_end",
 DEF_GCC_BUILTIN(BUILT_IN_VA_START, "va_start", BT_FN_VOID_VALIST_REF_VAR, ATTR_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_VA_ARG_PACK, "va_arg_pack", BT_FN_INT, ATTR_PURE_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_VA_ARG_PACK_LEN, "va_arg_pack_len", BT_FN_INT, ATTR_PURE_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_VFORK, "vfork", BT_FN_PID, ATTR_RT_NOTHROW_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN__EXIT, "_exit", BT_FN_VOID_INT, ATTR_NORETURN_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN__EXIT2, "_Exit", BT_FN_VOID_INT, ATTR_NORETURN_NOTHROW_LEAF_LIST)
 
Index: gcc/calls.c
===
--- gcc/calls.c	(revision 238611)
+++ gcc/calls.c	(working copy)
@@ -474,8 +474,6 @@ emit_call_1 (rtx funexp, tree fntree ATTRIBUTE_UNU
For example, if the function might return more than one 

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Jeff Law]

I saw a few places in GCC itself where you increased buffer sizes.  Were 
any of those level 1 failures?


In c.opt:


+C ObjC C++ ObjC++ Warning Alias (Wformat-length=, 1, 0)

Can't this take on values 0, 1, 2? And if so, is the "1" above correct?

In invoke.texi we have:

+-Wno-format-contains-nul -Wno-format-extra-args -Wformat-length=2 @gol
Note Wformat-length=2.

Then in the actual documentation it says the default level is 1.

+in output truncation.  GCC counts the number of bytes that each format
+string and directive within it writes into the provided buffer and, when
+it detects that more bytes that fit in the destination buffer may be output,
+it emits a warning.


s/that fit/than fit

In that same section is the text which says the default level is 1

I'm curious about the heuristics for level 1.  I guess if you get a 
warning at level 1, then you've got a situation where we know we'll 
write out of bounds.  level 2 is a may write out of bounds.  Which makes 
me wonder if rather than levels we should use symbolic names?


I guess my worry here is that if we don't message this right folks will 
make their code level 1 clean and think they're done.  When in reality 
all they've done is mitigate the most egregious problems.


Elsewhere in invoke.texi:


+buffer in an inforational note following the warning.

informational I assume


+the minimum buffer size.  For exampe, if @var{a} and @var{b} above can

example

In genmatch.c:

+  char id[13];   /* Big enough for a 32-bit UINT_MAX.  */
In general we don't add comments to the end of a line like that.  If a 
comment is needed, put it before the declaration.  I'm not sure if a 
comment is needed here or not -- your call.


Similarly for various other places were you increased buffer lengths.


In passes.c:


+
+  // inform (0, "executing pass: %s", pass->name);
+
   if (execute_one_pass (pass) && pass->sub)
-execute_pass_list_1 (pass->sub);
+   {
+ // inform (0, "executing subpass: %s", pass->sub->name);
+ execute_pass_list_1 (pass->sub);
+   }
+



The comments left over from debugging?

Looks like ~1/3 of the patch are tests.  Good stuff.  I'm going to 
assume those are correct.


I'll get into gimple-ssa-sprintf.c either later tonight or tomorrow. 
But so far nothing major, just nits.


Jeff

[PATCH], Add PowerPC vec_extract tests

[Michael Meissner]

I am preparing to submit patches to enhance vec_extract for 64-bit power8 and
power9 systems shortly.  As part of my work, I added executable tests to test
all vector types, and doing both constant and variable vector extracts from
each vector type.

Because these are just new tests and not compiler changes, I verified that the
new tests run correctly with a current bootstrapped compiler on both a big
endian power7 system and a little endian power8 system.  Can I install these
tests on the trunk?

2016-07-21  Michael Meissner  

* gcc.target/powerpc/vec-extract.h: New files to check the
vec_extract built-in functions for all vector types, testing
accessing each element, both with constant and variable element
numbers.
* gcc.target/powerpc/vec-extract-v16qi.c: Likewise.
* gcc.target/powerpc/vec-extract-v16qiu.c: Likewise.
* gcc.target/powerpc/vec-extract-v2df.c: Likewise.
* gcc.target/powerpc/vec-extract-v2di.c: Likewise.
* gcc.target/powerpc/vec-extract-v4sf.c: Likewise.
* gcc.target/powerpc/vec-extract-v4si.c: Likewise.
* gcc.target/powerpc/vec-extract-v4siu.c: Likewise.
* gcc.target/powerpc/vec-extract-v8hi.c: Likewise.
* gcc.target/powerpc/vec-extract-v8hiu.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/testsuite/gcc.target/powerpc/vec-extract.h
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract.h  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract.h  (working copy)
@@ -0,0 +1,1125 @@
+#include 
+#include 
+#include 
+#include 
+
+static void
+check (TYPE expected, TYPE got)
+{
+  if (expected != got)
+abort ();
+}
+
+static vector TYPE  deoptimize (vector TYPE)   
__attribute__((__noinline__));
+static vector TYPE *deoptimize_ptr (vector TYPE *) 
__attribute__((__noinline__));
+
+static vector TYPE
+deoptimize (vector TYPE a)
+{
+  __asm__ (" # %x0" : "+wa" (a));
+  return a;
+}
+
+static vector TYPE *
+deoptimize_ptr (vector TYPE *p)
+{
+  __asm__ (" # %0" : "+r" (p));
+  return p;
+}
+
+
+/* Tests for the normal case of vec_extract where the vector is in a register
+   and returning the result in a register as a return value.  */
+TYPE
+get_auto_n (vector TYPE a, ssize_t n)
+{
+  return vec_extract (a, n);
+}
+
+TYPE
+get_auto_0 (vector TYPE a)
+{
+  return vec_extract (a, 0);
+}
+
+TYPE
+get_auto_1 (vector TYPE a)
+{
+  return vec_extract (a, 1);
+}
+
+#if ELEMENTS >= 4
+TYPE
+get_auto_2 (vector TYPE a)
+{
+  return vec_extract (a, 2);
+}
+
+TYPE
+get_auto_3 (vector TYPE a)
+{
+  return vec_extract (a, 3);
+}
+
+#if ELEMENTS >= 8
+TYPE
+get_auto_4 (vector TYPE a)
+{
+  return vec_extract (a, 4);
+}
+
+TYPE
+get_auto_5 (vector TYPE a)
+{
+  return vec_extract (a, 5);
+}
+
+TYPE
+get_auto_6 (vector TYPE a)
+{
+  return vec_extract (a, 6);
+}
+
+TYPE
+get_auto_7 (vector TYPE a)
+{
+  return vec_extract (a, 7);
+}
+
+#if ELEMENTS >= 16
+TYPE
+get_auto_8 (vector TYPE a)
+{
+  return vec_extract (a, 8);
+}
+
+TYPE
+get_auto_9 (vector TYPE a)
+{
+  return vec_extract (a, 9);
+}
+
+TYPE
+get_auto_10 (vector TYPE a)
+{
+  return vec_extract (a, 10);
+}
+
+TYPE
+get_auto_11 (vector TYPE a)
+{
+  return vec_extract (a, 11);
+}
+
+TYPE
+get_auto_12 (vector TYPE a)
+{
+  return vec_extract (a, 12);
+}
+
+TYPE
+get_auto_13 (vector TYPE a)
+{
+  return vec_extract (a, 13);
+}
+
+TYPE
+get_auto_14 (vector TYPE a)
+{
+  return vec_extract (a, 14);
+}
+
+TYPE
+get_auto_15 (vector TYPE a)
+{
+  return vec_extract (a, 15);
+}
+
+#endif
+#endif
+#endif
+
+typedef TYPE (*auto_func_type) (vector TYPE);
+
+static auto_func_type get_auto_const[] = {
+  get_auto_0,
+  get_auto_1,
+#if ELEMENTS >= 4
+  get_auto_2,
+  get_auto_3,
+#if ELEMENTS >= 8
+  get_auto_4,
+  get_auto_5,
+  get_auto_6,
+  get_auto_7,
+#if ELEMENTS >= 16
+  get_auto_8,
+  get_auto_9,
+  get_auto_10,
+  get_auto_11,
+  get_auto_12,
+  get_auto_13,
+  get_auto_14,
+  get_auto_15,
+#endif
+#endif
+#endif
+};
+
+extern void do_auto (vector TYPE a) __attribute__((__noinline__));
+
+void
+do_auto (vector TYPE a)
+{
+  size_t i;
+
+  for (i = 0; i < sizeof (get_auto_const) / sizeof (get_auto_const[0]); i++)
+check (get_auto_n (a, i),  (get_auto_const[i]) (a));
+}
+
+
+/* Tests for vec_extract of a vector in a register, but storing the result
+   (there is an optimization where an element can be stored to memory if it is
+   in the right position to use a scalar store).  */
+
+void
+get_store_n (TYPE *p, vector TYPE a, ssize_t n)
+{
+  *p = vec_extract (a, n);
+}
+
+void
+get_store_0 (TYPE *p, vector TYPE a)
+{
+  *p = vec_extract (a, 0);
+}
+
+void
+get_store_1 (TYPE *p, vector TYPE a)
+{
+  *p = vec_extract (a, 1);
+}
+
+#if ELEMENTS >= 4
+void
+get_store_2 (TYPE *p, vector TYPE a)
+{
+  *p = 

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Jeff Law]

On 07/18/2016 03:59 PM, Martin Sebor wrote:


Unfortunately, linking with C_COMMON_OBJS isn't enough and linking
with C_OBJS doesn't work because of multiple definitions for symbols
like gt_ggc_mx_language_function.  I don't know this part of of GCC
but it seems that each front end gets a set of these generated
functions, some with the same names.  I spent a couple of hours
trying to get it to work but eventually gave up.
Correct.  gt_ggc_mx_* are generated functions to support the garbage 
collection system.  In this specific case, I think it's the GC bits for 
struct language_function which is specific to each front-end.  So each 
front-end is going to have that function hence the multiple definitions.




The only option left to make it work with LTO is to extract the
checker from c-format.c and move it where it gets linked with lto1.

I think you're right.



To that end, the attached patch adds the checker under its own new
pass.  The pass runs very early without optimization, and relatively
late with it to benefit from the passes above.  With optimization
the pass also can (but doesn't yet) fold the return value from these
functions into a constant.  In the Linux kernel, it folds 88 snprintf
calls (I didn't find any instances where the whole call could be
folded into a string constant).
So I haven't dug into the patch yet, but what (if any) interaction is 
there between the early and late passes?  Do they both emit warnings, or 
is it more that the early passe builds a candidate set which is refined 
by the later pass, or something totally different?





I tested the patch with LTO but due to bug 71907 no warnings are
issued.  Once the bug is resolved I'll re-test it and see about
adding test cases to verify it.
Note Richi checked in a patch a couple days ago to stream the abstract 
origins, which is supposed to fix 71907.





In the updated patch I tried to address the majority of everyone's
comments, including those I got from the bug submitter.  I also
made a number of enhancements based on the results I saw with the
Linux kernel and other code (e.g., support for %p, additional
heuristics to improve %s coverage, and support for POSIX numbered
arguments).

Once a patch along these lines is approved and committed, I'd like
to enhance it by adding one or more of the following:

 *  -fdump-sprintf-length option to have the pass dump details
about opportunities to fold expressions as well as instances
where the checker was unable to check a call because of lack
of object size or argument value or range information.

That'll definitely be useful as we've discussed in the past.



 *  Support for the return value folding (I have implemented and
lightly tested thid but I would prefer to treat it it as
a separate enhancement independent of this one).

Seems reasonable to me.



 *  If/when David's patch for on-demand locations within string
literals is accepted and committed
  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00441.html
replace the location handling code I copied from c-format.c
with the new API.

Also sounds good.



 *  Enhance the heuristics usesd to find likely %s argument
lengths to improve the checker's coverage.

 *  Add support for %n and perhaps other functions (e.g., scanf).

Also good stuff.

Onward to looking at the patch :-)

jeff

Re: [PATCH 2/2][v3] Drop excess size used for run time allocated stack variables.

[Jeff Law]

On 06/23/2016 03:57 AM, Dominik Vogt wrote:

0002-v3-ChangeLog


gcc/ChangeLog

* explow.c (round_push): Use know adjustment.
(allocate_dynamic_stack_space): Pass known adjustment to round_push.
gcc/testsuite/ChangeLog

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


0002-v3-Drop-excess-size-used-for-run-time-allocated-stack-v.patch



>From 4296d353e1d153b5b5ee435a44cae6117bf2fff0 Mon Sep 17 00:00:00 2001

From: Dominik Vogt 
Date: Fri, 29 Apr 2016 08:36:59 +0100
Subject: [PATCH 2/2] Drop excess size used for run time allocated stack
variables.

The present calculation sometimes led to more stack memory being used than
necessary with alloca.  First, (STACK_BOUNDARY -1) would be added to the
allocated size:

 size = plus_constant (Pmode, size, extra);
 size = force_operand (size, NULL_RTX);

Then round_push was called and added another (STACK_BOUNDARY - 1) before
rounding down to a multiple of STACK_BOUNDARY.  On s390x this resulted in
adding 14 before rounding down for "x" in the test case pr36728-1.c.

round_push() now takes an argument to inform it about what has already been
added to size.
---
gcc/explow.c   | 45 +---
gcc/testsuite/gcc.dg/pr50938.c | 52 ++
2 files changed, 79 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr50938.c

diff --git a/gcc/explow.c b/gcc/explow.c
index 09a0330..85596e2 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -949,24 +949,30 @@ anti_adjust_stack (rtx adjust)
}

/* Round the size of a block to be pushed up to the boundary required
-   by this machine.  SIZE is the desired size, which need not be constant.  */
+   by this machine.  SIZE is the desired size, which need not be constant.
+   ALREADY_ADDED is the number of units that have already been added to SIZE
+   for other alignment reasons.
+*/

static rtx
-round_push (rtx size)
+round_push (rtx size, int already_added)
{
-  rtx align_rtx, alignm1_rtx;
+  rtx align_rtx, add_rtx;

  if (!SUPPORTS_STACK_ALIGNMENT
  || crtl->preferred_stack_boundary == MAX_SUPPORTED_STACK_ALIGNMENT)
{
  int align = crtl->preferred_stack_boundary / BITS_PER_UNIT;
+  int add;

  if (align == 1)
return size;

+  add = (align > already_added) ? align - already_added - 1 : 0;
+
  if (CONST_INT_P (size))
{
- HOST_WIDE_INT new_size = (INTVAL (size) + align - 1) / align * align;
+ HOST_WIDE_INT new_size = (INTVAL (size) + add) / align * align;

  if (INTVAL (size) != new_size)
size = GEN_INT (new_size);

So presumably the idea here is when the requested SIZE would require
allocating additional space to first see if the necessary space is
already available inside ALREADY_ADDED


Yes.


and use that rather than rounding size up to an alignment boundary.


Not exactly.  Consider the unpatched code.  At the beginning we
have some amount of space to be allocated on the stack at runtime
("SSIZE"), some requested alignment for it ("SALIGN").

get_dynamic_stack_size() first calculates the space needed for run
time alignment:

  SIZE = SSIZE + SALIGN - 1

Then it calls round_push() to add *another* chunk of memory to the
allocation size to be able to align it to the required stack slot
alignment ("SLOTALIGN") at run time.

  SIZE = SIZE + SLOTALIGN - 1
   = SSIZE + (SALIGN - 1) + (SLOTALIGN - 1)

Now it has added two chunks of memory but alignment is only done
once.  With the patch it just adds the maximum of (SALIGN - 1) and
(SLOTALIGN - 1), not both.  Thinking about it, the "round_push"
stuff is a very complicated way of saying "add max(A, B)".

Now I see it.  Thanks, that helped a ton.



I'd volunteer to clean this up more, but preferrably when the two
pending patches are in.  The current code is a real brain-twister.
I'd be all for such cleanups after we wrap up the pending patches.  It's 
certainly a rats nest of code right now.


This patch is fine for the trunk.  Thanks for your patience.

jeff

Re: [patch, Fortran] Fix some string temporaries

[Thomas Koenig]

Am 21.07.2016 um 20:00 schrieb H.J. Lu:

On Tue, Jul 19, 2016 at 2:27 PM, Thomas Koenig  wrote:



Here is the pacth the way I committed it.

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961



As usual for SPEC errors: Please provide a test case.

Regards

Thomas

[PATCH 4/4] Fix undefined behaviour in libstdc++ testsuite

[Jonathan Wakely]

This fixes a couple of places where we replaced operator delete(void*)
but not the version that was needed by the tests (the first case used
to be correct, but was broken by the sized deallocation change in
C++14, so uses the feature-test macro to decide whether the extra
overload is needed).

   Define missing delete operators in libstdc++ testsuite
   
   	* testsuite/23_containers/vector/zero_sized_allocations.cc:

Define sized deallocation function.
* testsuite/util/testsuite_new_operators.h:
(operator delete(void*, const std::nothrow_t&)): Define nothrow
deallocation function.

Tested powerpc64-linux, committed to trunk.

commit 1e92e2338780cd47f624d13345f3575abd1bf369
Author: redi 
Date:   Thu Jul 21 19:38:57 2016 +

Define missing delete operators in libstdc++ testsuite

	* testsuite/23_containers/vector/zero_sized_allocations.cc:
	Define sized deallocation function.
	* testsuite/util/testsuite_new_operators.h:
	(operator delete(void*, const std::nothrow_t&)): Define nothrow
	deallocation function.

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

diff --git a/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc b/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
index 236b82f..74fa95c 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
@@ -22,7 +22,7 @@
 
 unsigned int zero_sized_news = 0;
 
-void *operator new(size_t size) throw (std::bad_alloc)
+void *operator new(std::size_t size) throw (std::bad_alloc)
 {
   /* malloc(0) is unpredictable; avoid it.  */
   if (size == 0)
@@ -45,6 +45,14 @@ void operator delete(void *ptr) throw()
 std::free(ptr);
 }
 
+#if __cpp_sized_deallocation
+void operator delete(void *ptr, std::size_t) throw()
+{
+  if (ptr != 0)
+std::free(ptr);
+}
+#endif
+
 // http://gcc.gnu.org/ml/libstdc++/2007-09/msg6.html
 void test01()
 {
@@ -57,7 +65,7 @@ void test01()
   VERIFY( zero_sized_news == 0 );
 
   v->resize(10);
-  delete(v);
+  delete v;
   VERIFY( zero_sized_news == 0 );
 }
 
diff --git a/libstdc++-v3/testsuite/util/testsuite_new_operators.h b/libstdc++-v3/testsuite/util/testsuite_new_operators.h
index 70603fa..6713fb8 100644
--- a/libstdc++-v3/testsuite/util/testsuite_new_operators.h
+++ b/libstdc++-v3/testsuite/util/testsuite_new_operators.h
@@ -64,6 +64,13 @@ void operator delete(void* p) throw()
 std::free(p);
 }
 
+void operator delete(void* p, const std::nothrow_t&) throw()
+{
+  if (p)
+std::free(p);
+}
+
+
 #endif // _GLIBCXX_TESTSUITE_NEW_OPERATORS_H
 
 

Re: [PATCH,rs6000] Consolidate Power9 Option Flags

[Segher Boessenkool]

Hello Kelvin,

On Thu, Jul 21, 2016 at 11:04:45AM -0600, Kelvin Nilsen wrote:
> This patch undocuments various compiler flags that are associated with
> different subsets of the full Power9 instruction set.  The benefits of
> hiding these option flags are to reduce testing complexity and to
> reduce the likelihood of user error (because certain combinations of
> flag values are not meaningful).  With this patch, users simply specify
> -mcpu=power9 and all of the relevant hidden (undocumented) flags are
> automatically enabled.
> 
> This patch has been bootstrapped and tested on powerpc64le-unkonwn-linux
> with no regressions.  Is this ok for the trunk?

Yes please.  One changelog nitpick...

>   * config/rs6000/rs6000.h: Add macro definition of MASK_FLOAT128
>   and change the macro definition of RS6000_BTM_FLOAT128 to correct
>   an error that was discovered during the development of this patch.

* config/rs6000/rs6000.h (MASK_FLOAT128): New macro.
(RS6000_BTM_FLOAT128): Use it.

Thanks,


Segher

[PATCH 3/4] Fix undefined behaviour in libstdc++ testsuite

[Jonathan Wakely]

This one's a bit more involved. There are a number of calls to
char_traits<>::copy() and char_traits<>::compare() that incorrectly
use the length of the larger array, not the shorter one.

The specialization in testsuite/util/testsuite_character.cc was
setting a null terminator after the numpunct atoms, past the end of he
array.

   Fix out-of-bound array accesses in libstdc++ testsuite
   
   	* testsuite/21_strings/basic_string/modifiers/append/char/1.cc: Fix

reads past the end of strings.
* testsuite/21_strings/basic_string/operations/compare/char/1.cc:
Likewise.
* testsuite/21_strings/char_traits/requirements/short/1.cc: Fix
invalid array accesses.
* testsuite/experimental/string_view/operations/compare/char/1.cc:
Fix read past the end of string.
* testsuite/util/testsuite_character.cc: Fix out-of-bounds write.


Tested powerpc64-linux, committed to trunk.
commit 11b5af6effaeb61d7a53dfc7fd6905d6cdd887e8
Author: redi 
Date:   Thu Jul 21 19:38:51 2016 +

Fix out-of-bound array accesses in libstdc++ testsuite

	* testsuite/21_strings/basic_string/modifiers/append/char/1.cc: Fix
	reads past the end of strings.
	* testsuite/21_strings/basic_string/operations/compare/char/1.cc:
	Likewise.
	* testsuite/21_strings/char_traits/requirements/short/1.cc: Fix
	invalid array accesses.
	* testsuite/experimental/string_view/operations/compare/char/1.cc:
	Fix read past the end of string.
	* testsuite/util/testsuite_character.cc: Fix out-of-bounds write.

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

diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/append/char/1.cc b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/append/char/1.cc
index 176c317..1ccb9da 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/append/char/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/append/char/1.cc
@@ -118,7 +118,7 @@ bool test01(void)
   VERIFY( str06 == "corpus, corpus" );
 
   str06 = str02;
-  str06.append("corpus, ", 12);
+  str06.append("corpus, ", 9); // n=9 includes null terminator
   VERIFY( str06 != "corpus, corpus, " );
 
 
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc b/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
index 55027b3..7fe30a7 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
@@ -80,10 +80,10 @@ test01()
   test_value(strcmp(str_1.data(), str_0.data()), lt);
   test_value(strcmp(str_0.data(), str_1.data()), gt);
   test_value(strncmp(str_1.data(), str_0.data(), 6), z);
-  test_value(strncmp(str_1.data(), str_0.data(), 14), lt);
+  test_value(strncmp(str_1.data(), str_0.data(), 10), lt);
   test_value(memcmp(str_1.data(), str_0.data(), 6), z);
-  test_value(memcmp(str_1.data(), str_0.data(), 14), lt);
-  test_value(memcmp("costa marbella", "costa rica", 14), lt);
+  test_value(memcmp(str_1.data(), str_0.data(), 10), lt);
+  test_value(memcmp("costa marbella", "costa rica", 10), lt);
 
   // int compare(const basic_string& str) const;
   test_value(str_0.compare(str_1), gt); //because r>m
diff --git a/libstdc++-v3/testsuite/21_strings/char_traits/requirements/short/1.cc b/libstdc++-v3/testsuite/21_strings/char_traits/requirements/short/1.cc
index 5b715a0..0a2d2ee 100644
--- a/libstdc++-v3/testsuite/21_strings/char_traits/requirements/short/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/char_traits/requirements/short/1.cc
@@ -75,10 +75,11 @@ void test02(void)
 
   const char_type str_lit1[] = {'m', 'o', 'n', 't', 'a', 'r', 'a', ' ', 'a', 'n', 'd', ' ', 'o', 'c', 'e', 'a', 'n', ' ', 'b', 'e', 'a', 'c', 'h', 0};
 
-  int len = sizeof(str_lit1)/sizeof(char_type) + sizeof(array1)/sizeof(char_type) - 1;
+  const int array2_len = sizeof(str_lit1)/sizeof(char_type) + sizeof(array1)/sizeof(char_type) - 1;
   // two terminating chars
   char_type array3[] = {'b', 'o', 'r', 'a', 'c', 'a', 'y', ',', ' ', 'p', 'h', 'i', 'l', 'i', 'p', 'p', 'i', 'n', 'e', 's', 0};
-  char_type array2[len];
+  char_type array2[array2_len];
+  int len = std::min(array2_len, sizeof(array3)/sizeof(char_type));
   std::char_traits::copy(array2, array3, len);
 
   VERIFY( str_lit1[0] == 'm' );
@@ -139,13 +140,12 @@ void test02(void)
   VERIFY( pc4 == 0 );
 
   // char_type* X::assign(char_type* s, size_t n, char_type c)
-  len = sizeof(array2) / sizeof(char_type);
-  std::memset(array2, 0xaf, len * sizeof(char_type));
+  std::memset(array2, 0xaf, array2_len * sizeof(char_type));
   VERIFY( array2[0] != 0x15a8 );
 
-  pc1 = std::char_traits::assign (array2, len, 0x15a8);
+  pc1 = std::char_traits::assign (array2, array2_len, 0x15a8);
   VERIFY( pc1 == array2 );
-  for (int i = 0; i < len; 

[PATCH] Fix naming, qualification and broken test for propagate_const

[Jonathan Wakely]

This test was invalid because it asserted that a default-constructed
propagate_const would be null, but it's intentional that the
default constructor doesn't initialize its member.

I also fixed things in  to meet our
conventions.

* include/experimental/propagate_const (propagate_const::__t): Rename
to _M_t and remove comment. Qualify std::move and std::forward.
* testsuite/experimental/propagate_const/cons/default.cc: Fix test.

Tested powerpc64-linux, committed to trunk.

commit 0752378113d2075d8ef5400900f043f6fa6b3b51
Author: redi 
Date:   Thu Jul 21 19:39:03 2016 +

Fix naming, qualification and broken test for propagate_const

* include/experimental/propagate_const (propagate_const::__t): Rename
to _M_t and remove comment. Qualify std::move and std::forward.
* testsuite/experimental/propagate_const/cons/default.cc: Fix test.

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

diff --git a/libstdc++-v3/include/experimental/propagate_const 
b/libstdc++-v3/include/experimental/propagate_const
index ea052ca..75cd8c0a 100644
--- a/libstdc++-v3/include/experimental/propagate_const
+++ b/libstdc++-v3/include/experimental/propagate_const
@@ -116,14 +116,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 is_convertible<_Up&&, _Tp>>::value, bool
  >::type=true>
   constexpr propagate_const(propagate_const<_Up>&& __pu)
-   : __t(move(get_underlying(__pu)))
+   : _M_t(std::move(get_underlying(__pu)))
   {}
   template ,
 __not_>>::value,
  bool>::type=false>
   constexpr explicit propagate_const(propagate_const<_Up>&& __pu)
-   : __t(move(get_underlying(__pu)))
+   : _M_t(std::move(get_underlying(__pu)))
   {}
   template ,
@@ -132,7 +132,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  typename decay<_Up>::type>>
 >::value, bool>::type=true>
   constexpr propagate_const(_Up&& __u)
-   : __t(forward<_Up>(__u))
+   : _M_t(std::forward<_Up>(__u))
   {}
   template ,
@@ -141,7 +141,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  typename decay<_Up>::type>>
 >::value, bool>::type=false>
   constexpr explicit propagate_const(_Up&& __u)
-   : __t(forward<_Up>(__u))
+   : _M_t(std::forward<_Up>(__u))
   {}
 
   // [propagate_const.assignment], assignment
@@ -152,7 +152,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typename enable_if::value>::type>
   constexpr propagate_const& operator=(propagate_const<_Up>&& __pu)
   {
-   __t = move(get_underlying(__pu));
+   _M_t = std::move(get_underlying(__pu));
   }
 
   template ::value>::type>
   constexpr propagate_const& operator=(_Up&& __u)
   {
-   __t = forward<_Up>(__u);
+   _M_t = std::forward<_Up>(__u);
   }
 
   // [propagate_const.const_observers], const observers
   explicit constexpr operator bool() const
   {
-   return bool(__t);
+   return bool(_M_t);
   }
 
   constexpr const element_type* operator->() const
@@ -193,7 +193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   constexpr const element_type* get() const
   {
-   return __to_raw_pointer(__t);
+   return __to_raw_pointer(_M_t);
   }
 
   // [propagate_const.non_const_observers], non-const observers
@@ -219,7 +219,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   constexpr element_type* get()
   {
-   return __to_raw_pointer(__t);
+   return __to_raw_pointer(_M_t);
   }
 
   // [propagate_const.modifiers], modifiers
@@ -227,11 +227,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   swap(propagate_const& __pt) noexcept(__is_nothrow_swappable<_Tp>::value)
   {
using std::swap;
-   swap(__t, get_underlying(__pt));
+   swap(_M_t, get_underlying(__pt));
   }
 
 private:
-  _Tp __t; //exposition only
+  _Tp _M_t;
 };
 
   // [propagate_const.relational], relational operators
@@ -408,14 +408,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 constexpr const _Tp&
 get_underlying(const propagate_const<_Tp>& __pt) noexcept
 {
-  return __pt.__t;
+  return __pt._M_t;
 }
 
   template 
 constexpr _Tp&
 get_underlying(propagate_const<_Tp>& __pt) noexcept
 {
-  return __pt.__t;
+  return __pt._M_t;
 }
 
   // @} group propagate_const
diff --git 
a/libstdc++-v3/testsuite/experimental/propagate_const/cons/default.cc 
b/libstdc++-v3/testsuite/experimental/propagate_const/cons/default.cc
index 6a9a8c6..ed597fb 100644
--- a/libstdc++-v3/testsuite/experimental/propagate_const/cons/default.cc
+++ 

[PATCH 2/4] Fix undefined behaviour in libstdc++ testsuite

[Jonathan Wakely]

This one just fixes some missing returns, where the functions should
have been declared to return void anyway.

   Fix missing returns in libstdc++ testsuite
   
   	* testsuite/24_iterators/container_access.cc: Fix missing returns.

* testsuite/24_iterators/range_access_cpp14.cc: Likewise.

Tested powerpc64-linux, committed to trunk.
commit 485fa6438286f25d3e1b66e7280d2c5105628416
Author: redi 
Date:   Thu Jul 21 19:38:44 2016 +

Fix missing returns in libstdc++ testsuite

	* testsuite/24_iterators/container_access.cc: Fix missing returns.
	* testsuite/24_iterators/range_access_cpp14.cc: Likewise.

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

diff --git a/libstdc++-v3/testsuite/24_iterators/container_access.cc b/libstdc++-v3/testsuite/24_iterators/container_access.cc
index a9cb54e..f4d4f7e 100644
--- a/libstdc++-v3/testsuite/24_iterators/container_access.cc
+++ b/libstdc++-v3/testsuite/24_iterators/container_access.cc
@@ -47,7 +47,7 @@ test02()
   static_assert(!e);
 }
 
-int
+void
 test03()
 {
   std::initializer_list il{1,2,3};
@@ -67,7 +67,7 @@ test03()
 
 }
 
-int
+void
 test04()
 {
   std::vector v{1,2,3};
diff --git a/libstdc++-v3/testsuite/24_iterators/range_access_cpp14.cc b/libstdc++-v3/testsuite/24_iterators/range_access_cpp14.cc
index 9292fa6..79fb0f4b 100644
--- a/libstdc++-v3/testsuite/24_iterators/range_access_cpp14.cc
+++ b/libstdc++-v3/testsuite/24_iterators/range_access_cpp14.cc
@@ -48,7 +48,7 @@ test02()
   constexpr auto ce __attribute__((unused)) = std::cend(i);
 }
 
-int
+void
 test03()
 {
   std::initializer_list il{1};
@@ -60,7 +60,7 @@ test03()
   VERIFY(std::crend(il) == std::reverse_iterator(il.begin()));
 }
 
-int
+void
 test04()
 {
   std::vector v{1};

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

[Eric Gallager]

On 7/21/16, Jeff Law  wrote:
> On 07/14/2016 01:57 PM, Eric Gallager wrote:
>
>>
>> So apparently the "-f" flag properly overwrites symlinks that point to
>> regular files, but I also did this in my gcc builddir:
>>
>> $ mkdir isl-0.1.2.3
>> $ ln -s isl-0.1.2.3 isl-s
>> $ ln -sfv isl isl-s
>> isl-s/isl -> isl
>> $ ln -sfFv isl isl-s
>> isl-s/isl -> isl
>> $ ls -l isl-s
>> lrwxr-xr-x  1 root  wheel  11 Jul 14 07:03 isl-s -> isl-0.1.2.3
>> $ unlink isl-s
>> $ ln -sfFv isl isl-s
>> isl-s -> isl
>> $ ls -l isl-s
>> lrwxr-xr-x  1 root  wheel  3 Jul 14 15:51 isl-s -> isl
>>
>> ...it just doesn't overwrite symlinks that point to a directory.
> Joys :(
>
> AFAIK unlink may not necessarily be available on the various host
> systems GCC supports (solaris, aix, hpux, etc etc).
>
> So rather than relying on ln to remove the link, why don't we just
> explicitly remove it with rm -f?
>
> Jeff
>

Sure, rm -f works, too; I just went with "unlink" in my patch because
it more clearly expresses programmer intent. But I guess portability
is more important. Updated patch attached, although someone else would
have to commit it, as I don't have commit access.

Eric
 contrib/download_prerequisites | 4 
 1 file changed, 4 insertions(+)

diff --git a/contrib/download_prerequisites b/contrib/download_prerequisites
index 917ee23..2c963f2 100755
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -36,14 +36,17 @@ MPC=mpc-1.0.3
 
 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1
 tar xjf $MPFR.tar.bz2 || exit 1
+if test -L mpfr; then rm -f mpfr; fi
 ln -sf $MPFR mpfr || exit 1
 
 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$GMP.tar.bz2 || exit 1
 tar xjf $GMP.tar.bz2  || exit 1
+if test -L gmp; then rm -f gmp; fi
 ln -sf $GMP gmp || exit 1
 
 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPC.tar.gz || exit 1
 tar xzf $MPC.tar.gz || exit 1
+if test -L mpc; then rm -f mpc; fi
 ln -sf $MPC mpc || exit 1
 
 # Necessary to build GCC with the Graphite loop optimizations.
@@ -52,5 +55,6 @@ if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then
 
   wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2 || exit 1
   tar xjf $ISL.tar.bz2  || exit 1
+  if test -L isl; then rm -f isl; fi
   ln -sf $ISL isl || exit 1
 fi

[PATCH 1/4] Fix undefined behaviour in libstdc++ testsuite

[Jonathan Wakely]

I've finally got the testsuite able to run with ubsan and asan
enabled, with a few hacks in place. That revealed quite a few
problems!

The first patch in this series just frees some memory which wasn't
being deallocated. That isn't really a problem, as the tests exit
immediately anyway, but it's nice to get clean reports from leak
checkers.

* testsuite/18_support/new_delete_placement.cc: Don't allocate (and
leak) memory for arguments to placement delete.
* testsuite/20_util/addressof/1.cc: Don't leak memory.
* testsuite/22_locale/locale/global_locale_objects/3.cc: Likewise.
* testsuite/23_containers/unordered_multimap/insert/55028-debug.cc:
Likewise.

Tested powerpc64-linux, committed to trunk.

commit 45bf3919ae2dbf9223f10c4dd854a13fd2ebc7ee
Author: Jonathan Wakely 
Date:   Wed Jul 20 22:32:52 2016 +0100

Remove memory leaks in libstdc++ testsuite

* testsuite/18_support/new_delete_placement.cc: Don't allocate (and
leak) memory for arguments to placement delete.
* testsuite/20_util/addressof/1.cc: Don't leak memory.
* testsuite/22_locale/locale/global_locale_objects/3.cc: Likewise.
* testsuite/23_containers/unordered_multimap/insert/55028-debug.cc:
Likewise.

diff --git a/libstdc++-v3/testsuite/18_support/new_delete_placement.cc 
b/libstdc++-v3/testsuite/18_support/new_delete_placement.cc
index 2c4607b..9049dca 100644
--- a/libstdc++-v3/testsuite/18_support/new_delete_placement.cc
+++ b/libstdc++-v3/testsuite/18_support/new_delete_placement.cc
@@ -25,11 +25,11 @@
 // libstdc++/7286
 void test01()
 {
-  void* pc = new char;
-  void* pa = new char[10];
+  char c = 'c';
+  void* p = 
   void* tmp = 0;
-  operator delete(pc, tmp);
-  operator delete[](pa, tmp);
+  operator delete(p, tmp);
+  operator delete[](p, tmp);
 }
 
 int main()
diff --git a/libstdc++-v3/testsuite/20_util/addressof/1.cc 
b/libstdc++-v3/testsuite/20_util/addressof/1.cc
index 7208fc4..732eebc 100644
--- a/libstdc++-v3/testsuite/20_util/addressof/1.cc
+++ b/libstdc++-v3/testsuite/20_util/addressof/1.cc
@@ -41,6 +41,9 @@ void test01()
   VERIFY( std::addressof(o2) == ao2 );
 
   VERIFY( std::addressof(f1) ==  );
+
+  delete ao1;
+  delete ao2;
 }
 
 int main()
diff --git a/libstdc++-v3/testsuite/22_locale/locale/global_locale_objects/3.cc 
b/libstdc++-v3/testsuite/22_locale/locale/global_locale_objects/3.cc
index 0eb656c..ec33614 100644
--- a/libstdc++-v3/testsuite/22_locale/locale/global_locale_objects/3.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/global_locale_objects/3.cc
@@ -73,13 +73,15 @@ void test03()
 VERIFY( loc04 == global_orig );
   }
 
-  // 2: Not destroyed when out of scope, deliberately leaked.
+  // 2: Not destroyed when out of scope, deliberately "leaked".
+  const facet_type* ptr = 0;
   {
 {
   {
VERIFY( counter == 0 );
{
- locale loc01(locale::classic(), new facet_type(1));
+  ptr = new facet_type(1);
+ locale loc01(locale::classic(), ptr);
  VERIFY( counter == 1 );
  global_orig = locale::global(loc01);
  name = loc01.name();
@@ -101,6 +103,9 @@ void test03()
   }
   VERIFY( counter == 1 );
 
+  // Clean up.
+  delete ptr;
+
   // Restore global settings.
   locale::global(global_orig);
 }
diff --git 
a/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/55028-debug.cc 
b/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/55028-debug.cc
index 65830ad..e7afc8f 100644
--- 
a/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/55028-debug.cc
+++ 
b/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/55028-debug.cc
@@ -30,7 +30,7 @@ void test()
   // using MyMap = std::multimap; // works
   using MyMap = std::unordered_multimap; // fails to link
   MyMap m;
-  m.insert(std::make_pair(std::string("blah"), new MyType));
+  m.insert(std::make_pair(std::string("blah"), (MyType*)nullptr));
 }
 
 int main()

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

[Alessandro Fanfarillo]

Dear Mikael and all,

in attachment the new patch, built and regtested on x86_64-pc-linux-gnu.

Cheers,
Alessandro

2016-07-20 13:17 GMT-06:00 Mikael Morin :
> Le 20/07/2016 à 11:39, Andre Vehreschild a écrit :
>>
>> Hi Mikael,
>>
>>
 +  if(st == ST_FAIL_IMAGE)
 +new_st.op = EXEC_FAIL_IMAGE;
 +  else
 +gcc_unreachable();
>>>
>>> You can use
>>> gcc_assert (st == ST_FAIL_IMAGE);
>>> foo...;
>>> instead of
>>> if (st == ST_FAIL_IMAGE)
>>> foo...;
>>> else
>>> gcc_unreachable ();
>>
>>
>> Be careful, this is not 100% identical in the general case. For older
>> gcc version (gcc < 4008) gcc_assert() is mapped to nothing, esp. not to
>> an abort(), so the behavior can change. But in this case everything is
>> fine, because the patch is most likely not backported.
>>
> Didn't know about this. The difference seems to be very subtle.
> I don't mind much anyway. The original version can stay if preferred, this
> was just a suggestion.
>
> By the way, if the function is inlined in its single caller, the assert or
> unreachable statement can be removed, which avoids choosing between them.
> That's another suggestion.
>
>
 +
 +  return MATCH_YES;
 +
 + syntax:
 +  gfc_syntax_error (st);
 +
 +  return MATCH_ERROR;
 +}
 +
 +match
 +gfc_match_fail_image (void)
 +{
 +  /* if (!gfc_notify_std (GFC_STD_F2008_TS, "FAIL IMAGE statement
 at %C")) */
 +  /*   return MATCH_ERROR; */
 +
>>>
>>> Can this be uncommented?
>>>
 +  return fail_image_statement (ST_FAIL_IMAGE);
 +}

  /* Match LOCK/UNLOCK statement. Syntax:
   LOCK ( lock-variable [ , lock-stat-list ] )
 diff --git a/gcc/fortran/trans-intrinsic.c
 b/gcc/fortran/trans-intrinsic.c index 1aaf4e2..b2f5596 100644
 --- a/gcc/fortran/trans-intrinsic.c
 +++ b/gcc/fortran/trans-intrinsic.c
 @@ -1647,6 +1647,24 @@ trans_this_image (gfc_se * se, gfc_expr
 *expr) m, lbound));
  }

 +static void
 +gfc_conv_intrinsic_image_status (gfc_se *se, gfc_expr *expr)
 +{
 +  unsigned int num_args;
 +  tree *args,tmp;
 +
 +  num_args = gfc_intrinsic_argument_list_length (expr);
 +  args = XALLOCAVEC (tree, num_args);
 +
 +  gfc_conv_intrinsic_function_args (se, expr, args, num_args);
 +
 +  if (flag_coarray == GFC_FCOARRAY_LIB)
 +{
>>>
>>> Can everything be put under the if?
>>> Does it work with -fcoarray=single?
>>
>>
>> IMO coarray=single should not generate code here, therefore putting
>> everything under the if should to fine.
>>
> My point was more avoiding generating code for the arguments if they are not
> used in the end.
> Regarding the -fcoarray=single case, the function returns a result, which
> can be used in an expression, so I don't think it will work without at least
> hardcoding a fixed value as result in that case.
> But even that wouldn't be enough, as the function wouldn't work consistently
> with the fail image statement.
>
>> Sorry for the comments ...
>>
> Comments are welcome here, as far as I know. ;-)
>
> Mikael
commit d6c91b2c14a12d1d012738f13f4920e207113982
Author: Alessandro Fanfarillo 
Date:   Thu Jul 21 10:01:33 2016 -0600

First review of failed images patch

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index d26e45e..121551c 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1210,6 +1210,97 @@ gfc_check_event_query (gfc_expr *event, gfc_expr *count, 
gfc_expr *stat)
   return true;
 }
 
+bool
+gfc_check_image_status (gfc_expr *image, gfc_expr *team)
+{
+
+  if (flag_coarray != GFC_FCOARRAY_LIB)
+{
+  gfc_fatal_error ("Failed images features "
+  "usable only with %<-fcoarray=lib%>");
+  return false;
+}
+
+  if (!type_check (image, 1, BT_INTEGER))
+return false;
+
+  int i = gfc_validate_kind (BT_INTEGER, image->ts.kind, false);
+  int j = gfc_validate_kind (BT_INTEGER, gfc_default_integer_kind, false);
+
+  if (gfc_integer_kinds[i].range < gfc_integer_kinds[j].range)
+{
+  gfc_error ("IMAGE argument of the IMAGE_STATUS intrinsic function at %L "
+"shall have at least the range of the default integer",
+>where);
+  return false;
+}
+
+  j = gfc_validate_kind (BT_INTEGER, gfc_default_integer_kind*2, false);
+
+  if (gfc_integer_kinds[i].range > gfc_integer_kinds[j].range)
+{
+  gfc_error ("IMAGE argument of the IMAGE_STATUS intrinsic function at %L "
+"shall have at most the range of the double precision integer",
+>where);
+  return false;
+}
+
+  if (team)
+{
+  gfc_error ("TEAM argument of the IMAGE_STATUS intrinsic function at %L "
+"not yet supported",
+>where);
+  return false;
+}
+
+  return true;
+}
+
+bool
+gfc_check_failed_images (gfc_expr *team, 

Re: [RFC, v2] Test coverage for --param boundary values

[Jeff Law]

On 07/18/2016 01:53 AM, Martin Liška wrote:

You are right, I was inspired by what we do for GCC plugins in:
gcc/testsuite/lib/plugin-support.exp

where we have following comment:
# Note that the plugin test support currently only works when the GCC
# build tree is available. (We make sure that is the case in plugin.exp.)
# Once we have figured out how/where to package/install GCC header files
# for general plugin support, we should modify the following include paths
# accordingly.

Well, I can imaging a guard which will test whether 
"$objdir/../../params.options" file exits,
and if so, then the tests are executed? Is it acceptable approach?

Yes.  That's acceptable to me.




>

>> +set text [read $fd]
>> +close $fd
>> +
>> +# Main loop.
>> +foreach params [split $text "\n"] {
>> +set parts [split $params "="]
>> +set name [string trim [lindex $parts 0] '"']
>> +set values [split [lindex $parts 1] ","]
>> +if { [llength $values] == 3 } {
>> +  set default [lindex $values 0]
>> +  set min [lindex $values 1]
>> +  set max [lindex $values 2]
>> +  set int_max "INT_MAX"
>> +
>> +  if { $min != -1 } {
>> +  param_run_test $name $min
>> +  }
>> +  if { $max != $min && $max > 0 && $max != $int_max } {
>> +  param_run_test $name $max
>> +  }
>> +}
>> +if { [llength $values] == 5 } {
>> +  foreach v $values {
>> +  param_run_test $name $v
>> +  }
>> +}
>> +}

>
> This produces ambiguous test result lines:
>
> Running 
/scratch/tschwing/nvidiak20-2/gcc/trunk-light/source-gcc/gcc/testsuite/gcc.dg/params/params.exp
 ...
> PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c (test for excess errors)
> [many more]
>
> OK to fix this as follows:
>
> PASS: gcc.dg/params/blocksort-part.c -O3 --param 
predictable-branch-outcome=0 (test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c -O3 --param 
predictable-branch-outcome=50 (test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c -O3 --param inline-min-speedup=0 
(test for excess errors)
> PASS: gcc.dg/params/blocksort-part.c -O3 --param 
max-inline-insns-single=0 (test for excess errors)
> [...]
>
> commit ae350ce9af062d7d2c05225280596b1bc982728b
> Author: Thomas Schwinge 
> Date:   Fri Jul 15 09:13:19 2016 +0200
>
> Disambiguate gcc.dg/params/params.exp test results
>
>gcc/testsuite/
>* gcc.dg/params/params.exp (param_run_test): Swap flags and
>default-extra-flags arguments when calling dg-runtest.
> ---
>  gcc/testsuite/gcc.dg/params/params.exp |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git gcc/testsuite/gcc.dg/params/params.exp 
gcc/testsuite/gcc.dg/params/params.exp
> index f2f397e..dd82a5d 100644
> --- gcc/testsuite/gcc.dg/params/params.exp
> +++ gcc/testsuite/gcc.dg/params/params.exp
> @@ -28,7 +28,7 @@ proc param_run_test { param_name param_value } {
>  global srcdir
>  global subdir
>
> -dg-runtest $srcdir/$subdir/blocksort-part.c "" "-O3 --param 
$param_name=$param_value"
> +dg-runtest $srcdir/$subdir/blocksort-part.c "-O3 --param $param_name=$param_value" 
""
>  }
>
>  set fd [open "$objdir/../../params.options" r]
>
>
> Grüße
>  Thomas
>

Thanks for the patch, that's probably the same problem that Andreas spotted.
I'm sending candidate patch.

Martin


0001-Fix-params.exp-test-cases.patch


From d5e3c5cb20306352af7f45cd827669b7ff51a709 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 18 Jul 2016 09:50:12 +0200
Subject: [PATCH] Fix params.exp test-cases

gcc/testsuite/ChangeLog:

2016-07-18  Thomas Schwinge  
Martin Liska  

* gcc.dg/params/LICENSE: Add missing LICENSE that is mentioned
in a source file.
* gcc.dg/params/README: Same for the README.
* gcc.dg/params/params.exp (param_run_test): Swap flags and
default-extra-flags arguments when calling dg-runtest.

OK.

jeff

Re: C, C++: Fix PR 69733 (bad location for ignored qualifiers warning)

[Jeff Law]

On 07/15/2016 07:04 AM, Bernd Schmidt wrote:

On 06/22/2016 05:37 AM, Jeff Law wrote:

It looks like this stalled...

Anyway, it's fine for the trunk.


Some of the surrounding code was changed a bit to produce different
errors for different C standards, so I had to make an adjustment to the
patch. While I was here, I added cdw_atomic to the list of qualifiers to
look for, and added a C-specific testcase for that case.

Retested as before. Ok for this version too?


Bernd

declspecs-v3.diff


c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c (grokdeclarator): Try to find the correct location for an
ignored qualifier.
testsuite/
PR c++/69733
* c-c++-common/pr69733.c: New test.
* gcc.dg/pr69733.c: New test.
* gcc.target/i386/pr69733.c: New test.

Yes, this version is OK too.

jeff

Re: [libstdc++] Add C++17clamp

[Jonathan Wakely]

On 15/07/16 13:34 -0400, Ed Smith-Rowland wrote:



OK for trunk, thanks.


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


p0096r3 proposes __cpp_lib_clamp = 201603.

I added the feature macro and committed the attached as 238383.

Thanks,

Ed




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

Implement C++17 P0025 clamp.
* include/bits/algorithmfwd.h: Declare clamp overloads.
* include/bits/stl_algo.h: Implement clamp.  Feature __cpp_lib_clamp.
* testsuite/25_algorithms/clamp/1.cc: New test.
* testsuite/25_algorithms/clamp/2.cc: New test.
* testsuite/25_algorithms/clamp/constexpr.cc: New test.
* testsuite/25_algorithms/clamp/requirements/explicit_instantiation/
1.cc: New test.
* testsuite/25_algorithms/clamp/requirements/explicit_instantiation/
pod.cc: New test.




+  const int xc = std::clamp(1, 2, 4, std::greater());
+  const int yc = std::clamp(3, 2, 4, std::greater());
+  const int zc = std::clamp(5, 2, 4, std::greater());


These all violate the precondition that !comp(hi, lo)
i.e. !greater(1, 0)

The arguments need to be re-arranged, and then these are wrong:


+  VERIFY( xc == 4 );
+  VERIFY( yc == 2 );
+  VERIFY( zc == 2 );




+static_assert(std::clamp(2, 0, 1) == 1, "");
+static_assert(std::clamp(2, 0, 1, std::greater()) == 0, "");


Same here. If the arguments are clamp(2, 1, 0, greater()) then it
returns 1.

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

[Bernd Edlinger]

Hi,

 > So rather than relying on ln to remove the link, why don't we just
 > explicitly remove it with rm -f?

sounds good, I ran into similar issues already.

ln -nfs does not follow the target if it is a symlink

-n, --no-dereference
   treat  LINK_NAME  as a normal file if it is a symbolic 
link to a
   directory


but I think a simple rm -f will do as well, and avoid potential
interoperability issues.

However wget has a similar issue, if the $MPFR.tar.gz file is already
there, maybe incomplete, the wget chooses a new name, so I'd suggest
to rm -f that file as well, and the whole $MPFR subtree while you are
already there.


Bernd.

Re: [C++ PATCH] Fix ICE with statement expression (PR c++/71728)

[Jason Merrill]

OK.

On Thu, Jul 21, 2016 at 12:09 PM, Jakub Jelinek  wrote:
> Hi!
>
> It is true that parsing should make sure that GOTO_EXPRs (other than
> break/continue) aren't allowed in constant expression contexts, but
> potential_constant_expression_1 may be called (with tf_none) also
> on arbitrary code either for warning purposes, or (very recent change)
> also in cp_fully_fold, usually from maybe_constant_value.
>
> So asserting they don't appear doesn't work.
>
> Fixed thusly, alternatively we could assert that (flags & tf_error) == 0
> before returning false.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/6.2?
>
> 2016-07-21  Jakub Jelinek  
>
> PR c++/71728
> * constexpr.c (potential_constant_expression_1) :
> Replace assert with test, return false if the goto isn't break
> or continue.  Formatting fix.
>
> * g++.dg/other/pr71728.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2016-07-21 08:59:50.0 +0200
> +++ gcc/cp/constexpr.c  2016-07-21 12:05:16.828618186 +0200
> @@ -5289,10 +5289,12 @@ potential_constant_expression_1 (tree t,
>  case GOTO_EXPR:
>{
> tree *target = _OPERAND (t, 0);
> -   /* Gotos representing break and continue are OK; we should have
> -  rejected other gotos in parsing.  */
> -   gcc_assert (breaks (target) || continues (target));
> -   return true;
> +   /* Gotos representing break and continue are OK.  */
> +   if (breaks (target) || continues (target))
> + return true;
> +   if (flags & tf_error)
> + error ("% is not a constant-expression");
> +   return false;
>}
>
>  default:
> @@ -5300,7 +5302,7 @@ potential_constant_expression_1 (tree t,
> return false;
>
>sorry ("unexpected AST of kind %s", get_tree_code_name (TREE_CODE 
> (t)));
> -  gcc_unreachable();
> +  gcc_unreachable ();
>return false;
>  }
>  #undef RECUR
> --- gcc/testsuite/g++.dg/other/pr71728.C.jj 2016-07-21 12:13:31.686461551 
> +0200
> +++ gcc/testsuite/g++.dg/other/pr71728.C2016-07-21 12:14:46.974524876 
> +0200
> @@ -0,0 +1,11 @@
> +// PR c++/71728
> +// { dg-do compile }
> +// { dg-options "-std=gnu++14 -Wall" }
> +
> +int
> +foo ()
> +{
> +  if (({ goto test; test: 1; }) != 1)
> +return 1;
> +  return 2;
> +}
>
> Jakub

Re: [patch, Fortran] Fix some string temporaries

[H.J. Lu]

On Tue, Jul 19, 2016 at 2:27 PM, Thomas Koenig  wrote:
> Hi Mikael,
>
>> Then handle the GFC_DEP_ERROR here. Or initialize fin_dep with
>> GFC_DEP_NODEP at the beginning, as you prefer.
>> OK with either (and the unreachable assertions).
>
>
> Here is the pacth the way I committed it.
>
> Thanks for the review and the comments.
>
> Regards
>
> Thomas
>
> 2016-07-19  Thomas Koenig  
>
> PR fortran/71902
> * dependency.c (gfc_check_dependency): Use dep_ref.  Handle case
> if identical is true and two array element references differ.
> (gfc_dep_resovler):  Move most of the code to dep_ref.
> (dep_ref):  New function.
> * frontend-passes.c (realloc_string_callback):  Name temporary
> variable "realloc_string".
>
> 2016-07-19  Thomas Koenig  
>
>
> PR fortran/71902
> * gfortran.dg/dependency_47.f90:  New test.

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961

-- 
H.J.

Re: [PATCH] Merge liboffloadmic from upstream

[Jakub Jelinek]

On Thu, Jul 21, 2016 at 08:46:00PM +0300, Ilya Verbin wrote:
> This patch contains an update for liboffloadmic, imported from
> , version 20160715.
> 
> abidiff didn't show any difference in the functions, which are used by libgomp
> plugin.  make check with intelmicemul passed.  OK for trunk?

Ok, thanks.

Jakub

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

[David Malcolm]

On Thu, 2016-07-21 at 10:38 -0400, David Malcolm wrote:
> On Thu, 2016-07-21 at 10:28 -0400, David Malcolm wrote:
> > On Thu, 2016-07-21 at 09:00 +0200, Uros Bizjak wrote:
> > > Hello!
> > > 
> > > > > gcc/ChangeLog:
> > > > > PR c/70339
> > > > > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
> > > > > the
> > > > > same location as last time, don't skip if we have fix-it
> > > > > hints.
> > > > > Clarify the skipping logic by converting it from one "if"
> > > > > clause
> > > > > to repeated "if" clauses.
> > > > > * spellcheck-tree.c: Include "cpplib.h".
> > > > > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
> > > > > (best_macro_match::best_macro_match): New constructor.
> > > > > * spellcheck-tree.h (struct edit_distance_traits > > > > *>):
> > > > > Move here from c/c-decl.c.
> > > > > (class best_macro_match): Move here from c/c-decl.c,
> > > > > converting
> > > > > from a typedef to a subclass, gaining a ctor.
> > > 
> > > This part introduced bootstrap failure on CentOS 5.11:
> > > 
> > > g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict
> > > -aliasing
> > > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> > > -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format
> > > -attribute
> > > -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
> > > -I../../git/gcc/gcc -I../../git/gcc/gcc/.
> > > -I../../git/gcc/gcc/../include 
> > > -I../../git/gcc/gcc/../libcpp/include
> > > -I/usr/local/include -I/usr/local/include -I/usr/local/include
> > > -I../../git/gcc/gcc/../libdecnumber
> > > -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
> > > -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
> > > spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
> > > ../../git/gcc/gcc/spellcheck-tree.c
> > > ../../git/gcc/gcc/spellcheck-tree.c: In constructor
> > > ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
> > > cpp_reader*)’:
> > > ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
> > > ‘best_macro_match’ does not have any field named ‘best_match’
> > > ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching
> > > function
> > > for call to ‘best_match::best_match()’
> > > ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
> > > best_match::best_match(GOAL_TYPE,
> > > edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
> > > cpp_hashnode*]
> > > ../../git/gcc/gcc/spellcheck.h:81: note:
> > > best_match::best_match(const
> > > best_match&)
> > > gmake: *** [spellcheck-tree.o] Error 1
> > > 
> > > CentOS 5 has pretty old system compiler [gcc version 4.1.2
> > > 20080704
> > > (Red Hat 4.1.2-55)], but the build worked until the above patch
> > > was
> > > committed. Is it possible to work around this failure somehow?
> > 
> > Sorry about the breakage.
> > 
> > I've now built a gcc 4.1 locally, and with that I can reproduce the
> > issue.  Am investigating...
> 
> The following patch seems to fix it; successfully compiles that file
> with my local builds of gcc 7 and gcc 4.1 (and with Fedora system gcc
> 4.8.3).
> 
> Does it fix the build for you?
> 
> Bootstrap underway here.
> 
> gcc/ChangeLog:
>   * spellcheck-tree.c (best_macro_match::best_macro_match):
>   Explicitly specify the template arguments when invoking the
> base
>   class constructor, to help older C++ compilers.
> 
> Sorry again about the breakage.

This patch survived bootstrap, and compiles and runs OK with
gcc-4.1, so I've committed it to trunk as r238598 (under the "obvious"
rule).

Please let me know if there are any configurations for which it still
doesn't work.

Sorry again.

Dave

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

[Thomas Schwinge]

Hi!

On Wed, 20 Jul 2016 08:27:56 -0400, Nathan Sidwell  wrote:
> On 07/19/16 14:34, Alexander Monakov wrote:
> > I've recently committed a middle-end patch that adds handling of undefined
> > variables (that the nvptx backend needs) under -fno-toplevel-reorder (svn 
> > rev.
> > 238371).  With that change, it's no longer necessary to implicitly enable
> > -ftoplevel-reorder in the backend, and the following patch removes that.

Yay for less special-casing!

> > Tested with nvptx-none-run, OK for trunk?
> 
> ok thanks

Hmm.  In an offloading configuration I see the following regression:

[-PASS:-]{+FAIL:+} 
libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test 
for excess errors)
[-PASS:-]{+UNRESOLVED:+} 
libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  
[-execution test-]{+compilation failed to produce executable+}

ptxas /tmp/ccmABlIh.o, line 971; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1008; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1017; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1035; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1331; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1373; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1385; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 1408; error   : State space mismatch between 
instruction and address in instruction 'atom'
ptxas /tmp/ccmABlIh.o, line 971; error   : Unknown symbol '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 971; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1008; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1008; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1017; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1017; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1035; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1035; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1331; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1331; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1373; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1373; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1385; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1385; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1408; error   : Unknown symbol 
'__reduction_lock'
ptxas /tmp/ccmABlIh.o, line 1408; error   : Label expected for forward 
reference of '__reduction_lock'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: 
[...]/build-gcc/gcc/x86_64-pc-linux-gnu-accel-nvptx-none-gcc return
ed 1 exit status
compilation terminated.
lto-wrapper: fatal error: [...]/build-gcc/gcc//accel/nvptx-none/mkoffload 
returned 1 exit s
tatus
compilation terminated.
[...]/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

Same for C++.

..., and in nvptx-none target testing I see the following:

C:

[-PASS:-]{+WARNING: program timed out.+}
{+FAIL:+} gcc.dg/large-size-array-4.c (test for excess errors)

This one times out when creating a huge *.s file:

[...]
.global .align 8 .u64 name[2147483649] = { 0, 0, [...]

Running with -ftoplevel-reorder (as implicitly enabled before), a *.s
file with just the preamble gets created.  Are these behaviors correct?

[-PASS:-]{+FAIL:+} gcc.dg/pr16973.c (test for excess errors)

[...]/source-gcc/gcc/testsuite/gcc.dg/pr16973.c:12:1: error: initializer 
for integer/fixed-point value is too complicated

C++:

PASS: g++.dg/debug/dwarf2/dwarf4-typedef.C  -std=gnu++98  (test for 
warnings, line 9)
FAIL: g++.dg/debug/dwarf2/dwarf4-typedef.C  -std=gnu++98 (test for excess 
errors)
PASS: g++.dg/debug/dwarf2/dwarf4-typedef.C  -std=gnu++11  (test for 
warnings, line 9)
[-PASS:-]{+FAIL:+} 

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

[Jeff Law]

On 07/14/2016 01:57 PM, Eric Gallager wrote:



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

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

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

Joys :(

AFAIK unlink may not necessarily be available on the various host 
systems GCC supports (solaris, aix, hpux, etc etc).


So rather than relying on ln to remove the link, why don't we just 
explicitly remove it with rm -f?


Jeff

[PATCH,rs6000] Consolidate Power9 Option Flags

[Kelvin Nilsen]

This patch undocuments various compiler flags that are associated with
different subsets of the full Power9 instruction set.  The benefits of
hiding these option flags are to reduce testing complexity and to
reduce the likelihood of user error (because certain combinations of
flag values are not meaningful).  With this patch, users simply specify
-mcpu=power9 and all of the relevant hidden (undocumented) flags are
automatically enabled.

This patch has been bootstrapped and tested on powerpc64le-unkonwn-linux
with no regressions.  Is this ok for the trunk?

Thanks.

gcc/ChangeLog:

2016-07-21  Kelvin Nilsen  

* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
comments to explain why certain error messages make mention of
undocumented options.
(rs6000_invalid_builtin): Change error messages to replace mention
of undocumented options with mention of the -mcpu=power9 option
that enables those undocumented options.
* config/rs6000/rs6000.h: Add macro definition of MASK_FLOAT128
and change the macro definition of RS6000_BTM_FLOAT128 to correct
an error that was discovered during the development of this patch.
* config/rs6000/rs6000.opt: Add the Undocumented qualifier to the
mpower9-fusion, mpower9-vector, mpower9-dform, and mmodulo entries.
* doc/extend.texi (PowerPC AltiVec Built-in Functions): Modify
descriptions of built-in functions so that they depend on
-mcpu=power9 instead of on the corresponding undocumented flags.
* doc/invoke.texi (Option Summary):  Remove all mention of newly
undocumented flags.
(IBM RS/6000 and PowerPC Options): Likewise.
* doc/md.texi (Constraints for Particuliar Machines): Remove all
mention of newly undocumented flags.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 238439)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4212,6 +4212,10 @@ rs6000_option_override_internal (bool global_init_
 {
   if (rs6000_isa_flags_explicit & OPTION_MASK_P8_FUSION)
{
+ /* We prefer to not mention undocumented options in
+error messages.  However, if users have managed to select
+power9-fusion without selecting power8-fusion, they
+already know about undocumented flags.  */
  error ("-mpower9-fusion requires -mpower8-fusion");
  rs6000_isa_flags &= ~OPTION_MASK_P9_FUSION;
}
@@ -4259,6 +4263,10 @@ rs6000_option_override_internal (bool global_init_
   /* ISA 3.0 vector instructions include ISA 2.07.  */
   if (TARGET_P9_VECTOR && !TARGET_P8_VECTOR)
 {
+  /* We prefer to not mention undocumented options in
+error messages.  However, if users have managed to select
+power9-vector without selecting power8-vector, they
+already know about undocumented flags.  */
   if (rs6000_isa_flags_explicit & OPTION_MASK_P8_VECTOR)
error ("-mpower9-vector requires -mpower8-vector");
   rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR;
@@ -4286,6 +4294,10 @@ rs6000_option_override_internal (bool global_init_
   /* ISA 3.0 D-form instructions require p9-vector and upper-regs.  */
   if ((TARGET_P9_DFORM_SCALAR || TARGET_P9_DFORM_VECTOR) && !TARGET_P9_VECTOR)
 {
+  /* We prefer to not mention undocumented options in
+error messages.  However, if users have managed to select
+power9-dform without selecting power9-vector, they
+already know about undocumented flags.  */
   if (rs6000_isa_flags_explicit & OPTION_MASK_P9_VECTOR)
error ("-mpower9-dform requires -mpower9-vector");
   rs6000_isa_flags &= ~(OPTION_MASK_P9_DFORM_SCALAR
@@ -4294,6 +4306,10 @@ rs6000_option_override_internal (bool global_init_
 
   if (TARGET_P9_DFORM_SCALAR && !TARGET_UPPER_REGS_DF)
 {
+  /* We prefer to not mention undocumented options in
+error messages.  However, if users have managed to select
+power9-dform without selecting upper-regs-df, they
+already know about undocumented flags.  */
   if (rs6000_isa_flags_explicit & OPTION_MASK_UPPER_REGS_DF)
error ("-mpower9-dform requires -mupper-regs-df");
   rs6000_isa_flags &= ~OPTION_MASK_P9_DFORM_SCALAR;
@@ -15507,13 +15523,13 @@ rs6000_invalid_builtin (enum rs6000_builtins fncod
   else if ((fnmask & RS6000_BTM_P8_VECTOR) != 0)
 error ("Builtin function %s requires the -mpower8-vector option", name);
   else if ((fnmask & RS6000_BTM_P9_VECTOR) != 0)
-error ("Builtin function %s requires the -mpower9-vector option", name);
+error ("Builtin function %s requires the -mcpu=power9 option", name);
   else if ((fnmask & (RS6000_BTM_P9_MISC | RS6000_BTM_64BIT))
   == (RS6000_BTM_P9_MISC | RS6000_BTM_64BIT))
-error ("Builtin function %s requires the -mpower9-misc and"
+error 

Re: Fix fir PR71696 in Libiberty Demangler (6)

[Jeff Law]

On 06/30/2016 12:46 AM, Marcel Böhme wrote:

Hi,

The attached patch fixes the stack overflow in the demangler due to cycles in 
the references of “remembered” mangled types 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71696).

The methods demangle_signature and do_arg in cplus-dem.c allow to “remember” 
mangled type names that can later be referenced and will also be demangled. The 
method demangle_args demangles those types following any references. So, if 
there is a cycle in the referencing (or in the simplest case a self-reference), 
the method enters infinite recursion.

The patch tracks the mangled types that are currently being demangled in a new 
variable called work->proctypevec. If a referenced type is currently being 
demangled, the demangling is marked as not successful.

Bootstrapped and regression tested on x86_64-pc-linux-gnu. Test case added to 
libiberty/testsuite/demangler-expected and checked PR71696 is resolved.


Index: libiberty/ChangeLog
===
--- libiberty/ChangeLog (revision 237852)
+++ libiberty/ChangeLog (working copy)
@@ -1,3 +1,21 @@
+2016-06-30  Marcel Böhme 
+
+   * cplus-dem.c: Prevent infinite recursion when there is a cycle
+   in the referencing of remembered mangled types.
+   (work_stuff): New stack to keep track of the remembered mangled
+   types that are currently being processed.
+   (push_processed_type): New method to push currently processed
+   remembered type onto the stack.
+   (pop_processed_type): New method to pop currently processed
+   remembered type from the stack.
+   (work_stuff_copy_to_from): Copy values of new variables.
+   (delete_non_B_K_work_stuff): Free stack memory.
+   (demangle_args): Push/Pop currently processed remembered type.
+   (do_type): Do not demangle a cyclic reference and push/pop
+   referenced remembered type.
+
+   * testsuite/demangle-expected: Add tests.
+
@@ -1302,6 +1309,13 @@ work_stuff_copy_to_from (struct work_stuff *to, st
   memcpy (to->btypevec[i], from->btypevec[i], len);
 }

+  if (from->proctypevec)
+{
+  to->proctypevec = XNEWVEC (int, from->proctypevec_size);
+  memcpy (to->proctypevec, from->proctypevec,
+ from->proctypevec_size * sizeof(int));
+}

Isn't this

 to->proctypevec
   = XDUPVEC (int, from->proctypevec, from->proctypevec_size);



@@ -1336,6 +1350,12 @@ delete_non_B_K_work_stuff (struct work_stuff *work
   work -> typevec = NULL;
   work -> typevec_size = 0;
 }
+  if (work -> proctypevec != NULL)
+{
+  free (work -> proctypevec);
+  work -> proctypevec = NULL;
+  work -> proctypevec_size = 0;
+}
Whitespace nits.  No whitespace around the "->".  Can you fix the one 
immediately above your new code as well?  (there's many others in 
cplus-dem.c, feel free to fix those as an independent patch).


I see similar whitespace nits in your changes to do_type.



@@ -3566,6 +3588,7 @@ do_type (struct work_stuff *work, const char **man

   done = 0;
   success = 1;
+  is_proctypevec = 0;
   while (success && !done)
 {
   int member;
@@ -3626,7 +3649,14 @@ do_type (struct work_stuff *work, const char **man
  success = 0;
}
  else
-   {
+   for (i = 0; i < work -> nproctypes; i++)



+ if (work -> proctypevec [i] == n)
+   success = 0;
So presumably this doesn't happen all that often or this could get 
expensive and we'd want something more efficient for searching, right?



 static void
+push_processed_type (struct work_stuff *work, int typevec_index)
+{
+  if (work -> nproctypes >= work -> proctypevec_size)
+{
+  if (work -> proctypevec_size == 0)
+   {
+ work -> proctypevec_size = 3;
+ work -> proctypevec = XNEWVEC (int, work -> proctypevec_size);
+   }
+  else
+   {
+ if (work -> proctypevec_size > INT_MAX / 2)
+xmalloc_failed (INT_MAX);
+  work -> proctypevec_size *= 2;
+  work -> proctypevec
+= XRESIZEVEC (int, work->proctypevec, work->proctypevec_size);
+}
+}
+work -> proctypevec [work -> nproctypes ++] = typevec_index;
"->" whitespace nits all over the place here.  I thought we had a better 
growing heuristic than just double every time..  Hmm, in gcc/vec.c we have:


  /* Exponential growth. */
  if (!alloc)
alloc = 4;
  else if (alloc < 16)
/* Double when small.  */
alloc = alloc * 2;
  else
/* Grow slower when large.  */
alloc = (alloc * 3 / 2);

  /* If this is still too small, set it to the right size. */
  if (alloc < desired)
alloc = desired;

Let's go with something similar here.




+}
+
+static void
+pop_processed_type (struct work_stuff *work)
+{
+  work -> nproctypes --;

No whitespace around the "->" or "--".

Can you take care of the minor issues above, retest & repost?

[PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

[Jakub Jelinek]

Hi!

The early debug changes broke e.g. following testcase:
program pr71906
  character(len=8) :: vard
  character(len=:), allocatable :: vare
  type t
character(len=:), allocatable :: f
  end type
  type(t) :: varf
  allocate(character(len=10) :: vare)
  allocate(character(len=9) :: varf%f)
  vare = 'foo'
  call foo (vard, vare, varf)
contains
  subroutine foo (vara, varb, varc)
character(len=*) :: vara
character(len=:), allocatable :: varb
type(t) :: varc
vara = 'bar'
varb = 'baz'
varc%f = 'str'
  end subroutine
end program pr71906

The issue is that unlike e.g. DW_AT_upper_bound, DW_AT_string_length
doesn't allow a reference to some other DIE, so while for the former
we just emit a reference to an artificial var holding the VLA sizes,
for non-constant string length loc_list_from_tree used to work, but
doesn't anymore.

The following patch has 4 major parts:
1) Fortran FE change to emit the artificial vars holding string length
   before the string vars (something I broke recently with PR71687
   fix)
2) for early_dwarf, loc_list_from_tree for the DW_AT_string_length
   var will most likely fail, the code in gen_array_type_die
   in that case adds DW_OP_call4 referencing the DIE of the artificial
   var or parameter; DW_OP_call4 is a rough match, in that it only works
   properly if the artificial var has DWARF expressions (rather than
   location descriptions); the patch also adds newly support for
   varb above, where the string length is INDIRECT_REF of artificial
   PARM_DECL; for early dwarf this adds DW_OP_call4; DW_OP_deref{,_size};
   the reason to handle it this way is that IMHO it matches more the
   spirit and intention of the early dwarf eventually for LTO, where
   I presume we'd stream the early dwarf created debug info and read/adjust
   it afterwards; LTO doesn't know that something is a fortran character
   and what string length it has
3) unfortunately, for the PARM_DECL and INDIRECT_REF of PARM_DECL
   cases, usually we need to refer to a parameter whose DIE has not
   been created yet during early_dwarf; and trying to create it
   out of order has various issues, e.g. the debugger would show them
   up in different order.  So, this is resolved using the string_types
   vector, adjust_string_types function and some code in gen_subprogram_die
4) finally, when finalizing the debug info, resolve_addr and its helper
   functions look at DW_AT_string_length with DW_OP_call4 optionally
   followed by DW_OP_deref{,_size} in its DWARF expression, look up the
   referenced DIE, consider its DW_AT_location and either:
   - keep it as is, if it is valid DWARF (i.e. known to be defined for
 all PCs to a DWARF expression)
   - copy the DW_AT_location attribute value/form to the DW_AT_string_length
 (in the non-deref case)
   - for the deref case, adjust what can be easily adjusted
 (DWARF expression with DW_OP_stack_value at the end drops the stack
 value and thus handles the dereference, regx/regN replaced by
 bregx/bregN 0, for DWARF expression only add dereference at the end,
 drop cases that can't be adjusted
   - drop the DW_AT_string_length attribute and DW_AT_byte_size if present
 too if the DIE doesn't have DW_AT_location, or it isn't usable etc.

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

2016-07-21  Jakub Jelinek  

PR debug/71906
* dwarf2out.c (string_types): New variable.
(gen_array_type_die): Change early_dwarf handling of
DW_AT_string_length, create DW_OP_call4 referencing the
length var temporarily.  Handle parameters that are pointers
to string length.
(adjust_string_types): New function.
(gen_subprogram_die): Temporarily set string_types to local var,
call adjust_string_types if needed.
(non_dwarf_expression, copy_deref_exprloc, optimize_string_length):
New functions.
(resolve_addr): Adjust DW_AT_string_length if it is DW_OP_call4.

* trans-decl.c (gfc_get_symbol_decl): Call gfc_finish_var_decl
for decl's character length before gfc_finish_var_decl on the
decl itself.

--- gcc/dwarf2out.c.jj  2016-07-21 08:59:47.101616662 +0200
+++ gcc/dwarf2out.c 2016-07-21 11:10:11.510137511 +0200
@@ -3123,6 +3123,10 @@ static bool frame_pointer_fb_offset_vali
 
 static vec base_types;
 
+/* Pointer to vector of DW_TAG_string_type DIEs that need finalization
+   once all arguments are parsed.  */
+static vec *string_types;
+
 /* Flags to represent a set of attribute classes for attributes that represent
a scalar value (bounds, pointers, ...).  */
 enum dw_scalar_form
@@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re
   if (size >= 0)
add_AT_unsigned (array_die, DW_AT_byte_size, size);
   else if (TYPE_DOMAIN (type) != NULL_TREE
-  && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE
-  && DECL_P (TYPE_MAX_VALUE 

[PATCH GCC/03]New option warning missed optimization on loops whose counter may overflow

[Bin Cheng]

Hi,
This patch adds new option -Wmissed-loop-optimizations warning on loops whose 
counter may overflow, as well as makes -Wunsafe-loop-optimizations an alias to 
the new option.
Bootstrap and test on x86_64 ongoing.  Is it OK?

Thanks,
bin

2016-07-20  Bin Cheng  

* common.opt (Wmissed-loop-optimizations): New option.
(Wunsafe-loop-optimizations): Alias to Wmissed-loop-optimizations.
* doc/invoke.texi (Wmissed-loop-optimizations): Ditto.
(Wunsafe-loop-optimizations): Alias to Wmissed-loop-optimizations.
* tree-ssa-loop-niter.c (number_of_iterations_exit): Use option
Wmissed-loop-optimizations.diff --git a/gcc/common.opt b/gcc/common.opt
index 8a292ed..3d62657 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -625,7 +625,12 @@ Common Var(warn_null_dereference) Warning
 Warn if dereferencing a NULL pointer may lead to erroneous or undefined 
behavior.
 
 Wunsafe-loop-optimizations
-Common Var(warn_unsafe_loop_optimizations) Warning
+Common Alias(Wmissed-loop-optimizations)
+Warn if the loop cannot be optimized due to nontrivial assumptions.
+Same as -Wmissed-loop-optimizations.
+
+Wmissed-loop-optimizations
+Common Var(warn_missed_loop_optimizations) Warning
 Warn if the loop cannot be optimized due to nontrivial assumptions.
 
 Wmissing-noreturn
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3041c18..5a2bb09 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -302,8 +302,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wswitch  -Wswitch-bool  -Wswitch-default  -Wswitch-enum @gol
 -Wswitch-unreachable  -Wsync-nand @gol
 -Wsystem-headers  -Wtautological-compare  -Wtrampolines  -Wtrigraphs @gol
--Wtype-limits  -Wundef @gol
--Wuninitialized  -Wunknown-pragmas  -Wunsafe-loop-optimizations @gol
+-Wtype-limits  -Wundef -Wuninitialized  -Wunknown-pragmas @gol
+-Wmissed-loop-optimizations -Wunsafe-loop-optimizations @gol
 -Wunsuffixed-float-constants  -Wunused  -Wunused-function @gol
 -Wunused-label  -Wunused-local-typedefs -Wunused-parameter @gol
 -Wno-unused-result -Wunused-value @gol -Wunused-variable @gol
@@ -4990,9 +4990,14 @@ If the stack usage is (partly) dynamic and not bounded, 
it's:
 @opindex Wunsafe-loop-optimizations
 @opindex Wno-unsafe-loop-optimizations
 Warn if the loop cannot be optimized because the compiler cannot
-assume anything on the bounds of the loop indices.  With
-@option{-funsafe-loop-optimizations} warn if the compiler makes
-such assumptions.
+assume anything on the bounds of the loop indices.  Same as
+@option{-Wmissed-loop-optimizations}.
+
+@item -Wmissed-loop-optimizations
+@opindex Wmissed-loop-optimizations
+@opindex Wno-missed-loop-optimizations
+Warn if the loop cannot be optimized because the compiler cannot
+assume anything on the bounds of the loop indices.
 
 @item -Wno-pedantic-ms-format @r{(MinGW targets only)}
 @opindex Wno-pedantic-ms-format
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 2061eafa..38b5552 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -2333,7 +2333,7 @@ number_of_iterations_exit (struct loop *loop, edge exit,
 
   wording = N_("missed loop optimization, the loop counter may overflow");
   warning_at ((LOCATION_LINE (loc) > 0) ? loc : input_location,
- OPT_Wunsafe_loop_optimizations, "%s", gettext (wording));
+ OPT_Wmissed_loop_optimizations, "%s", gettext (wording));
 }
 
   return false;

[Patch GCC/01]Bring back warning message on loop whose counter might overflow

[Bin Cheng]

Hi,
Previous patch removed warning message on loops whose counter might overflow, 
while this patch adds it back.  Reason is it's always good to have a warning 
message indicating missed loop optimizations.  Also warning message itself is 
slightly changed.
There will be following patch which removes -funsafe-loop-optimizations.

Bootstrap and test on x86_64.  Is it OK?

Thanks,
bin

2016-07-20  Bin Cheng  

* tree-ssa-loop-niter.h (number_of_iterations_exit_assumptions): New
Parameter.
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions): New
Parameter.
(number_of_iterations_exit): Warn missed loop optimization for
possible infinite loops.

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

* gcc.dg/tree-ssa/pr19210-1.c: Refine test strings.
* gcc.dg/tree-ssa/pr19210-2.c: Delete.diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
index 906132c..3c8ee06 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c
@@ -6,10 +6,10 @@ void
 f (unsigned n)
 {
   unsigned k;
-  for(k = 0;k <= n;k++) /* { dg-warning "cannot optimize.*infinite loops" } */
+  for(k = 0;k <= n;k++) /* { dg-warning "missed loop optimization.*overflow" } 
*/
 g();
 
-  for(k = 0;k <= n;k += 4) /* { dg-warning "cannot optimize.*overflow" } */
+  for(k = 0;k <= n;k += 4) /* { dg-warning "missed loop 
optimization.*overflow" } */
 g();
 
   /* We used to get warning for this loop.  However, since then # of iterations
@@ -21,9 +21,9 @@ f (unsigned n)
 g();
 
   /* So we need the following loop, instead.  */
-  for(k = 4;k <= n;k += 5) /* { dg-warning "cannot optimize.*overflow" } */
+  for(k = 4;k <= n;k += 5) /* { dg-warning "missed loop 
optimization.*overflow" } */
 g();
   
-  for(k = 15;k >= n;k--) /* { dg-warning "cannot optimize.*infinite" } */
+  for(k = 15;k >= n;k--) /* { dg-warning "missed loop optimization.*overflow" 
} */
 g();
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c
deleted file mode 100644
index 9116e97..000
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-O2 -funsafe-loop-optimizations -Wunsafe-loop-optimizations" 
} */
-extern void g(void);
-
-void
-f (unsigned n)
-{
-  unsigned k;
-  for(k = 0;k <= n;k++) /* { dg-warning "assuming.*not infinite" } */
-g();
-
-  for(k = 5;k <= n;k += 4) /* { dg-warning "assuming.*not overflow" } */
-g();
-
-  /* We used to get warning for this loop.  However, since then # of iterations
- analysis improved, and we can now prove that this loop does not verflow.
- This is because the only case when it would overflow is if n = ~0 (since
- ~0 is divisible by 5), and this cannot be the case, since when we got
- here, the previous loop exited, thus there exists k > n.  */
-  for(k = 5;k <= n;k += 5)
-g();
-
-  for(k = 4;k <= n;k += 5) /* { dg-warning "assuming.*not overflow" } */
-g();
-
-  for(k = 15;k >= n;k--) /* { dg-warning "assuming.*not infinite" } */
-g();
-
-}
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index d96c03b..48947f0 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -2181,12 +2181,13 @@ loop_only_exit_p (const struct loop *loop, const_edge 
exit)
in comments at struct tree_niter_desc declaration), false otherwise.
When EVERY_ITERATION is true, only tests that are known to be executed
every iteration are considered (i.e. only test that alone bounds the loop).
- */
+   If AT_STMT is not NULL, this function stores LOOP's condition statement in
+   it when returning true.  */
 
 bool
 number_of_iterations_exit_assumptions (struct loop *loop, edge exit,
   struct tree_niter_desc *niter,
-  bool every_iteration)
+  gcond **at_stmt, bool every_iteration)
 {
   gimple *last;
   gcond *stmt;
@@ -2303,6 +2304,9 @@ number_of_iterations_exit_assumptions (struct loop *loop, 
edge exit,
   if (TREE_CODE (niter->niter) == INTEGER_CST)
 niter->max = wi::to_widest (niter->niter);
 
+  if (at_stmt)
+*at_stmt = stmt;
+
   return (!integer_zerop (niter->assumptions));
 }
 
@@ -2312,13 +2316,27 @@ number_of_iterations_exit_assumptions (struct loop 
*loop, edge exit,
 bool
 number_of_iterations_exit (struct loop *loop, edge exit,
   struct tree_niter_desc *niter,
-  bool, bool every_iteration)
+  bool warn, bool every_iteration)
 {
+  gcond *stmt;
   if (!number_of_iterations_exit_assumptions (loop, exit, niter,
- every_iteration))
+ , every_iteration))
 return false;
 
-  

[PATCH GCC/02]Remove -funsafe-loop-optimizations option.

[Bin Cheng]

Hi,
This patch removes support for -funsafe-loop-optimizations on both GIMPLE and 
RTL level by marking it as ignored.
Bootstrap and test on x86_64.  Is it OK?

Thanks,
bin

2016-07-20  Bin Cheng  

* common.opt (funsafe-loop-optimizations): Mark ignore.
* doc/invoke.texi (funsafe-loop-optimizations): Remove.
* loop-iv.c (get_simple_loop_desc): Remove unsafe-loop-optimizations
related code.
* tree-ssa-loop-niter.c (finite_loop_p): Ditto.
* config/bfin/bfin.c (bfin_can_use_doloop_p): Ditto.diff --git a/gcc/common.opt b/gcc/common.opt
index b56ba47..8a292ed 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2507,8 +2507,8 @@ Perform loop unrolling for all loops.
 ; that control loops do not overflow and that the loops with nontrivial
 ; exit condition are not infinite
 funsafe-loop-optimizations
-Common Report Var(flag_unsafe_loop_optimizations) Optimization
-Allow loop optimizations to assume that the loops behave in normal way.
+Common Ignore
+Does nothing.  Preserved for backward compatibility.
 
 fassociative-math
 Common Report Var(flag_associative_math) SetByCombined Optimization
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index 75ddcf0..b6edf2c 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3375,10 +3375,7 @@ bfin_can_use_doloop_p (const widest_int &, const 
widest_int _max,
   /* Due to limitations in the hardware (an initial loop count of 0
  does not loop 2^32 times) we must avoid to generate a hardware
  loops when we cannot rule out this case.  */
-  if (!flag_unsafe_loop_optimizations
-  && wi::geu_p (iterations_max, 0x))
-return false;
-  return true;
+  return (wi::ltu_p (iterations_max, 0x));
 }
 
 /* Increment the counter for the number of loop instructions in the
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9a4db38..3041c18 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -414,7 +414,7 @@ Objective-C and Objective-C++ Dialects}.
 -ftree-switch-conversion -ftree-tail-merge -ftree-ter @gol
 -ftree-vectorize -ftree-vrp -funconstrained-commons @gol
 -funit-at-a-time -funroll-all-loops -funroll-loops @gol
--funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops @gol
+-funsafe-math-optimizations -funswitch-loops @gol
 -fipa-ra -fvariable-expansion-in-unroller -fvect-cost-model -fvpt @gol
 -fweb -fwhole-program -fwpa -fuse-linker-plugin @gol
 --param @var{name}=@var{value}
@@ -6818,15 +6818,6 @@ number of iterations of a loop are used to guide loop 
unrolling and peeling
 and loop exit test optimizations.
 This option is enabled by default.
 
-@item -funsafe-loop-optimizations
-@opindex funsafe-loop-optimizations
-This option tells the loop optimizer to assume that loop indices do not
-overflow, and that loops with nontrivial exit condition are not
-infinite.  This enables a wider range of loop optimizations even if
-the loop optimizer itself cannot prove that these assumptions are valid.
-If you use @option{-Wunsafe-loop-optimizations}, the compiler warns you
-if it finds this kind of loop.
-
 @item -funconstrained-commons
 @opindex funconstrained-commons
 This option tells the compiler that variables declared in common blocks
diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
index 57fb8c1..b3d41604 100644
--- a/gcc/loop-iv.c
+++ b/gcc/loop-iv.c
@@ -3027,42 +3027,6 @@ get_simple_loop_desc (struct loop *loop)
   iv_analysis_loop_init (loop);
   find_simple_exit (loop, desc);
   loop->simple_loop_desc = desc;
-
-  if (desc->simple_p && (desc->assumptions || desc->infinite))
-{
-  const char *wording;
-
-  /* Assume that no overflow happens and that the loop is finite.
-We already warned at the tree level if we ran optimizations there.  */
-  if (!flag_tree_loop_optimize && warn_unsafe_loop_optimizations)
-   {
- if (desc->infinite)
-   {
- wording =
-   flag_unsafe_loop_optimizations
-   ? N_("assuming that the loop is not infinite")
-   : N_("cannot optimize possibly infinite loops");
- warning (OPT_Wunsafe_loop_optimizations, "%s",
-  gettext (wording));
-   }
- if (desc->assumptions)
-   {
- wording =
-   flag_unsafe_loop_optimizations
-   ? N_("assuming that the loop counter does not overflow")
-   : N_("cannot optimize loop, the loop counter may overflow");
- warning (OPT_Wunsafe_loop_optimizations, "%s",
-  gettext (wording));
-   }
-   }
-
-  if (flag_unsafe_loop_optimizations && single_exit (loop))
-   {
- desc->assumptions = NULL_RTX;
- desc->infinite = NULL_RTX;
-   }
-}
-
   return desc;
 }
 
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 48947f0..2061eafa 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ 

Re: [PATCH] RFC: On-demand locations within string-literals

[Jeff Law]

On 07/20/2016 01:38 PM, David Malcolm wrote:

On Fri, 2016-07-08 at 17:49 -0400, David Malcolm wrote:
[...]


Also, this patch currently makes the assumption (in charset.c)
that there's a 1:1 correspondence between bytes in the source
character set and bytes in the execution character set.  This can
be the case if both are, say, UTF-8, but might not hold in
general.

The source char set is UTF-8 or UTF-EBCDIC, and safe-ctype.c has:

# if HOST_CHARSET == HOST_CHARSET_EBCDIC
  #error "FIXME: write tables for EBCDIC"

so presumably we don't actually have any hosts that supports EBCDIC
(do we?); as far as I can tell, we only currently support UTF-8
as the source char set.

Similarly, do we support any targets for which the execution
character set is *not* UTF-8?


I brought this up in this thread on the gcc mailing list:
"gcc/libcpp: non-UTF-8 source or execution encodings?"
  https://gcc.gnu.org/ml/gcc/2016-07/msg00091.html
and in particular:
  https://gcc.gnu.org/ml/gcc/2016-07/msg00106.html
it's possible to select the execution char set using at the command
-line for C-family frontends using:
  -fexec-charset=
  -fwide-exec-charset=
e.g. "-fexec-charset=IBM1047" will give one of the variants of EBCDIC.

Given that the internal interface already has a failure mode, I'm
thinking that a reasonable restriction is to only support locations
within string literals for the case where source character set ==
execution character set, and hence we have "convert_no_conversion" as
the converter.  Does that sound sane?  (I can write test coverage for
this).
I think this is sane.  We can always revisit later if we change our 
minds, particularly if folks want to do something crazy like self-host 
on an EBCDIC system.


jeff

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

[Jeff Law]

On 07/21/2016 03:15 AM, Ilya Enkovich wrote:

In my list I see #1, #4, and #5 are not approved.
So I think Richi wanted to see param control for the new options; Joseph 
wanted the new options properly documented in invoke.texi;  I had a few 
higher level questions which you answered.  Your updated patch #1 added 
param control and invoke.texi documentation.  So IMHO, #1 is approved.



#4 had some whitespace nits and needed some light doc improvements which 
you've done.  I think the only real implementation issue was computing 
costs in a single scan vs restarting the scan.  I was OK with the single 
scan approach you took -- not sure how strongly Richi feels about 
restarting the scan.  Seems like Richi needs to chime in on that topic.


I'm hoping to finish reviewing the update to #5 today.

jeff

Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

[Bernd Edlinger]

On 07/20/16 22:04, Jeff Law wrote:
> On 06/22/2016 02:48 PM, Bernd Edlinger wrote:
>> On 06/22/16 21:51, Jeff Law wrote:
>>> On 06/19/2016 07:25 AM, Bernd Edlinger wrote:
 Hi,

 ping...

 As this discussion did not make any progress, I just attached
 the latest version of my patch with the the changes that
 Vladimir proposed.

 Boot-strapped and reg-tested again on x86_64-linux-gnu.
 Is it OK for the trunk?
>>> Well, I don't think we've got any kind of consensus on whether or not
>>> this is reasonable or not.
>>>
>>> The fundamental issue is that "X" is supposed to accept anything,
>>> literally anything.  That implies it's really the downstream users of
>>> those operands that are broken.
>>>
>>
>> Hmm...
>>
>> I think it must be pretty easy to write something in a .md file with the
>> X constraint that ends up in an ICE, right?
> Probably not terribly hard.
>
>>
>> But in an .md file we have much more control on what happens.
>> That's why I did not propose to change the meaning of "X" in .md files.
> We have control over RTL generation, operand predicates and the like.
> And those are how we control things like combine.
>
>>
>> And we only have problems with asm statements that use "X" constraints.
> But I'd disagree.  I think we could easily have problems with "X"
> constraints in the MD file.  But the most common uses of "X" probably
> don't try to refer to that operand in the output string and use good
> predicates.
>
> And that's one of the key differences here.  In an MD file the operand
> predicate has to pass -- that's not the case in an ASM.  The operand
> predicate allows the backend to prevent all kinds of things from showing
> up.
>
>>
>> But I think we have a use case where "X" means really more possible
>> registers (i.e. includes ss2, mmx etc.) than "g" (only general
>> registers).  Otherwise, in the test cases of pr59155 we would not
>> have any benefit for using "+X" instead of "+g" or "+r".
>>
>> Does that sound reasonable?
> If it's the case that the real benefit of +X is that it's allowing more
> registers, then that argues that the backend ought to be providing
> another (larger) register class.
>

X allows more different registers than r, and it is already documented.
In the cases where it is already used, the patch should not break
anything.  I would not understand, why we should forbid the use of X and
waste another letter of the alphabet for a slightly modified version
of X.



Bernd.

[committed] Fix asan C++ ICE with PCH (PR sanitizer/71953)

[Jakub Jelinek]

Hi!

If a PCH file is built without -fsanitize=address and a TU doesn't contain
any functions, only file scope ctor, then we ICE because sanitizer builtins
aren't yet initialized.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk and 6.2 as obvious.

2016-07-21  Jakub Jelinek  

PR sanitizer/71953
* asan.c (asan_dynamic_init_call): Call asan_init_shadow_ptr_types
before builtin_decl_implicit.

--- gcc/asan.c.jj   2016-07-11 22:18:08.0 +0200
+++ gcc/asan.c  2016-07-21 10:37:28.869914949 +0200
@@ -2159,6 +2159,9 @@ transform_statements (void)
 tree
 asan_dynamic_init_call (bool after_p)
 {
+  if (shadow_ptr_types[0] == NULL_TREE)
+asan_init_shadow_ptr_types ();
+
   tree fn = builtin_decl_implicit (after_p
   ? BUILT_IN_ASAN_AFTER_DYNAMIC_INIT
   : BUILT_IN_ASAN_BEFORE_DYNAMIC_INIT);
@@ -2168,8 +2171,6 @@ asan_dynamic_init_call (bool after_p)
   pretty_printer module_name_pp;
   pp_string (_name_pp, main_input_filename);
 
-  if (shadow_ptr_types[0] == NULL_TREE)
-   asan_init_shadow_ptr_types ();
   module_name_cst = asan_pp_string (_name_pp);
   module_name_cst = fold_convert (const_ptr_type_node,
  module_name_cst);

Jakub

[C++ PATCH] Fix ICE with statement expression (PR c++/71728)

[Jakub Jelinek]

Hi!

It is true that parsing should make sure that GOTO_EXPRs (other than
break/continue) aren't allowed in constant expression contexts, but
potential_constant_expression_1 may be called (with tf_none) also
on arbitrary code either for warning purposes, or (very recent change)
also in cp_fully_fold, usually from maybe_constant_value.

So asserting they don't appear doesn't work.

Fixed thusly, alternatively we could assert that (flags & tf_error) == 0
before returning false.

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

2016-07-21  Jakub Jelinek  

PR c++/71728
* constexpr.c (potential_constant_expression_1) :
Replace assert with test, return false if the goto isn't break
or continue.  Formatting fix.

* g++.dg/other/pr71728.C: New test.

--- gcc/cp/constexpr.c.jj   2016-07-21 08:59:50.0 +0200
+++ gcc/cp/constexpr.c  2016-07-21 12:05:16.828618186 +0200
@@ -5289,10 +5289,12 @@ potential_constant_expression_1 (tree t,
 case GOTO_EXPR:
   {
tree *target = _OPERAND (t, 0);
-   /* Gotos representing break and continue are OK; we should have
-  rejected other gotos in parsing.  */
-   gcc_assert (breaks (target) || continues (target));
-   return true;
+   /* Gotos representing break and continue are OK.  */
+   if (breaks (target) || continues (target))
+ return true;
+   if (flags & tf_error)
+ error ("% is not a constant-expression");
+   return false;
   }
 
 default:
@@ -5300,7 +5302,7 @@ potential_constant_expression_1 (tree t,
return false;
 
   sorry ("unexpected AST of kind %s", get_tree_code_name (TREE_CODE (t)));
-  gcc_unreachable();
+  gcc_unreachable ();
   return false;
 }
 #undef RECUR
--- gcc/testsuite/g++.dg/other/pr71728.C.jj 2016-07-21 12:13:31.686461551 
+0200
+++ gcc/testsuite/g++.dg/other/pr71728.C2016-07-21 12:14:46.974524876 
+0200
@@ -0,0 +1,11 @@
+// PR c++/71728
+// { dg-do compile }
+// { dg-options "-std=gnu++14 -Wall" }
+
+int
+foo ()
+{
+  if (({ goto test; test: 1; }) != 1)
+return 1;
+  return 2;
+}

Jakub

Re: [Fortran, patch, v1] Add STAT= support to caf_single get()/send()

[Paul Richard Thomas]

Hi Andre,

That looks good to me. OK for trunk.

Thanks for the patch.

Paul

On 21 July 2016 at 15:31, Andre Vehreschild  wrote:
> Hi all,
>
> the attached patch adds support for a stat parameter to caf_single's
> caf_get() and caf_send() routines and adds a testcase. Unfortunately is
> there not much that can go wrong in a caf_single's get/send, so the test
> resides to check whether stat is reset correctly.
>
> Bootstraps and regtests ok on x86_64-linux/F23.
>
> Ok for trunk?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



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

Albert Einstein

Re: [patch] Get rid of stack trampolines for nested functions

[Andrew Pinski]

On Thu, Jul 21, 2016 at 8:45 AM, Arnaud Charlet  wrote:
> Jeff,
>
>> So just to be clear, once installed, for Ada we'll start using the
>> descriptor based scheme on the subset of targets below, which will
>> be an ABI change, right?
>
> Right.
>
>> If so and this goes in, we'll have to make sure to signal loud and
>> wide about the ABI change at the project level and the various
>> distributors will need to do the same for their consumers as well.
>
> Not really, there is not and never has been a stable ABI for Ada, so this
> isn't new. In other words, it's already impossible to mix Ada objects compiled
> with two different versions of GCC, so there is nothing "loud and wide"
> needed here as far as Ada is concerned.


We should be able to change the ABI for Fortran too.  It does make
sense to break the Fortran ABI (C is another matter for another day
and it makes sense to make sure all newly added ABIs use this even for
C).

Thanks,
Andrew

>
> Arno

Re: [patch] Get rid of stack trampolines for nested functions

[Arnaud Charlet]

Jeff,

> So just to be clear, once installed, for Ada we'll start using the
> descriptor based scheme on the subset of targets below, which will
> be an ABI change, right?

Right.

> If so and this goes in, we'll have to make sure to signal loud and
> wide about the ABI change at the project level and the various
> distributors will need to do the same for their consumers as well.

Not really, there is not and never has been a stable ABI for Ada, so this
isn't new. In other words, it's already impossible to mix Ada objects compiled
with two different versions of GCC, so there is nothing "loud and wide"
needed here as far as Ada is concerned.

Arno

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 17:17, Jeff Law wrote:
> It's possible the issue came up building the SunOS/Solaris kernel --
> circa 1992 I was loosely involved in a project that was bringing up that
> kernel on non-Sun hardware.  And that fits my recollection of when
> savectx support went into GCC.
>
> jeff

Yes.  That matches to the svn revision where "savectx" appeared for the
first time:

r201 | rms | 1992-01-17 23:48:42 +0100 (Fr, 17. Jan 1992) | 2 Zeilen
Geänderte Pfade:
A /trunk/gcc/calls.c

Initial revision


So we had 25 years to fix a header file...


Bernd.

Re: [patch] Get rid of stack trampolines for nested functions

[Jeff Law]

On 06/29/2016 04:08 PM, Eric Botcazou wrote:

Hi,

this patch implements generic support for the elimination of stack trampolines
and, consequently, of the need to make the stack executable when pointers to
nested functions are used.  That's done on a per-language and per-target basis
(i.e. there is 1 language hook and 1 target hook to parameterize it) and there
are no changes whatsoever in code generation if both are not turned on (and
the patch implements a -ftrampolines option to let the user override them).
I'm sure there's security folks that would want to see this across all 
targets for all languages.  Sadly due to the ABI implications that's not 
likely to happen :(




The idea is based on the fact that, for targets using function descriptors as
per their ABI like IA-64, AIX or VMS platforms, stack trampolines "degenerate"
into descriptors built at run time on the stack and thus made up of data only,
which in turn means that the stack doesn't need to be made executable.

Right.



This descriptor-based scheme is implemented generically for nested functions,
i.e. the nested function lowering pass builds generic descriptors instead of
trampolines on the stack when encountering pointers to nested functions, which
means that there are 2 kinds of pointers to functions and therefore a run-time
identification mechanism is needed for indirect calls to distinguish them.

Because of that, enabling the support breaks binary compatibility (for code
manipulating pointers to nested functions).  That's OK for Ada and nested
functions are first-class citizens in the language anyway so we really need
this, but not for C so for example Ada doesn't use it at the interface with C
(when objects have "convention C" in Ada parlance).
So just to be clear, once installed, for Ada we'll start using the 
descriptor based scheme on the subset of targets below, which will be an 
ABI change, right?


If so and this goes in, we'll have to make sure to signal loud and wide 
about the ABI change at the project level and the various distributors 
will need to do the same for their consumers as well.





This was bootstrapped/regtested on x86_64-suse-linux but AdaCore has been
using it on native platforms (Linux, Windows, Solaris, etc) for years.

OK for the mainline?


2016-06-29  Eric Botcazou  

PR ada/37139
PR ada/67205
* common.opt (-ftrampolines): New option.
* doc/invoke.texi (Code Gen Options): Document it.
* doc/tm.texi.in (Trampolines): Add TARGET_CUSTOM_FUNCTION_DESCRIPTORS
* doc/tm.texi: Regenerate.
* builtins.def: Add init_descriptor and adjust_descriptor.
* builtins.c (expand_builtin_init_trampoline): Do not issue a warning
on platforms with descriptors.
(expand_builtin_init_descriptor): New function.
(expand_builtin_adjust_descriptor): Likewise.
(expand_builtin) : New case.
: Likewise.
* calls.c (prepare_call_address): Remove SIBCALLP parameter and add
FLAGS parameter.  Deal with indirect calls by descriptor and adjust.
Set STATIC_CHAIN_REG_P on the static chain register, if any.
(call_expr_flags): Set ECF_BY_DESCRIPTOR for calls by descriptor.
(expand_call): Likewise.  Move around call to prepare_call_address
and pass all flags to it.
* cfgexpand.c (expand_call_stmt): Reinstate CALL_EXPR_BY_DESCRIPTOR.
* gimple.h (enum gf_mask): New GF_CALL_BY_DESCRIPTOR value.
(gimple_call_set_by_descriptor): New setter.
(gimple_call_by_descriptor_p): New getter.
* gimple.c (gimple_build_call_from_tree): Set CALL_EXPR_BY_DESCRIPTOR.
(gimple_call_flags): Deal with GF_CALL_BY_DESCRIPTOR.
* langhooks.h (struct lang_hooks): Add custom_function_descriptors.
* langhooks-def.h (LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS): Define.
(LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS.
* rtl.h (STATIC_CHAIN_REG_P): New macro.
* rtlanal.c (find_first_parameter_load): Skip static chain registers.
* target.def (custom_function_descriptors): New POD hook.
* tree.h (FUNC_ADDR_BY_DESCRIPTOR): New flag on ADDR_EXPR.
(CALL_EXPR_BY_DESCRIPTOR): New flag on CALL_EXPR.
* tree-core.h (ECF_BY_DESCRIPTOR): New mask.
Document FUNC_ADDR_BY_DESCRIPTOR and CALL_EXPR_BY_DESCRIPTOR.
* tree.c (make_node_stat) : Set function alignment to
DEFAULT_FUNCTION_ALIGNMENT instead of FUNCTION_BOUNDARY.
(build_common_builtin_nodes): Initialize init_descriptor and
adjust_descriptor.
* tree-nested.c: Include target.h.
(struct nesting_info): Add 'any_descr_created' field.
(get_descriptor_type): New function.
(lookup_element_for_decl): New function extracted from...
(create_field_for_decl): Likewise.
(lookup_tramp_for_decl): ...here.  Adjust.
(lookup_descr_for_decl): New 

[patch,avr] remove secondary_reload hook implementation

[Georg-Johann Lay]

This removes avr's TARGET_SECONDARY_RELOAD implementation which never worked as 
expected...


Its intention was to provide an 8-bit scratch register for loads from 
non-generic address-spaces as they might need to set RAMPZ to the needed flash 
segment.


The avr BE uses avr_find_unused_d_reg for that purpose, and if that function 
does not come up with a d-reg then the using function avr_out_lpm cooks up a 
scratch on the fly.


Ok for trunk?


Johann

* config/avr/avr.c (TARGET_SECONDARY_RELOAD): Remove hook define...
(avr_secondary_reload): ...and implementation.
(avr_adjust_insn_length) [ADJUST_LEN_LPM]: Remove handling.
* config/avr/avr.md (reload_in): Remove insns.
(adjust_len) [lpm]: Remove insn attribute value.
* config/avr/predicates.md (flash_operand): Remove insn predicate.
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 238587)
+++ config/avr/avr.c	(working copy)
@@ -2048,50 +2048,6 @@ avr_legitimize_reload_address (rtx *px,
 }
 
 
-/* Implement `TARGET_SECONDARY_RELOAD' */
-
-static reg_class_t
-avr_secondary_reload (bool in_p, rtx x,
-  reg_class_t reload_class ATTRIBUTE_UNUSED,
-  machine_mode mode, secondary_reload_info *sri)
-{
-  if (in_p
-  && MEM_P (x)
-  && !ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
-  && ADDR_SPACE_MEMX != MEM_ADDR_SPACE (x))
-{
-  /* For the non-generic 16-bit spaces we need a d-class scratch.  */
-
-  switch (mode)
-{
-default:
-  gcc_unreachable();
-
-case QImode:  sri->icode = CODE_FOR_reload_inqi; break;
-case QQmode:  sri->icode = CODE_FOR_reload_inqq; break;
-case UQQmode: sri->icode = CODE_FOR_reload_inuqq; break;
-
-case HImode:  sri->icode = CODE_FOR_reload_inhi; break;
-case HQmode:  sri->icode = CODE_FOR_reload_inhq; break;
-case HAmode:  sri->icode = CODE_FOR_reload_inha; break;
-case UHQmode: sri->icode = CODE_FOR_reload_inuhq; break;
-case UHAmode: sri->icode = CODE_FOR_reload_inuha; break;
-
-case PSImode: sri->icode = CODE_FOR_reload_inpsi; break;
-
-case SImode:  sri->icode = CODE_FOR_reload_insi; break;
-case SFmode:  sri->icode = CODE_FOR_reload_insf; break;
-case SQmode:  sri->icode = CODE_FOR_reload_insq; break;
-case SAmode:  sri->icode = CODE_FOR_reload_insa; break;
-case USQmode: sri->icode = CODE_FOR_reload_inusq; break;
-case USAmode: sri->icode = CODE_FOR_reload_inusa; break;
-}
-}
-
-  return NO_REGS;
-}
-
-
 /* Helper function to print assembler resp. track instruction
sequence lengths.  Always return "".
 
@@ -8847,7 +8803,6 @@ avr_adjust_insn_length (rtx_insn *insn,
 case ADJUST_LEN_MOV32: output_movsisf (insn, op, ); break;
 case ADJUST_LEN_MOVMEM: avr_out_movmem (insn, op, ); break;
 case ADJUST_LEN_XLOAD: avr_out_xload (insn, op, ); break;
-case ADJUST_LEN_LPM: avr_out_lpm (insn, op, ); break;
 case ADJUST_LEN_SEXT: avr_out_sign_extend (insn, op, ); break;
 
 case ADJUST_LEN_SFRACT: avr_out_fract (insn, op, true, ); break;
@@ -13888,9 +13843,6 @@ avr_fold_builtin (tree fndecl, int n_arg
 #undef  TARGET_MODE_DEPENDENT_ADDRESS_P
 #define TARGET_MODE_DEPENDENT_ADDRESS_P avr_mode_dependent_address_p
 
-#undef  TARGET_SECONDARY_RELOAD
-#define TARGET_SECONDARY_RELOAD avr_secondary_reload
-
 #undef  TARGET_PRINT_OPERAND
 #define TARGET_PRINT_OPERAND avr_print_operand
 #undef  TARGET_PRINT_OPERAND_ADDRESS
Index: config/avr/avr.md
===
--- config/avr/avr.md	(revision 238587)
+++ config/avr/avr.md	(working copy)
@@ -151,7 +151,7 @@ (define_attr "adjust_len"
tsthi, tstpsi, tstsi, compare, compare64, call,
mov8, mov16, mov24, mov32, reload_in16, reload_in24, reload_in32,
ufract, sfract, round,
-   xload, lpm, movmem,
+   xload, movmem,
ashlqi, ashrqi, lshrqi,
ashlhi, ashrhi, lshrhi,
ashlsi, ashrsi, lshrsi,
@@ -455,23 +455,6 @@ (define_split
 ;;
 ;; Move stuff around
 
-;; Secondary input reload from non-generic 16-bit address spaces
-(define_insn "reload_in"
-  [(set (match_operand:MOVMODE 0 "register_operand"   "=r")
-(match_operand:MOVMODE 1 "flash_operand"   "m"))
-   (clobber (match_operand:QI 2 "d_register_operand"  "=d"))]
-  ;; Fixme: The insn condition must not test the address space.
-  ;;   Because the gen tools refuse to generate insns for address spaces
-  ;;   and will generate insn-codes.h to look like:
-  ;;   #define CODE_FOR_reload_inhi CODE_FOR_nothing
-  "reload_completed || reload_in_progress"
-  {
-return avr_out_lpm (insn, operands, NULL);
-  }
-  [(set_attr "adjust_len" "lpm")
-   (set_attr "cc" "clobber")])
-
-
 ;; "loadqi_libgcc"
 ;; "loadhi_libgcc"
 ;; "loadpsi_libgcc"
Index: 

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[H.J. Lu]

On Wed, Jul 20, 2016 at 1:02 PM, Eric Botcazou  wrote:
>> Very few targets continue to use SJLJ eh (perhaps just cygwin/mingw).
>> *But* I think the Ada front-end explicitly uses SJLJ EH, so if you want
>> to get some smoke testing, the Ada testsuite is probably the place to go.
>
> Right, the Ada front-end uses an EH scheme directly based on __builtin_setjmp
> (which is similar but distinct from the regular SJLJ EH because the front-end
> directly manages the SJLJ buffers) for internal EH.  Note that it's on the
> host only, for the target it uses the same EH scheme as C++/Java/etc.
>

libcilkrts/include/internal/abi.h:#   define CILK_SETJMP(X) __builtin_setjmp(X)



-- 
H.J.

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Jeff Law]

On 07/21/2016 09:07 AM, Bernd Edlinger wrote:

On 07/21/16 14:08, Richard Biener wrote:

On Thu, 21 Jul 2016, Bernd Edlinger wrote:


On 07/21/16 13:35, Richard Biener wrote:

On Thu, 21 Jul 2016, Bernd Edlinger wrote:


On 07/21/16 13:25, Bernd Schmidt wrote:



On 07/21/2016 01:16 PM, Jakub Jelinek wrote:

On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:

   bool
+gimple_alloca_call_p (const gimple *stmt)
+{
+  tree fndecl;
+
+  if (!is_gimple_call (stmt))
+return false;
+
+  fndecl = gimple_call_fndecl (stmt);
+  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;
+  }


This should have failed bootstrap because of -Wswitch-enum.
You need
  default:
break;
in.


+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;


Likewise here.


Or write it in the more natural way as an if.



I'm open for that suggestion.

Then I should probably also rewrite the switch statement
in special_function_p as an if.


I think a switch is a good fit though I don't mind an if as we probably
know we'll never get more than two alloca builtins (heh, you never know).



Thanks, style-nits are always welcome for me.  I also do care about
that a lot.

I will keep the switch at the moment, and continue the boot-strap
with the approved version.

BTW: in the function below "is_tm_builtin" there is a single switch
in a block statement, we usually don't do that redundant braces...


Richard, do you still have objections against the builtin_setjmp patch
from https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01225.html ?


No, I think it is ok, thus, approved as well.  Good to see that
special_function_p cleaned up ;)



Yeah that was about time!  But that function is still like a mine field.
And it looks like it has been waiting there for me, all these years ;)

Jeff has found a reference to "savectx" in Solaris10, so it is probably
not yet completely dead as I thought.

If we need to keep the handling of savectx in special_function_p, that
would mean there ought to be a new built-in function for savectx as
well IMO.

With that hint I have googled up a header file /usr/include/sys/proc.h
from 2002 where the function signature can be seen:

extern  voidsavectx(kthread_t *);

But that is in a #ifdef _KERNEL block, which means it is a kernel
function.
It's possible the issue came up building the SunOS/Solaris kernel -- 
circa 1992 I was loosely involved in a project that was bringing up that 
kernel on non-Sun hardware.  And that fits my recollection of when 
savectx support went into GCC.


jeff

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 14:08, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/21/16 13:35, Richard Biener wrote:
>>> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>>>
 On 07/21/16 13:25, Bernd Schmidt wrote:
>
>
> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
>> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>>>bool
>>> +gimple_alloca_call_p (const gimple *stmt)
>>> +{
>>> +  tree fndecl;
>>> +
>>> +  if (!is_gimple_call (stmt))
>>> +return false;
>>> +
>>> +  fndecl = gimple_call_fndecl (stmt);
>>> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
>>> +switch (DECL_FUNCTION_CODE (fndecl))
>>> +  {
>>> +  case BUILT_IN_ALLOCA:
>>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>>> +return true;
>>> +  }
>>
>> This should have failed bootstrap because of -Wswitch-enum.
>> You need
>>   default:
>> break;
>> in.
>>
>>> +switch (DECL_FUNCTION_CODE (fndecl))
>>> +  {
>>> +  case BUILT_IN_ALLOCA:
>>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>>> +return true;
>>
>> Likewise here.
>>
> Or write it in the more natural way as an if.
>

 I'm open for that suggestion.

 Then I should probably also rewrite the switch statement
 in special_function_p as an if.
>>>
>>> I think a switch is a good fit though I don't mind an if as we probably
>>> know we'll never get more than two alloca builtins (heh, you never know).
>>>
>>
>> Thanks, style-nits are always welcome for me.  I also do care about
>> that a lot.
>>
>> I will keep the switch at the moment, and continue the boot-strap
>> with the approved version.
>>
>> BTW: in the function below "is_tm_builtin" there is a single switch
>> in a block statement, we usually don't do that redundant braces...
>>
>>
>> Richard, do you still have objections against the builtin_setjmp patch
>> from https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01225.html ?
>
> No, I think it is ok, thus, approved as well.  Good to see that
> special_function_p cleaned up ;)
>

Yeah that was about time!  But that function is still like a mine field.
And it looks like it has been waiting there for me, all these years ;)

Jeff has found a reference to "savectx" in Solaris10, so it is probably
not yet completely dead as I thought.

If we need to keep the handling of savectx in special_function_p, that
would mean there ought to be a new built-in function for savectx as
well IMO.

With that hint I have googled up a header file /usr/include/sys/proc.h
from 2002 where the function signature can be seen:

extern  voidsavectx(kthread_t *);

But that is in a #ifdef _KERNEL block, which means it is a kernel
function.

All that is only necessary, because we try to fix broken header files :(
I mean they should simply add a __attribute__((returns_twice)) here.

So I think that means that it is not possible to fix a kernel-header
file with a fixinclude rule.  I have heard that gcc can be built
on solaris, but is gcc also used as a tool to generate the solaris
kernel?

Is it really justified to have a built-in function for that?
I mean, that would be there even for windows and linux where that
function name is not reserved?


Thanks
Bernd.

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

[David Malcolm]

On Thu, 2016-07-21 at 10:28 -0400, David Malcolm wrote:
> On Thu, 2016-07-21 at 09:00 +0200, Uros Bizjak wrote:
> > Hello!
> > 
> > > > gcc/ChangeLog:
> > > > PR c/70339
> > > > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
> > > > the
> > > > same location as last time, don't skip if we have fix-it hints.
> > > > Clarify the skipping logic by converting it from one "if"
> > > > clause
> > > > to repeated "if" clauses.
> > > > * spellcheck-tree.c: Include "cpplib.h".
> > > > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
> > > > (best_macro_match::best_macro_match): New constructor.
> > > > * spellcheck-tree.h (struct edit_distance_traits > > > *>):
> > > > Move here from c/c-decl.c.
> > > > (class best_macro_match): Move here from c/c-decl.c, converting
> > > > from a typedef to a subclass, gaining a ctor.
> > 
> > This part introduced bootstrap failure on CentOS 5.11:
> > 
> > g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict-aliasing
> > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> > -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> > -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
> > -I../../git/gcc/gcc -I../../git/gcc/gcc/.
> > -I../../git/gcc/gcc/../include 
> > -I../../git/gcc/gcc/../libcpp/include
> > -I/usr/local/include -I/usr/local/include -I/usr/local/include
> > -I../../git/gcc/gcc/../libdecnumber
> > -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
> > -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
> > spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
> > ../../git/gcc/gcc/spellcheck-tree.c
> > ../../git/gcc/gcc/spellcheck-tree.c: In constructor
> > ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
> > cpp_reader*)’:
> > ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
> > ‘best_macro_match’ does not have any field named ‘best_match’
> > ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching function
> > for call to ‘best_match::best_match()’
> > ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
> > best_match::best_match(GOAL_TYPE,
> > edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
> > cpp_hashnode*]
> > ../../git/gcc/gcc/spellcheck.h:81: note:
> > best_match::best_match(const
> > best_match&)
> > gmake: *** [spellcheck-tree.o] Error 1
> > 
> > CentOS 5 has pretty old system compiler [gcc version 4.1.2 20080704
> > (Red Hat 4.1.2-55)], but the build worked until the above patch was
> > committed. Is it possible to work around this failure somehow?
> 
> Sorry about the breakage.
> 
> I've now built a gcc 4.1 locally, and with that I can reproduce the
> issue.  Am investigating...

The following patch seems to fix it; successfully compiles that file
with my local builds of gcc 7 and gcc 4.1 (and with Fedora system gcc
4.8.3).

Does it fix the build for you?

Bootstrap underway here.

gcc/ChangeLog:
* spellcheck-tree.c (best_macro_match::best_macro_match):
Explicitly specify the template arguments when invoking the base
class constructor, to help older C++ compilers.

Sorry again about the breakage.

Dave
diff --git a/gcc/spellcheck-tree.c b/gcc/spellcheck-tree.c
index ef1e689..99a8dba 100644
--- a/gcc/spellcheck-tree.c
+++ b/gcc/spellcheck-tree.c
@@ -91,7 +91,7 @@ find_closest_macro_cpp_cb (cpp_reader *, cpp_hashnode *hashnode,
 best_macro_match::best_macro_match (tree goal,
 edit_distance_t best_distance_so_far,
 cpp_reader *reader)
-  : best_match (goal, best_distance_so_far)
+: best_match  (goal, best_distance_so_far)
 {
   cpp_forall_identifiers (reader, find_closest_macro_cpp_cb, this);
 }

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

[David Malcolm]

On Thu, 2016-07-21 at 09:00 +0200, Uros Bizjak wrote:
> Hello!
> 
> > > gcc/ChangeLog:
> > > PR c/70339
> > > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
> > > the
> > > same location as last time, don't skip if we have fix-it hints.
> > > Clarify the skipping logic by converting it from one "if"
> > > clause
> > > to repeated "if" clauses.
> > > * spellcheck-tree.c: Include "cpplib.h".
> > > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
> > > (best_macro_match::best_macro_match): New constructor.
> > > * spellcheck-tree.h (struct edit_distance_traits > > *>):
> > > Move here from c/c-decl.c.
> > > (class best_macro_match): Move here from c/c-decl.c, converting
> > > from a typedef to a subclass, gaining a ctor.
> 
> This part introduced bootstrap failure on CentOS 5.11:
> 
> g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict-aliasing
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../../git/gcc/gcc -I../../git/gcc/gcc/.
> -I../../git/gcc/gcc/../include -I../../git/gcc/gcc/../libcpp/include
> -I/usr/local/include -I/usr/local/include -I/usr/local/include
> -I../../git/gcc/gcc/../libdecnumber
> -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
> -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
> spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
> ../../git/gcc/gcc/spellcheck-tree.c
> ../../git/gcc/gcc/spellcheck-tree.c: In constructor
> ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
> cpp_reader*)’:
> ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
> ‘best_macro_match’ does not have any field named ‘best_match’
> ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching function
> for call to ‘best_match::best_match()’
> ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
> best_match::best_match(GOAL_TYPE,
> edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
> cpp_hashnode*]
> ../../git/gcc/gcc/spellcheck.h:81: note:
> best_match::best_match(const
> best_match&)
> gmake: *** [spellcheck-tree.o] Error 1
> 
> CentOS 5 has pretty old system compiler [gcc version 4.1.2 20080704
> (Red Hat 4.1.2-55)], but the build worked until the above patch was
> committed. Is it possible to work around this failure somehow?

Sorry about the breakage.

I've now built a gcc 4.1 locally, and with that I can reproduce the
issue.  Am investigating...

[Fortran, patch, v1] Add STAT= support to caf_single get()/send()

[Andre Vehreschild]

Hi all,

the attached patch adds support for a stat parameter to caf_single's
caf_get() and caf_send() routines and adds a testcase. Unfortunately is
there not much that can go wrong in a caf_single's get/send, so the test
resides to check whether stat is reset correctly. 

Bootstraps and regtests ok on x86_64-linux/F23.

Ok for trunk?

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


stat4cafsingle.clog
Description: Binary data
diff --git a/gcc/testsuite/gfortran.dg/coarray_stat_2.f90 b/gcc/testsuite/gfortran.dg/coarray_stat_2.f90
new file mode 100644
index 000..3bbd3fc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_stat_2.f90
@@ -0,0 +1,23 @@
+! { dg-do run }
+! { dg-options "-fcoarray=lib -lcaf_single" }
+!
+! Support for stat= in caf reference
+!
+program whitespace
+  implicit none
+
+  integer :: me[*],tmp,stat
+
+  me = this_image()
+  stat = 0
+
+  sync all(stat = stat)
+
+  if(stat /= 0) write(*,*) 'failure during sync'
+
+  stat = 42
+
+  tmp = me[num_images(),stat = stat]
+  if(stat /= 0) call abort()
+
+end program whitespace
diff --git a/libgfortran/caf/libcaf.h b/libgfortran/caf/libcaf.h
index 01a33f9..863b5b4 100644
--- a/libgfortran/caf/libcaf.h
+++ b/libgfortran/caf/libcaf.h
@@ -121,9 +121,11 @@ void _gfortran_caf_co_reduce (gfc_descriptor_t *, void* (*) (void *, void*),
 			  int, int, int *, char *, int, int);
 
 void _gfortran_caf_get (caf_token_t, size_t, int, gfc_descriptor_t *,
-caf_vector_t *, gfc_descriptor_t *, int, int, bool);
+			caf_vector_t *, gfc_descriptor_t *, int, int, bool,
+			int *);
 void _gfortran_caf_send (caf_token_t, size_t, int, gfc_descriptor_t *,
-			 caf_vector_t *, gfc_descriptor_t *, int, int, bool);
+			 caf_vector_t *, gfc_descriptor_t *, int, int, bool,
+			 int *);
 void _gfortran_caf_sendget (caf_token_t, size_t, int, gfc_descriptor_t *,
 			caf_vector_t *, caf_token_t, size_t, int,
 			gfc_descriptor_t *, caf_vector_t *, int, int, bool);
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index f726537..21916d3 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -328,7 +328,7 @@ assign_char1_from_char4 (size_t dst_size, size_t src_size, unsigned char *dst,
 
 static void
 convert_type (void *dst, int dst_type, int dst_kind, void *src, int src_type,
-	  int src_kind)
+	  int src_kind, int *stat)
 {
 #ifdef HAVE_GFC_INTEGER_16
   typedef __int128 int128t;
@@ -581,7 +581,10 @@ convert_type (void *dst, int dst_type, int dst_kind, void *src, int src_type,
 error:
   fprintf (stderr, "libcaf_single RUNTIME ERROR: Cannot convert type %d kind "
 	   "%d to type %d kind %d\n", src_type, src_kind, dst_type, dst_kind);
-  abort();
+  if (stat)
+*stat = 1;
+  else
+abort ();
 }
 
 
@@ -591,7 +594,7 @@ _gfortran_caf_get (caf_token_t token, size_t offset,
 		   gfc_descriptor_t *src,
 		   caf_vector_t *src_vector __attribute__ ((unused)),
 		   gfc_descriptor_t *dest, int src_kind, int dst_kind,
-		   bool may_require_tmp)
+		   bool may_require_tmp, int *stat)
 {
   /* FIXME: Handle vector subscripts.  */
   size_t i, k, size;
@@ -600,6 +603,9 @@ _gfortran_caf_get (caf_token_t token, size_t offset,
   size_t src_size = GFC_DESCRIPTOR_SIZE (src);
   size_t dst_size = GFC_DESCRIPTOR_SIZE (dest);
 
+  if (stat)
+*stat = 0;
+
   if (rank == 0)
 {
   void *sr = (void *) ((char *) TOKEN (token) + offset);
@@ -626,7 +632,7 @@ _gfortran_caf_get (caf_token_t token, size_t offset,
  sr);
   else
 	convert_type (GFC_DESCRIPTOR_DATA (dest), GFC_DESCRIPTOR_TYPE (dest),
-		  dst_kind, sr, GFC_DESCRIPTOR_TYPE (src), src_kind);
+		  dst_kind, sr, GFC_DESCRIPTOR_TYPE (src), src_kind, stat);
   return;
 }
 
@@ -710,7 +716,7 @@ _gfortran_caf_get (caf_token_t token, size_t offset,
 	assign_char4_from_char1 (dst_size, src_size, dst, sr);
 	  else
 	convert_type (dst, GFC_DESCRIPTOR_TYPE (dest), dst_kind,
-			  sr, GFC_DESCRIPTOR_TYPE (src), src_kind);
+			  sr, GFC_DESCRIPTOR_TYPE (src), src_kind, stat);
   array_offset_sr += src_size;
 	}
 
@@ -770,7 +776,7 @@ _gfortran_caf_get (caf_token_t token, size_t offset,
 	assign_char4_from_char1 (dst_size, src_size, dst, sr);
   else
 	convert_type (dst, GFC_DESCRIPTOR_TYPE (dest), dst_kind,
-		  sr, GFC_DESCRIPTOR_TYPE (src), src_kind);
+		  sr, GFC_DESCRIPTOR_TYPE (src), src_kind, stat);
 }
 }
 
@@ -781,7 +787,7 @@ _gfortran_caf_send (caf_token_t token, size_t offset,
 		gfc_descriptor_t *dest,
 		caf_vector_t *dst_vector __attribute__ ((unused)),
 		gfc_descriptor_t *src, int dst_kind, int src_kind,
-		bool may_require_tmp)
+		bool may_require_tmp, int *stat)
 {
   /* FIXME: Handle vector subscripts.  */
   size_t i, k, size;
@@ -790,6 +796,9 @@ _gfortran_caf_send (caf_token_t token, size_t offset,
   size_t src_size = GFC_DESCRIPTOR_SIZE (src);
   size_t dst_size = GFC_DESCRIPTOR_SIZE (dest);
 
+  if (stat)
+*stat = 0;
+
   

[PATCH] Improve VRP for PR71947

[Richard Biener]

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

Richard.

2016-07-21  Richard Biener  

PR tree-optimization/71947
* tree-vrp.c (extract_range_from_assert): Singleton symbolic
ranges have useful limit_vr information.

* gcc.dg/tree-ssa/vrp102.c: New testcase.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 238469)
--- gcc/tree-vrp.c  (working copy)
*** extract_range_from_assert (value_range *
*** 1513,1522 
limit_vr = (TREE_CODE (limit) == SSA_NAME) ? get_value_range (limit) : NULL;
  
/* LIMIT's range is only interesting if it has any useful information.  */
!   if (limit_vr
!   && (limit_vr->type == VR_UNDEFINED
! || limit_vr->type == VR_VARYING
! || symbolic_range_p (limit_vr)))
  limit_vr = NULL;
  
/* Initially, the new range has the same set of equivalences of
--- 1514,1526 
limit_vr = (TREE_CODE (limit) == SSA_NAME) ? get_value_range (limit) : NULL;
  
/* LIMIT's range is only interesting if it has any useful information.  */
!   if (! limit_vr
!   || limit_vr->type == VR_UNDEFINED
!   || limit_vr->type == VR_VARYING
!   || (symbolic_range_p (limit_vr)
! && ! (limit_vr->type == VR_RANGE
!   && (limit_vr->min == limit_vr->max
!   || operand_equal_p (limit_vr->min, limit_vr->max, 0)
  limit_vr = NULL;
  
/* Initially, the new range has the same set of equivalences of
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp102.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/vrp102.c  (revision 0)
--- gcc/testsuite/gcc.dg/tree-ssa/vrp102.c  (working copy)
***
*** 0 
--- 1,18 
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -fno-tree-dominator-opts -fdump-tree-vrp1" } */
+ 
+ int f(int x, int y)
+ { 
+   int ret; 
+   if (x == y)
+ ret = x ^ y;
+   else
+ ret = 1;
+ 
+   return ret;
+ } 
+ 
+ /* We should have computed x ^ y as zero and propagated the result into the
+PHI feeding the result.  */
+ 
+ /* { dg-final { scan-tree-dump "ret_\[0-9\]+ = PHI <\[01\]\\\(\[0-9\]+\\\), 
\[01\]\\\(\[0-9\]+\\\)>" "vrp1" } } */

Re: [Fortran] Help with STAT= attribute in coarray reference

[Andre Vehreschild]

Hi all,

the attached patch fixes some style issues in the caf code recently
modified. Furthermore does it correct the function specifications of 
caf_get() and caf_send() that where missing some specifiers.

Bootstrapped and regtested ok on x86_64-linux/F23. If noone objects I
commit this patch as obvious tomorrow.

In my pipeline is a patch that will add stat= support to the libcaf
interface and caf_single.

Regards,
Andre

On Tue, 5 Jul 2016 09:33:49 -0600
Alessandro Fanfarillo  wrote:

> Thanks, committed as rev. 238007.
> 
> 2016-07-04 14:41 GMT-06:00 Mikael Morin :
> > Le 30/06/2016 06:05, Alessandro Fanfarillo a écrit :  
> >>
> >> Dear Mikael,
> >>
> >> thanks for your review and for the test. The attached patch, built
> >> and regtested for x86_64-pc-linux-gnu, addresses all the
> >> suggestions.
> >>
> >> The next patch will change the documentation related to the caf_get
> >> and caf_send functions and will add support for STAT= to the
> >> sendget function.
> >>
> >> In the meantime, is this patch OK for trunk?
> >>  
> > Yes, thanks.
> >
> > Mikael
> >
> >  


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


cosmetics_caf.clog
Description: Binary data
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 7328898..6d0eb22 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4437,9 +4437,9 @@ gfc_find_stat_co(gfc_expr *e)
 if (ref->type == REF_ARRAY && ref->u.ar.codimen > 0)
   return ref->u.ar.stat;
 
-  if(e->value.function.actual->expr)
-for(ref = e->value.function.actual->expr->ref; ref;
-	ref = ref->next)
+  if (e->value.function.actual->expr)
+for (ref = e->value.function.actual->expr->ref; ref;
+	 ref = ref->next)
   if (ref->type == REF_ARRAY && ref->u.ar.codimen > 0)
 	return ref->u.ar.stat;
 
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 4d288ba..cc80204 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -3799,7 +3799,7 @@ compared to the base address of the coarray.
 number.
 @item @var{dest} @tab intent(in) Array descriptor for the remote image for the
 bounds and the size. The base_addr shall not be accessed.
-@item @var{dst_vector} @tab intent(int)  If not NULL, it contains the vector
+@item @var{dst_vector} @tab intent(in)  If not NULL, it contains the vector
 subscript of the destination array; the values are relative to the dimension
 triplet of the dest argument.
 @item @var{src} @tab intent(in) Array descriptor of the local array to be
@@ -3839,7 +3839,7 @@ Called to get an array section or whole array from a a remote,
 image identified by the image_index.
 
 @item @emph{Syntax}:
-@code{void _gfortran_caf_get_desc (caf_token_t token, size_t offset,
+@code{void _gfortran_caf_get (caf_token_t token, size_t offset,
 int image_index, gfc_descriptor_t *src, caf_vector_t *src_vector,
 gfc_descriptor_t *dest, int src_kind, int dst_kind, bool may_require_tmp)}
 
@@ -3850,13 +3850,13 @@ gfc_descriptor_t *dest, int src_kind, int dst_kind, bool may_require_tmp)}
 compared to the base address of the coarray.
 @item @var{image_index} @tab The ID of the remote image; must be a positive
 number.
-@item @var{dest} @tab intent(in) Array descriptor of the local array to be
-transferred to the remote image
+@item @var{dest} @tab intent(out) Array descriptor of the local array to store
+the data transferred from the remote image
 @item @var{src} @tab intent(in) Array descriptor for the remote image for the
 bounds and the size. The base_addr shall not be accessed.
-@item @var{src_vector} @tab intent(int)  If not NULL, it contains the vector
-subscript of the destination array; the values are relative to the dimension
-triplet of the dest argument.
+@item @var{src_vector} @tab intent(in)  If not NULL, it contains the vector
+subscript of the source array; the values are relative to the dimension
+triplet of the src argument.
 @item @var{dst_kind} @tab Kind of the destination argument
 @item @var{src_kind} @tab Kind of the source argument
 @item @var{may_require_tmp} @tab The variable is false it is known at compile
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 69ddd17..05dfcb4 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3538,38 +3538,38 @@ gfc_build_builtin_function_decls (void)
 	= build_pointer_type (build_pointer_type (pchar_type_node));
 
   gfor_fndecl_caf_init = gfc_build_library_function_decl (
-		   get_identifier (PREFIX("caf_init")),  void_type_node,
-		   2, pint_type, pppchar_type);
+	get_identifier (PREFIX("caf_init")), void_type_node,
+	2, pint_type, pppchar_type);
 
   gfor_fndecl_caf_finalize = gfc_build_library_function_decl (
 	get_identifier (PREFIX("caf_finalize")), void_type_node, 0);
 
   gfor_fndecl_caf_this_image = gfc_build_library_function_decl (
-		   get_identifier (PREFIX("caf_this_image")), integer_type_node,
-		   1, integer_type_node);
+	get_identifier 

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

[Jan Hubicka]

> Maybe it is better to separate value range and alignment summary
> writing/reading to different functions. Here is another updated
> version which does this.

Makes sense to me. Note that the alignment summary propagation can be either
handled by doing bitwise constant propagation and/or extending our value ranges
by stride (as described in
http://www.lighterra.com/papers/valuerangeprop/Patterson1995-ValueRangeProp.pdf
I would like it to go eventually away in favour of more generic solution.

> -/* If DEST_PLATS already has aggregate items, check that aggs_by_ref matches
> +/* Propagate value range across jump function JFUNC that is associated with
> +   edge CS and update DEST_PLATS accordingly.  */
> +
> +static bool
> +propagate_vr_accross_jump_function (cgraph_edge *cs,
> + ipa_jump_func *jfunc,
> + struct ipcp_param_lattices *dest_plats)
> +{
> +  struct ipcp_param_lattices *src_lats;
> +  ipcp_vr_lattice *dest_lat = _plats->m_value_range;
> +
> +  if (dest_lat->bottom_p ())
> +return false;
> +
> +  if (jfunc->type == IPA_JF_PASS_THROUGH)
> +{
> +  struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> +  int src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
> +  src_lats = ipa_get_parm_lattices (caller_info, src_idx);
> +
> +  if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
> + return dest_lat->meet_with (src_lats->m_value_range);

Clearly we can propagate thorugh expressions here (PLUS_EXPR). I have run
into similar issue in loop code that builds simple generic expresisons
(like (int)ssa_name+10) and it would be nice to have easy way to deterine
their value range based on the knowledge of SSA_NAME's valur range.

Bit this is fine for initial implementaiotn for sure.
>  
> +/* Look up all VR information that we have discovered and copy it over
> +   to the transformation summary.  */
> +
> +static void
> +ipcp_store_vr_results (void)
> +{
> +  cgraph_node *node;
> +
> +  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
> +  {
> +ipa_node_params *info = IPA_NODE_REF (node);
> +bool found_useful_result = false;
> +
> +if (!opt_for_fn (node->decl, flag_ipa_vrp))
> +  {
> + if (dump_file)
> +   fprintf (dump_file, "Not considering %s for VR discovery "
> +"and propagate; -fipa-ipa-vrp: disabled.\n",
> +node->name ());
> + continue;

I belive you need to also prevent propagation through functions copmiled with
-fno-ipa-vrp, not only prevent any transformations.
> +/* Update value range of formal parameters as described in
> +   ipcp_transformation_summary.  */
> +
> +static void
> +ipcp_update_vr (struct cgraph_node *node)
> +{
> +  tree fndecl = node->decl;
> +  tree parm = DECL_ARGUMENTS (fndecl);
> +  tree next_parm = parm;
> +  ipcp_transformation_summary *ts = ipcp_get_transformation_summary (node);
> +  if (!ts || vec_safe_length (ts->m_vr) == 0)
> +return;
> +  const vec  = *ts->m_vr;
> +  unsigned count = vr.length ();
> +
> +  for (unsigned i = 0; i < count; ++i, parm = next_parm)
> +{
> +  if (node->clone.combined_args_to_skip
> +   && bitmap_bit_p (node->clone.combined_args_to_skip, i))
> + continue;
> +  gcc_checking_assert (parm);
> +  next_parm = DECL_CHAIN (parm);
> +  tree ddef = ssa_default_def (DECL_STRUCT_FUNCTION (node->decl), parm);
> +
> +  if (!ddef || !is_gimple_reg (parm))
> + continue;
> +
> +  if (cgraph_local_p (node)
The test of cgraph_local_p seems redundant here. The analysis phase should not 
determine
anything if function is reachable non-locally.
> +/* Info about value ranges.  */
> +
> +struct GTY(()) ipa_vr
> +{
> +  /* The data fields below are valid only if known is true.  */
> +  bool known;
> +  enum value_range_type type;
> +  tree min;
> +  tree max;
What is the point of representing range as trees rather than wide ints. Can they
be non-constant integer?

The patch looks good to me otherwise!
Honza

[PATCH, OBVIOUS] Do not divide by zero in analyze_brprob.py

[Martin Liška]

Hi.

Following trivial patch is necessary to preserve division by zero.

Installed as r238590.

Thanks,
Martin
>From 990fd22bfe222a5f66fa780d5b596b7a948ea267 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 21 Jul 2016 14:49:30 +0200
Subject: [PATCH] Do not divide by zero in analyze_brprob.py

contrib/ChangeLog:

2016-07-21  Martin Liska  

	* analyze_brprob.py: If there's no loop, do not calculate
	average number of loop iterations.
---
 contrib/analyze_brprob.py | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/contrib/analyze_brprob.py b/contrib/analyze_brprob.py
index c276d81..c083d2b 100755
--- a/contrib/analyze_brprob.py
+++ b/contrib/analyze_brprob.py
@@ -149,12 +149,13 @@ class Profile:
  percentage(v.hits, v.count), percentage(v.fits, v.count),
  v.count, v.count_formatted(), percentage(v.count, self.count_max()) ))
 
-print ('\nLoop count: %d' % len(self.niter_vector)),
-print('  avg. # of iter: %.2f' % average(self.niter_vector))
-print('  median # of iter: %.2f' % median(self.niter_vector))
-for v in [1, 5, 10, 20, 30]:
-cut = 0.01 * v
-print('  avg. (%d%% cutoff) # of iter: %.2f' % (v, average_cutoff(self.niter_vector, cut)))
+if len(self.niter_vector) > 0:
+print ('\nLoop count: %d' % len(self.niter_vector)),
+print('  avg. # of iter: %.2f' % average(self.niter_vector))
+print('  median # of iter: %.2f' % median(self.niter_vector))
+for v in [1, 5, 10, 20, 30]:
+cut = 0.01 * v
+print('  avg. (%d%% cutoff) # of iter: %.2f' % (v, average_cutoff(self.niter_vector, cut)))
 
 parser = argparse.ArgumentParser()
 parser.add_argument('dump_file', metavar = 'dump_file', help = 'IPA profile dump file')
-- 
2.9.0

[PATCH] Assorted fixes from LTO early debug

[Richard Biener]

The following makes sure the BLOCK_SUPERCONTEXT of DECL_INITIAL (decl)
is decl itself (I won't commit the assert in cfgexpand.c but 
bootstrap/test passed with it).  It also marks yet another global
initializer with DECL_IGNORED_P, in this case as it is emitted very
late after early debug is finished.

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

Richard.

2016-07-21  Richard Biener  

* function-tests.c (build_trivial_generic_function): Set
BLOCK_SUPERCONTEXT of DECL_INITIAL.
* omp-low.c (create_omp_child_function): Likewise.
(grid_expand_target_grid_body): Likewise.
* cgraphunit.c (init_lowered_empty_function): Likewise.
(cgraph_node::expand_thunk): Likewise.
* tree-parloops.c (create_loop_fn): Likewise.
* ipa.c (cgraph_build_static_cdtor_1): Likewise.

cp/
* vtable-class-hierarchy.c (vtv_generate_init_routine): Set
DECL_IGNORED_P.

java/
* jcf-parse.c (java_emit_static_constructor): Set
BLOCK_SUPERCONTEXT of DECL_INITIAL.

Index: gcc/function-tests.c
===
--- gcc/function-tests.c(revision 238584)
+++ gcc/function-tests.c(working copy)
@@ -249,6 +249,7 @@ build_trivial_generic_function ()
   tsi_link_after (_iter, return_stmt, TSI_CONTINUE_LINKING);
 
   DECL_INITIAL (fndecl) = block;
+  BLOCK_SUPERCONTEXT (block) = fndecl;
 
   /* how to add to function? the following appears to be how to
  set the body of a fndecl: */
Index: gcc/java/jcf-parse.c
===
--- gcc/java/jcf-parse.c(revision 238584)
+++ gcc/java/jcf-parse.c(working copy)
@@ -1719,6 +1719,7 @@ java_emit_static_constructor (void)
   DECL_UNINLINABLE (decl) = 1;
 
   DECL_INITIAL (decl) = make_node (BLOCK);
+  BLOCK_SUPERCONTEXT (DECL_INITIAL (decl)) = decl;
   TREE_USED (DECL_INITIAL (decl)) = 1;
 
   DECL_STATIC_CONSTRUCTOR (decl) = 1;
Index: gcc/omp-low.c
===
--- gcc/omp-low.c   (revision 238584)
+++ gcc/omp-low.c   (working copy)
@@ -2472,6 +2472,7 @@ create_omp_child_function (omp_context *
   DECL_EXTERNAL (decl) = 0;
   DECL_CONTEXT (decl) = NULL_TREE;
   DECL_INITIAL (decl) = make_node (BLOCK);
+  BLOCK_SUPERCONTEXT (DECL_INITIAL (decl)) = decl;
   if (cgraph_node::get (current_function_decl)->offloadable)
 cgraph_node::get_create (decl)->offloadable = 1;
   else
@@ -13670,6 +13671,7 @@ grid_expand_target_grid_body (struct omp
   BLOCK_ABSTRACT_ORIGIN (fniniblock) = tgtblock;
   BLOCK_SOURCE_LOCATION (fniniblock) = BLOCK_SOURCE_LOCATION (tgtblock);
   BLOCK_SOURCE_END_LOCATION (fniniblock) = BLOCK_SOURCE_END_LOCATION 
(tgtblock);
+  BLOCK_SUPERCONTEXT (fniniblock) = kern_fndecl;
   DECL_INITIAL (kern_fndecl) = fniniblock;
   push_struct_function (kern_fndecl);
   cfun->function_end_locus = gimple_location (tgt_stmt);
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 238584)
+++ gcc/cgraphunit.c(working copy)
@@ -1438,6 +1438,7 @@ init_lowered_empty_function (tree decl,
 }
 
   DECL_INITIAL (decl) = make_node (BLOCK);
+  BLOCK_SUPERCONTEXT (DECL_INITIAL (decl)) = decl;
 
   DECL_SAVED_TREE (decl) = error_mark_node;
   cfun->curr_properties |= (PROP_gimple_lcf | PROP_gimple_leh | PROP_gimple_any
@@ -1627,6 +1628,7 @@ cgraph_node::expand_thunk (bool output_a
   fn_block = make_node (BLOCK);
   BLOCK_VARS (fn_block) = a;
   DECL_INITIAL (thunk_fndecl) = fn_block;
+  BLOCK_SUPERCONTEXT (fn_block) = thunk_fndecl;
   allocate_struct_function (thunk_fndecl, false);
   init_function_start (thunk_fndecl);
   cfun->is_thunk = 1;
Index: gcc/cp/vtable-class-hierarchy.c
===
--- gcc/cp/vtable-class-hierarchy.c (revision 238584)
+++ gcc/cp/vtable-class-hierarchy.c (working copy)
@@ -1182,6 +1182,9 @@ vtv_generate_init_routine (void)
   TREE_STATIC (vtv_fndecl) = 1;
   TREE_USED (vtv_fndecl) = 1;
   DECL_PRESERVE_P (vtv_fndecl) = 1;
+  /* We are running too late to generate any meaningful debug information
+ for this routine.  */
+  DECL_IGNORED_P (vtv_fndecl) = 1;
   if (flag_vtable_verify == VTV_PREINIT_PRIORITY && !TARGET_PECOFF)
 DECL_STATIC_CONSTRUCTOR (vtv_fndecl) = 0;
 
Index: gcc/tree-parloops.c
===
--- gcc/tree-parloops.c (revision 238584)
+++ gcc/tree-parloops.c (working copy)
@@ -1476,6 +1476,7 @@ create_loop_fn (location_t loc)
   DECL_EXTERNAL (decl) = 0;
   DECL_CONTEXT (decl) = NULL_TREE;
   DECL_INITIAL (decl) = make_node (BLOCK);
+  BLOCK_SUPERCONTEXT (DECL_INITIAL (decl)) = decl;
 
   t = build_decl (loc, RESULT_DECL, NULL_TREE, void_type_node);
   

fix typo in comment in tree-ssa-strlen.c

[Prathamesh Kulkarni]

Committed as obvious (r238588).

Thanks,
Prathamesh
Index: tree-ssa-strlen.c
===
--- tree-ssa-strlen.c   (revision 238587)
+++ tree-ssa-strlen.c   (working copy)
@@ -2383,7 +2383,7 @@
 };
 
 /* Callback for walk_dominator_tree.  Attempt to optimize various
-   string ops by remembering string lenths pointed by pointer SSA_NAMEs.  */
+   string ops by remembering string lengths pointed by pointer SSA_NAMEs.  */
 
 edge
 strlen_dom_walker::before_dom_children (basic_block bb)


ChangeLog
Description: Binary data

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Richard Biener]

On Thu, 21 Jul 2016, Bernd Edlinger wrote:

> On 07/21/16 13:35, Richard Biener wrote:
> > On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> >
> >> On 07/21/16 13:25, Bernd Schmidt wrote:
> >>>
> >>>
> >>> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
>  On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> >   bool
> > +gimple_alloca_call_p (const gimple *stmt)
> > +{
> > +  tree fndecl;
> > +
> > +  if (!is_gimple_call (stmt))
> > +return false;
> > +
> > +  fndecl = gimple_call_fndecl (stmt);
> > +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> > +switch (DECL_FUNCTION_CODE (fndecl))
> > +  {
> > +  case BUILT_IN_ALLOCA:
> > +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> > +return true;
> > +  }
> 
>  This should have failed bootstrap because of -Wswitch-enum.
>  You need
>   default:
> break;
>  in.
> 
> > +switch (DECL_FUNCTION_CODE (fndecl))
> > +  {
> > +  case BUILT_IN_ALLOCA:
> > +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> > +return true;
> 
>  Likewise here.
> 
> >>> Or write it in the more natural way as an if.
> >>>
> >>
> >> I'm open for that suggestion.
> >>
> >> Then I should probably also rewrite the switch statement
> >> in special_function_p as an if.
> >
> > I think a switch is a good fit though I don't mind an if as we probably
> > know we'll never get more than two alloca builtins (heh, you never know).
> >
> 
> Thanks, style-nits are always welcome for me.  I also do care about
> that a lot.
> 
> I will keep the switch at the moment, and continue the boot-strap
> with the approved version.
> 
> BTW: in the function below "is_tm_builtin" there is a single switch
> in a block statement, we usually don't do that redundant braces...
> 
> 
> Richard, do you still have objections against the builtin_setjmp patch
> from https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01225.html ?

No, I think it is ok, thus, approved as well.  Good to see that
special_function_p cleaned up ;)

Thanks,
Richard.

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 13:35, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/21/16 13:25, Bernd Schmidt wrote:
>>>
>>>
>>> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
 On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>   bool
> +gimple_alloca_call_p (const gimple *stmt)
> +{
> +  tree fndecl;
> +
> +  if (!is_gimple_call (stmt))
> +return false;
> +
> +  fndecl = gimple_call_fndecl (stmt);
> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> +switch (DECL_FUNCTION_CODE (fndecl))
> +  {
> +  case BUILT_IN_ALLOCA:
> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> +return true;
> +  }

 This should have failed bootstrap because of -Wswitch-enum.
 You need
  default:
break;
 in.

> +switch (DECL_FUNCTION_CODE (fndecl))
> +  {
> +  case BUILT_IN_ALLOCA:
> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> +return true;

 Likewise here.

>>> Or write it in the more natural way as an if.
>>>
>>
>> I'm open for that suggestion.
>>
>> Then I should probably also rewrite the switch statement
>> in special_function_p as an if.
>
> I think a switch is a good fit though I don't mind an if as we probably
> know we'll never get more than two alloca builtins (heh, you never know).
>

Thanks, style-nits are always welcome for me.  I also do care about
that a lot.

I will keep the switch at the moment, and continue the boot-strap
with the approved version.

BTW: in the function below "is_tm_builtin" there is a single switch
in a block statement, we usually don't do that redundant braces...


Richard, do you still have objections against the builtin_setjmp patch
from https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01225.html ?




Bernd.


> Richard.
>
>> Thanks
>> Bernd.
>>
>>>
>>> Bernd
>>>
>>
>>
>

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Richard Biener]

On Thu, 21 Jul 2016, Bernd Edlinger wrote:

> On 07/21/16 13:25, Bernd Schmidt wrote:
> >
> >
> > On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
> >> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> >>>  bool
> >>> +gimple_alloca_call_p (const gimple *stmt)
> >>> +{
> >>> +  tree fndecl;
> >>> +
> >>> +  if (!is_gimple_call (stmt))
> >>> +return false;
> >>> +
> >>> +  fndecl = gimple_call_fndecl (stmt);
> >>> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> >>> +switch (DECL_FUNCTION_CODE (fndecl))
> >>> +  {
> >>> +  case BUILT_IN_ALLOCA:
> >>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> >>> +return true;
> >>> +  }
> >>
> >> This should have failed bootstrap because of -Wswitch-enum.
> >> You need
> >> default:
> >>   break;
> >> in.
> >>
> >>> +switch (DECL_FUNCTION_CODE (fndecl))
> >>> +  {
> >>> +  case BUILT_IN_ALLOCA:
> >>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> >>> +return true;
> >>
> >> Likewise here.
> >>
> > Or write it in the more natural way as an if.
> >
> 
> I'm open for that suggestion.
> 
> Then I should probably also rewrite the switch statement
> in special_function_p as an if.

I think a switch is a good fit though I don't mind an if as we probably
know we'll never get more than two alloca builtins (heh, you never know).

Richard.

> Thanks
> Bernd.
> 
> >
> > Bernd
> >
> 
> 

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

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 13:25, Bernd Schmidt wrote:
>
>
> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
>> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>>>  bool
>>> +gimple_alloca_call_p (const gimple *stmt)
>>> +{
>>> +  tree fndecl;
>>> +
>>> +  if (!is_gimple_call (stmt))
>>> +return false;
>>> +
>>> +  fndecl = gimple_call_fndecl (stmt);
>>> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
>>> +switch (DECL_FUNCTION_CODE (fndecl))
>>> +  {
>>> +  case BUILT_IN_ALLOCA:
>>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>>> +return true;
>>> +  }
>>
>> This should have failed bootstrap because of -Wswitch-enum.
>> You need
>> default:
>>   break;
>> in.
>>
>>> +switch (DECL_FUNCTION_CODE (fndecl))
>>> +  {
>>> +  case BUILT_IN_ALLOCA:
>>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>>> +return true;
>>
>> Likewise here.
>>
> Or write it in the more natural way as an if.
>

I'm open for that suggestion.

Then I should probably also rewrite the switch statement
in special_function_p as an if.

Thanks
Bernd.

>
> Bernd
>

Re: [Re: RFC: Patch 1/2 v3] New target hook: max_noce_ifcvt_seq_cost

[Bernd Schmidt]

On 07/20/2016 06:39 PM, James Greenhalgh wrote:

On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote:

How about wrapping the param value into COSTS_N_INSNS, to make the
value of the param less dependent on compiler internals?


I did consider this, but found it hard to word for the user documentation.
I found it easier to understand when it was in the same units as
rtx_cost, particularly as the AArch64 backend prints RTX costs to most
dump files (including ce1, ce2, ce3) so comparing directly was easy for me
to grok. I think going in either direction has the potential to confuse
users, the cost metrics of the RTL passes are very tightly coupled to
compiler internals.

I don't have a strong feeling either way, just a slight preference to keep
everything in the same units as rtx_cost where I can.


I guess it's ok.


Bernd

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Richard Biener]

On Thu, 21 Jul 2016, Bernd Edlinger wrote:

> On 07/21/16 13:16, Jakub Jelinek wrote:
> > On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> >>   bool
> >> +gimple_alloca_call_p (const gimple *stmt)
> >> +{
> >> +  tree fndecl;
> >> +
> >> +  if (!is_gimple_call (stmt))
> >> +return false;
> >> +
> >> +  fndecl = gimple_call_fndecl (stmt);
> >> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> >> +switch (DECL_FUNCTION_CODE (fndecl))
> >> +  {
> >> +  case BUILT_IN_ALLOCA:
> >> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> >> +return true;
> >> +  }
> >
> > This should have failed bootstrap because of -Wswitch-enum.
> > You need
> > default:
> >   break;
> > in.
> >
> >> +switch (DECL_FUNCTION_CODE (fndecl))
> >> +  {
> >> +  case BUILT_IN_ALLOCA:
> >> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> >> +return true;
> >
> > Likewise here.
> >
> 
> Thanks, confirmed.
> I added that now.

Ok with that change.

Thanks,
Richard.


> Bernd.
> 
> > Jakub
> >
> 
> 

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

Re: [PATCH] Tree-level fix for PR 69526

[Richard Biener]

On Thu, Jul 21, 2016 at 12:42 PM, Robin Dapp  wrote:
> As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526, we
> currently fail to simplify cases like
>
> (unsigned long)(a - 1) + 1
>
> to
>
> (unsigned long)a
>
> when VRP knows that (a - 1) does not overflow.
>
> This patch introduces a match.pd pattern as well as a helper function
> that checks for overflow in a binary operation using VRP information and
> simplifies when no overflow is present.
>
> Some effort was put in to stay in the inner type in cases like this
>
> (unsigned long)(a + CST1) - CST2
> ->
> (unsigned long)(a + CST3) rather than
> (unsigned long)a + CST3
>
> where abs(CST3) = abs(CST1 - CST) <= abs(CST1). I wonder if this is
> warranted, i.e. if it is always advantageous or if the evaluation should
> rather involve a cost estimation - e.g. distinguish between costs for
> operations in int vs. in long.
>
> Absence of signed overflow is also exploited:
>
> (long)(a + 2) - 1
> ->
> (long)(a + 1)
>
> Bootstrapped and regression tested on s390x and x86_64.

I find this a bit hard to follow (looking at the match.pd pattern).

+   if (check_inner_ovf)
+ {
+   // check if the inner binop does not overflow i.e. we have VRP
+   // information and can prove prove it
+   inner_ovf = binop_overflow (inner_op, @0, @1, inner_type);
+ }

if !inner_ovf (just set that to false if !check_inner_ovf to simplify
checks please).
you know it's valid to transform the op to (T)@0 innerop (T)@1 outerop @2
(if T is wider than the inner type which I think you should check and
which should
simplify things).

You can then combine (T)@1 and @2 where I think you fail to handle mixed
MINUS_EXPR/PLUS_EXPR (practically you'll see only PLUS_EXPRs for integers).

So you have (T)@0 + combined-in-T which you then can either emit or
check whether
combined-in-T fits in the inner type and @0 + combined-in-T does not overflow in
which case (T)(@0 + combined-in-T) is safe.

I believe that for simplicity we want to split this transform into two
- one doing
(T)(a + CST) - CST -> (T)a + CST' and one doing (T)a + CST -> (T)(a + CST).

The testcase is rather unspecific as to what testcases shoudl fold and what not
given your very simple scan and mixing should/should-not simplify cases.  Please
consider splitting it up and make it a run test that verifies the
bogus transforms
do not take place.

Doing

+static bool
+simplify_plus_or_minus_using_ranges (gimple_stmt_iterator *gsi, gimple *stmt)
+{
+  enum tree_code code = gimple_assign_rhs_code (stmt);
+  tree op0 = gimple_assign_rhs1 (stmt);
+  tree op1 = gimple_assign_rhs2 (stmt);
+
+  if ((code == PLUS_EXPR || code == MINUS_EXPR) &&
+  op0 != NULL && op1 != NULL)
+{
+  gimple *stmt1 = SSA_NAME_DEF_STMT (op0);
+  if (gassign *def = dyn_cast  (stmt1))
+   {
+ if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
+ && TREE_CODE (op1) == INTEGER_CST)
+   {
+ if (fold_stmt (gsi, follow_single_use_edges))
+   return true;

causes such stmts to be folded twice as substitute_and_fold does

  /* Some statements may be simplified using propagator
 specific information.  Do this before propagating
 into the stmt to not disturb pass specific information.  */
  if (fold_fn
  && (*fold_fn)())
{
  did_replace = true;
  prop_stats.num_stmts_folded++;
  stmt = gsi_stmt (i);
  update_stmt (stmt);
}

  /* Replace real uses in the statement.  */
  did_replace |= replace_uses_in (stmt, get_value_fn);

  /* If we made a replacement, fold the statement.  */
  if (did_replace)
{
  fold_stmt (, follow_single_use_edges);
  stmt = gsi_stmt (i);

which is less than ideal.  I think that given we have fold_stmt following
SSA edges and thus not only stmts we propagated into are possibly
interesting to fold (but also their single-uses, recursively), we should
evaluate the compile-time cost of doing the fold_stmt unconditionally.

diff --git a/gcc/tree.c b/gcc/tree.c
index 2295111..bc477fa 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -1358,6 +1358,108 @@ force_fit_type (tree type, const wide_int_ref ,
   return wide_int_to_tree (type, cst);
 }

+bool binop_overflow (enum tree_code op, tree t1, tree t2, tree type)
+{

tree.c doesn't look like the best fit.  I think putting it into
tree-vrp.c is better
and I think that extract_range_from_binary_expr_1 itself should compute what we
want here as additional output.  Conservative handling for all but plus/minus is
ok with me.

+  if (t1 == NULL_TREE || t2 == NULL_TREE || type == NULL_TREE)
+return true;
+
+  if (TYPE_OVERFLOW_UNDEFINED (type))
+return false;
+
+  if (!INTEGRAL_TYPE_P (type))
+return true;

note that we'll ICE if you call TYPE_OVERFLOW_UNDEFINED on a type
that is not ANY_INTEGRAL_TYPE_P, so better 

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 13:16, Jakub Jelinek wrote:
> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>>   bool
>> +gimple_alloca_call_p (const gimple *stmt)
>> +{
>> +  tree fndecl;
>> +
>> +  if (!is_gimple_call (stmt))
>> +return false;
>> +
>> +  fndecl = gimple_call_fndecl (stmt);
>> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
>> +switch (DECL_FUNCTION_CODE (fndecl))
>> +  {
>> +  case BUILT_IN_ALLOCA:
>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>> +return true;
>> +  }
>
> This should have failed bootstrap because of -Wswitch-enum.
> You need
>   default:
> break;
> in.
>
>> +switch (DECL_FUNCTION_CODE (fndecl))
>> +  {
>> +  case BUILT_IN_ALLOCA:
>> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
>> +return true;
>
> Likewise here.
>

Thanks, confirmed.
I added that now.

Bernd.

>   Jakub
>

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Schmidt]

On 07/21/2016 01:16 PM, Jakub Jelinek wrote:

On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:

 bool
+gimple_alloca_call_p (const gimple *stmt)
+{
+  tree fndecl;
+
+  if (!is_gimple_call (stmt))
+return false;
+
+  fndecl = gimple_call_fndecl (stmt);
+  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;
+  }


This should have failed bootstrap because of -Wswitch-enum.
You need
default:
  break;
in.


+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;


Likewise here.


Or write it in the more natural way as an if.


Bernd

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

[Peter Bergner]

On 7/21/16 3:26 AM, Alan Modra wrote:

On Wed, Jul 20, 2016 at 08:51:21PM -0500, Peter Bergner wrote:

This still doesn't answer David's question about what will happen if
we generate this pattern (or one of the older VSX reg+reg patterns)
when we are NOT using -mno-vsx.  In those cases, quad_address_p and
mode_supports_vsx_dform_quad will return true and it seems like
we'll go ahead and generate these reg+offset addresses when they're
not legal for these patterns.


The question doesn't make a great deal of sense.  altivec_mov* and
vsx_mov* have mutually exclusive insn predicates, and at the RTL level
they all look the same.  So even if you did generate the "wrong"
insn RTL, the right one would match.  For example, if you generated
RTL using altivec_mov with -mvsx, vsx_mov would match it, *not*
altivec_mov.


Ah, so you're saying we'll never generate those patterns (modulo thru
builtins which already force reg+reg addressing), so this isn't a
problem?  Well that answers our question then.  Thanks!

Peter

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Jakub Jelinek]

On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>  bool
> +gimple_alloca_call_p (const gimple *stmt)
> +{
> +  tree fndecl;
> +
> +  if (!is_gimple_call (stmt))
> +return false;
> +
> +  fndecl = gimple_call_fndecl (stmt);
> +  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> +switch (DECL_FUNCTION_CODE (fndecl))
> +  {
> +  case BUILT_IN_ALLOCA:
> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> +return true;
> +  }

This should have failed bootstrap because of -Wswitch-enum.
You need
default:
  break;
in.

> +switch (DECL_FUNCTION_CODE (fndecl))
> +  {
> +  case BUILT_IN_ALLOCA:
> +  case BUILT_IN_ALLOCA_WITH_ALIGN:
> +return true;

Likewise here.

Jakub

Re: [PATCH, Fortran, OpenACC] Fix PR70598, Fortran host_data ICE

[Jakub Jelinek]

On Mon, May 09, 2016 at 10:26:50PM +0800, Chung-Lin Tang wrote:
> 2015-05-09  Chung-Lin Tang  
> 
>   gcc/
>   * fortran/openmp.c (resolve_omp_clauses): Adjust use_device clause
>   handling to only allow pointers and arrays.

As has been mentioned earlier, this should go into gcc/fortran/ChangeLog
without fortran/ prefix.

> --- gcc/fortran/openmp.c  (revision 236020)
> +++ gcc/fortran/openmp.c  (working copy)
> @@ -3743,11 +3743,18 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_claus
> && CLASS_DATA (n->sym)->attr.allocatable))
>   gfc_error ("ALLOCATABLE object %qs in %s clause at %L",
>  n->sym->name, name, >where);
> -   if (n->sym->attr.pointer
> -   || (n->sym->ts.type == BT_CLASS && CLASS_DATA (n->sym)
> -   && CLASS_DATA (n->sym)->attr.class_pointer))
> - gfc_error ("POINTER object %qs in %s clause at %L",
> -n->sym->name, name, >where);
> +   if (n->sym->attr.flavor == FL_VARIABLE
> +   && !n->sym->as && !n->sym->attr.pointer

Better put every && on a separate line if the whole if (...) doesn't fit
on a single line.

> +   && !n->sym->attr.cray_pointer
> +   && !n->sym->attr.cray_pointee)

This is too ugly.  I'd instead move the if after the cray pointer/pointee
tests, i.e.
if (n->sym->attr.cray_pointer)
  gfc_error (...);
else if (n->sym->attr.cray_pointee)
  gfc_error (...);
else if (n->sym->attr.flavor == FL_VARIABLE
 && !n->sym->as
 && !n->sym->attr.pointer)
  gfc_error (...);

> + gfc_error ("%s clause variable %qs at %L is neither "
> +"a pointer nor an array", name,
> +n->sym->name, >where);

Why pointer rather than POINTER ?

> +   if (n->sym->ts.type == BT_CLASS && CLASS_DATA (n->sym)
> +   && CLASS_DATA (n->sym)->attr.class_pointer)
> + gfc_error ("POINTER object %qs of polymorphic type in "
> +"%s clause at %L", n->sym->name, name,
> +>where);

And, doesn't this mean you emit 2 errors, the first one because it is not
a pointer nor array, and the second one because it is a class with
attr.class_pointer?  Also put && on the next line.

I think best would be to make it else if after the cray pointer/pointee
checks.

Jakub

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Bernd Edlinger]

On 07/21/16 09:09, Richard Biener wrote:
> On Wed, 20 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/20/16 20:08, Richard Biener wrote:
>>> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger 
>>>  wrote:

 But I think that alloca just should not be recognized by name any
 more.
>>>
>>> It was introduced to mark calls that should not be duplicated by inlining 
>>> or unrolling to avoid increasing stack usage too much.  Sth worthwhile to 
>>> keep even with -ffreestanding.
>>>
>>> Richard.
>>>
>>
>> On second thought I start to think that an external alloca function
>> might still work.  And returning ECF_MAY_BE_ALLOCA just based on the
>> name could be made safe by checking the malloc attribute at the right
>> places.
>>
>> With this new incremental patch the example
>>
>> extern "C"
>> void *alloca(unsigned long);
>> void bar(unsigned long n)
>> {
>> char *x = (char*) alloca(n);
>> if (x)
>>   *x = 0;
>> }
>>
>> might actually work when -ansi is used,
>> i.e. it does no longer assume that alloca cannot return null,
>> but still creates a frame pointer, which it would not have done
>> for allocb for instance.
>>
>> But the built-in alloca is still recognized because the builtin
>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
>>
>>
>> Is it OK for trunk after boot-strap and reg-testing?
>
> Hmm, but ECF_MALLOC doesn't guarantee non-NULL return.  I think the
> two calls you patched simply shouldn't use the predicates (which
> are misnamed as they check for _maybe_alloca_call_p).  Instead they
> have to check for the respective builtins (BUILT_IN_ALLOCA,
> BUILT_IN_ALLOCA_WITH_ALIGN).
>

Yes, I agree.  The name should really be gimple_maybe_alloca_call_p if
we are just guessing.

How about this updated patch?

Is it OK for trunk after boot-strap and reg-testing?


Thanks
Bernd.

> Richard.
>
>>
>> Thanks
>> Bernd.
>>
>
2016-07-21  Bernd Edlinger  

	PR middle-end/71876
	* calls.c (gimple_maybe_alloca_call_p): New function.  Return true
	if STMT may be an alloca call.
	(gimple_alloca_call_p, alloca_call_p): Return only true for the
	builtin alloca call.
	* calls.h (gimple_maybe_alloca_call_p): New function.
	* tree-inline.c (inline_forbidden_p_stmt): Use
	gimple_maybe_alloca_call_p here.

Index: gcc/calls.c
===
--- gcc/calls.c	(revision 238584)
+++ gcc/calls.c	(working copy)
@@ -617,10 +617,10 @@ setjmp_call_p (const_tree fndecl)
 }
 
 
-/* Return true if STMT is an alloca call.  */
+/* Return true if STMT may be an alloca call.  */
 
 bool
-gimple_alloca_call_p (const gimple *stmt)
+gimple_maybe_alloca_call_p (const gimple *stmt)
 {
   tree fndecl;
 
@@ -634,16 +634,44 @@ bool
   return false;
 }
 
-/* Return true when exp contains alloca call.  */
+/* Return true if STMT is a builtin alloca call.  */
 
 bool
+gimple_alloca_call_p (const gimple *stmt)
+{
+  tree fndecl;
+
+  if (!is_gimple_call (stmt))
+return false;
+
+  fndecl = gimple_call_fndecl (stmt);
+  if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;
+  }
+
+  return false;
+}
+
+/* Return true when exp contains a builtin alloca call.  */
+
+bool
 alloca_call_p (const_tree exp)
 {
   tree fndecl;
   if (TREE_CODE (exp) == CALL_EXPR
   && (fndecl = get_callee_fndecl (exp))
-  && (special_function_p (fndecl, 0) & ECF_MAY_BE_ALLOCA))
-return true;
+  && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (fndecl))
+  {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+return true;
+  }
+
   return false;
 }
 
Index: gcc/calls.h
===
--- gcc/calls.h	(revision 238584)
+++ gcc/calls.h	(working copy)
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 extern int flags_from_decl_or_type (const_tree);
 extern int call_expr_flags (const_tree);
 extern int setjmp_call_p (const_tree);
+extern bool gimple_maybe_alloca_call_p (const gimple *);
 extern bool gimple_alloca_call_p (const gimple *);
 extern bool alloca_call_p (const_tree);
 extern bool must_pass_in_stack_var_size (machine_mode, const_tree);
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c	(revision 238584)
+++ gcc/tree-inline.c	(working copy)
@@ -3577,7 +3577,7 @@ inline_forbidden_p_stmt (gimple_stmt_iterator *gsi
 	 RAM instead of 256MB.  Don't do so for alloca calls emitted for
 	 VLA objects as those can't cause unbounded growth (they're always
 	 wrapped inside stack_save/stack_restore regions.  */
-  if (gimple_alloca_call_p (stmt)
+  if (gimple_maybe_alloca_call_p (stmt)
 	  && !gimple_call_alloca_for_var_p (as_a  (stmt))
 	  && !lookup_attribute ("always_inline", 

Re: [PATCH, Fortran, OpenACC] Fix PR70598, Fortran host_data ICE (ping x4)

[Paul Richard Thomas]

Hi Chung-Lin,

I was ignoring your patch on the grounds that one of the omp gurus
should deal with it.  That says, it looks OK for trunk to me.

I presume that fortran/host_data-1.f90 should have the XFAIL removed?

Cheers

Paul

On 21 July 2016 at 11:28, Chung-Lin Tang  wrote:
> Ping x4
>
> On 2016/7/13 7:52 PM, Chung-Lin Tang wrote:
>> Ping x3
>>
>> On 06/21/2016 02:18 PM, Chung-Lin Tang wrote:
>>> Ping x2
>>>
>>> On 2016/6/7 08:03 PM, Chung-Lin Tang wrote:
 Ping.

 On 2016/5/11 02:57 AM, Bernhard Reutner-Fischer wrote:
> On May 9, 2016 4:26:50 PM GMT+02:00, Chung-Lin Tang 
>  wrote:
>> Hi, this patch resolves an ICE for Fortran when using the OpenACC
>> host_data directive.  Actually, rather than say resolve, it's more like
>> adjusting the front-end to same middle-end restrictions as C/C++,
>> namely that we only support pointers or arrays for host_data right now.
>>
>> This patch contains a little bit of adjustments in
>> fortran/openmp.c:resolve_omp_clauses(),
>> and some testcase adjustments. This has been tested without regressions
>> for Fortran.
>>
>> Is this okay for trunk?
>>
>> Thanks,
>> Chung-Lin
>>
>> 2015-05-09  Chung-Lin Tang  
>>
>> gcc/
>> * fortran/openmp.c (resolve_omp_clauses): Adjust use_device clause
>> handling to only allow pointers and arrays.
>
> Fortran has it's own ChangeLog. The patch itself looks somewhat plausible 
> to me, fwiw, but Jakub or a FE maintainer has the
> say.
>

>>>
>



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

Albert Einstein

[PATCH] Tree-level fix for PR 69526

[Robin Dapp]

As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526, we
currently fail to simplify cases like

(unsigned long)(a - 1) + 1

to

(unsigned long)a

when VRP knows that (a - 1) does not overflow.

This patch introduces a match.pd pattern as well as a helper function
that checks for overflow in a binary operation using VRP information and
simplifies when no overflow is present.

Some effort was put in to stay in the inner type in cases like this

(unsigned long)(a + CST1) - CST2
->
(unsigned long)(a + CST3) rather than
(unsigned long)a + CST3

where abs(CST3) = abs(CST1 - CST) <= abs(CST1). I wonder if this is
warranted, i.e. if it is always advantageous or if the evaluation should
rather involve a cost estimation - e.g. distinguish between costs for
operations in int vs. in long.

Absence of signed overflow is also exploited:

(long)(a + 2) - 1
->
(long)(a + 1)

Bootstrapped and regression tested on s390x and x86_64.

Regards
 Robin
diff --git a/gcc/match.pd b/gcc/match.pd
index b24bfb4..87925e0 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1119,6 +1119,124 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(minus @0 (minus @0 @1))
@1)
 
+  /* ((T)(A +- CST)) +- CST -> (T)(A +- CST)  */
+#if GIMPLE
+   (for outer_op (plus minus)
+ (for inner_op (plus minus)
+   (simplify
+	 (outer_op (convert (inner_op@3 @0 INTEGER_CST@1)) INTEGER_CST@2)
+	   (with
+	{
+	   /* If the inner operation is wrapped inside a conversion, we have to
+	  check it overflows/underflows and can only then perform the
+	  simplification, i.e. add the second constant to the first
+	  (wrapped) and convert afterwards.  This fixes
+	  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526 */
+
+	bool inner_ovf = false;
+	bool combined_ovf = false;
+	bool combined_ovf2 = false;
+	bool need_outer = false;
+	tree cst = NULL_TREE;
+	tree cst_inner = NULL_TREE;
+	bool combine_constants = false;
+
+	tree inner_type = TREE_TYPE (@3);
+	// check overflow in wrapped binop?
+	bool check_inner_ovf = !TYPE_OVERFLOW_UNDEFINED (inner_type);
+	// check overflow when combining constants
+	bool check_combine_ovf = TYPE_OVERFLOW_UNDEFINED (inner_type)
+|| TYPE_OVERFLOW_UNDEFINED (type);
+
+	if (check_inner_ovf)
+	  {
+	// check if the inner binop does not overflow i.e. we have VRP
+	// information and can prove prove it
+	inner_ovf = binop_overflow (inner_op, @0, @1, inner_type);
+	  }
+
+	// check for overflow in combined operation
+	wide_int combined_cst = wi::add (@1, @2,
+	 TYPE_SIGN (type),
+	 _ovf);
+	wide_int w1 = @2;
+	unsigned int prec = w1.get_precision();
+	unsigned HOST_WIDE_INT tm = 0;
+	if (tree_fits_uhwi_p (TYPE_MAX_VALUE (inner_type)))
+	  tree_to_uhwi (TYPE_MAX_VALUE (inner_type));
+	wide_int w2 = wi::uhwi (tm, prec);
+	if (wi::gtu_p (wi::abs (w1), w2))
+	  combined_ovf = true;
+
+	wide_int combined_cst_outer = wi::add (@2, @1,
+		   TYPE_SIGN (type),
+		   _ovf2);
+
+	// the combined constant is ok if its type does not have an
+	// undefined overflow or one of the combination options does not
+	// overflow
+	bool combined_cst_ok = !check_combine_ovf
+	  || !(combined_ovf && combined_ovf2);
+
+	if (check_inner_ovf ? !inner_ovf && combined_cst_ok :
+		combined_cst_ok)
+	  combine_constants = true;
+
+	if (combine_constants)
+	  {
+		cst_inner = wide_int_to_tree (inner_type, combined_cst);
+		cst = wide_int_to_tree (type, combined_cst_outer);
+
+		int s1 = tree_int_cst_sgn (@1);
+		int s2 = tree_int_cst_sgn (cst_inner);
+
+		bool not_larger_abs = wi::leu_p (wi::abs (cst_inner),
+		 wi::abs (@1));
+
+		// check for an inner overflow with the combined constant
+		bool inner_ovf2 = binop_overflow (inner_op, @0, cst_inner,
+		  inner_type);
+
+		if (check_inner_ovf ? !inner_ovf2 : not_larger_abs &&
+		!combined_ovf)
+		  {
+		cst = cst_inner;
+		  }
+		else
+		  {
+		// we need the outer type if the signs
+		// differ i.e. if we had an (a - 2) before and have an
+		// (a + 1) afterwards since the proved non-overflow
+		// would not necessarily hold
+		need_outer = true;
+
+		// if we overflow in the inner type (with non-undefined
+		// type) we need to zero-extend the overflowed result
+		// in the outer type
+		if (check_inner_ovf && combined_ovf
+			&& tree_fits_uhwi_p (cst_inner))
+		  {
+			HOST_WIDE_INT hw = tree_to_uhwi (cst_inner);
+			wide_int ww = wi::uhwi (hw, TYPE_PRECISION (type));
+			cst = wide_int_to_tree (type, ww);
+		  }
+
+		// if we need the outer type but the operation overflows
+		// we cannot do anything
+		if (combined_ovf2)
+		  combine_constants = false;
+		  }
+	 }
+	  }
+	(if (combine_constants && cst && @0)
+	  (switch
+	   (if (!need_outer)
+	(convert (outer_op { @0; } { cst; })))
+	   (if (need_outer)
+	   

Re: [patch,avr] More insns to handle (inverted) bit-bit moves

[Denis Chertykov]

2016-07-20 15:59 GMT+03:00 Georg-Johann Lay :
> This adds some insns that set a destination bit expressed as zero_extract to
> a source bit expressed as extract, right shift, and simple combinations
> thereof.
>
> Purpose is smaller code and to avoid costly extracts or shifts.  This
> applies mostly to bitfields; for open-coded bit insertions the patterns that
> I'm seeing are sometimes too complicated, i.e. IOR of AND and SHIFTRT and
> XOR and SUBREGs and all sorts of arithmetic that are not canonicalized in
> any way by the middle end (insn combiner, if conversion, ...)
>
> Ok for trunk?
>

Ok.
Please commit.

> Johann
>
> * config/avr/avr.md (any_extract, any_shiftrt): New code iterators.
> (*insv.extract, *insv.shiftrt, *insv.not-bit.0, *insv.not-bit.7)
> (*insv.xor-extract, *insv.xor1-bit.0): New insns.
> (adjust_len) [insv_notbit, insv_notbit_0, insv_notbit_7]: New
> values for insn attribute.
> * config/avr/avr.c (avr_out_insert_notbit): New function.
> (avr_adjust_insn_length): Handle ADJUST_LEN_INSV_NOTBIT,
> ADJUST_LEN_INSV_NOTBIT_0/_7.
> * config/avr/avr-protos.h (avr_out_insert_notbit): New proto.
>

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

[Richard Earnshaw (lists)]

On 20/07/16 16:02, Jiong Wang wrote:
> On 20/07/16 15:18, Richard Earnshaw (lists) wrote:
>> On 20/07/16 14:03, Jiong Wang wrote:
>>> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
>>> are doing exactly what's aarch64_add_constant offered, except they also
>>> need to be aware of dwarf generation.
>>>
>>> This patch teach existed aarch64_add_constant about dwarf generation and
>>> currently SP register is supported.  Whenever SP is updated, there
>>> should be CFA update, we then mark these instructions as frame related,
>>> and if the update is too complex for gcc to guess the adjustment, we
>>> attach explicit annotation.
>>>
>>> Both dwarf frame info size and pro/epilogue scheduling are improved
>>> after
>>> this patch as aarch64_add_constant has better utilization of scratch
>>> register.
>>>
>>> OK for trunk?
>>>
>>> gcc/
>>> 2016-07-20  Jiong Wang  
>>>
>>>  * config/aarch64/aarch64.c (aarch64_add_constant): Mark
>>>  instruction as frame related when it is.  Generate CFA
>>>  annotation when it's necessary.
>>>  (aarch64_expand_prologue): Use aarch64_add_constant.
>>>  (aarch64_expand_epilogue): Likewise.
>>>
>> Are you sure using aarch64_add_constant is unconditionally safe?  Stack
>> adjustments need to be done very carefully to ensure that we never
>> transiently deallocate part of the stack.
> 
> Richard,
> 
>   Thanks for the review, yes, I believe using aarch64_add_constant is
> unconditionally
> safe here.  Because we have generated a stack tie to clobber the whole
> memory thus
> prevent any instruction which access stack be scheduled after that.
> 
>   The access to deallocated stack issue was there and fixed by
> 
>   https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02292.html.
> 
>  aarch64_add_constant itself is generating the same instruction
> sequences as the
> original code, except for a few cases, it will prefer
> 
>   move scratch_reg, #imm
>   add sp, sp, scratch_reg
> 
> than:
>   add sp, sp, #imm_part1
>   add sp, sp, #imm_part2
> 
> 
> 
> 

OK, I've had another look at this and I'm happy that we don't
(currently) run into the problem I'm concerned about.

However, this new usage does impose a constraint on aarch64_add_constant
that will need to be respected in future, so please can you add the
following to the comment that precedes that function:

/* ...

   This function is sometimes used to adjust the stack pointer, so we
   must ensure that it can never cause transient stack deallocation
   by writing an invalid value into REGNUM.  */


> +  bool frame_related_p = (regnum == SP_REGNUM);

I think it would be better to make the frame-related decision be an
explicit parameter passed to the routine (don't forget SP is not always
the frame pointer).  Then the new uses would pass 'true' and the
existing uses 'false'.

R.

Re: [PATCH GCC]Cleanup lt_to_ne handling in niter analyzer

[Richard Biener]

On Wed, Jul 20, 2016 at 6:40 PM, Bin Cheng  wrote:
> Hi,
> This patch cleans up function number_of_iterations_lt_to_ne mainly by 
> removing computation of may_be_zero.  The computation is unnecessary and 
> may_be_zero in this case must be true.  Specifically, DELTA is integer 
> constant and iv0.base < iv1.base bounds to be true because the false case is 
> handled in function number_of_iterations_cond before.  This patch also 
> refines comment a little.
>
> Bootstrap and test on x86_64, is it OK?

Ok.

Richard.

> Thanks,
> bin
>
> 2016-07-19  Bin Cheng  
>
> * tree-ssa-loop-niter.c (number_of_iterations_lt_to_ne): Clean up
> by removing computation of may_be_zero.

Re: [PATCH GCC]Improve no-overflow check in SCEV using value range info.

[Richard Biener]

On Wed, Jul 20, 2016 at 6:23 PM, Bin.Cheng  wrote:
> On Wed, Jul 20, 2016 at 11:01 AM, Richard Biener
>  wrote:
>> On Tue, Jul 19, 2016 at 6:15 PM, Bin.Cheng  wrote:
>>> On Tue, Jul 19, 2016 at 1:10 PM, Richard Biener
>>>  wrote:
 On Mon, Jul 18, 2016 at 6:27 PM, Bin Cheng  wrote:
> Hi,
> Scalar evolution needs to prove no-overflow for source variable when 
> handling type conversion.  This is important because otherwise we would 
> fail to recognize result of the conversion as SCEV, resulting in missing 
> loop optimizations.  Take case added by this patch as an example, the 
> loop can't be distributed as memset call because address of memory 
> reference is not recognized.  At the moment, we rely on type overflow 
> semantics and loop niter info for no-overflow checking, unfortunately 
> that's not enough.  This patch introduces new method checking no-overflow 
> using value range information.  As commented in the patch, value range 
> can only be used when source operand variable evaluates on every loop 
> iteration, rather than guarded by some conditions.
>
> This together with patch improving loop niter analysis 
> (https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00736.html) can help 
> various loop passes like vectorization.
> Bootstrap and test on x86_64 and AArch64.  Is it OK?

 @@ -3187,7 +3187,8 @@ idx_infer_loop_bounds (tree base, tree *idx, void 
 *dta)
/* If access is not executed on every iteration, we must ensure that 
 overlow
   may not make the access valid later.  */
if (!dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb 
 (data->stmt))
 -  && scev_probably_wraps_p (initial_condition_in_loop_num (ev, 
 loop->num),
 +  && scev_probably_wraps_p (NULL,

 use NULL_TREE for the null pointer constant of tree.

 +  /* Check if VAR evaluates in every loop iteration.  */
 +  gimple *def;
 +  if ((def = SSA_NAME_DEF_STMT (var)) != NULL

 def is never NULL but it might be a GIMPLE_NOP which has a NULL gimple_bb.
 Better check for ! SSA_DEFAULT_DEF_P (var)

 +  if (TREE_CODE (step) != INTEGER_CST || !INTEGRAL_TYPE_P (TREE_TYPE 
 (var)))
 +return false;

 this looks like a cheaper test so please do that first.

 +  step_wi = step;
 +  type = TREE_TYPE (var);
 +  if (tree_int_cst_sign_bit (step))
 +{
 +  diff = lower_bound_in_type (type, type);
 +  diff = minv - diff;
 +  step_wi = - step_wi;
 +}
 +  else
 +{
 +  diff = upper_bound_in_type (type, type);
 +  diff = diff - maxv;
 +}

 this lacks a comment - it's not obvious to me what the gymnastics
 with lower/upper_bound_in_type are supposed to achieve.
>>>
>>> Thanks for reviewing, I will prepare another version of patch.

 As VRP uses niter analysis itself I wonder how this fires back-to-back 
 between
>>> I am not sure if I mis-understood the question.  If the VRP
>>> information comes from loop niter, I think it will not change loop
>>> niter or VRP2 in back because that's the best information we got in
>>> the first place in niter.  If the VRP information comes from other
>>> places (guard conditions?)  SCEV and loop niter after vrp1 might be
>>> improved and thus VRP2.  There should be no problems in either case,
>>> as long as GCC breaks the recursive chain among niter/scev/vrp
>>> correctly.
>>
>> Ok.
>>
 VRP1 and VRP2?  If the def of var dominates the latch isn't it enough to do
 a + 1 to check whether VRP bumped the range up to INT_MAX/MIN?  That is,
 why do we need to add step if not for the TYPE_OVERFLOW_UNDEFINED case
 of VRP handling the ranges optimistically?
>>> Again, please correct me if I mis-understood.  Considering a variable
>>> whose type is unsigned int and scev is {0, 4}_loop, the value range
>>> could be computed as [0, 0xfffc], thus MAX + 1 is smaller than
>>> type_MAX, but the scev could be overflow.
>>
>> Yes.  I was wondering about the case where VRP bumps the range to +INF
>> because it gave up during iteration or because overflow behavior is 
>> undefined.
>> Do I understand correctly that the code is mostly to improve the not
>> undefined-overflow case?
> Hi Richard,
>
> I think we resolved these on IRC, here are words for the record.
> The motivation case is for unsigned type loop counter, while the patch
> should work for signed type in theory.  Considering a loop has signed
> char counter i and it's used in array_ref[i + 10], since front-end
> converts signed char addition into unsigned operation, we may need the
> range information to prove (unsigned char)i + 10 doesn't overflow,
> thus address of array reference is a scev.  I am not sure if the
> signed case 

Re: [PATCH, Fortran, OpenACC] Fix PR70598, Fortran host_data ICE (ping x4)

[Chung-Lin Tang]

Ping x4

On 2016/7/13 7:52 PM, Chung-Lin Tang wrote:
> Ping x3
> 
> On 06/21/2016 02:18 PM, Chung-Lin Tang wrote:
>> Ping x2
>>
>> On 2016/6/7 08:03 PM, Chung-Lin Tang wrote:
>>> Ping.
>>>
>>> On 2016/5/11 02:57 AM, Bernhard Reutner-Fischer wrote:
 On May 9, 2016 4:26:50 PM GMT+02:00, Chung-Lin Tang 
  wrote:
> Hi, this patch resolves an ICE for Fortran when using the OpenACC
> host_data directive.  Actually, rather than say resolve, it's more like
> adjusting the front-end to same middle-end restrictions as C/C++,
> namely that we only support pointers or arrays for host_data right now.
>
> This patch contains a little bit of adjustments in
> fortran/openmp.c:resolve_omp_clauses(),
> and some testcase adjustments. This has been tested without regressions
> for Fortran.
>
> Is this okay for trunk?
>
> Thanks,
> Chung-Lin
>
> 2015-05-09  Chung-Lin Tang  
>
> gcc/
> * fortran/openmp.c (resolve_omp_clauses): Adjust use_device clause
> handling to only allow pointers and arrays.

 Fortran has it's own ChangeLog. The patch itself looks somewhat plausible 
 to me, fwiw, but Jakub or a FE maintainer has the
 say.

>>>
>>

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

[Ilya Enkovich]

In my list I see #1, #4, and #5 are not approved.

Thanks,
Ilya

2016-07-20 19:24 GMT+03:00 Jeff Law :
> On 07/20/2016 08:37 AM, Ilya Enkovich wrote:
>
>> Here is an updated version.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2016-07-20  Ilya Enkovich  
>>
>> * dbgcnt.def (vect_tail_combine): New.
>> * params.def (PARAM_VECT_COST_INCREASE_COMBINE_THRESHOLD): New.
>> * tree-vect-data-refs.c (vect_get_new_ssa_name): Support
>> vect_mask_var.
>> * tree-vect-loop-manip.c (slpeel_tree_peel_loop_to_edge): Support
>> epilogue combined with loop body.
>> (vect_do_peeling_for_loop_bound): LIkewise.
>> (vect_do_peeling_for_alignment): ???
>> * tree-vect-loop.c Include alias.h and dbgcnt.h.
>> (vect_estimate_min_profitable_iters): Add
>> ret_min_profitable_combine_niters
>> arg, compute number of iterations for which loop epilogue
>> combining is
>> profitable.
>> (vect_generate_tmps_on_preheader): Support combined apilogue.
>> (vect_gen_ivs_for_masking): New.
>> (vect_get_mask_index_for_elems): New.
>> (vect_get_mask_index_for_type): New.
>> (vect_create_narrowed_masks): New.
>> (vect_create_widened_masks): New.
>> (vect_gen_loop_masks): New.
>> (vect_mask_reduction_stmt): New.
>> (vect_mask_mask_load_store_stmt): New.
>> (vect_mask_load_store_stmt): New.
>> (vect_combine_loop_epilogue): New.
>> (vect_transform_loop): Support combined apilogue.
>
> I think this is OK.  We've just got patch #5 to work through now, correct?
>
> Jeff
>

Re: [PATCH] Consider functions with xloc.file == NULL (PR, gcov-profile/69028)

[Richard Biener]

On Wed, Jul 20, 2016 at 3:34 PM, Martin Liška  wrote:
> Hi.
>
> Following patch addresses ICE which happens when coverage.c computes checksum
> of a function w/o xloc.file. My patch assumes it's a valid state having a 
> function
> w/o xloc.file, which is situation exposed by cilkplus functions.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

Yes.

I think we should try to do better when assigning a location to new
function decls,
that is, avoid UNKNOWN_LOCATION and at least have some file information.
For cilk-plus functions using the decl location of the original
function might work.

That said, a safe-guard against this case is ok, thus the patch is as well.

Richard.

> Martin

Re: [PATCH GCC]Vectorize possible infinite loops by versioning

[Bin.Cheng]

On Wed, Jul 20, 2016 at 10:27 PM, Jeff Law  wrote:
> On 06/28/2016 12:18 AM, Bin Cheng wrote:
>>
>> Hi,
>> This patch improves vectorizer in order to handle possible infinite loops
>> by versioning.  Its changes fall in three categories.
>> A) Changes in vect_get_loop_niters.  AT the moment, it computes niter
>> using number_of_executions_latch, in this way the assumption is discarded
>> and loop not vectorized.  To fix the issue, we need assumption information
>> from niter analyzer and use that as a break condition to version the loop.
>> This patch uses newly introduced interface
>> number_of_iterations_exit_assumptions and passes assumptions all the way to
>> vect_analyze_loop_form.  The assumptions will be finally recorded in
>> LOOP_VINFO_NITERS_ASSUMPTIONS.
>> B) It sets and clears flag LOOP_F_ASSUMPTIONS for loop.  The flag is
>> important because during checking if a loop can be vectorized (with
>> versioning), all data references need to be analyzed by assuming
>> LOOP_VINFO_NITERS_ASSUMPTIONS is TRUE.  Otherwise it's very likely address
>> expression of data reference won't be identified as SCEV and vectorization
>> would fail.  With this flag set to TRUE, niter analyzer will bypass
>> assumptions recorded LOOP_VINFO_NITERS_ASSUMPTIONS.  I also keep this flag
>> for versioned loop because the assumption is guaranteed to be TRUE after
>> versioning.  For now, I didn't copy these flags in copy_loop_info, but I
>> think this can be done so that the flags can be inherited by peeled pre/post
>> loop.  Maybe in follow up patches.  Also it's possible to turn other bool
>> fields into flags in the future?
>> C) This patch uses existing infrastructure to version a loop against
>> LOOP_VINFO_NITERS_ASSUMPTIONS, just like for alignment or alias check.  The
>> change is straightforward, however, I did refactoring to versioning related
>> macros hoping the code would be cleaner.
>>
>> Bootstrap and test along with previous niter patches on x86_64 and
>> AArch64.  Is it OK?
>
Hi Jeff,
Thanks for looking at this.

> So I have one high level concern -- how (if at all) does this interact with
> Ilya's changes to vectorize loop tails that are just about through the
> review process?
Though I haven't look into details of tail-vect patch set, I would not
expect interference between them.  Versioning in this patch is before
tail-vect exactly like existing versioning for alias/alignment.
>
> Related -- I see that you throw away the SCEV/iteration knowledge then
> analyze the loop using the given assumptions, then eventually throw that
> information away.  Which sounds generally reasonable -- except for one
> potential issue -- does anything still want to look at the original
> SCEV/iteration information (that we've lost)?  I'm assuming no since you
> didn't try to restore it and we pass the testsuite with your change.
The niter/scev information discarded are buffered data.  The only
impact is on compile time, that is, scev/niter information will be
computed from scratch rather than queried from buffered (hash)
data-structure, if following customer need these information.  For
successful versioning, I think this is kind of inevitable because
scev/niter information of versioned loop IS different to the original
loop.

>
>
>>
>> Thanks,
>> bin
>>
>> 2016-06-27  Bin Cheng  
>>
>> PR tree-optimization/57558
>> * tree-vect-loop-manip.c (vect_create_cond_for_niters_checks): New
>> function.
>> (vect_loop_versioning): Support versioning with niter assumptions.
>> * tree-vect-loop.c (tree-ssa-loop.h): Include new header file.
>> (vect_get_loop_niters): New parameter.  Reimplement to support
>> assumptions in loop niter info.
>> (vect_analyze_loop_form_1, vect_analyze_loop_form): Ditto.
>> (new_loop_vec_info): Init LOOP_VINFO_NITERS_ASSUMPTIONS.
>> (vect_estimate_min_profitable_iters): Use
>> LOOP_REQUIRES_VERSIONING.
>> * tree-vectorizer.c (vect_free_loop_info_assumptions): New
>> function.
>> (vectorize_loops): Free loop niter info for loops with flag
>> LOOP_F_ASSUMPTIONS set.
>> * tree-vectorizer.h (struct _loorefactoredp_vec_info): New field
>
> Typo in the ChangeLog entry.
At this moment, prerequisite patch set for this one is ongoing
review/rework, I will update this patch after finishing prerequisites.

>
>> num_iters_assumptions.
>> (LOOP_VINFO_NITERS_ASSUMPTIONS): New macro.
>> (LOOP_REQUIRES_VERSIONING_FOR_NITERS): New macro.
>> (LOOP_REQUIRES_VERSIONING): New macro.
>> (vect_free_loop_info_assumptions): New decl.
>>
>> gcc/testsuite/ChangeLog
>> 2016-06-27  Bin Cheng  
>>
>> * gcc.dg/vect/pr57558-1.c: New test.
>> * gcc.dg/vect/pr57558-2.c: New test.
>
> I was rather surprised at how simple supporting this case was.  THe two high
> level questions above are the only things I'm worried about.  

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

[Richard Biener]

On Thu, Jul 21, 2016 at 10:37 AM, Richard Biener
 wrote:
> On Thu, Jul 21, 2016 at 9:00 AM, Uros Bizjak  wrote:
>> Hello!
>>
>>> > gcc/ChangeLog:
>>> > PR c/70339
>>> > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
>>> > the
>>> > same location as last time, don't skip if we have fix-it hints.
>>> > Clarify the skipping logic by converting it from one "if"
>>> > clause
>>> > to repeated "if" clauses.
>>> > * spellcheck-tree.c: Include "cpplib.h".
>>> > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
>>> > (best_macro_match::best_macro_match): New constructor.
>>> > * spellcheck-tree.h (struct edit_distance_traits>> > *>):
>>> > Move here from c/c-decl.c.
>>> > (class best_macro_match): Move here from c/c-decl.c, converting
>>> > from a typedef to a subclass, gaining a ctor.
>>
>> This part introduced bootstrap failure on CentOS 5.11:
>>
>> g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict-aliasing
>> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
>> -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
>> -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
>> -I../../git/gcc/gcc -I../../git/gcc/gcc/.
>> -I../../git/gcc/gcc/../include -I../../git/gcc/gcc/../libcpp/include
>> -I/usr/local/include -I/usr/local/include -I/usr/local/include
>> -I../../git/gcc/gcc/../libdecnumber
>> -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
>> -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
>> spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
>> ../../git/gcc/gcc/spellcheck-tree.c
>> ../../git/gcc/gcc/spellcheck-tree.c: In constructor
>> ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
>> cpp_reader*)’:
>> ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
>> ‘best_macro_match’ does not have any field named ‘best_match’
>> ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching function
>> for call to ‘best_match::best_match()’
>> ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
>> best_match::best_match(GOAL_TYPE,
>> edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
>> cpp_hashnode*]
>> ../../git/gcc/gcc/spellcheck.h:81: note:
>> best_match::best_match(const
>> best_match&)
>> gmake: *** [spellcheck-tree.o] Error 1
>>
>> CentOS 5 has pretty old system compiler [gcc version 4.1.2 20080704
>> (Red Hat 4.1.2-55)], but the build worked until the above patch was
>> committed. Is it possible to work around this failure somehow?
>
> Similar failure with SLE11 host compiler (gcc 4.3.4):
>
> g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I/space/rguenther/src/svn/trunk/gcc
> -I/space/rguenther/src/svn/trunk/gcc/.
> -I/space/rguenther/src/svn/trunk/gcc/../include
> -I/space/rguenther/src/svn/trunk/gcc/../libcpp/include
> -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber
> -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid
> -I../libdecnumber -I/space/rguenther/src/svn/trunk/gcc/../libbacktrace
>   -o spellcheck-tree.o -MT spellcheck-tree.o -MMD -MP -MF
> ./.deps/spellcheck-tree.TPo
> /space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c
> /space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c: In constructor
> ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
> cpp_reader*)’:
> /space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c:94: error: class
> ‘best_macro_match’ does not have any field named ‘best_match’
> /space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c:94: error: no
> matching function for call to ‘best_match cpp_hashnode*>::best_match()’
> /space/rguenther/src/svn/trunk/gcc/spellcheck.h:91: note: candidates
> are: best_match::best_match(GOAL_TYPE,
> edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
> cpp_hashnode*]
> /space/rguenther/src/svn/trunk/gcc/spellcheck.h:81: note:
>best_match::best_match(const
> best_match&)
> make[3]: *** [spellcheck-tree.o] Error 1
>
> works with GCC 4.5 (didn't check 4.4 yet).

Not sure where it should pick up best_macro_match : best_match ,
the only best_macro_match I find is

class best_macro_match : public best_match

shouldn't

best_macro_match::best_macro_match (tree goal,
edit_distance_t best_distance_so_far,
cpp_reader *reader)
  : best_match (goal, best_distance_so_far)
{
  cpp_forall_identifiers (reader, find_closest_macro_cpp_cb, this);
}

be using best_match (goal, reader) 

Re: [PATCH, PR59833]: Fix sNaN handling in ARM float to double conversion

[Ramana Radhakrishnan]

On Wed, Jul 20, 2016 at 1:40 PM, Aurelien Jarno  wrote:
> On 2016-07-20 11:22, Ramana Radhakrishnan wrote:
>> On Wed, Jul 20, 2016 at 11:14 AM, Aurelien Jarno  
>> wrote:
>> > On 2016-07-20 11:04, Ramana Radhakrishnan wrote:
>> >> On Wed, Jul 20, 2016 at 10:56 AM, Aurelien Jarno  
>> >> wrote:
>> >> > On 2016-07-20 10:10, Ramana Radhakrishnan wrote:
>> >> >> On Wed, Jul 20, 2016 at 8:48 AM, Aurelien Jarno  
>> >> >> wrote:
>> >> >> > On ARM soft-float, the float to double conversion doesn't convert a 
>> >> >> > sNaN
>> >> >> > to qNaN as the IEEE Std 754 standard mandates:
>> >> >> >
>> >> >> > "Under default exception handling, any operation signaling an invalid
>> >> >> > operation exception and for which a floating-point result is to be
>> >> >> > delivered shall deliver a quiet NaN."
>> >> >> >
>> >> >> > Given the soft float ARM code ignores exceptions and always provides 
>> >> >> > a
>> >> >> > result, a float to double conversion of a signaling NaN should 
>> >> >> > return a
>> >> >> > quiet NaN. Fix this in extendsfdf2.
>> >> >> >
>> >> >> > gcc/ChangeLog:
>> >> >> >
>> >> >> > PR target/59833
>> >> >> > * config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to 
>> >> >> > qNaN.
>> >> >> >
>> >> >> > gcc/testsuite/ChangeLog:
>> >> >> >
>> >> >> > * gcc.dg/pr59833.c: New testcase.
>> >> >>
>> >> >>
>> >> >> Ok - assuming this was tested appropriately with no regressions.
>> >> >
>> >> > Given it only touches arm code, I only tested it on arm and I have seen
>> >> > no regression. That said I wouldn't be surprised if the new testcase
>> >> > fails on some other architectures.
>> >>
>> >> I was assuming you tested it on ARM :)  In this case given the change
>> >> is only in the backend I would have expected this patch to have been
>> >> tested for soft-float ARM or an appropriate multilib. Saying what
>> >> configuration the patch was tested on is useful for the audit trail.
>> >> For e.g. it's no use testing this patch on armhf ( i.e.
>> >> --with-float=hard --with-fpu=vfpv3/neon --with-arch=armv7-a) as by
>> >> default the test would never generate the call to the library function
>> >> but I'm sure you know all that anyway.
>> >
>> > Indeed I should have given more details. I tested it on a Debian armel
>> > machine, and I configured GCC the same way as the Debian package, that
>> > is using --with-arch=armv4t --with-float=soft.
>> >
>> > I built it once with the new test but without the fix and a second time
>> > with both the test and the fix. I have verified that the test fails in
>> > the first case and pass in the second case.
>>
>> Thanks for the info - what about all the other regression tests ? Did
>> you do a full make check and ensure that no other tests regressed in
>> comparison ?  Patches need to be tested against the entire regression
>> testsuite and not just what was added.
>
> Yes, I compared the testsuite result between the two runs, and there are
> identical beside this new test (hence my "I have seen no regression" in
> my first answer).
>
Thanks now fixed on trunk.

Ramana

> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

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

[Richard Biener]

On Thu, Jul 21, 2016 at 9:00 AM, Uros Bizjak  wrote:
> Hello!
>
>> > gcc/ChangeLog:
>> > PR c/70339
>> > * diagnostic-show-locus.c (diagnostic_show_locus): If this is
>> > the
>> > same location as last time, don't skip if we have fix-it hints.
>> > Clarify the skipping logic by converting it from one "if"
>> > clause
>> > to repeated "if" clauses.
>> > * spellcheck-tree.c: Include "cpplib.h".
>> > (find_closest_macro_cpp_cb): Move here from c/c-decl.c.
>> > (best_macro_match::best_macro_match): New constructor.
>> > * spellcheck-tree.h (struct edit_distance_traits> > *>):
>> > Move here from c/c-decl.c.
>> > (class best_macro_match): Move here from c/c-decl.c, converting
>> > from a typedef to a subclass, gaining a ctor.
>
> This part introduced bootstrap failure on CentOS 5.11:
>
> g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict-aliasing
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../../git/gcc/gcc -I../../git/gcc/gcc/.
> -I../../git/gcc/gcc/../include -I../../git/gcc/gcc/../libcpp/include
> -I/usr/local/include -I/usr/local/include -I/usr/local/include
> -I../../git/gcc/gcc/../libdecnumber
> -I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
> -I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
> spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
> ../../git/gcc/gcc/spellcheck-tree.c
> ../../git/gcc/gcc/spellcheck-tree.c: In constructor
> ‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
> cpp_reader*)’:
> ../../git/gcc/gcc/spellcheck-tree.c:94: error: class
> ‘best_macro_match’ does not have any field named ‘best_match’
> ../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching function
> for call to ‘best_match::best_match()’
> ../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
> best_match::best_match(GOAL_TYPE,
> edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
> cpp_hashnode*]
> ../../git/gcc/gcc/spellcheck.h:81: note:
> best_match::best_match(const
> best_match&)
> gmake: *** [spellcheck-tree.o] Error 1
>
> CentOS 5 has pretty old system compiler [gcc version 4.1.2 20080704
> (Red Hat 4.1.2-55)], but the build worked until the above patch was
> committed. Is it possible to work around this failure somehow?

Similar failure with SLE11 host compiler (gcc 4.3.4):

g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/space/rguenther/src/svn/trunk/gcc
-I/space/rguenther/src/svn/trunk/gcc/.
-I/space/rguenther/src/svn/trunk/gcc/../include
-I/space/rguenther/src/svn/trunk/gcc/../libcpp/include
-I/space/rguenther/src/svn/trunk/gcc/../libdecnumber
-I/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I/space/rguenther/src/svn/trunk/gcc/../libbacktrace
  -o spellcheck-tree.o -MT spellcheck-tree.o -MMD -MP -MF
./.deps/spellcheck-tree.TPo
/space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c
/space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c: In constructor
‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
cpp_reader*)’:
/space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c:94: error: class
‘best_macro_match’ does not have any field named ‘best_match’
/space/rguenther/src/svn/trunk/gcc/spellcheck-tree.c:94: error: no
matching function for call to ‘best_match::best_match()’
/space/rguenther/src/svn/trunk/gcc/spellcheck.h:91: note: candidates
are: best_match::best_match(GOAL_TYPE,
edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
cpp_hashnode*]
/space/rguenther/src/svn/trunk/gcc/spellcheck.h:81: note:
   best_match::best_match(const
best_match&)
make[3]: *** [spellcheck-tree.o] Error 1

works with GCC 4.5 (didn't check 4.4 yet).

Richard.

> Uros.

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

[Alan Modra]

On Wed, Jul 20, 2016 at 08:51:21PM -0500, Peter Bergner wrote:
> This still doesn't answer David's question about what will happen if
> we generate this pattern (or one of the older VSX reg+reg patterns)
> when we are NOT using -mno-vsx.  In those cases, quad_address_p and
> mode_supports_vsx_dform_quad will return true and it seems like
> we'll go ahead and generate these reg+offset addresses when they're
> not legal for these patterns.

The question doesn't make a great deal of sense.  altivec_mov* and
vsx_mov* have mutually exclusive insn predicates, and at the RTL level
they all look the same.  So even if you did generate the "wrong"
insn RTL, the right one would match.  For example, if you generated
RTL using altivec_mov with -mvsx, vsx_mov would match it, *not*
altivec_mov.

-- 
Alan Modra
Australia Development Lab, IBM

[committed] Fix up narrowing conversion in tree-object-size.c

[Jakub Jelinek]

Hi!

The reporter mentioned in PR71941 a narrowing conversion in
tree-object-size.c.  Normally we build with -std=gnu++98 at least during
bootstrap, so this doesn't show up, but I've committed following as obvious
anyway:

2016-07-21  Jakub Jelinek  

* tree-object-size.c (unknown): Use HOST_WIDE_INT_M1U instead of -1.

--- gcc/tree-object-size.c.jj   2016-07-21 08:59:55.0 +0200
+++ gcc/tree-object-size.c  2016-07-21 09:43:29.288555197 +0200
@@ -43,7 +43,12 @@ struct object_size_info
   unsigned int *stack, *tos;
 };
 
-static const unsigned HOST_WIDE_INT unknown[4] = { -1, -1, 0, 0 };
+static const unsigned HOST_WIDE_INT unknown[4] = {
+  HOST_WIDE_INT_M1U,
+  HOST_WIDE_INT_M1U,
+  0,
+  0
+};
 
 static tree compute_object_offset (const_tree, const_tree);
 static unsigned HOST_WIDE_INT addr_object_size (struct object_size_info *,

Jakub

Re: fold x ^ y to 0 if x == y

[Richard Biener]

On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:

> On 20 July 2016 at 16:35, Richard Biener  wrote:
> > On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:
> >
> >> On 8 July 2016 at 12:29, Richard Biener  wrote:
> >> > On Fri, 8 Jul 2016, Richard Biener wrote:
> >> >
> >> >> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
> >> >>
> >> >> > Hi Richard,
> >> >> > For the following test-case:
> >> >> >
> >> >> > int f(int x, int y)
> >> >> > {
> >> >> >int ret;
> >> >> >
> >> >> >if (x == y)
> >> >> >  ret = x ^ y;
> >> >> >else
> >> >> >  ret = 1;
> >> >> >
> >> >> >return ret;
> >> >> > }
> >> >> >
> >> >> > I was wondering if x ^ y should be folded to 0 since
> >> >> > it's guarded by condition x == y ?
> >> >> >
> >> >> > optimized dump shows:
> >> >> > f (int x, int y)
> >> >> > {
> >> >> >   int iftmp.0_1;
> >> >> >   int iftmp.0_4;
> >> >> >
> >> >> >   :
> >> >> >   if (x_2(D) == y_3(D))
> >> >> > goto ;
> >> >> >   else
> >> >> > goto ;
> >> >> >
> >> >> >   :
> >> >> >   iftmp.0_4 = x_2(D) ^ y_3(D);
> >> >> >
> >> >> >   :
> >> >> >   # iftmp.0_1 = PHI 
> >> >> >   return iftmp.0_1;
> >> >> >
> >> >> > }
> >> >> >
> >> >> > The attached patch tries to fold for above case.
> >> >> > I am checking if op0 and op1 are equal using:
> >> >> > if (bitmap_intersect_p (vr1->equiv, vr2->equiv)
> >> >> >&& operand_equal_p (vr1->min, vr1->max)
> >> >> >&& operand_equal_p (vr2->min, vr2->max))
> >> >> >   { /* equal /* }
> >> >> >
> >> >> > I suppose intersection would check if op0 and op1 have equivalent 
> >> >> > ranges,
> >> >> > and added operand_equal_p check to ensure that there is only one
> >> >> > element within the range. Does that look correct ?
> >> >> > Bootstrap+test in progress on x86_64-unknown-linux-gnu.
> >> >>
> >> >> I think VRP is the wrong place to catch this and DOM should have but it
> >> >> does
> >> >>
> >> >> Optimizing block #3
> >> >>
> >> >> 1>>> STMT 1 = x_2(D) le_expr y_3(D)
> >> >> 1>>> STMT 1 = x_2(D) ge_expr y_3(D)
> >> >> 1>>> STMT 1 = x_2(D) eq_expr y_3(D)
> >> >> 1>>> STMT 0 = x_2(D) ne_expr y_3(D)
> >> >> 0>>> COPY x_2(D) = y_3(D)
> >> >> 0>>> COPY y_3(D) = x_2(D)
> >> >> Optimizing statement ret_4 = x_2(D) ^ y_3(D);
> >> >>   Replaced 'x_2(D)' with variable 'y_3(D)'
> >> >>   Replaced 'y_3(D)' with variable 'x_2(D)'
> >> >>   Folded to: ret_4 = x_2(D) ^ y_3(D);
> >> >> LKUP STMT ret_4 = x_2(D) bit_xor_expr y_3(D)
> >> >>
> >> >> heh, registering both reqivalencies is obviously not going to help...
> >> >>
> >> >> The 2nd equivalence is from doing
> >> >>
> >> >>   /* We already recorded that LHS = RHS, with canonicalization,
> >> >>  value chain following, etc.
> >> >>
> >> >>  We also want to record RHS = LHS, but without any
> >> >> canonicalization
> >> >>  or value chain following.  */
> >> >>   if (TREE_CODE (rhs) == SSA_NAME)
> >> >> const_and_copies->record_const_or_copy_raw (rhs, lhs,
> >> >> SSA_NAME_VALUE 
> >> >> (rhs));
> >> >>
> >> >> generally recording both is not helpful.  Jeff?  This seems to be
> >> >> r233207 (fix for PR65917) which must have regressed this testcase.
> >> >
> >> > Just verified it works fine on the GCC 5 branch:
> >> >
> >> > Optimizing block #3
> >> >
> >> > 0>>> COPY y_3(D) = x_2(D)
> >> > 1>>> STMT 1 = x_2(D) le_expr y_3(D)
> >> > 1>>> STMT 1 = x_2(D) ge_expr y_3(D)
> >> > 1>>> STMT 1 = x_2(D) eq_expr y_3(D)
> >> > 1>>> STMT 0 = x_2(D) ne_expr y_3(D)
> >> > Optimizing statement ret_4 = x_2(D) ^ y_3(D);
> >> >   Replaced 'y_3(D)' with variable 'x_2(D)'
> >> > Applying pattern match.pd:240, gimple-match.c:11346
> >> > gimple_simplified to ret_4 = 0;
> >> >   Folded to: ret_4 = 0;
> >> I have reported it as PR71947.
> >> Could you help me point out how to fix this ?
> >
> > Not record both equivalences.  This might break the testcase it was
> > introduced for (obviously).  Which is why I CCed Jeff for his opinion.
> Well, folding happens for x - y, if x == y.
> 
> int f(int x, int y)
> {
>   int ret;
>   if (x == y)
> ret = x - y;
>   else
> ret = 1;
> 
>   return ret;
> }
> 
> For the above test-case, extract_range_from_binary_expr_1()
> determines that range of ret = [0, 0]
> and propagates it.
> 
> vrp1 dump:
> f (int x, int y)
> {
>   int ret;
> 
>   :
>   if (x_2(D) == y_3(D))
> goto ;
>   else
> goto ;
> 
>   :
>   ret_4 = x_2(D) - y_3(D);
> 
>   :
>   # ret_1 = PHI <0(3), 10(2)>
>   return ret_1;
> 
> }
> 
> Then the dce pass removes ret_4 = x_2(D) - y_3(D) since it's
> redundant.
> However it appears vrp fails to notice the equality for the following 
> test-case,
> and sets range for ret to VARYING.
> 
> int f(int x, int y, int a, int b)
> {
>   int ret = 10;
>   if (a == x
>   && b == y
>   && a == b)
> ret = x - y;
> 
>   return ret;
> }
> 
> Looking at the vrp dump, shows the following form
> after inserting 

Re: [PATCH][C++] C++ bitfield memory model for as-base classes

[Richard Biener]

On Wed, 20 Jul 2016, Jeff Law wrote:

> On 06/29/2016 05:54 AM, Richard Biener wrote:
> > 
> > Currently as-base classes lack DECL_BIT_FIELD_REPRESENTATIVEs which
> > means RTL expansion doesn't honor the C++ memory model for bitfields
> > in them thus for the following testcase
> > 
> > struct B {
> > B() {}
> > int x;
> > int a : 6;
> > int b : 6;
> > int c : 6;
> > };
> > 
> > struct C : B {
> > char d;
> > };
> > 
> > C c;
> > 
> > int main()
> > {
> >   c.c = 1;
> >   c.d = 2;
> > }
> > 
> > on x86 we happily store to c.c in a way creating a store data race with
> > c.d:
> > 
> > main:
> > .LFB6:
> > .cfi_startproc
> > movlc+4(%rip), %eax
> > andl$-258049, %eax
> > orb $16, %ah
> > movl%eax, c+4(%rip)
> > movb$2, c+7(%rip)
> > xorl%eax, %eax
> > ret
> > 
> > Fixing the lack of DECL_BIT_FIELD_REPRESENTATIVEs in as-base
> > classes doesn't help though as the C++ FE builds access trees
> > for c.c using the non-as-base class FIELD_DECLs which is because
> > of layout_class_type doing
> > 
> >   /* Now that we're done with layout, give the base fields the real types.
> > */
> >   for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
> > if (DECL_ARTIFICIAL (field) && IS_FAKE_BASE_TYPE (TREE_TYPE (field)))
> >   TREE_TYPE (field) = TYPE_CONTEXT (TREE_TYPE (field));
> > 
> > this would basically require us to always treat tail-padding in a
> > struct conservatively in finish_bitfield_representative (according
> > to the doubt by the ??? comment I patch out below).
> > 
> > Simply commenting out the above makes fixing build_simple_base_path
> > necessary but even after that it then complains in the verifier
> > later ("type mismatch in component reference" - as-base to class
> > assignment).
> > 
> > But it still somehow ends up using the wrong FIELD_DECL in the end.
> > 
> > Now I think we need to fix the wrong-code issue somehow and
> > doing so in stor-layout.c by conservatively treating tail-padding
> > is a possibility.  But that will pessimize PODs and other languages
> > unless we have a way to know whether a RECORD_TYPE possibly can
> > have its tail-padding re-used (I'd hate to put a lang_hooks.name
> > check there and even that would pessimize C++ PODs).
> > 
> > Any guidance here?
> Note that if we change tail-padding re-use properties, then we effectively
> have an ABI change.  Given that, the only path forward is to use smaller
> memory operations.

Yes, we can't change the ABI.  It seems the most straigt-forward solution
is to add a langhook we can query from stor-layout that says whether
tail padding of an aggregate might be re-used.

> Do any other compilers gets this right (LLVM?)

clang++ 3.6.1 gives me

movzbl  c+6(%rip), %eax
shll$16, %eax
movzwl  c+4(%rip), %ecx
orl %eax, %ecx
andl$16519167, %ecx # imm = 0xFC0FFF
leal4096(%rcx), %eax
shrl$16, %ecx
movb%cl, c+6(%rip)
movw%ax, c+4(%rip)
movb$2, c+7(%rip)
xorl%eax, %eax
retq

so it avoids the store data race (it even avoids load data races).
Not sure if it does because of the C++ memory model or lack of
optimization.

Richard.
 
> jeff
> 
> 
> 

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

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Richard Biener]

On Wed, 20 Jul 2016, Bernd Edlinger wrote:

> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger 
> >  wrote:
> >>
> >> But I think that alloca just should not be recognized by name any
> >> more.
> >
> > It was introduced to mark calls that should not be duplicated by inlining 
> > or unrolling to avoid increasing stack usage too much.  Sth worthwhile to 
> > keep even with -ffreestanding.
> >
> > Richard.
> >
> 
> On second thought I start to think that an external alloca function
> might still work.  And returning ECF_MAY_BE_ALLOCA just based on the
> name could be made safe by checking the malloc attribute at the right
> places.
> 
> With this new incremental patch the example
> 
> extern "C"
> void *alloca(unsigned long);
> void bar(unsigned long n)
> {
>char *x = (char*) alloca(n);
>if (x)
>  *x = 0;
> }
> 
> might actually work when -ansi is used,
> i.e. it does no longer assume that alloca cannot return null,
> but still creates a frame pointer, which it would not have done
> for allocb for instance.
> 
> But the built-in alloca is still recognized because the builtin
> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
> 
> 
> Is it OK for trunk after boot-strap and reg-testing?

Hmm, but ECF_MALLOC doesn't guarantee non-NULL return.  I think the
two calls you patched simply shouldn't use the predicates (which
are misnamed as they check for _maybe_alloca_call_p).  Instead they
have to check for the respective builtins (BUILT_IN_ALLOCA,
BUILT_IN_ALLOCA_WITH_ALIGN).

Richard.

> 
> Thanks
> Bernd.
> 

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

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

[Uros Bizjak]

Hello!

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

This part introduced bootstrap failure on CentOS 5.11:

g++ -std=gnu++98 -fno-PIE -c   -g  -DIN_GCC-fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../git/gcc/gcc -I../../git/gcc/gcc/.
-I../../git/gcc/gcc/../include -I../../git/gcc/gcc/../libcpp/include
-I/usr/local/include -I/usr/local/include -I/usr/local/include
-I../../git/gcc/gcc/../libdecnumber
-I../../git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../git/gcc/gcc/../libbacktrace   -o spellcheck-tree.o -MT
spellcheck-tree.o -MMD -MP -MF ./.deps/spellcheck-tree.TPo
../../git/gcc/gcc/spellcheck-tree.c
../../git/gcc/gcc/spellcheck-tree.c: In constructor
‘best_macro_match::best_macro_match(tree_node*, edit_distance_t,
cpp_reader*)’:
../../git/gcc/gcc/spellcheck-tree.c:94: error: class
‘best_macro_match’ does not have any field named ‘best_match’
../../git/gcc/gcc/spellcheck-tree.c:94: error: no matching function
for call to ‘best_match::best_match()’
../../git/gcc/gcc/spellcheck.h:91: note: candidates are:
best_match::best_match(GOAL_TYPE,
edit_distance_t) [with GOAL_TYPE = tree_node*, CANDIDATE_TYPE =
cpp_hashnode*]
../../git/gcc/gcc/spellcheck.h:81: note:
best_match::best_match(const
best_match&)
gmake: *** [spellcheck-tree.o] Error 1

CentOS 5 has pretty old system compiler [gcc version 4.1.2 20080704
(Red Hat 4.1.2-55)], but the build worked until the above patch was
committed. Is it possible to work around this failure somehow?

Uros.

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Jan Hubicka]

> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger 
> >  wrote:
> >>
> >> Yes. That is another interesting observation.  I think, originally this
> >> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
> >> or a weak alias to alloca or maybe even something different".
> >> But some of the later optimizations use it in a way as if it meant
> >> "it must be alloca".  However I have not been able to come up with
> >> a test case that makes this assumption false, but I probably just
> >> did not try hard enough.
> >>
> >> But I think that alloca just should not be recognized by name any
> >> more.
> >
> > It was introduced to mark calls that should not be duplicated by inlining 
> > or unrolling to avoid increasing stack usage too much.  Sth worthwhile to 
> > keep even with -ffreestanding.
> >
> > Richard.
> >
> 
> Apparently the MAY_BE_ALLOCA issue is worse than I ever thought...
> 
> But I could not imagine that alloca can be anything else than a
> built-in.
> 
> Is there any implementation where alloca is like an ordinary function
> call?
> 
> I mean, does something like a function that allocates n bytes
> from the caller's stack frame work at all with any calling convention?

I just looked up the original patch introducing MAY_BE_ALLOCA
https://gcc.gnu.org/ml/gcc-patches/2000-03/msg00998.html
I did not introduce the flag and it was there for ages (I just came with
ECF_*).  The reason for it back then was only to prevent pending stack
adjustements before call to alloca. It is not completely clear to me why it is
needed - if alloca is bulitin it will do pending adjustments. There used to be
library implementation of alloca which did malloc and then gabrage collected
based on stack pointer. For that you need no special handling.

Unrolling is safe WRT alloca (because it depends on how many the function is
invoked). I added the logic to prevent inlining long time ago because otherwise
gcc benchmark from SPEC exploded in stack usage.
It is ages on my TODO to remove it and instead save/restore stack pointer around
inlined functions which does alloca.

Not fully relevant for this thread, just my 2 cents ;)
Honza
> 
> 
> Bernd.

Re: [libstdc++, C++17] Implement C++17 P0330 size_t UDL.

[Jonathan Wakely]

On 21/07/16 00:18 -0400, Ed Smith-Rowland wrote:

This patch defines

 operator""zu(unsigned long long __n)

for size_t literals.

for (auto k = 0zul; k < v.size(); ++k)

  ...


Testing on x86-64-linux is finishing but I'm past these tests.

OK?


P0330 isn't in C++17. In Oulu LEWG voted to forward it to LWG for
C++Next (i.e. C++20) and LFTSv3. I don't think LWG reviewed it yet.

https://issues.isocpp.org/show_bug.cgi?id=77

C++ PATCH for c++/70781 (ICE with ill-formed lambda)

[Jason Merrill]

Here we were returning OK from cp_parser_lambda_declarator_opt even
though we had encountered parse errors, and so parsing the inner
lambda aborted due to seeing an error_mark_node expression-statement
without ever having emitted any errors.

Fixed by clearing OK if there were parse errors.

Tested x86_64-pc-linux-gnu, applying to trunk and 6.
commit 17fea383f9a2861903ae6d144b3ba7e6a4bf191a
Author: Jason Merrill 
Date:   Wed Jul 20 17:03:50 2016 -0400

PR c++/70781 - ICE on ill-formed lambda.

* parser.c (cp_parser_lambda_expression): Unset OK if there was an
error parsing the lambda-declarator.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9bdb108..b71b9e5 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9771,10 +9771,12 @@ cp_parser_lambda_expression (cp_parser* parser)
 
 ok &= cp_parser_lambda_declarator_opt (parser, lambda_expr);
 
+if (ok && cp_parser_error_occurred (parser))
+  ok = false;
+
 if (ok)
   {
-   if (!cp_parser_error_occurred (parser)
-   && cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE)
+   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE)
&& cp_parser_start_tentative_firewall (parser))
  start = token;
cp_parser_lambda_body (parser, lambda_expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice16.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice16.C
new file mode 100644
index 000..e94a0b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice16.C
@@ -0,0 +1,8 @@
+// PR c++/70781
+// { dg-do compile { target c++11 } }
+
+template < typename T >  
+void foo ()
+{
+  T ([=] (S) { [=] {}; }); // { dg-error "" }
+}

C++ PATCH for c++/71896 (constexpr pointer to member comparison)

[Jason Merrill]

Here one operand of the comparison had been reduced to an INTEGER_CST
and the other was still a PTRMEM_CST.  We should deal with that
situation by reducing the PTRMEM_CST.

Tested x86_64-pc-linux-gnu, applying to trunk and 6.
commit 984c524f8a302059a1f71f84935dcae5f9914c7f
Author: Jason Merrill 
Date:   Wed Jul 20 17:11:00 2016 -0400

PR c++/71896 - constexpr pointer-to-member comparison.

* constexpr.c (cxx_eval_binary_expression): Handle comparison
between lowered and unlowered PTRMEM_CST.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 346fdfa..240c606 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1838,6 +1838,10 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, 
tree t,
   && (null_member_pointer_value_p (lhs)
   || null_member_pointer_value_p (rhs)))
r = constant_boolean_node (!is_code_eq, type);
+  else if (TREE_CODE (lhs) == PTRMEM_CST)
+   lhs = cplus_expand_constant (lhs);
+  else if (TREE_CODE (rhs) == PTRMEM_CST)
+   rhs = cplus_expand_constant (rhs);
 }
 
   if (r == NULL_TREE)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem6.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem6.C
new file mode 100644
index 000..ed18ab1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem6.C
@@ -0,0 +1,13 @@
+// PR c++/71896
+// { dg-do compile { target c++11 } }
+
+struct Foo {
+  int x;
+};
+
+constexpr bool compare(int Foo::*t) { return t == ::x; }
+
+constexpr bool b = compare(::x);
+
+#define SA(X) static_assert ((X),#X)
+SA(b);

C++ PATCH for -Waddress false positive in unevaluated context

[Jason Merrill]

The fix for 65168 didn't check c_inhibit_evaluation_warnings, which
means getting warnings about comparing the address of a reference to
NULL in places where we aren't actually interested in the value.  This
patch corrects that, but this lead to some regressions because
cp_truthvalue_conversion was inappropriately setting that flag to
avoid -Wzero-as-null-pointer-constant warnings.  So now we avoid those
warnings by comparing to nullptr rather than 0.

Tested x86_64-cp-linux-gnu, applying to trunk.
commit e274607c02db6d92af948b670cb90d4af452aa77
Author: Jason Merrill 
Date:   Wed Jul 20 12:03:48 2016 -0400

PR c++/65168 - -Waddress in unevaluated context.

gcc/c-family/
* c-common.c (c_common_truthvalue_conversion): Check
c_inhibit_evaluation_warnings for warning about address of
reference.
gcc/cp/
* typeck.c (cp_truthvalue_conversion): Compare pointers to nullptr.
Don't set c_inhibit_evaluation_warnings.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 936ddfb..9900e93 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4551,6 +4551,7 @@ c_common_truthvalue_conversion (location_t location, tree 
expr)
tree fromtype = TREE_TYPE (TREE_OPERAND (expr, 0));
 
if (POINTER_TYPE_P (totype)
+   && !c_inhibit_evaluation_warnings
&& TREE_CODE (fromtype) == REFERENCE_TYPE)
  {
tree inner = expr;
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index f9e45ee..d4bfb11 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5459,21 +5459,10 @@ tree
 cp_truthvalue_conversion (tree expr)
 {
   tree type = TREE_TYPE (expr);
-  if (TYPE_PTRDATAMEM_P (type)
+  if (TYPE_PTR_OR_PTRMEM_P (type)
   /* Avoid ICE on invalid use of non-static member function.  */
   || TREE_CODE (expr) == FUNCTION_DECL)
-return build_binary_op (EXPR_LOCATION (expr),
-   NE_EXPR, expr, nullptr_node, 1);
-  else if (TYPE_PTR_P (type) || TYPE_PTRMEMFUNC_P (type))
-{
-  /* With -Wzero-as-null-pointer-constant do not warn for an
-'if (p)' or a 'while (!p)', where p is a pointer.  */
-  tree ret;
-  ++c_inhibit_evaluation_warnings;
-  ret = c_common_truthvalue_conversion (input_location, expr);
-  --c_inhibit_evaluation_warnings;
-  return ret;
-}
+return build_binary_op (input_location, NE_EXPR, expr, nullptr_node, 1);
   else
 return c_common_truthvalue_conversion (input_location, expr);
 }
diff --git a/gcc/testsuite/g++.dg/warn/Waddress-3.C 
b/gcc/testsuite/g++.dg/warn/Waddress-3.C
new file mode 100644
index 000..13d7cd2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Waddress-3.C
@@ -0,0 +1,14 @@
+// PR c++/65168
+// { dg-do compile { target c++11 } }
+// { dg-options -Waddress }
+// We shouldn't warn in unevaluated context about the address of a reference
+// always being true.
+
+template 
+auto f(U&& u) -> decltype(T(u)) { }
+
+int main()
+{
+  bool ar[4];
+  f(ar);
+}
diff --git a/gcc/testsuite/g++.dg/warn/Walways-true-1.C 
b/gcc/testsuite/g++.dg/warn/Walways-true-1.C
index ae6f9dc..48b9f72 100644
--- a/gcc/testsuite/g++.dg/warn/Walways-true-1.C
+++ b/gcc/testsuite/g++.dg/warn/Walways-true-1.C
@@ -12,19 +12,19 @@ void
 bar (int a)
 {
  lab:
-  if (foo) // { dg-warning "always evaluate as" "correct warning" }
+  if (foo) // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (0);
   if (foo (1))
 ;
-  if ()  // { dg-warning "always evaluate as" "correct warning" }
+  if ()  // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (2);
   if (i)
 foo (3);
-  if ()  // { dg-warning "always evaluate as" "correct warning" }
+  if ()  // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (4);
   if (a)
 foo (5);
-  if (&)   // { dg-warning "always evaluate as" "correct warning" }
+  if (&)   // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (6);
   if (foo == 0)// { dg-warning "never be NULL" "correct warning" }
 foo (7);
diff --git a/gcc/testsuite/g++.dg/warn/Walways-true-2.C 
b/gcc/testsuite/g++.dg/warn/Walways-true-2.C
index f157347..e4b5713 100644
--- a/gcc/testsuite/g++.dg/warn/Walways-true-2.C
+++ b/gcc/testsuite/g++.dg/warn/Walways-true-2.C
@@ -23,11 +23,11 @@ bar (int a)
 foo (2);
   if (i)
 foo (3);
-  if ()  // { dg-warning "always evaluate as" "correct warning" }
+  if ()  // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (4);
   if (a)
 foo (5);
-  if (&)   // { dg-warning "always evaluate as" "correct warning" }
+  if (&)   // { dg-warning "always evaluate as|never be NULL" "correct 
warning" }
 foo (6);
   if (foo == 0)
 foo (7);