[PR84682] disregard address constraints on non-addresses

[Alexandre Oliva]

LRA gets very confused when non-addresses are passed as operands to
asms with address contraints.  Even if other constraints are
available, and the operand is a perfect fit for them, we'd still
attempt to process the operand as an address, and fail miserably at
that.

Truth is, address constraints expect operands allowed by
address_operand, and we make sure this is the case throughout the
compiler, even in asm statements.  The problem was that, if multiple
constraints were available, we wouldn't insist that the operand be
allowed by address_operand, but we would proceed as if it was,
regardless of any other constraints.

To address this problem, I've arranged for LRA to attempt to deal with
address-constrained operands as addresses only when the is_address
flag is set, and to not set this flag in preprocess_constraints for
asm operands that are not allowed by address_operand.

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

for  gcc/ChangeLog

PR rtl-optimization/84682
* lra-constraints.c (process_address_1): Check is_address flag
for address constraints.
(process_alt_operands): Likewise.
* lra.c (lra_set_insn_recog_data): Pass asm operand locs to
preprocess_constraints.
* recog.h (preprocess_constraints): Add oploc parameter.
Adjust callers.
* recog.c (preprocess_constraints): Test address_operand for
CT_ADDRESS constraints.

for  gcc/testsuite/ChangeLog

PR rtl-optimization/84682
* gcc.dg/torture/pr84682-1.c: New.
* gcc.dg/torture/pr84682-2.c: New.
* gcc.dg/torture/pr84682-3.c: New.
---
 gcc/lra-constraints.c|   15 ++-
 gcc/lra.c|3 ++-
 gcc/recog.c  |   24 +---
 gcc/recog.h  |2 +-
 gcc/testsuite/gcc.dg/torture/pr84682-1.c |5 +
 gcc/testsuite/gcc.dg/torture/pr84682-2.c |   10 ++
 gcc/testsuite/gcc.dg/torture/pr84682-3.c |8 
 7 files changed, 57 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-2.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-3.c

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 59b97540d98f..ae55c86f1777 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -2276,6 +2276,12 @@ process_alt_operands (int only_alternative)
  break;
 
case CT_ADDRESS:
+ /* An asm operand with an address constraint
+that doesn't satisfy address_operand has
+is_address cleared, so that we don't try to
+make a non-address fit.  */
+ if (!curr_static_id->operand[nop].is_address)
+   break;
  /* If we didn't already win, we can reload the address
 into a base register.  */
  if (satisfies_address_constraint_p (op, cn))
@@ -3236,7 +3242,14 @@ process_address_1 (int nop, bool check_only_p,
   && GET_CODE (XEXP (op, 0)) == SCRATCH)
 return false;
 
-  if (insn_extra_address_constraint (cn))
+  if (insn_extra_address_constraint (cn)
+  /* When we find an asm operand with an address constraint that
+doesn't satisfy address_operand to begin with, we clear
+is_address, so that we don't try to make a non-address fit.
+If the asm statement got this far, it's because other
+constraints are available, and we'll use them, disregarding
+the unsatisfiable address ones.  */
+  && curr_static_id->operand[nop].is_address)
 decompose_lea_address (&ad, curr_id->operand_loc[nop]);
   /* Do not attempt to decompose arbitrary addresses generated by combine
  for asm operands with loose constraints, e.g 'X'.  */
diff --git a/gcc/lra.c b/gcc/lra.c
index a64d8f1a3011..0a251144026c 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -1039,7 +1039,8 @@ lra_set_insn_recog_data (rtx_insn *insn)
{
  operand_alternative *op_alt = XCNEWVEC (operand_alternative,
  nalt * nop);
- preprocess_constraints (nop, nalt, constraints, op_alt);
+ preprocess_constraints (nop, nalt, constraints, op_alt,
+ data->operand_loc);
  setup_operand_alternative (data, op_alt);
}
 }
diff --git a/gcc/recog.c b/gcc/recog.c
index af6a6b01d88c..fa8e261d1476 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -2331,15 +2331,20 @@ extract_insn (rtx_insn *insn)
   which_alternative = -1;
 }
 
-/* Fill in OP_ALT_BASE for an instruction that has N_OPERANDS operands,
-   N_ALTERNATIVES alternatives and constraint strings CONSTRAINTS.
-   OP_ALT_BASE has N_ALTERNATIVES * N_OPERANDS entries and CONSTRAINTS
-   has N_OPERANDS entries.  */
+/*

Re: Fix some _GLIBCXX_DEBUG pretty printer errors

[François Dumont]

On 08/03/2018 19:11, Jonathan Wakely wrote:

This caused a new regression for:

   std::forward_list flst;
   std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }


$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL: libstdc++-prettyprinters/debug_cxx11.cc print flstiter0


Fixed by the attached patch, committed as trivial.

François

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index b5f76f2..45aaa12 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1744,10 +1744,10 @@ def build_libstdcxx_dictionary ():
   StdVectorIteratorPrinter)
 libstdcxx_printer.add_version('__gnu_cxx::', '_Slist_iterator',
   StdSlistIteratorPrinter)
-libstdcxx_printer.add_version('__gnu_cxx::', '_Fwd_list_iterator',
-  StdFwdListIteratorPrinter)
-libstdcxx_printer.add_version('__gnu_cxx::', '_Fwd_list_const_iterator',
-  StdFwdListIteratorPrinter)
+libstdcxx_printer.add_container('std::', '_Fwd_list_iterator',
+StdFwdListIteratorPrinter)
+libstdcxx_printer.add_container('std::', '_Fwd_list_const_iterator',
+StdFwdListIteratorPrinter)
 
 # Debug (compiled with -D_GLIBCXX_DEBUG) printer
 # registrations.

[C++ Patch] PR 71169 ("[7/8 Regression] ICE on invalid C++ code in pop_nested_class"), PR 71832 and more (Take 2)

[Paolo Carlini]

Hi again,

eventually I'm back with sort-of a synthesis of the various ideas, thus 
something I believe very close in spirit to my original RFC, but much 
more direct, using CLASSTYPE_TI_ARGS (eh!) and Jason' helper. And I 
managed to see that we want to vec_safe_truncate the unparsed entities - 
better late than never.


Anyway, another round of testing is in progress (in v3), all good so far.

Cheers, Paolo.



/cp
2018-03-09  Jason Merrill  
Paolo Carlini  

PR c++/71169
PR c++/71832
* pt.c (any_erroneous_template_args_p): New.
* cp-tree.h (any_erroneous_template_args_p): Declare it.
* parser.c (cp_parser_class_specifier_1): Use it.

/testsuite
2018-03-09  Jason Merrill  
Paolo Carlini  

PR c++/71169
PR c++/71832
* g++.dg/cpp0x/pr71169.C: New.
* g++.dg/cpp0x/pr71169-2.C: Likewise.
* g++.dg/cpp0x/pr71832.C: Likewise.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 258378)
+++ cp/cp-tree.h(working copy)
@@ -6558,6 +6558,7 @@ extern int processing_template_parmlist;
 extern bool dependent_type_p   (tree);
 extern bool dependent_scope_p  (tree);
 extern bool any_dependent_template_arguments_p  (const_tree);
+extern bool any_erroneous_template_args_p   (const_tree);
 extern bool dependent_template_p   (tree);
 extern bool dependent_template_id_p(tree, tree);
 extern bool type_dependent_expression_p(tree);
Index: cp/parser.c
===
--- cp/parser.c (revision 258378)
+++ cp/parser.c (working copy)
@@ -22669,6 +22669,19 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   cp_default_arg_entry *e;
   tree save_ccp, save_ccr;
 
+  if (type != error_mark_node
+ && CLASSTYPE_TEMPLATE_INFO (type)
+ && any_erroneous_template_args_p (CLASSTYPE_TI_ARGS (type)))
+   {
+ /* Skip default arguments, NSDMIs, etc, in order to improve
+error recovery (c++/71169, c++/71832).  */
+ vec_safe_truncate (unparsed_funs_with_default_args, 0);
+ vec_safe_truncate (unparsed_nsdmis, 0);
+ vec_safe_truncate (unparsed_classes, 0);
+ vec_safe_truncate (unparsed_funs_with_definitions, 0);
+ goto out;
+   }
+
   /* In a first pass, parse default arguments to the functions.
 Then, in a second pass, parse the bodies of the functions.
 This two-phased approach handles cases like:
@@ -22745,6 +22758,7 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   else
 vec_safe_push (unparsed_classes, type);
 
+ out:
   /* Put back any saved access checks.  */
   pop_deferring_access_checks ();
 
Index: cp/pt.c
===
--- cp/pt.c (revision 258378)
+++ cp/pt.c (working copy)
@@ -25048,6 +25048,38 @@ any_dependent_template_arguments_p (const_tree arg
   return false;
 }
 
+/* Returns true if ARGS contains any errors.  */
+
+bool
+any_erroneous_template_args_p (const_tree args)
+{
+  int i;
+  int j;
+
+  if (args && TREE_CODE (args) != TREE_VEC)
+{
+  if (tree ti = get_template_info (args))
+   args = TI_ARGS (ti);
+  else
+   args = NULL_TREE;
+}
+
+  if (!args)
+return false;
+  if (args == error_mark_node)
+return true;
+
+  for (i = 0; i < TMPL_ARGS_DEPTH (args); ++i)
+{
+  const_tree level = TMPL_ARGS_LEVEL (args, i + 1);
+  for (j = 0; j < TREE_VEC_LENGTH (level); ++j)
+   if (error_operand_p (TREE_VEC_ELT (level, j)))
+ return true;
+}
+
+  return false;
+}
+
 /* Returns TRUE if the template TMPL is type-dependent.  */
 
 bool
Index: testsuite/g++.dg/cpp0x/pr71169-2.C
===
--- testsuite/g++.dg/cpp0x/pr71169-2.C  (nonexistent)
+++ testsuite/g++.dg/cpp0x/pr71169-2.C  (working copy)
@@ -0,0 +1,19 @@
+// { dg-do compile { target c++11 } }
+
+template  class A {  // { dg-error "declared" }
+  template  void m_fn1() {
+m_fn1();
+}
+};
+
+template
+struct B
+{
+  int f(int = 0) { return 0; }
+};
+
+int main()
+{
+  B b;
+  return b.f();
+}
Index: testsuite/g++.dg/cpp0x/pr71169.C
===
--- testsuite/g++.dg/cpp0x/pr71169.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr71169.C(working copy)
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++11 } }
+
+template  class A {  // { dg-error "declared" }
+  template  void m_fn1() {
+m_fn1();
+}
+};
Index: testsuite/g++.dg/cpp0x/pr71832.C
===
--- testsuite/g++.dg/cpp0x/pr71832.C(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr71832.C(working copy)
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++11 } }
+
+template < typename declty

Re: [C++ PATCH] For -Wformat purposes use ellipsis args before class to pointer to class conversion (PR c++/84076)

[Jakub Jelinek]

On Thu, Mar 08, 2018 at 04:20:40PM -0500, Jason Merrill wrote:
> On Thu, Mar 8, 2018 at 1:08 PM, Jakub Jelinek  wrote:
> > The reporter complains that -Wformat incorrectly reports std::string* passed
> > to "%s" format rather than std::string, which is what the user did.
> >
> > This transformation of non-trivial copy init or dtor classes in ellipsis is
> > done by convert_arg_to_ellipsis; that function does many changes and all
> > but this one look desirable for the -Wnonnull/-Wformat/-Wsentinel/-Wrestrict
> > warnings.  We prepare a special argument vector in any case, so this patch
> > just arranges to undo what convert_arg_to_ellipsis did for the classes.
> > I think -Wnonnull shouldn't care, because when passing such a class by
> > value, it will be non-NULL (and -Wnonnull looks only for literal NULLs
> > anyway), -Wrestrict only cares about named arguments and -Wsentinel only
> > cares about NULL arguments passed to ellipsis.
> 
> I notice that convert_arg_to_ellipsis generates a pointer-typed
> expression, whereas convert_for_arg_passing generates a reference.
> Does correcting that inconsistency help?

No (though I think it is a good idea anyway).
With this patch the original testcase reports:
pr84076.C:7:16: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘std::__cxx11::string&’ {aka 
‘std::__cxx11::basic_string&’} [-Wformat=]
where the user expects that without the & characters and without the patch
it has * instead of &.
With the patch I've posted it is:
pr84076.C:7:16: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘std::__cxx11::string’ {aka 
‘std::__cxx11::basic_string’} [-Wformat=]

Similarly, the testcase included in the patch with just your patch:
pr84076.C: In function ‘void foo()’:
pr84076.C:13:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘S&’ [-Wformat=]
   __builtin_printf ("%s\n", s); // { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'S'" }
 ^~
pr84076.C:14:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘T&’ [-Wformat=]
   __builtin_printf ("%s\n", t); // { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'T'" }
 ^~
pr84076.C:15:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘S*’ [-Wformat=]
   __builtin_printf ("%s\n", &s);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'S\\*'" }
 ^~  ~~
pr84076.C:16:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘T*’ [-Wformat=]
   __builtin_printf ("%s\n", &t);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'T\\*'" }
 ^~  ~~
and with both patches:
pr84076.C: In function ‘void foo()’:
pr84076.C:13:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘S’ [-Wformat=]
   __builtin_printf ("%s\n", s); // { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'S'" }
 ^~  ~
pr84076.C:14:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘T’ [-Wformat=]
   __builtin_printf ("%s\n", t); // { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'T'" }
 ^~  ~
pr84076.C:15:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘S*’ [-Wformat=]
   __builtin_printf ("%s\n", &s);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'S\\*'" }
 ^~  ~~
pr84076.C:16:21: warning: format ‘%s’ expects argument of type ‘char*’, but 
argument 2 has type ‘T*’ [-Wformat=]
   __builtin_printf ("%s\n", &t);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'T\\*'" }
 ^~  ~~

> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index f83d51f3457..617ce18f8cd 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -7209,7 +7209,7 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t 
> complain)
>"passing objects of non-trivially-copyable "
>"type %q#T through %<...%> is conditionally supported",
>arg_type);
> -   return cp_build_addr_expr (arg, complain);
> +   return build1 (ADDR_EXPR, build_reference_type (arg_type), arg);
>   }
>/* Build up a real lvalue-to-rvalue conversion in case the
>copy constructor is trivial but not callable.  */


Jakub

PR libstdc++/84769 qualify std::get and std::get_if to avoid ADL

[Jonathan Wakely]

PR libstdc++/84769
* include/std/variant (get<_Tp, _Types...>, get_if<_Tp, _Types...>):
Qualify calls to get<_Np, Types...> and get_if<_Np, _Types...>.

Tested powerpc64le-linux, committed to trunk, and will commit to
gcc-7-branch too.
commit 011ffe188a225ed472ac3e9cd3806dc1ef47b48b
Author: Jonathan Wakely 
Date:   Fri Mar 9 00:52:57 2018 +

PR libstdc++/84769 qualify std::get and std::get_if to avoid ADL

PR libstdc++/84769
* include/std/variant (get<_Tp, _Types...>, get_if<_Tp, _Types...>):
Qualify calls to get<_Np, Types...> and get_if<_Np, _Types...>.

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 85a2428715b..4aba131cb73 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -891,7 +891,7 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
+  return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
 }
 
   template
@@ -900,7 +900,7 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
+  return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
std::move(__v));
 }
 
@@ -910,7 +910,7 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
+  return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
 }
 
   template
@@ -919,7 +919,7 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
+  return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(
std::move(__v));
 }
 
@@ -958,7 +958,8 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(__ptr);
+  return std::get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(
+ __ptr);
 }
 
   template
@@ -969,7 +970,8 @@ namespace __variant
   static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T should occur for exactly once in alternatives");
   static_assert(!is_void_v<_Tp>, "_Tp should not be void");
-  return get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(__ptr);
+  return std::get_if<__detail::__variant::__index_of_v<_Tp, _Types...>>(
+ __ptr);
 }
 
   struct monostate { };

Use non-throwing is_directory in filesystem::create_directory

[Jonathan Wakely]

The create_dir helper was calling the throwing form of
filesystem::is_directory instead of passing the error_code argument.
Since std::filesystem::create_directory(const path&, error_code&) is
noexcept, it would call std::terminate if an error occurred in
is_directory.

Passing the error_code also takes care of clearing it in the case where
is_directory returns true.

src/filesystem/ops.cc (create_dir): Pass error_code to is_directory.
src/filesystem/std-ops.cc (create_dir): Likewise.

Tested powerpc64le-linux, committed to trunk.
commit c3ac5f5cbb2ce9d20c30da06d19bcdca20630e0b
Author: Jonathan Wakely 
Date:   Fri Mar 9 00:42:20 2018 +

Use non-throwing is_directory in filesystem::create_directory

The create_dir helper was calling the throwing form of
filesystem::is_directory instead of passing the error_code argument.
Since std::filesystem::create_directory(const path&, error_code&) is
noexcept, it would call std::terminate if an error occurred in
is_directory.

Passing the error_code also takes care of clearing it in the case where
is_directory returns true.

src/filesystem/ops.cc (create_dir): Pass error_code to is_directory.
src/filesystem/std-ops.cc (create_dir): Likewise.

diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 899defea6d2..328332a8a82 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -463,10 +463,8 @@ namespace
 if (::mkdir(p.c_str(), mode))
   {
const int err = errno;
-   if (err != EEXIST || !is_directory(p))
+   if (err != EEXIST || !is_directory(p, ec))
  ec.assign(err, std::generic_category());
-   else
- ec.clear();
   }
 else
   {
diff --git a/libstdc++-v3/src/filesystem/std-ops.cc 
b/libstdc++-v3/src/filesystem/std-ops.cc
index 65b06f5b67b..930b186e88c 100644
--- a/libstdc++-v3/src/filesystem/std-ops.cc
+++ b/libstdc++-v3/src/filesystem/std-ops.cc
@@ -668,10 +668,8 @@ namespace
 if (::mkdir(p.c_str(), mode))
   {
const int err = errno;
-   if (err != EEXIST || !is_directory(p))
+   if (err != EEXIST || !is_directory(p, ec))
  ec.assign(err, std::generic_category());
-   else
- ec.clear();
   }
 else
   {

Re: [PATCH] avoid warning for memcpy to self (PR 83456)

[Martin Sebor]

On 03/08/2018 01:59 AM, Richard Biener wrote:

On Thu, Mar 8, 2018 at 12:01 AM, Martin Sebor  wrote:

I have become convinced that issuing -Wrestrict in gimple-fold
for calls to memcpy() where the source pointer is the same as
the destination causes more trouble than it's worth, especially
when inlining is involved, as in:

  inline void bar (void *d, void *s, unsigned N)
  {
if (s != d)
  memcpy (d, s, N);
  }

  void foo (void* src)
  {
bar (src, src, 1);
  }

It seems that there should be a way to teach GCC to avoid
folding statements in dead blocks (e.g., in a block controlled
by 'if (0 != 0)' as the one below), and that it might even speed
up compilation, but in the meantime it leads to false positive
-Wrestrict warnings.

The attached patch removes this instance of the warning and
adjusts tests not to expect it.


Ok.


I'm sorry, I just discovered that simply removing the code from
gimple-fold would cause a regression with respect to GCC 7.0
which does diagnose memcpy(p, p, N) calls, and the diagnostic
is useful to users (pr60256 and pr65452 request one for all
string functions, although for reasons other than to detect
overlapping accesses).

To maintain the warning and at the same time eliminate the pesky
false positives from gimple-fold I've partially restored the
detection in the front-end.  That in turn exposed some missing
checking of the no-warning bit, leading to duplicate warnings.
I've fixed all that up in the attached slightly bigger patch.

Martin

PS Even with the change to the front end above, removing
the memcpy warning from gimple-fold has the downside of
failing to detect bugs like:

  struct S { char a[32]; } s;
  memcpy (&s, s.a, sizeof s.a);

because the front end doesn't know that &s and s.a are at
the same address (copying between distinct members of the
same union causes another false negative).  I want to
revisit this in stage 1 and see about handling it.  If
you have suggestions/preference for how or where I'd
appreciate your input.
PR tree-optimization/83456 - -Wrestrict false positive on a non-overlapping memcpy in an inline function

gcc/ChangeLog:

	PR tree-optimization/83456
	* gimple-fold.c (gimple_fold_builtin_memory_op): Avoid warning
	for perfectly overlapping calls to memcpy.
	(gimple_fold_builtin_memory_chk): Same.
	(gimple_fold_builtin_strcpy): Handle no-warning.
	(gimple_fold_builtin_stxcpy_chk): Same.
	* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Handle no-warning.

gcc/c-family/ChangeLog:

	PR tree-optimization/83456
	* gcc/c-family/c-common.c (check_function_restrict): Return bool.
	Restore checking of bounded built-in functions.
	(check_function_arguments): Also return the result
	of warn_for_restrict.
	* gcc/c-family/c-common.c (check_function_restrict): Return bool.
	* gcc/c-family/c-warn.c (warn_for_restrict): Return bool.

gcc/testsuite/ChangeLog:

	PR tree-optimization/83456
	* c-c++-common/Wrestrict-2.c: Remove test cases.
	* c-c++-common/Wrestrict.c: Same.
	* gcc.dg/Wrestrict-12.c: New test.
	* gcc.dg/Wrestrict-14.c: New test.
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c	(revision 258366)
+++ gcc/c-family/c-common.c	(working copy)
@@ -5309,10 +5309,11 @@ check_function_sentinel (const_tree fntype, int na
 }
 }
 
-/* Check that the same argument isn't passed to restrict arguments
-   and other arguments.  */
+/* Check that the same argument isn't passed to two or more
+   restrict-qualified formal and issue a -Wrestrict warning
+   if it is.  Return true if a warning has been issued.  */
 
-static void
+static bool
 check_function_restrict (const_tree fndecl, const_tree fntype,
 			 int nargs, tree *argarray)
 {
@@ -5322,11 +5323,14 @@ check_function_restrict (const_tree fndecl, const_
   if (fndecl
   && TREE_CODE (fndecl) == FUNCTION_DECL)
 {
-  /* Skip checking built-ins here.  They are checked in more
-	 detail elsewhere.  */
+  /* Avoid diagnosing calls built-ins with a zero size/bound
+	 here.  They are checked in more detail elsewhere. */
   if (DECL_BUILT_IN (fndecl)
-	  && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
-	return;
+	  && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
+	  && nargs == 3
+	  && TREE_CODE (argarray[2]) == INTEGER_CST
+	  && integer_zerop (argarray[2]))
+	return false;
 
   if (DECL_ARGUMENTS (fndecl))
 	parms = DECL_ARGUMENTS (fndecl);
@@ -5335,6 +5339,8 @@ check_function_restrict (const_tree fndecl, const_
   for (i = 0; i < nargs; i++)
 TREE_VISITED (argarray[i]) = 0;
 
+  bool warned = false;
+
   for (i = 0; i < nargs && parms && parms != void_list_node; i++)
 {
   tree type;
@@ -5351,11 +5357,13 @@ check_function_restrict (const_tree fndecl, const_
   if (POINTER_TYPE_P (type)
 	  && TYPE_RESTRICT (type)
 	  && !TYPE_READONLY (TREE_TYPE (type)))
-	warn_for_restrict (i, argarray, nargs);
+	warned |= warn_for_restrict (i, argarray, nargs);
 }
 
   for (i = 0; i < nar

PR libstdc++/78420 Make std::less etc. yield total order for pointers

[Jonathan Wakely]

In order to meet the total order requirements of [comparisons] p2 we
need to cast unrelated pointers to uintptr_t before comparing them.
Those casts aren't allowed in constant expressions, so only cast
when __builtin_constant_p says the result of the comparison is not a
compile-time constant (because the arguments are not constants, or the
result of the comparison is unspecified). When the result is constant
just compare the pointers directly without casting.

This ensures that the function can be called in constant expressions
with suitable arguments, but still yields a total order even for
otherwise unspecified pointer comparisons.

PR libstdc++/78420
* include/bits/stl_function.h (__ptr_rel_ops): New struct providing
relational operators defining total order on pointers.
(greater<_Tp*>, less<_Tp*>, greater_equal<_Tp*>, less_equal<_Tp>*):
New partial specializations for pointers, using __ptr_rel_ops.
(greater, less, greater_equal, less_equalcommit e03605434a5c378c55e1961402319a20af75a909
Author: Jonathan Wakely 
Date:   Thu Mar 8 20:27:04 2018 +

PR libstdc++/78420 Make std::less etc. yield total order for pointers

In order to meet the total order requirements of [comparisons] p2 we
need to cast unrelated pointers to uintptr_t before comparing them.
Those casts aren't allowed in constant expressions, so only cast
when __builtin_constant_p says the result of the comparison is not a
compile-time constant (because the arguments are not constants, or the
result of the comparison is unspecified). When the result is constant
just compare the pointers directly without casting.

This ensures that the function can be called in constant expressions
with suitable arguments, but still yields a total order even for
otherwise unspecified pointer comparisons.

PR libstdc++/78420
* include/bits/stl_function.h (__ptr_rel_ops): New struct providing
relational operators defining total order on pointers.
(greater<_Tp*>, less<_Tp*>, greater_equal<_Tp*>, less_equal<_Tp>*):
New partial specializations for pointers, using __ptr_rel_ops.
(greater, less, greater_equal, less_equal 201103L
+  struct __ptr_rel_ops
+  {
+__ptr_rel_ops() = delete;
+~__ptr_rel_ops() = delete;
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_greater(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x > __y))
+ return __x > __y;
+   return (__UINTPTR_TYPE__)__x > (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_less(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x < __y))
+ return __x < __y;
+   return (__UINTPTR_TYPE__)__x < (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_greater_equal(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x >= __y))
+ return __x >= __y;
+   return (__UINTPTR_TYPE__)__x >= (__UINTPTR_TYPE__)__y;
+  }
+
+template
+  static _GLIBCXX14_CONSTEXPR bool
+  _S_less_equal(_Tp* __x, _Up* __y)
+  {
+   if (__builtin_constant_p (__x <= __y))
+ return __x <= __y;
+   return (__UINTPTR_TYPE__)__x <= (__UINTPTR_TYPE__)__y;
+  }
+  };
+
+  // Partial specialization of std::greater for pointers.
+  template
+struct greater<_Tp*> : public binary_function<_Tp*, _Tp*, bool>
+{
+  _GLIBCXX14_CONSTEXPR bool
+  operator()(_Tp* const& __x, _Tp* const& __y) const _GLIBCXX_NOTHROW
+  { return __ptr_rel_ops::_S_greater(__x, __y); }
+};
+
+  // Partial specialization of std::less for pointers.
+  template
+struct less<_Tp*> : public binary_function<_Tp*, _Tp*, bool>
+{
+  _GLIBCXX14_CONSTEXPR bool
+  operator()(_Tp* const& __x, _Tp* const& __y) const _GLIBCXX_NOTHROW
+  { return __ptr_rel_ops::_S_less(__x, __y); }
+};
+
+  // Partial specialization of std::greater_equal for pointers.
+  template
+struct greater_equal<_Tp*> : public binary_function<_Tp*, _Tp*, bool>
+{
+  _GLIBCXX14_CONSTEXPR bool
+  operator()(_Tp* const& __x, _Tp* const& __y) const _GLIBCXX_NOTHROW
+  { return __ptr_rel_ops::_S_greater_equal(__x, __y); }
+};
+
+  // Partial specialization of std::less_equal for pointers.
+  template
+struct less_equal<_Tp*> : public binary_function<_Tp*, _Tp*, bool>
+{
+  _GLIBCXX14_CONSTEXPR bool
+  operator()(_Tp* const& __x, _Tp* const& __y) const _GLIBCXX_NOTHROW
+  { return __ptr_rel_ops::_S_less_equal(__x, __y); }
+};
+
+#if __cplusplus >= 201402L
   /// One of the @link comparison_functors comparison functors@endlink.
   template<>
 struct equal_to
 {
   template 
-   _GLIBCXX14_CONSTEXPR
-   auto
+   constexpr auto
operator()(_Tp&& __t, _Up&& __u) const
noexcept(noexcept(std::forward<_Tp>

[og7] Update nvptx_fork/join barrier placement

[Cesar Philippidis]

Nvidia Volta GPUs now support warp-level synchronization. As such, the
semantics of legacy bar.sync instructions have slightly changed on newer
GPUs. The PTX JIT will now, occasionally, emit a warpsync instruction
immediately before a bar.sync for Volta GPUs. That implies that warps
must be convergent on entry to those threads barriers.

The problem in og7, and trunk, is that GCC emits barrier instructions at
the wrong spots. E.g., consider the following OpenACC parallel region:

  #pragma acc parallel loop worker
  for (i = 0; i < 10; i++)
a[i] = i;

At -O2, GCC generates the following PTX code:

{
.reg.u32%y;
mov.u32 %y, %tid.y;
setp.ne.u32 %r76, %y, 0;
}
{
.reg.u32%x;
mov.u32 %x, %tid.x;
setp.ne.u32 %r75, %x, 0;
}
@%r76   bra.uni $L6;
@%r75   bra $L7;
mov.u64 %r67, %ar0;
// fork 2;
cvta.shared.u64 %r74, __oacc_bcast;
st.u64  [%r74], %r67;
$L7:
$L6:
@%r75   bra $L5;
// forked 2;
bar.sync0;
cvta.shared.u64 %r73, __oacc_bcast;
ld.u64  %r67, [%r73];
mov.u32 %r62, %ntid.y;
mov.u32 %r63, %tid.y;
setp.gt.s32 %r68, %r63, 9;
@%r68   bra $L2;
mov.u32 %r55, %r63;
cvt.s64.s32 %r69, %r62;
shl.b64 %r59, %r69, 2;
cvt.s64.s32 %r70, %r55;
shl.b64 %r71, %r70, 2;
add.u64 %r58, %r67, %r71;
$L3:
st.u32  [%r58], %r55;
add.u32 %r55, %r55, %r62;
add.u64 %r58, %r58, %r59;
setp.le.s32 %r72, %r55, 9;
@%r72   bra $L3;
$L2:
bar.sync1;
// joining 2;
$L5:
// join 2;
ret;

Note the bar.sync instructions placed immediately after the forked
comment and before the joining comment. The problem here is that branch
above the forked comment guarantees that the warps are not synchronous
(when vector_length > 1, which is always the case). Likewise, bar.sync
instruction before joining should be placed after label L5 in order to
allow all of the threads in the warp to reach it.

The attached patch teaches the nvptx to make those adjustments. It
doesn't cause any regressions on legacy GPUs, but it does resolve quite
a few failures with Volta in the libgomp execution tests. Therefore,
this patch doesn't include any new test cases. Part of this patch came
from my vector_length patch set that I posted last week. However, that
patch set didn't consider the placement of the joining barrier.

I've applied this patch to openacc-gcc-7-branch.

Tom, is a similar patch OK for trunk? The major difference between trunk
and og7 is that og7 changed the name of nvptx_warp_sync to nvptx_cta_sync.

Cesar
2018-03-08  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx.c (nvptx_single): Adjust placement of nvptx_fork
	and nvptx_join nutering labels.
	(nvptx_process_pars): Place the CTA barrier at the beginning of the
	join block.


diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index b16cf59575c..efc6161a6b0 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4056,6 +4056,15 @@ nvptx_single (unsigned mask, basic_block from, basic_block to)
 	return;
 }
 
+  /* NVPTX_BARSYNC barriers are placed immediately before NVPTX_JOIN
+ in order to ensure that all of the threads in a CTA reach the
+ barrier.  Don't nueter BLOCK if head is NVPTX_BARSYNC and tail is
+ NVPTX_JOIN.  */
+  if (from == to
+  && recog_memoized (head) == CODE_FOR_nvptx_barsync
+  && recog_memoized (tail) == CODE_FOR_nvptx_join)
+return;
+
   /* Insert the vector test inside the worker test.  */
   unsigned mode;
   rtx_insn *before = tail;
@@ -4103,7 +4112,17 @@ nvptx_single (unsigned mask, basic_block from, basic_block to)
 	  br = gen_br_true (pred, label);
 	else
 	  br = gen_br_true_uni (pred, label);
-	emit_insn_before (br, head);
+
+	if (recog_memoized (head) == CODE_FOR_nvptx_forked
+	&& recog_memoized (NEXT_INSN (head)) == CODE_FOR_nvptx_barsync)
+	  {
+	head = NEXT_INSN (head);
+	emit_insn_after (br, head);
+	  }
+	else if (recog_memoized (head) == CODE_FOR_nvptx_barsync)
+	  emit_insn_after (br, head);
+	else
+	  emit_insn_before (br, head);
 
 	LABEL_NUSES (label)++;
 	if (tail_branch)
@@ -4325,7 +4344,7 @@ nvptx_process_pars (parallel *par)
 	{
 	  /* Insert begin and end synchronizations.  */
 	  emit_insn_after (nvptx_cta_sync (false), par->forked_insn);
-	  emit_insn_before (nvptx_cta_sync (true), par->joining_insn);
+	  emit_insn_before (nvptx_cta_sync (true), par->join_insn);
 	}
 }
   else if (par->mask & GOMP_DIM_MASK (GOMP_DIM_VECTOR))

Re: Fix some _GLIBCXX_DEBUG pretty printer errors

[Jonathan Wakely]

On 8 March 2018 at 21:32, François Dumont  wrote:
> On 08/03/2018 19:11, Jonathan Wakely wrote:
>>
>> This caused a new regression for:
>>
>>std::forward_list flst;
>>std::forward_list::iterator flstiter0;
>> // { dg-final { note-test flstiter0 {non-dereferenceable iterator for
>> std::forward_list}} }
>>
>>
>> $1 = {_M_node = 0x0}
>> got: $1 = {_M_node = 0x0}
>> FAIL: libstdc++-prettyprinters/debug_cxx11.cc print flstiter0
>>
> Yes, sorry, it looks like I was more concerned by the fixes than by the
> errors on the new test.
>
> This is coming from an attempt to move the forward_list iterators outside
> the std namespace. I'll provide a fix tomorrow.

Thanks!


> François
>

Re: [RFC][PR82479] missing popcount builtin detection

[Kugan Vivekanandarajah]

Hi Richard and Bin,

Thanks for your comments. I will revise the patch and post it as soon
as stage-1 opens.

Kugan

On 7 March 2018 at 22:25, Bin.Cheng  wrote:
> On Wed, Mar 7, 2018 at 8:26 AM, Richard Biener
>  wrote:
>> On Tue, Mar 6, 2018 at 5:20 PM, Bin.Cheng  wrote:
>>> On Mon, Mar 5, 2018 at 3:24 PM, Richard Biener
>>>  wrote:
 On Thu, Feb 8, 2018 at 1:41 AM, Kugan Vivekanandarajah
  wrote:
> Hi Richard,
>
> On 1 February 2018 at 23:21, Richard Biener  
> wrote:
>> On Thu, Feb 1, 2018 at 5:07 AM, Kugan Vivekanandarajah
>>  wrote:
>>> Hi Richard,
>>>
>>> On 31 January 2018 at 21:39, Richard Biener 
>>>  wrote:
 On Wed, Jan 31, 2018 at 11:28 AM, Kugan Vivekanandarajah
  wrote:
> Hi Richard,
>
> Thanks for the review.
> On 25 January 2018 at 20:04, Richard Biener 
>  wrote:
>> On Wed, Jan 24, 2018 at 10:56 PM, Kugan Vivekanandarajah
>>  wrote:
>>> Hi All,
>>>
>>> Here is a patch for popcount builtin detection similar to LLVM. I
>>> would like to queue this for review for next stage 1.
>>>
>>> 1. This is done part of loop-distribution and effective for -O3 and 
>>> above.
>>> 2. This does not distribute loop to detect popcount (like
>>> memcpy/memmove). I dont think that happens in practice. Please 
>>> correct
>>> me if I am wrong.
>>
>> But then it has no business inside loop distribution but instead is
>> doing final value
>> replacement, right?  You are pattern-matching the whole loop after 
>> all.  I think
>> final value replacement would already do the correct thing if you
>> teached number of
>> iteration analysis that niter for
>>
>>[local count: 955630224]:
>>   # b_11 = PHI 
>>   _1 = b_11 + -1;
>>   b_8 = _1 & b_11;
>>   if (b_8 != 0)
>> goto ; [89.00%]
>>   else
>> goto ; [11.00%]
>>
>>[local count: 850510900]:
>>   goto ; [100.00%]
>
> I am looking into this approach. What should be the scalar evolution
> for b_8 (i.e. b & (b -1) in a loop) should be? This is not clear to me
> and can this be represented with the scev?

 No, it's not affine and thus cannot be represented.  You only need the
 scalar evolution of the counting IV which is already handled and
 the number of iteration analysis needs to handle the above IV - this
 is the missing part.
>>> Thanks for the clarification. I am now matching this loop pattern in
>>> number_of_iterations_exit when number_of_iterations_exit_assumptions
>>> fails. If the pattern matches, I am inserting the _builtin_popcount in
>>> the loop preheater and setting the loop niter with this. This will be
>>> used by the final value replacement. Is this what you wanted?
>>
>> No, you shouldn't insert a popcount stmt but instead the niter
>> GENERIC tree should be a CALL_EXPR to popcount with the
>> appropriate argument.
>
> Thats what I tried earlier but ran into some ICEs. I wasn't sure if
> niter in tree_niter_desc can take such.
>
> Attached patch now does this. Also had to add support for CALL_EXPR in
> few places to handle niter with CALL_EXPR. Does this look OK?

 Overall this looks ok - the patch includes changes in places that I don't 
 think
 need changes such as chrec_convert_1 or extract_ops_from_tree.
 The expression_expensive_p change should be more specific than making
 all calls inexpensive as well.

 The verify_ssa change looks bogus, you do

 +  dest = gimple_phi_result (count_phi);
 +  tree var = make_ssa_name (TREE_TYPE (dest), NULL);
 +  tree fn = builtin_decl_implicit (BUILT_IN_POPCOUNT);
 +
 +  var = build_call_expr (fn, 1, src);
 +  *niter = fold_build2 (MINUS_EXPR, TREE_TYPE (dest), var,
 +   build_int_cst (TREE_TYPE (dest), 1));

 why do you allocate a new SSA name here?  It seems unused
 as you overwrive 'var' with the CALL_EXPR immediately.

 I didn't review the pattern matching thoroughly nor the exact place you
 call it.  But

 +  if (check_popcount_pattern (loop, &count))
 +   {
 + niter->assumptions = boolean_false_node;
 + niter->control.base = NULL_TREE;
 + niter->control.step = NULL_TREE;
 + niter->control.no_overflow = false;
 + niter->niter = count;
 + niter->assumptions = boolean_true_node;
 + niter->may_be_zero = boolean_false_node;
 + niter->max = -1;
 + niter->bound = NULL_TREE;
 + niter->cmp = ERROR_MARK;
 + return true;
 +   }

 simply settin

Re: [C++ PATCH] Avoid -Wunused-function warning when a static function is only used from uninstantiated template (PR c++/80598)

[Jakub Jelinek]

On Thu, Mar 08, 2018 at 10:08:20AM -0500, Jason Merrill wrote:
> On Wed, Mar 7, 2018 at 5:19 PM, Jakub Jelinek  wrote:
> > This testcase regressed when the mark_used call in finish_id_expression
> > has been guarded with if (done).  Wonder if we can't just mark it TREE_USED
> > otherwise for the benefit of -Wunused-function and leave it
> > non-DECL_ODR_USED as it should.  Or do we want to mark it TREE_USED
> > elsewhere?
> 
> Probably in the processing_template_decl block near the top of 
> build_over_call.

This works too.  Ok for trunk then (passed bootstrap/regtest on x86_64-linux
and i686-linux)?

2018-03-08  Jason Merrill  
Jakub Jelinek  

PR c++/80598
* call.c (build_over_call): In templates set TREE_USED (first_fn) when
not calling mark_used for the benefit of -Wunused-function warning.

* g++.dg/warn/Wunused-function4.C: New test.

--- gcc/cp/call.c.jj2018-03-08 10:58:58.157373982 +0100
+++ gcc/cp/call.c   2018-03-08 16:18:19.897340581 +0100
@@ -7634,6 +7634,10 @@ build_over_call (struct z_candidate *can
 
   if (undeduced_auto_decl (fn))
mark_used (fn, complain);
+  else
+   /* Otherwise set TREE_USED for the benefit of -Wunused-function.
+  See PR80598.  */
+   TREE_USED (fn) = 1;
 
   return_type = TREE_TYPE (TREE_TYPE (fn));
   nargs = vec_safe_length (args);
--- gcc/testsuite/g++.dg/warn/Wunused-function4.C.jj2018-03-08 
16:16:23.756274559 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-function4.C   2018-03-08 
16:16:23.756274559 +0100
@@ -0,0 +1,21 @@
+// PR c++/80598
+// { dg-do compile }
+// { dg-options "-Wunused-function" }
+
+static void
+foo () // { dg-bogus "defined but not used" }
+{
+}
+
+static void
+bar () // { dg-warning "defined but not used" }
+{
+}
+
+template 
+int
+baz (T x)
+{
+  foo ();
+  return 0;
+}


Jakub

Re: [PATCH] Fix dwarf2out regression introduced with LVUs (PR debug/84456)

[Jason Merrill]

OK.

On Thu, Mar 8, 2018 at 1:14 PM, Jakub Jelinek  wrote:
> Hi!
>
> GCC 7 and earlier had in this spot
>   if (list && loc_list->first->next)
> gen_llsym (list);
> where we wanted to force loclist if we've seen more than one
> NOTE_INSN_VAR_LOCATION for the decl, which means it is not possible to use
> a block form DW_AT_location.
>
> Alex has changed this to maybe_gen_llsym (list) call, which does:
>   if (!list || (!list->dw_loc_next && !loc_list_has_views (list)))
> return;
>
>   gen_llsym (list);
> This matches what the other caller of gen_llsym did:
>   if (list && list->dw_loc_next)
> gen_llsym (list);
> but not the dw_loc_list spot.  The difference between the two is
> (when -gno-variable-location-views) that maybe_gen_llsym will not force
> loclist form if we transform 2+ NOTE_INSN_VAR_LOCATION notes into a single
> defined location expression, which can happen e.g. when the first
> note is some usable location and the second one is .
> In that case we must use loclist to force the variable to be 
> in the second part of the function, because the first DWARF expression would
> give wrong results there.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-03-08  Jakub Jelinek  
>
> PR debug/84456
> * dwarf2out.c (dw_loc_list): If list && loc_list->first->next, call
> gen_llsym, otherwise call maybe_gen_llsym.
>
> --- gcc/dwarf2out.c.jj  2018-03-02 00:15:54.704780976 +0100
> +++ gcc/dwarf2out.c 2018-03-08 12:54:01.794054675 +0100
> @@ -17076,7 +17076,10 @@ dw_loc_list (var_loc_list *loc_list, tre
>   representable, we don't want to pretend a single entry that was
>   applies to the entire scope in which the variable is
>   available.  */
> -  maybe_gen_llsym (list);
> +  if (list && loc_list->first->next)
> +gen_llsym (list);
> +  else
> +maybe_gen_llsym (list);
>
>return list;
>  }
>
> Jakub

Re: Fix some _GLIBCXX_DEBUG pretty printer errors

[François Dumont]

On 08/03/2018 19:11, Jonathan Wakely wrote:

This caused a new regression for:

   std::forward_list flst;
   std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }


$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL: libstdc++-prettyprinters/debug_cxx11.cc print flstiter0

Yes, sorry, it looks like I was more concerned by the fixes than by the 
errors on the new test.


This is coming from an attempt to move the forward_list iterators 
outside the std namespace. I'll provide a fix tomorrow.


François

Re: [C++ PATCH] For -Wformat purposes use ellipsis args before class to pointer to class conversion (PR c++/84076)

[Jason Merrill]

On Thu, Mar 8, 2018 at 1:08 PM, Jakub Jelinek  wrote:
> The reporter complains that -Wformat incorrectly reports std::string* passed
> to "%s" format rather than std::string, which is what the user did.
>
> This transformation of non-trivial copy init or dtor classes in ellipsis is
> done by convert_arg_to_ellipsis; that function does many changes and all
> but this one look desirable for the -Wnonnull/-Wformat/-Wsentinel/-Wrestrict
> warnings.  We prepare a special argument vector in any case, so this patch
> just arranges to undo what convert_arg_to_ellipsis did for the classes.
> I think -Wnonnull shouldn't care, because when passing such a class by
> value, it will be non-NULL (and -Wnonnull looks only for literal NULLs
> anyway), -Wrestrict only cares about named arguments and -Wsentinel only
> cares about NULL arguments passed to ellipsis.

I notice that convert_arg_to_ellipsis generates a pointer-typed
expression, whereas convert_for_arg_passing generates a reference.
Does correcting that inconsistency help?
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f83d51f3457..617ce18f8cd 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7209,7 +7209,7 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t complain)
 		 "passing objects of non-trivially-copyable "
 		 "type %q#T through %<...%> is conditionally supported",
 		 arg_type);
-	  return cp_build_addr_expr (arg, complain);
+	  return build1 (ADDR_EXPR, build_reference_type (arg_type), arg);
 	}
   /* Build up a real lvalue-to-rvalue conversion in case the
 	 copy constructor is trivial but not callable.  */

Re: [C++ PATCH] Avoid -Wunused-function warning when a static function is only used from uninstantiated template (PR c++/80598)

[Jason Merrill]

OK.

On Thu, Mar 8, 2018 at 12:53 PM, Jakub Jelinek  wrote:
> On Thu, Mar 08, 2018 at 10:08:20AM -0500, Jason Merrill wrote:
>> On Wed, Mar 7, 2018 at 5:19 PM, Jakub Jelinek  wrote:
>> > This testcase regressed when the mark_used call in finish_id_expression
>> > has been guarded with if (done).  Wonder if we can't just mark it TREE_USED
>> > otherwise for the benefit of -Wunused-function and leave it
>> > non-DECL_ODR_USED as it should.  Or do we want to mark it TREE_USED
>> > elsewhere?
>>
>> Probably in the processing_template_decl block near the top of 
>> build_over_call.
>
> This works too.  Ok for trunk then (passed bootstrap/regtest on x86_64-linux
> and i686-linux)?
>
> 2018-03-08  Jason Merrill  
> Jakub Jelinek  
>
> PR c++/80598
> * call.c (build_over_call): In templates set TREE_USED (first_fn) when
> not calling mark_used for the benefit of -Wunused-function warning.
>
> * g++.dg/warn/Wunused-function4.C: New test.
>
> --- gcc/cp/call.c.jj2018-03-08 10:58:58.157373982 +0100
> +++ gcc/cp/call.c   2018-03-08 16:18:19.897340581 +0100
> @@ -7634,6 +7634,10 @@ build_over_call (struct z_candidate *can
>
>if (undeduced_auto_decl (fn))
> mark_used (fn, complain);
> +  else
> +   /* Otherwise set TREE_USED for the benefit of -Wunused-function.
> +  See PR80598.  */
> +   TREE_USED (fn) = 1;
>
>return_type = TREE_TYPE (TREE_TYPE (fn));
>nargs = vec_safe_length (args);
> --- gcc/testsuite/g++.dg/warn/Wunused-function4.C.jj2018-03-08 
> 16:16:23.756274559 +0100
> +++ gcc/testsuite/g++.dg/warn/Wunused-function4.C   2018-03-08 
> 16:16:23.756274559 +0100
> @@ -0,0 +1,21 @@
> +// PR c++/80598
> +// { dg-do compile }
> +// { dg-options "-Wunused-function" }
> +
> +static void
> +foo () // { dg-bogus "defined but not used" }
> +{
> +}
> +
> +static void
> +bar () // { dg-warning "defined but not used" }
> +{
> +}
> +
> +template 
> +int
> +baz (T x)
> +{
> +  foo ();
> +  return 0;
> +}
>
>
> Jakub

Re: [C++ PATCH] Don't redefine __* builtins (PR c++/84724)

[Jason Merrill]

On Thu, Mar 8, 2018 at 1:01 PM, Jakub Jelinek  wrote:
> The C FE just warns and doesn't override builtins, but C++ FE
> on say int __builtin_trap (); will override the builtin, so later
> builtin_decl_explicit will return the bogus user function which e.g.
> doesn't have any merged attributes, can have different arguments or
> return type etc.
>
> This patch prevents that; generally the builtins we want to override
> are the DECL_ANTICIPATED which we handle properly earlier.
>
> The testcase in the PR ICEs not because of the argument mismatch (there is
> none in this case) or return value mismatch (because nothing cares about the
> return value), but because the new decl lacks noreturn attribute and GCC
> relies on builtin_decl_explicit (BUILT_IN_TRAP) to be really noreturn.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Or shall we error on these, or ignore the name checks and just
> if (DECL_BUILT_IN (olddecl)) return NULL_TREE;, something else?

Seems like returning NULL_TREE means that we overload the built-in,
which also seems undesirable; what if we return olddecl unmodified?
It would also be good to improve the diagnostic to say that we're
ignoring the declaration.  Perhaps as a permerror.

Jason

Re: [PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

[Jeff Law]

On 03/08/2018 11:19 AM, Jakub Jelinek wrote:
> Hi!
> 
> We have many loops that use CONSTRAINT_LEN to skip over various constraint
> characters, but we assume the constraints have valid length and don't walk
> the individual characters to double check this.
> 
> If that is not the case, when e.g. 2 character constraint starting letter
> is followed by '\0', we'd reject it early (during vregs pass, through
> asm_operand_ok).  The PR has different testcase (that fails randomly based
> on ASLR), where a 2 character constraint starting letter is followed by ',',
> and several spots expect that not to happen (they count number of
> alternatives and then for each alternative walk with skipping CONSTRAINT_LEN
> characters).
> 
> This patch diagnoses this problematic case early as well.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-03-08  Jakub Jelinek  
> 
>   PR inline-asm/84742
>   * recog.c (asm_operand_ok): Return 0 if multi-character constraint
>   has ',' character inside of it.
> 
>   * gcc.target/i386/pr84742-1.c: New test.
>   * gcc.target/i386/pr84742-2.c: New test.
OK.
jeff

[C++ PATCH] For -Wformat purposes use ellipsis args before class to pointer to class conversion (PR c++/84076)

[Jakub Jelinek]

Hi!

The reporter complains that -Wformat incorrectly reports std::string* passed
to "%s" format rather than std::string, which is what the user did.

This transformation of non-trivial copy init or dtor classes in ellipsis is
done by convert_arg_to_ellipsis; that function does many changes and all
but this one look desirable for the -Wnonnull/-Wformat/-Wsentinel/-Wrestrict
warnings.  We prepare a special argument vector in any case, so this patch
just arranges to undo what convert_arg_to_ellipsis did for the classes.
I think -Wnonnull shouldn't care, because when passing such a class by
value, it will be non-NULL (and -Wnonnull looks only for literal NULLs
anyway), -Wrestrict only cares about named arguments and -Wsentinel only
cares about NULL arguments passed to ellipsis.

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

2018-03-08  Jakub Jelinek  

PR c++/84076
* call.c (build_over_call): For purposes of check_function_arguments,
undo convert_arg_to_ellipsis passing of classes with non-trivial
copy ctor or dtor by invisible reference.

* g++.dg/warn/Wformat-2.C: New test.

--- gcc/cp/call.c.jj2018-03-07 22:51:58.698478669 +0100
+++ gcc/cp/call.c   2018-03-08 10:58:58.157373982 +0100
@@ -7967,6 +7967,8 @@ build_over_call (struct z_candidate *can
 }
 
   /* Ellipsis */
+  int ellipsis_first = j;
+  unsigned ellipsis_bias = arg_index - j;
   int magic = magic_varargs_p (fn);
   for (; arg_index < vec_safe_length (args); ++arg_index)
 {
@@ -8014,7 +8016,22 @@ build_over_call (struct z_candidate *can
   tree *fargs = (!nargs ? argarray
: (tree *) alloca (nargs * sizeof (tree)));
   for (j = 0; j < nargs; j++)
-   fargs[j] = maybe_constant_value (argarray[j]);
+   {
+ /* For the purposes of check_function_arguments, undo the implicit
+passing of classes with non-trivial copy ctor or dtor in ellipsis
+by invisible reference.  */
+ if (j >= ellipsis_first && POINTER_TYPE_P (TREE_TYPE (argarray[j])))
+   {
+ tree orig_type = TREE_TYPE ((*args)[ellipsis_bias + j]);
+ if (type_has_nontrivial_copy_init (orig_type)
+ || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (orig_type))
+   {
+ fargs[j] = (*args)[ellipsis_bias + j];
+ continue;
+   }
+   }
+ fargs[j] = maybe_constant_value (argarray[j]);
+   }
 
   warned_p = check_function_arguments (input_location, fn, TREE_TYPE (fn),
   nargs, fargs, NULL);
--- gcc/testsuite/g++.dg/warn/Wformat-2.C.jj2018-03-08 11:05:27.269422301 
+0100
+++ gcc/testsuite/g++.dg/warn/Wformat-2.C   2018-03-08 11:04:52.915418031 
+0100
@@ -0,0 +1,17 @@
+// PR c++/84076
+// { dg-do compile }
+// { dg-options "-Wformat" }
+
+struct S { ~S (); };
+struct T { T (); T (const T &); };
+
+void
+foo ()
+{
+  S s;
+  T t;
+  __builtin_printf ("%s\n", s);// { dg-warning "format '%s' expects 
argument of type 'char\\*', but argument 2 has type 'S'" }
+  __builtin_printf ("%s\n", t);// { dg-warning "format '%s' expects 
argument of type 'char\\*', but argument 2 has type 'T'" }
+  __builtin_printf ("%s\n", &s);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'S\\*'" }
+  __builtin_printf ("%s\n", &t);// { dg-warning "format '%s' expects argument 
of type 'char\\*', but argument 2 has type 'T\\*'" }
+}

Jakub

[C++ PATCH] Don't redefine __* builtins (PR c++/84724)

[Jakub Jelinek]

Hi!

The C FE just warns and doesn't override builtins, but C++ FE
on say int __builtin_trap (); will override the builtin, so later
builtin_decl_explicit will return the bogus user function which e.g.
doesn't have any merged attributes, can have different arguments or
return type etc.

This patch prevents that; generally the builtins we want to override
are the DECL_ANTICIPATED which we handle properly earlier.

The testcase in the PR ICEs not because of the argument mismatch (there is
none in this case) or return value mismatch (because nothing cares about the
return value), but because the new decl lacks noreturn attribute and GCC
relies on builtin_decl_explicit (BUILT_IN_TRAP) to be really noreturn.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or shall we error on these, or ignore the name checks and just
if (DECL_BUILT_IN (olddecl)) return NULL_TREE;, something else?

2018-03-08  Jakub Jelinek  

PR c++/84724
* decl.c (duplicate_decls): Don't override __* prefixed builtins
except for __[^b]*_chk.

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

--- gcc/cp/decl.c.jj2018-03-05 17:23:45.901130856 +0100
+++ gcc/cp/decl.c   2018-03-08 10:28:55.574179119 +0100
@@ -1578,6 +1578,28 @@ next_arg:;
  DECL_BUILT_IN (olddecl)
  ? G_("shadowing built-in function %q#D")
  : G_("shadowing library function %q#D"), olddecl);
+ /* Don't really override olddecl for __* prefixed builtins
+except for __[^b]*_chk, the compiler might be using those
+explicitly.  */
+ if (DECL_BUILT_IN (olddecl))
+   {
+ tree id = DECL_NAME (olddecl);
+ const char *name = IDENTIFIER_POINTER (id);
+
+ if (name[0] == '_' && name[1] == '_')
+   {
+ if (strncmp (name + 2, "builtin_",
+  strlen ("builtin_")) == 0)
+   return NULL_TREE;
+
+ size_t len = strlen (name);
+
+ if (len <= strlen ("___chk")
+ || memcmp (name + len - strlen ("_chk"),
+"_chk", strlen ("_chk") + 1) != 0)
+   return NULL_TREE;
+   }
+   }
}
  else
/* Discard the old built-in function.  */
--- gcc/testsuite/g++.dg/ext/pr84724.C.jj   2018-03-08 10:31:03.683183914 
+0100
+++ gcc/testsuite/g++.dg/ext/pr84724.C  2018-03-08 10:30:45.489183233 +0100
@@ -0,0 +1,13 @@
+// PR c++/84724
+// { dg-do compile }
+// { dg-options "-O3 -fpermissive" }
+
+int __builtin_trap (); // { dg-warning "ambiguates built-in 
declaration" }
+
+int
+foo ()
+{
+  int b;
+  int c (&b);  // { dg-warning "invalid conversion from" }
+  return b %= b ? c : 0;
+}

Jakub

[PATCH] Fix dwarf2out regression introduced with LVUs (PR debug/84456)

[Jakub Jelinek]

Hi!

GCC 7 and earlier had in this spot
  if (list && loc_list->first->next)
gen_llsym (list);
where we wanted to force loclist if we've seen more than one
NOTE_INSN_VAR_LOCATION for the decl, which means it is not possible to use
a block form DW_AT_location.

Alex has changed this to maybe_gen_llsym (list) call, which does:
  if (!list || (!list->dw_loc_next && !loc_list_has_views (list)))
return;
   
  gen_llsym (list);
This matches what the other caller of gen_llsym did:
  if (list && list->dw_loc_next)
gen_llsym (list);
but not the dw_loc_list spot.  The difference between the two is
(when -gno-variable-location-views) that maybe_gen_llsym will not force
loclist form if we transform 2+ NOTE_INSN_VAR_LOCATION notes into a single
defined location expression, which can happen e.g. when the first
note is some usable location and the second one is .
In that case we must use loclist to force the variable to be 
in the second part of the function, because the first DWARF expression would
give wrong results there.

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

2018-03-08  Jakub Jelinek  

PR debug/84456
* dwarf2out.c (dw_loc_list): If list && loc_list->first->next, call
gen_llsym, otherwise call maybe_gen_llsym.

--- gcc/dwarf2out.c.jj  2018-03-02 00:15:54.704780976 +0100
+++ gcc/dwarf2out.c 2018-03-08 12:54:01.794054675 +0100
@@ -17076,7 +17076,10 @@ dw_loc_list (var_loc_list *loc_list, tre
  representable, we don't want to pretend a single entry that was
  applies to the entire scope in which the variable is
  available.  */
-  maybe_gen_llsym (list);
+  if (list && loc_list->first->next)
+gen_llsym (list);
+  else
+maybe_gen_llsym (list);
 
   return list;
 }

Jakub

[PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

[Jakub Jelinek]

Hi!

We have many loops that use CONSTRAINT_LEN to skip over various constraint
characters, but we assume the constraints have valid length and don't walk
the individual characters to double check this.

If that is not the case, when e.g. 2 character constraint starting letter
is followed by '\0', we'd reject it early (during vregs pass, through
asm_operand_ok).  The PR has different testcase (that fails randomly based
on ASLR), where a 2 character constraint starting letter is followed by ',',
and several spots expect that not to happen (they count number of
alternatives and then for each alternative walk with skipping CONSTRAINT_LEN
characters).

This patch diagnoses this problematic case early as well.

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

2018-03-08  Jakub Jelinek  

PR inline-asm/84742
* recog.c (asm_operand_ok): Return 0 if multi-character constraint
has ',' character inside of it.

* gcc.target/i386/pr84742-1.c: New test.
* gcc.target/i386/pr84742-2.c: New test.

--- gcc/recog.c.jj  2018-01-16 09:53:47.0 +0100
+++ gcc/recog.c 2018-03-08 14:04:35.889274871 +0100
@@ -1825,7 +1825,7 @@ asm_operand_ok (rtx op, const char *cons
   len = CONSTRAINT_LEN (c, constraint);
   do
constraint++;
-  while (--len && *constraint);
+  while (--len && *constraint && *constraint != ',');
   if (len)
return 0;
 }
--- gcc/testsuite/gcc.target/i386/pr84742-1.c.jj2018-03-08 
14:11:20.155463943 +0100
+++ gcc/testsuite/gcc.target/i386/pr84742-1.c   2018-03-08 14:12:28.453495882 
+0100
@@ -0,0 +1,10 @@
+/* PR inline-asm/84742 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void 
+foo ()
+{
+  char b = 1;
+  asm volatile ("" : "+T,Y" (b));  /* { dg-error "impossible constraint in 
'asm'" } */
+}
--- gcc/testsuite/gcc.target/i386/pr84742-2.c.jj2018-03-08 
14:12:37.205499976 +0100
+++ gcc/testsuite/gcc.target/i386/pr84742-2.c   2018-03-08 14:12:52.150506968 
+0100
@@ -0,0 +1,10 @@
+/* PR inline-asm/84742 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void 
+foo ()
+{
+  char b = 1;
+  asm volatile ("" : "+gT,m" (b)); /* { dg-error "impossible constraint in 
'asm'" } */
+}

Jakub

Re: Fix some _GLIBCXX_DEBUG pretty printer errors

[Jonathan Wakely]

This caused a new regression for:

  std::forward_list flst;
  std::forward_list::iterator flstiter0;
// { dg-final { note-test flstiter0 {non-dereferenceable iterator for
std::forward_list}} }


$1 = {_M_node = 0x0}
got: $1 = {_M_node = 0x0}
FAIL: libstdc++-prettyprinters/debug_cxx11.cc print flstiter0

Re: [C++ Patch/RFC] PR 71169 ("[7/8 Regression] ICE on invalid C++ code in pop_nested_class"), PR 71832 and more

[Paolo Carlini]

Hi again,

On 07/03/2018 21:49, Paolo Carlini wrote:
... If you ask my opinion, at the moment I still believe that the best 
solution would be doing something at parsing time, save the 
information, in a more elegant way, maybe adding a special "erroneous 
TREE_VEC" flag to the TREE_VECs. I don't know exactly. Even better a 
unique flag for all the template parameter lists of each class.
Just to explain more *concretely* what I had in mind, I quickly hacked 
the below, which would be a *minimal* implementation of my idea. It 
should be also possible to consolidate the flags of the various 
TMPL_ARGS_LEVELs to the flag of the TREE_VEC returned by TI_ARGS 
(get_template_info). That would be fantastic: ideally I would like to 
see an O(0) any_erroneous_template_args_p. Maybe we can do that when we 
use SET_TMPL_ARGS_LEVEL? Probably it would take you 5 mins to implement 
all of that. Or, I was thinking, something completely different, instead 
of fiddling with TREE_VECs, have something in DECL_TEMPLATE_INFO? (see 
again my remark about the 5 mins ;)


Paolo.

//
Index: cp-tree.h
===
--- cp-tree.h	(revision 258355)
+++ cp-tree.h	(working copy)
@@ -592,6 +592,8 @@ struct GTY(()) ptrmem_cst {
 };
 typedef struct ptrmem_cst * ptrmem_cst_t;
 
+#define ERRONEOUS_TREE_VEC(NODE) ((NODE)->base.u.bits.lang_flag_0)
+
 #define CLEANUP_P(NODE)		TREE_LANG_FLAG_0 (TRY_BLOCK_CHECK (NODE))
 
 #define BIND_EXPR_TRY_BLOCK(NODE) \
@@ -6558,6 +6560,7 @@ extern int processing_template_parmlist;
 extern bool dependent_type_p			(tree);
 extern bool dependent_scope_p			(tree);
 extern bool any_dependent_template_arguments_p  (const_tree);
+extern bool any_erroneous_template_args_p	(const_tree);
 extern bool dependent_template_p		(tree);
 extern bool dependent_template_id_p		(tree, tree);
 extern bool type_dependent_expression_p		(tree);
Index: parser.c
===
--- parser.c	(revision 258355)
+++ parser.c	(working copy)
@@ -22682,6 +22682,8 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   FOR_EACH_VEC_SAFE_ELT (unparsed_funs_with_default_args, ix, e)
 	{
 	  decl = e->decl;
+	  if (any_erroneous_template_args_p (decl))
+	continue;
 	  /* If there are default arguments that have not yet been processed,
 	 take care of them now.  */
 	  if (class_type != e->class_type)
@@ -22704,6 +22706,8 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   save_ccr = current_class_ref;
   FOR_EACH_VEC_SAFE_ELT (unparsed_nsdmis, ix, decl)
 	{
+	  if (any_erroneous_template_args_p (decl))
+	continue;
 	  if (class_type != DECL_CONTEXT (decl))
 	{
 	  if (pushed_scope)
@@ -27642,6 +27646,9 @@ cp_parser_late_parsing_for_member (cp_parser* pars
   if (DECL_FUNCTION_TEMPLATE_P (member_function))
 member_function = DECL_TEMPLATE_RESULT (member_function);
 
+  if (any_erroneous_template_args_p (member_function))
+return;
+
   /* There should not be any class definitions in progress at this
  point; the bodies of members are only parsed outside of all class
  definitions.  */
Index: pt.c
===
--- pt.c	(revision 258355)
+++ pt.c	(working copy)
@@ -4459,6 +4459,8 @@ end_template_parm_list (tree parms)
 {
   next = TREE_CHAIN (parm);
   TREE_VEC_ELT (saved_parmlist, nparms) = parm;
+  if (error_operand_p (parm))
+	ERRONEOUS_TREE_VEC (saved_parmlist) = true;
   TREE_CHAIN (parm) = NULL_TREE;
 }
 
@@ -25048,6 +25050,42 @@ any_dependent_template_arguments_p (const_tree arg
   return false;
 }
 
+/* Returns true if ARGS contains any errors.  */
+
+bool
+any_erroneous_template_args_p (const_tree args)
+{
+  int i;
+  int j;
+
+  if (args && TREE_CODE (args) != TREE_VEC)
+{
+  if (tree ti = get_template_info (args))
+	args = TI_ARGS (ti);
+  else
+	args = NULL_TREE;
+}
+
+  if (!args)
+return false;
+  if (args == error_mark_node)
+return true;
+
+  for (i = 0; i < TMPL_ARGS_DEPTH (args); ++i)
+{
+  const_tree level = TMPL_ARGS_LEVEL (args, i + 1);
+  if (ERRONEOUS_TREE_VEC (level))
+	return true;
+  /*
+  for (j = 0; j < TREE_VEC_LENGTH (level); ++j)
+	if (error_operand_p (TREE_VEC_ELT (level, j)))
+	  return true;
+  */
+}
+
+  return false;
+}
+
 /* Returns TRUE if the template TMPL is type-dependent.  */
 
 bool

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

[Kyrill Tkachov]

On 02/03/18 17:34, Jeff Law wrote:

On 03/01/2018 08:19 AM, Kyrill Tkachov wrote:

Ping.

Thanks,
Kyrill

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

Ping.

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

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

Thanks everyone for your comments so far.
Kyrill

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

Hi Richard,

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

Thanks for doing this.

Kyrill  Tkachov  writes:

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

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

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

Is this ok?

Thanks,
Kyrill

2018-02-12  Kyrylo Tkachov  

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

2018-02-12  Kyrylo Tkachov  

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

Sorry.  I suspect I dropped this from my inbox when it had the AArch64
marker -- I didn't realize it had a target independent component.

The simplify-rtx bits are fine.  The version in simplify_truncation is
much better than the original in simplify_subreg (which I think needed
to verify that you were looking at the lowpart before optimizing).


Thanks Jeff,

I'd like to ask for approval for the aarch64 parts as well from the maintainers.

Kyrill


jeff

Re: [C++ PATCH] Avoid -Wunused-function warning when a static function is only used from uninstantiated template (PR c++/80598)

[Jason Merrill]

On Wed, Mar 7, 2018 at 5:19 PM, Jakub Jelinek  wrote:
> This testcase regressed when the mark_used call in finish_id_expression
> has been guarded with if (done).  Wonder if we can't just mark it TREE_USED
> otherwise for the benefit of -Wunused-function and leave it
> non-DECL_ODR_USED as it should.  Or do we want to mark it TREE_USED
> elsewhere?

Probably in the processing_template_decl block near the top of build_over_call.

Jason

Re: [PATCH] __builtin_early_constant_p (PR c++/78420)

[Jason Merrill]

On Wed, Mar 7, 2018 at 5:04 PM, Jakub Jelinek  wrote:
> -  /* Don't fold __builtin_constant_p within a constexpr function.  */
> -  bool bi_const_p = (DECL_FUNCTION_CODE (fun) == BUILT_IN_CONSTANT_P);
> +  /* Don't fold __builtin_{,early_}constant_p within a constexpr function.  
> */
> +  bool bi_const_p
> += (DECL_FUNCTION_CODE (fun) == BUILT_IN_CONSTANT_P
> +   || DECL_FUNCTION_CODE (fun) == BUILT_IN_EARLY_CONSTANT_P);

Let's use DECL_IS_BUILTIN_CONSTANT_P here.  With that change the C++
bits are OK.

Jason

[PATCH] Fix PR84552

[Richard Biener]

The following fixes SCEV follow_copies_to_constant to properly deal
with regions with not up-to-date SSA form as we are presented with
by some passes like for example unrolling or graphite.
follow_copies_to_constant can venture into sibling loops which is
what those passes do not expect -- they rightfully treat those
as unrelated and thus not important to have correct IL in.

So here's another name_registered_for_update_p () workaround for this.

Eventually a fix would be to simply make update_ssa cheaper (work
on SESE regions).  Those passes delay update-ssa because else they'd be
quadratic.

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

Richard.

2018-03-08  Richard Biener  

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

* gcc.dg/graphite/pr84552.c: New testcase.

Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 258359)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -280,6 +280,7 @@ along with GCC; see the file COPYING3.
 #include "params.h"
 #include "tree-ssa-propagate.h"
 #include "gimple-fold.h"
+#include "tree-into-ssa.h"
 
 static tree analyze_scalar_evolution_1 (struct loop *, tree);
 static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
@@ -1540,7 +1541,10 @@ static tree
 follow_copies_to_constant (tree var)
 {
   tree res = var;
-  while (TREE_CODE (res) == SSA_NAME)
+  while (TREE_CODE (res) == SSA_NAME
+/* We face not updated SSA form in multiple places and this walk
+   may end up in sibling loops so we have to guard it.  */
+&& !name_registered_for_update_p (res))
 {
   gimple *def = SSA_NAME_DEF_STMT (res);
   if (gphi *phi = dyn_cast  (def))
Index: gcc/testsuite/gcc.dg/graphite/pr84552.c
===
--- gcc/testsuite/gcc.dg/graphite/pr84552.c (nonexistent)
+++ gcc/testsuite/gcc.dg/graphite/pr84552.c (working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre 
-fno-tree-loop-ivcanon" } */
+
+int cx;
+
+int
+e6 (int pj, int xe)
+{
+  for (cx = 0; cx < 2; ++cx)
+while (xe < 1)
+  {
+   for (cx = 0; cx < 2; ++cx)
+ pj *= 2;
+
+   if (cx != 0)
+ goto o3;
+
+   ++xe;
+  }
+
+o3:
+  return pj;
+}

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

[Luis Machado]

On 03/08/2018 10:30 AM, James Greenhalgh wrote:

On Thu, Mar 01, 2018 at 06:45:21PM +, Luis Machado wrote:

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

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


This is OK for trunk now. I'm happy for you to take the risk of the change
in code-gen for qdf24xx if you are.

Thanks,
James



Thanks. There is no risk yet given prefetching is still disabled for 
qdf24xx and will be re-enabled once development reopens.

Re: [PR84620] output symbolic entry_view as data2, not addr

[Jakub Jelinek]

On Thu, Mar 08, 2018 at 06:05:04AM -0300, Alexandre Oliva wrote:
> On Mar  6, 2018, Jakub Jelinek  wrote:
> 
> > I'm afraid I haven't understood yet why we need labels instead of compiler
> > assigned numbers for the views,
> 
> The compiler can't determine points at which the insn address changes
> reliably (or at all).  It's impossible in the general case, considering
> that alignment requests might be fulfilled by an assembler without any
> address change, if the current address was just right, and only the
> assembler would know that.

An upper bound would be fine, count any potential spot where you introduce a
view and if the upper bound fits into 8-bit value, use data1, if into 16-bit
value, use data2, otherwise use data4.

Jakub

Re: [PATCH][AArch64][2/3] PR target/84164: Add ZERO_EXTRACT + LSHIFTRT pattern for BFXIL instruction

[James Greenhalgh]

On Thu, Feb 08, 2018 at 05:10:52PM +, Kyrill Tkachov wrote:
> Hi all,
> 
> This is a followup to the other PR target/84164 patch [1] that fixes the 
> testsuite regression
> gcc.target/aarch64/bfxil_1.c.
> The regression is that with the new subreg+masking simplification we no 
> longer match the
> pattern for BFXIL that has the form:
> (set (zero_extract:DI (reg/v:DI 76 [ a ])
>  (const_int 8 [0x8])
>  (const_int 0 [0]))
>  (zero_extract:DI (reg/v:DI 76 [ a ])
>  (const_int 8 [0x8])
>  (const_int 16 [0x10])))
> 
> This is now instead represented as:
> (set (zero_extract:DI (reg/v:DI 93 [ a ])
>  (const_int 8 [0x8])
>  (const_int 0 [0]))
>  (lshiftrt:DI (reg/v:DI 93 [ a ])
>  (const_int 16 [0x10])))
> 
> As far as I can see the two are equivalent semantically and the LSHIFTRT form 
> is a bit
> simpler, so I think the simplified form is valid, but we have no pattern to 
> match it.
> This patch adds that pattern to catch this form as well.
> This fixes the aforementioned regression and bootstrap and testing on 
> aarch64-none-linux-gnu
> shows no problem.
> 
> Is this ok for trunk if the first patch goes in?

OK.

Thanks,
James

> [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00443.html
> 
> 2018-02-08  Kyrylo Tkachov  
> 
>  PR target/84164
>  * config/aarch64/aarch64.md (*extr_insv_lower_reg_lshiftrt):
>  New pattern.

> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 62a4f8262a316087894aeb555c609fbe75885203..2c6343a363c161ed503ca1ddd752e21b5c941eb8
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -4803,6 +4803,19 @@ (define_insn "*extr_insv_lower_reg"
>[(set_attr "type" "bfm")]
>  )
>  
> +(define_insn "*extr_insv_lower_reg_lshiftrt"
> +  [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
> +   (match_operand 1 "const_int_operand" "n")
> +   (const_int 0))
> + (lshiftrt:GPI (match_operand:GPI 2 "register_operand" "r")
> + (match_operand 3 "const_int_operand" "n")))]
> +  "!(UINTVAL (operands[1]) == 0
> + || (UINTVAL (operands[3]) + UINTVAL (operands[1])
> +  > GET_MODE_BITSIZE (mode)))"
> +  "bfxil\\t%0, %2, %3, %1"
> +  [(set_attr "type" "bfm")]
> +)
> +
>  (define_insn "*_shft_"
>[(set (match_operand:GPI 0 "register_operand" "=r")
>   (ashift:GPI (ANY_EXTEND:GPI

Re: [PATCH][AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

[James Greenhalgh]

On Wed, Mar 07, 2018 at 05:39:41PM +, Kyrill Tkachov wrote:
> Hi all,
> 
> In this wrong-code PR the combine pass ends up moving a CC-using instruction 
> past a *compare_cstore_insn
> insn_and_split. After reload the *compare_cstore_insn splitter ends up 
> generating a SUBS instruction that
> clobbers the condition flags, and things go bad.
> 
> The solution is simple, the *compare_cstore_insn pattern should specify 
> that it clobbers the CC register
> so that combine (or any other pass) does not assume that it can move CC-using 
> patterns across it.
> 
> This patch does that and fixes the testcase.
> 
> The testcase FAILs on GCC 8 only, but the buggy pattern is in GCC 6 onwards, 
> so we should backport this as
> a latent bug fix after it's had some time to bake in trunk.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Ok for trunk and later backports?

OK.

Thanks,
James

> 2018-03-07  Kyrylo Tkachov  
> 
>  PR target/84748
>  * config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
>  as clobbering CC_REGNUM.
> 
> 2018-03-07  Kyrylo Tkachov  
> 
>  PR target/84748
>  * gcc.c-torture/execute/pr84748.c: New test.

Re: [PATCH][AARCH64]Fix immediate alternative of movhf_aarch64 pattern.

[James Greenhalgh]

On Wed, Mar 07, 2018 at 11:23:10AM +, Renlin Li wrote:
> Hi all,
> 
> For the immediate alternative, the constraint checks the operand with HF mode
> while SImode is provided to the output template generation function.
> 
> Before the change, this inconsistency causes an ICE compiling the new test 
> case in the patch.
> 
> 
> aarch64-none-elf regression test Okay. Okay to commit the patch?

OK.

Thanks,
James

> gcc/ChangeLog:
> 
> 2018-03-07  Renlin Li  
> 
>   * config/aarch64/aarch64.md (movhf_aarch64): Fix mode argument to
>   aarch64_output_scalar_simd_mov_immediate.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-03-07  Renlin Li  
> 
>   * gcc.target/aarch64/movi_hf.c: New.
>   * gcc.target/aarch64/f16_mov_immediate_1.c: Update.

> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 5a2a9309a3bbbfad6fcb6db07422d774909f0ba1..391fdd07e52f4d165a0109e3baa82571bafa37de
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -1145,7 +1145,7 @@
> umov\\t%w0, %1.h[0]
> mov\\t%0.h[0], %1.h[0]
> fmov\\t%h0, %1
> -   * return aarch64_output_scalar_simd_mov_immediate (operands[1], SImode);
> +   * return aarch64_output_scalar_simd_mov_immediate (operands[1], HImode);
> ldr\\t%h0, %1
> str\\t%h1, %0
> ldrh\\t%w0, %1
> diff --git a/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c 
> b/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c
> index 
> 1ed3831e139745227487eafa3ccfdc05c99deb34..3d22d225851af653f17e04ce7c7cc65ee1c86172
>  100644
> --- a/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c
> @@ -45,5 +45,5 @@ __fp16 f5 ()
>  }
>  
>  /* { dg-final { scan-assembler-times "mov\tw\[0-9\]+, #?19520"   3 } 
> } */
> -/* { dg-final { scan-assembler-times "movi\tv\[0-9\]+\\\.2s, 0xbc, lsl 8"  1 
> } } */
> -/* { dg-final { scan-assembler-times "movi\tv\[0-9\]+\\\.2s, 0x4c, lsl 8"  1 
> } } */
> +/* { dg-final { scan-assembler-times "movi\tv\[0-9\]+\\\.4h, 0xbc, lsl 8"  1 
> } } */
> +/* { dg-final { scan-assembler-times "movi\tv\[0-9\]+\\\.4h, 0x4c, lsl 8"  1 
> } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/movi_hf.c 
> b/gcc/testsuite/gcc.target/aarch64/movi_hf.c
> new file mode 100644
> index 
> ..9521b9b09c87bd5f19cb6b62b1228bae685d8667
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/movi_hf.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O0 -std=c99" } */
> +
> +__fp16
> +foo ()
> +{
> +  /* { dg-final { scan-assembler "movi\tv\[0-9\]+\.8b" } } */
> +  return 0x1.544p5;
> +}

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

[James Greenhalgh]

On Thu, Mar 01, 2018 at 06:45:21PM +, Luis Machado wrote:
> Falkor's prefetch tuning structure still carries the L2 cache size value from
> early support code. This patch updates it to match the specifications.
> 
> Even though the prefetcher is currently disabled for Falkor, we have a patch
> waiting for GCC development to reopen that re-enables it, so i take it this
> update should be trivial enough to go in before development reopens?

This is OK for trunk now. I'm happy for you to take the risk of the change
in code-gen for qdf24xx if you are.

Thanks,
James

> 2018-03-01  Luis Machado  
> 
>   * config/aarch64/aarch64.c (qdf24xx_prefetch_tune) : Set
>   to 512.
> ---
>  gcc/config/aarch64/aarch64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 2f98a21..5a732b1 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -564,7 +564,7 @@ static const cpu_prefetch_tune qdf24xx_prefetch_tune =
>4, /* num_slots  */
>32,/* l1_cache_size  */
>64,/* l1_cache_line_size  */
> -  1024,  /* l2_cache_size  */
> +  512,   /* l2_cache_size  */
>-1 /* default_opt_level  */
>  };
>  
> -- 
> 2.7.4
> 

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

[Michael Matz]

Hi,

On Thu, 8 Mar 2018, Richard Biener wrote:

> Or re-do the warning?  Since in the other thread about setjmp side-effects
> we concluded that setjmp has to preserve all call-saved regs?

Even worse.  On SPARC setjmp clobbers even more than just call-clobbered 
regs (!).


Ciao,
Michael.

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

[Richard Biener]

On Thu, Mar 8, 2018 at 2:22 PM, Richard Biener
 wrote:
> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz  wrote:
>> Hi,
>>
>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>
>>> On 3/7/18 12:01 AM, Jeff Law wrote:
>>> > I believe so by nature that the setjmp dominates the longjmp sites and
>>> > thus also dominates the dispatcher.  But it's something I want to
>>> > explicitly check before resubmitting.
>>>
>>> Are we sure a setjmp has to dominate its longjmp sites?
>>
>> No, they don't have to dominate.  For lack of better term I used something
>> like "ordered after" in my mails :)
>>
>>> Couldn't you have something like:
>>
>> Yeah, exactly.
>
> So given all the discussion _iff_ we want to change the CFG we generate then
> let's invent a general __builtin_receiver () and lower setjmp to
>
>   setjmp ();
>   res = __builtin_receiver ();
>
> and construct a CFG around that.  Remember that IIRC I added the abnormal
> edges to and from setjmp to inhibit code-motion across it so whatever CFG
> we'll end up with should ensure that there can't be any code-motion 
> optimization
> across the above pair nor "inbetween" it.  The straight-forward
> CFG of, apart from the fallthru from setjmp to the receiver, a abnormal edge
> to the dispatcher from setjmp and an abnormal edge from the dispatcher to
> the receiver would do that trick I think.
>
> I'd rather not do that for GCC 8 though.  So to fix the warning can't we do
> sth else "good" and move the strange warning code from RTL to GIMPLE?
>
> Or re-do the warning?  Since in the other thread about setjmp side-effects
> we concluded that setjmp has to preserve all call-saved regs?  I don't see
> that reflected in regno_clobbered_at_setjmp or its caller -- that is,
> we should only warn for call clobbered and thus caller-saved regs because
> normal return may clobber the spilled values.
>
> Not sure if the PR testcase is amongst the cases fixed by such change.

Ah, slight complication is we warn from IRA but _before_ RA.  Not sure if
there's a place where hardregs are assigned but not yet spilled (and those
hardreg assignments hold in the end) where we can move the warning to.

Richard.

> Richard.
>
>>
>> Ciao,
>> Michael.

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

[Richard Biener]

On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz  wrote:
> Hi,
>
> On Wed, 7 Mar 2018, Peter Bergner wrote:
>
>> On 3/7/18 12:01 AM, Jeff Law wrote:
>> > I believe so by nature that the setjmp dominates the longjmp sites and
>> > thus also dominates the dispatcher.  But it's something I want to
>> > explicitly check before resubmitting.
>>
>> Are we sure a setjmp has to dominate its longjmp sites?
>
> No, they don't have to dominate.  For lack of better term I used something
> like "ordered after" in my mails :)
>
>> Couldn't you have something like:
>
> Yeah, exactly.

So given all the discussion _iff_ we want to change the CFG we generate then
let's invent a general __builtin_receiver () and lower setjmp to

  setjmp ();
  res = __builtin_receiver ();

and construct a CFG around that.  Remember that IIRC I added the abnormal
edges to and from setjmp to inhibit code-motion across it so whatever CFG
we'll end up with should ensure that there can't be any code-motion optimization
across the above pair nor "inbetween" it.  The straight-forward
CFG of, apart from the fallthru from setjmp to the receiver, a abnormal edge
to the dispatcher from setjmp and an abnormal edge from the dispatcher to
the receiver would do that trick I think.

I'd rather not do that for GCC 8 though.  So to fix the warning can't we do
sth else "good" and move the strange warning code from RTL to GIMPLE?

Or re-do the warning?  Since in the other thread about setjmp side-effects
we concluded that setjmp has to preserve all call-saved regs?  I don't see
that reflected in regno_clobbered_at_setjmp or its caller -- that is,
we should only warn for call clobbered and thus caller-saved regs because
normal return may clobber the spilled values.

Not sure if the PR testcase is amongst the cases fixed by such change.

Richard.

>
> Ciao,
> Michael.

Re: [PATCH, rs6000] Fix PR83969: ICE in final_scan_insn, at final.c:2997

[Peter Bergner]

On 3/7/18 6:50 PM, Peter Bergner wrote:
> This passed bootstrap and regtesting on powerpc64-linux, running the
> testsuite in both 32-bit and 64-bit modes with no regressions.
> Ok for trunk?

FYI, this also passed bootstrap and regtesting on powerpc64le-linux
without regressions also.

Peter

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

[Michael Matz]

Hi,

On Wed, 7 Mar 2018, Peter Bergner wrote:

> On 3/7/18 12:01 AM, Jeff Law wrote:
> > I believe so by nature that the setjmp dominates the longjmp sites and
> > thus also dominates the dispatcher.  But it's something I want to
> > explicitly check before resubmitting.
> 
> Are we sure a setjmp has to dominate its longjmp sites?

No, they don't have to dominate.  For lack of better term I used something 
like "ordered after" in my mails :)

> Couldn't you have something like:

Yeah, exactly.


Ciao,
Michael.

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

[Luis Machado]

On 03/01/2018 03:45 PM, Luis Machado wrote:

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

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

Thanks,
Luis

2018-03-01  Luis Machado  

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

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



Ping?

Re: [PATCH 2/2] ifcvt: unfixed testcase for 2nd issue within PR tree-optimization/84178

[Richard Biener]

On Wed, Mar 7, 2018 at 7:56 PM, David Malcolm  wrote:
> Here's a testcase for the 2nd issue within PR tree-optimization/84178.
>
> With -03 -fno-tree-forwprop, trunk and gcc 7 segfault inside update_ssa
> when called from version_loop_for_if_conversion when a loop is versioned.
>
> During loop_version, some blocks are duplicated, and this can duplicate
> SSA names, leading to the duplicated SSA names being added to
> tree-into-ssa.c's old_ssa_names.
>
> For example, _117 is an SSA name defined in one of these to-be-duplicated
> blocks, and hence is added to old_ssa_names when duplicated.
>
> One of the BBs has this gimplified predicate (again, these stmts are *not*
> yet in a BB):
>   _173 = h4.1_112 != 0;
>   _171 = (signed char) _117;
>   _172 = _171 >= 0;
>   _170 = ~_172;
>   _169 = _170 & _173;
>
> Note the reference to SSA name _117 in the above.
>
> When update_ssa runs later on in version_loop_for_if_conversion,
> SSA name _117 is in the old_ssa_names bitmap, and thus has
> prepare_use_sites_for called on it:
>
> 2771  /* If an old name is in NAMES_TO_RELEASE, we cannot remove it from
> 2772 OLD_SSA_NAMES, but we have to ignore its definition site.  */
> 2773  EXECUTE_IF_SET_IN_BITMAP (old_ssa_names, 0, i, sbi)
> 2774{
> 2775  if (names_to_release == NULL || !bitmap_bit_p 
> (names_to_release, i))
> 2776prepare_def_site_for (ssa_name (i), insert_phi_p);
> 2777  prepare_use_sites_for (ssa_name (i), insert_phi_p);
> 2778}
>
> prepare_use_sites_for iterates over the immediate users, which includes
> the:
>   _171 = (signed char) _117;
> in the gimplified predicate.
>
> This tried to call "mark_block_for_update" on the BB of this def_stmt,
> leading to a read-through-NULL segfault, since this statement isn't in a
> BB yet.
>
> In an earlier attempt to fix this I wrote:
>> The following patch fixes the 2nd ICE by inserting the gimplified predicates
>> earlier: immediately before the possible version_loop_for_if_conversion,
>> rather than within combine_blocks.  That way they're in their BBs before
>> we attempt any further manipulation of the CFG.
>
> to which Richard responded:
>> Hum, but that will alter both copies of the loops, no?  I think the fix is
>> to instead delay the update_ssa call to _after_ combine_blocks ()
>> (and remember if it is necessary just in case we didn't version).
>
> I attempted this, but didn't come up with something that worked; so am
> posting this in the hope that Richard (or someone else) can finish the
> fix.

Preliminary testing shows the attached works.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2018-03-08  Richard Biener  

PR tree-optimization/84178
* tree-if-conv.c (combine_blocks): Move insert_gimplified_predicates
to caller.
(version_loop_for_if_conversion): Delay update_ssa call.
(tree_if_conversion): Delay update_ssa until after predicate
insertion.

* gcc.dg/torture/pr84178-2.c: New testcase.


> gcc/testsuite/ChangeLog:
> PR tree-optimization/84178
> * gcc.c-torture/compile/pr84178-2.c: New test.
> ---
>  gcc/testsuite/gcc.c-torture/compile/pr84178-2.c | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr84178-2.c
>
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c
> new file mode 100644
> index 000..b2548e9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr84178-2.c
> @@ -0,0 +1,18 @@
> +/* { dg-options "-fno-tree-forwprop" } */
> +
> +int zy, h4;
> +
> +void
> +r8 (long int mu, int *jr, int *fi, short int dv)
> +{
> +  do
> +{
> +  int tx;
> +
> +  tx = !!h4 ? (zy + h4) : 1;
> +  mu = tx;
> +  *jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) + 
> *fi;
> +} while (*jr == 0);
> +
> +  r8 (mu, jr, fi, 1);
> +}
> --
> 1.8.5.3
>


fix-pr84178
Description: Binary data

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

[Martin Liška]

PING^1

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

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Martin Liška]

On 03/08/2018 10:15 AM, Martin Liška wrote:
> On 03/02/2018 05:38 PM, Thomas Schwinge wrote:
>> Hi!
>>
>> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
>>> This fixes detection of ifunc target capability.
>>> I'm going to install the patch.
>>
>> You could also just have approved the patch I had sent two months before:
>> .
>> ;-)
> 
> Hello.
> 
> Sorry for overlooking your patch. It's better to not return 0. Thomas
> please install the patch, it's obvious fix.

Looks Thomas is out of office, thus I installed his patch as r258362.

Martin

> 
> Thanks,
> Martin
> 
>>
>> One remark:
>>
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
>>> extern "C" {
>>> #endif
>>> typedef void F (void);
>>> -   F* g (void) {}
>>> +   F* g (void) { return 0; }
>>> void f () __attribute__ ((ifunc ("g")));
>>> #ifdef __cplusplus
>>> }
>>
>> Is it OK to "return 0" from this ifunc handler, or might some analysis in
>> GCC trip over that (at some later point)?  In my patch, I returned the
>> address of an "extern" function.
>>
>>
>> Grüße
>>  Thomas
>>
> 

[PATCH] Fix PR84746

[Richard Biener]

The following fixes a bug where we lookup simplified expression results
in the ANTIC_IN sets but we've simplified aready translated expressions
so that lookup is bogus - we have to lookup in ANTIC_OUT instead.
The following does this and makes sure the (partially constructed) set
is available.

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

Richard.

2018-03-08  Richard Biener  

* tree-ssa-pre.c (find_leader_in_sets): Deal with SET1 being NULL.
(phi_translate): Pass in destination ANTIC_OUT set.
(phi_translate_1): Likewise.  For a simplified result lookup
a leader in ANTIC_OUT and AVAIL_OUT, not the ANTIC_IN sets.
(phi_translate_set): Adjust.
(do_pre_regular_insertion): Likewise.
(do_pre_partial_partial_insertion): Likewise.

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

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 258317)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -1226,9 +1226,10 @@ static inline pre_expr
 find_leader_in_sets (unsigned int val, bitmap_set_t set1, bitmap_set_t set2,
 bitmap_set_t set3 = NULL)
 {
-  pre_expr result;
+  pre_expr result = NULL;
 
-  result = bitmap_find_leader (set1, val);
+  if (set1)
+result = bitmap_find_leader (set1, val);
   if (!result && set2)
 result = bitmap_find_leader (set2, val);
   if (!result && set3)
@@ -1332,14 +1333,15 @@ get_representative_for (const pre_expr e
 
 
 static pre_expr
-phi_translate (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e);
+phi_translate (bitmap_set_t, pre_expr, bitmap_set_t, bitmap_set_t, edge);
 
 /* Translate EXPR using phis in PHIBLOCK, so that it has the values of
the phis in PRED.  Return NULL if we can't find a leader for each part
of the translated expression.  */
 
 static pre_expr
-phi_translate_1 (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e)
+phi_translate_1 (bitmap_set_t dest,
+pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e)
 {
   basic_block pred = e->src;
   basic_block phiblock = e->dest;
@@ -1363,10 +1365,11 @@ phi_translate_1 (pre_expr expr, bitmap_s
 pre_expr leader, result;
unsigned int op_val_id = VN_INFO (newnary->op[i])->value_id;
leader = find_leader_in_sets (op_val_id, set1, set2);
-   result = phi_translate (leader, set1, set2, e);
+   result = phi_translate (dest, leader, set1, set2, e);
if (result && result != leader)
- /* Force a leader as well as we are simplifying this
-expression.  */
+ /* If op has a leader in the sets we translate make
+sure to use the value of the translated expression.
+We might need a new representative for that.  */
  newnary->op[i] = get_representative_for (result, pred);
else if (!result)
  return NULL;
@@ -1399,7 +1402,12 @@ phi_translate_1 (pre_expr expr, bitmap_s
else
  {
unsigned value_id = get_expr_value_id (constant);
-   constant = find_leader_in_sets (value_id, set1, set2,
+   /* We want a leader in ANTIC_OUT or AVAIL_OUT here.
+  dest has what we computed into ANTIC_OUT sofar
+  so pick from that - since topological sorting
+  by sorted_array_from_bitmap_set isn't perfect
+  we may lose some cases here.  */
+   constant = find_leader_in_sets (value_id, dest,
AVAIL_OUT (pred));
if (constant)
  return constant;
@@ -1485,7 +1493,7 @@ phi_translate_1 (pre_expr expr, bitmap_s
  }
op_val_id = VN_INFO (op[n])->value_id;
leader = find_leader_in_sets (op_val_id, set1, set2);
-   opresult = phi_translate (leader, set1, set2, e);
+   opresult = phi_translate (dest, leader, set1, set2, e);
if (opresult && opresult != leader)
  {
tree name = get_representative_for (opresult);
@@ -1635,7 +1643,8 @@ phi_translate_1 (pre_expr expr, bitmap_s
 /* Wrapper around phi_translate_1 providing caching functionality.  */
 
 static pre_expr
-phi_translate (pre_expr expr, bitmap_set_t set1, bitmap_set_t set2, edge e)
+phi_translate (bitmap_set_t dest, pre_expr expr,
+  bitmap_set_t set1, bitmap_set_t set2, edge e)
 {
   expr_pred_trans_t slot = NULL;
   pre_expr phitrans;
@@ -1661,7 +1670,7 @@ phi_translate (pre_expr expr, bitmap_set
 }
 
   /* Translate.  */
-  phitrans = phi_translate_1 (expr, set1, set2, e);
+  phitrans = phi_translate_1 (dest, expr, set1, s

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Martin Liška]

On 03/02/2018 05:38 PM, Thomas Schwinge wrote:
> Hi!
> 
> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
>> This fixes detection of ifunc target capability.
>> I'm going to install the patch.
> 
> You could also just have approved the patch I had sent two months before:
> .
> ;-)

Hello.

Sorry for overlooking your patch. It's better to not return 0. Thomas
please install the patch, it's obvious fix.

Thanks,
Martin

> 
> One remark:
> 
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
>>  extern "C" {
>>  #endif
>>  typedef void F (void);
>> -F* g (void) {}
>> +F* g (void) { return 0; }
>>  void f () __attribute__ ((ifunc ("g")));
>>  #ifdef __cplusplus
>>  }
> 
> Is it OK to "return 0" from this ifunc handler, or might some analysis in
> GCC trip over that (at some later point)?  In my patch, I returned the
> address of an "extern" function.
> 
> 
> Grüße
>  Thomas
> 

Re: [PR84620] output symbolic entry_view as data2, not addr

[Alexandre Oliva]

On Mar  6, 2018, Jakub Jelinek  wrote:

> I'm afraid I haven't understood yet why we need labels instead of compiler
> assigned numbers for the views,

The compiler can't determine points at which the insn address changes
reliably (or at all).  It's impossible in the general case, considering
that alignment requests might be fulfilled by an assembler without any
address change, if the current address was just right, and only the
assembler would know that.

> Can the compiler count how many different view labels it has produced or
> will produce

It can do that, yeah.  We could even count the max estimated view
number, which, in the absence of view reset points (the compiler has
that disabled except on ports that define a target hook to enable it,
and none do), is equivalent to the number of views.  I guess this is a
reasonable upper bound to use, in the absence of a closer estimate.
I'll give it a shot.


> Or what will exactly happen if you use too small form?
> Silent wrong-debug, assembler error, something else?

>> the assembler will warn if it truncates a view number

Wrong-debug, but not silent.  Not an error either.


>> Why do you say it would be terribly expensive to let the assembler compute
>> offsets in .debug_info?

> Because people are already complaining about slow assembly times of debug
> info, and offsets are used pretty much everywhere in .debug_info.

They're used pretty much everywhere in code as well; I suspect we have a
lot more labels in code than we'd have within debug info.

As to complaints...  are those recent, possibly related with
https://sourceware.org/bugzilla/show_bug.cgi?id=22870
or were the complains already in place before LVU went in?

> With some assemblers that don't allow .uleb128/.sleb128 that is impossible
> to do, with others you'd need to emit a new label before every DIE and all
> DW_AT_type and many others would need to use .LD123456-.LD1092456 kind of
> expressions which assembler would need to parse and resolve
> (DW_FORM_ref{1,2,4,8,_udata}).

Assemblers determine addresses for labels all the time, and surely
computing offsets between them, when they're in the same section, can't
be that expensive.  Well, with relaxable frags whose sizes depend on the
offsets, it could in theory get expensive indeed, but would it in
practice?


I can see that mandatory [us]leb128 fields could be a problem, but are
there any fields that involve offsets into .debug_info, and that must be
represented as [us]leb128?  I don't think so.

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

Re: Add "native" as a valid option value for -march= on arm (PR driver/83193).

[Martin Liška]

PING^1

On 02/22/2018 01:15 PM, Martin Liška wrote:
> On 02/22/2018 11:59 AM, Kyrill Tkachov wrote:
>> Hi Martin,
>>
>> On 22/02/18 08:51, Martin Liška wrote:
>>> On 02/21/2018 10:23 AM, Kyrill Tkachov wrote:
 On arm we also support "native" as a value for -mcpu and -mtune. These are 
 both handled by
 the arm_print_hint_for_cpu_option function in the same file. Can you 
 please add this snippet
 to them as well?
>>> Hi.
>>>
>>> Can you please test for me attached follow up patch?
>>
>> I've bootstrapped and tested this patch on a native and a cross compiler and 
>> confirmed
>> the help string for -mcpu behaves as intended.
>>
>> This patch is ok for trunk.
>> Thanks,
>> Kyrill
> 
> Thanks for review. May I please ask you for taking look at:
> 2b) point in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193#c6
> 
> We should fix it (if possible) for GCC 8 as it's regression.
> 
> Thanks,
> Martin
> 
>>
>>> Thanks,
>>> Martin
>>
> 

Re: [PATCH] avoid warning for memcpy to self (PR 83456)

[Richard Biener]

On Thu, Mar 8, 2018 at 12:01 AM, Martin Sebor  wrote:
> I have become convinced that issuing -Wrestrict in gimple-fold
> for calls to memcpy() where the source pointer is the same as
> the destination causes more trouble than it's worth, especially
> when inlining is involved, as in:
>
>   inline void bar (void *d, void *s, unsigned N)
>   {
> if (s != d)
>   memcpy (d, s, N);
>   }
>
>   void foo (void* src)
>   {
> bar (src, src, 1);
>   }
>
> It seems that there should be a way to teach GCC to avoid
> folding statements in dead blocks (e.g., in a block controlled
> by 'if (0 != 0)' as the one below), and that it might even speed
> up compilation, but in the meantime it leads to false positive
> -Wrestrict warnings.
>
> The attached patch removes this instance of the warning and
> adjusts tests not to expect it.

Ok.

Richard.

> Martin

Re: [PATCH 1/2] tree-if-conv.c: fix ICE seen with -fno-tree-forwprop (PR tree-optimization/84178)

[Richard Biener]

On Wed, Mar 7, 2018 at 7:56 PM, David Malcolm  wrote:
> PR tree-optimization/84178 reports a couple of source files that ICE inside
> ifcvt when compiled with -03 -fno-tree-forwprop (trunk and gcc 7).
>
> Both cases involve problems with ifcvt's per-BB gimplified predicates.
>
> Testcase 1 fails this assertion within release_bb_predicate during cleanup:
>
> 283   if (flag_checking)
> 284 for (gimple_stmt_iterator i = gsi_start (stmts);
> 285  !gsi_end_p (i); gsi_next (&i))
> 286   gcc_assert (! gimple_use_ops (gsi_stmt (i)));
>
> The testcase contains a division in the loop, which leads to
> if_convertible_loop_p returning false (due to gimple_could_trap_p being true
> for the division).  This happens *after* the per-BB gimplified predicates
> have been created in predicate_bbs (loop).
> Hence tree_if_conversion bails out to "cleanup", but the gimplified predicates
> exist and make use of SSA names; for example this conjunction for two BB
> conditions:
>
>   _4 = h4.1_112 != 0;
>   _175 = (signed char) _117;
>   _176 = _175 >= 0;
>   _174 = _4 & _176;
>
> is using SSA names.
>
> This assertion was added in r236498 (aka 
> c3deca2519d97c55876869c57cf11ae1e5c6cf8b):
>
> 2016-05-20  Richard Biener  
>
> * tree-if-conv.c (add_bb_predicate_gimplified_stmts): Use
> gimple_seq_add_seq_without_update.
> (release_bb_predicate): Assert we have no operands to free.
> (if_convertible_loop_p_1): Calculate post dominators later.
> Do not free BB predicates here.
> (combine_blocks): Do not recompute BB predicates.
> (version_loop_for_if_conversion): Save BB predicates around
> loop versioning.
>
> * gcc.dg/tree-ssa/ifc-cd.c: Adjust.
>
> The following patch fixes this by adding a call to gimple_seq_discard
> to release_bb_predicate.  It also updates the assertion, so that
> instead of asserting the stmts have no imm uses, instead assert that
> they weren't added to a bb before discarding them (otherwise discarding
> them would be a bug).  We know this is the case because
> insert_gimplified_predicates has:
>
>   /* Once the sequence is code generated, set it to NULL.  */
>   set_bb_predicate_gimplified_stmts (bb, NULL);
>
> but asserting it seems appropriate as a double-check.
>
> The patch doesn't address the 2nd issue within PR tree-optimization/84178.
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
>
> OK for trunk?

OK.

Thanks,
Richard.

> gcc/ChangeLog:
> PR tree-optimization/84178
> * tree-if-conv.c (release_bb_predicate): Remove the
> the assertion that the stmts have NULL use_ops.
> Discard the statements, asserting that they haven't
> yet been added to a BB.
>
> gcc/testsuite/ChangeLog:
> PR tree-optimization/84178
> * gcc.c-torture/compile/pr84178-1.c: New test.
> ---
>  gcc/testsuite/gcc.c-torture/compile/pr84178-1.c | 18 ++
>  gcc/tree-if-conv.c  |  8 +---
>  2 files changed, 23 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
>
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
> new file mode 100644
> index 000..49f2c89
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-options "-fno-tree-forwprop" } */
> +
> +int zy, h4;
> +
> +void
> +r8 (long int mu, int *jr, int *fi, short int dv)
> +{
> +  do
> +{
> +  int tx;
> +
> +  tx = !!h4 ? (zy / h4) : 1;
> +  mu = tx;
> +  *jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) + 
> *fi;
> +} while (*jr == 0);
> +
> +  r8 (mu, jr, fi, 1);
> +}
> diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c
> index cac3fd7..5467f3f 100644
> --- a/gcc/tree-if-conv.c
> +++ b/gcc/tree-if-conv.c
> @@ -271,8 +271,7 @@ init_bb_predicate (basic_block bb)
>set_bb_predicate (bb, boolean_true_node);
>  }
>
> -/* Release the SSA_NAMEs associated with the predicate of basic block BB,
> -   but don't actually free it.  */
> +/* Release the SSA_NAMEs associated with the predicate of basic block BB.  */
>
>  static inline void
>  release_bb_predicate (basic_block bb)
> @@ -280,11 +279,14 @@ release_bb_predicate (basic_block bb)
>gimple_seq stmts = bb_predicate_gimplified_stmts (bb);
>if (stmts)
>  {
> +  /* Ensure that these stmts haven't yet been added to a bb.  */
>if (flag_checking)
> for (gimple_stmt_iterator i = gsi_start (stmts);
>  !gsi_end_p (i); gsi_next (&i))
> - gcc_assert (! gimple_use_ops (gsi_stmt (i)));
> + gcc_assert (! gimple_bb (gsi_stmt (i)));
>
> +  /* Discard them.  */
> +  gimple_seq_discard (stmts);
>set_bb_predicate_gimplified_stmts (bb, NULL);
>  }
>  }
> --
> 1.8.5.3
>

Re: GCC 6 backports

[Martin Liška]

On 03/07/2018 10:41 AM, Martin Liška wrote:
> Hi.
> 
> Sending GCC 6 branch backports.
> Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
> I'm going to install the patches.
> 
> Martin
> 

Hi.

There are 4 more patches I've tested.

Martin