Re: [PATCH] plug memory leaks in warn_parm_array_mismatch (PR 99055)

[Richard Biener via Gcc-patches]

On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor  wrote:
>
> The attached patch replaces calls to print_generic_expr_to_str() with
> a helper function that returns a std::string and releases the caller
> from the responsibility to explicitly free memory.

I don't like this.  What's the reason to use generic_expr_as_string
anyway?  We have %E pretty-printers after all.  Couldn't you have
fixed the leak by doing

if (newbnd)
  free (newbndstr);

etc.?

> With the patch installed, Valgrind shows more leaks in this code that
> I'm not sure what to do about:
>
> 1) A tree built by build_type_attribute_qual_variant() called from
> attr_access::array_as_string() to build a temporary type only
> for the purposes of formatting it.
>
> 2) A tree (an attribute list) built by tree_cons() called from
> build_attr_access_from_parms() that's used only for the duration
> of the caller.
>
> Do these temporary trees need to be released somehow or are the leaks
> expected?

You should configure GCC with --enable-valgrind-annotations to make
it aware of our GC.

> Martin
>
> Leak 1:
> ==7112== 56 bytes in 1 blocks are still reachable in loss record 73 of 691
> ==7112==at 0x483AB1A: calloc (vg_replace_malloc.c:762)
> ==7112==by 0x294ED71: xcalloc (xmalloc.c:162)
> ==7112==by 0xB8B21D: alloc_page(unsigned int) (ggc-page.c:918)
> ==7112==by 0xB8BAD1: ggc_internal_alloc(unsigned long, void
> (*)(void*), unsigned long, unsigned long) (ggc-page.c:1294)
> ==7112==by 0x9E1F33: ggc_internal_alloc(unsigned long) (ggc.h:130)
> ==7112==by 0x198AB1A: ggc_alloc_tree_node_stat(unsigned long)
> (ggc.h:309)
> ==7112==by 0x193BD18: copy_node(tree_node*) (tree.c:1223)
> ==7112==by 0x1953BDD: build_distinct_type_copy(tree_node*) (tree.c:6730)
> ==7112==by 0x9A1379: build_type_attribute_qual_variant(tree_node*,
> tree_node*, int) (attribs.c:1161)
> ==7112==by 0x9A483D:
> attr_access::array_as_string[abi:cxx11](tree_node*) const (attribs.c:2332)
> ==7112==by 0xB7C5A7: warn_parm_array_mismatch(unsigned int,
> tree_node*, tree_node*) (c-warn.c:3449)
> ==7112==by 0xA3EB57: c_parser_declaration_or_fndef(c_parser*, bool,
> bool, bool, bool, bool, tree_node**, vec,
> bool, tree_node*, oacc_routine_data*, bool*) (c-parser.c:2342)
>
>
> Leak 2:
> ==7112== 64 bytes in 1 blocks are still reachable in loss record 150 of 691
> ==7112==at 0x483AB1A: calloc (vg_replace_malloc.c:762)
> ==7112==by 0x294ED71: xcalloc (xmalloc.c:162)
> ==7112==by 0xB8B21D: alloc_page(unsigned int) (ggc-page.c:918)
> ==7112==by 0xB8BAD1: ggc_internal_alloc(unsigned long, void
> (*)(void*), unsigned long, unsigned long) (ggc-page.c:1294)
> ==7112==by 0x9E1F33: ggc_internal_alloc(unsigned long) (ggc.h:130)
> ==7112==by 0x198AB1A: ggc_alloc_tree_node_stat(unsigned long)
> (ggc.h:309)
> ==7112==by 0x19433E6: tree_cons(tree_node*, tree_node*, tree_node*)
> (tree.c:3331)
> ==7112==by 0xB67188: build_attr_access_from_parms(tree_node*, bool)
> (c-attribs.c:5060)
> ==7112==by 0xB7C008: warn_parm_array_mismatch(unsigned int,
> tree_node*, tree_node*) (c-warn.c:3364)
> ==7112==by 0xA3EB57: c_parser_declaration_or_fndef(c_parser*, bool,
> bool, bool, bool, bool, tree_node**, vec,
> bool, tree_node*, oacc_routine_data*, bool*) (c-parser.c:2342)
> ==7112==by 0xA3D5A9: c_parser_external_declaration(c_parser*)
> (c-parser.c:1777)
> ==7112==by 0xA3D06A: c_parser_translation_unit(c_parser*)
> (c-parser.c:1650)

Productronica Show Potential Contact Email List

[Christina Ridlon]

Hi,

Hope you are doing well!!

 

Are you interested in the “Productronica Show” Updated Client List?

 

Please let me know your industry so that I can share you the Samples & Cost
details.

 

I appreciate your quick response

Christina Ridlon | Marketing Specialist

To stop receiving this email, reply unsubscribe.

 

New French PO file for 'cpplib' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/fr.po

(This file, 'cpplib-11.1-b20210207.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-11.1-b20210207.fr.po'

[Translation Project Robot]

cpplib-11.1-b20210207.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: use -mfpu=neon for arm/simd/vmmla_1.c

[Alexandre Oliva]

On Feb  9, 2021, Kyrylo Tkachov  wrote:

> Ok. Aren't there more tests that have this problem?

Thanks.  This was the only test that exhibited this problem.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[PATCH] c++: ICE with unexpanded pack in do-while [PR99063]

[Marek Polacek via Gcc-patches]

Here an unexpanded parameter pack snuck into prep_operand which doesn't
expect to see an operand without a type, and since r247842
NONTYPE_ARGUMENT_PACK doesn't have a type anymore.

This only happens with the do-while loop whose condition may not
contain a declaration so we never called finish_cond which checks
for unexpanded parameter packs.  So use check_for_bare_parameter_packs
to remedy that.

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

gcc/cp/ChangeLog:

PR c++/99063
* semantics.c (finish_do_stmt): Check for unexpanded parameter packs.

gcc/testsuite/ChangeLog:

PR c++/99063
* g++.dg/cpp0x/variadic-crash6.C: New test.
---
 gcc/cp/semantics.c   |  5 +
 gcc/testsuite/g++.dg/cpp0x/variadic-crash6.C | 16 
 2 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-crash6.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 73834467fca..30dd206c899 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -1028,6 +1028,11 @@ finish_do_stmt (tree cond, tree do_stmt, bool ivdep, 
unsigned short unroll)
 {
   cond = maybe_convert_cond (cond);
   end_maybe_infinite_loop (cond);
+  /* Unlike other iteration statements, the condition may not contain
+ a declaration, so we don't call finish_cond which checks for
+ unexpanded parameter packs.  */
+  if (check_for_bare_parameter_packs (cond))
+cond = error_mark_node;
   if (ivdep && cond != error_mark_node)
 cond = build3 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
   build_int_cst (integer_type_node, annot_expr_ivdep_kind),
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-crash6.C 
b/gcc/testsuite/g++.dg/cpp0x/variadic-crash6.C
new file mode 100644
index 000..88009b765c2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-crash6.C
@@ -0,0 +1,16 @@
+// PR c++/99063
+// { dg-do compile { target c++11 } }
+
+template 
+void f (T... n)
+{
+  do
+{
+}
+  while (--n); // { dg-error "parameter packs not expanded with '...'" }
+}
+
+void g ()
+{
+  f(3);
+}

base-commit: 27a804bc62805aedb1b097a00eb2c0059244680a
-- 
2.29.2

Re: [patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

[Jerry DeLisle]

On 2/7/21 9:07 AM, Thomas Koenig wrote:


Hi Jerry,


OK for trunk and backport to 10 since it is simple enough?


OK for trunk.

Because this is a user-visible change (even if we did the wrong
thing before) I don't feel that we should backport (but I am
open to suggestions otherwise).

Could you also mention this in gcc-11/changes.html ?

Best regards

Thomas


The above was committed.  I had a very frustrating experiance with the 
push process.  Over and over attempting to push and having it rejected 
for an invalid PR reference. The directory that holds the runtime 
library is called "libgfortran".  The official gcc component in Bugzilla 
is called "libfortran".  There is no letter "g" in that component name 
and thus the hooks rejected my push attempts.  The only reason I figured 
it out, after exhausting about 25 other variations I could think of is 
that I thought "What does the PR think this is?"


Well that was not intuitively obvious, but my bug tracking persistance 
hung in there. Sheesh!


Just telling people so others might be aware of this little detail.

Thomas, I will get around to updating the changes.html.

Thanks and best regards,

Jerry

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

[Jason Merrill via Gcc-patches]

On 2/10/21 5:25 PM, Patrick Palka wrote:



On Wed, 10 Feb 2021, Jason Merrill wrote:


On 2/10/21 12:32 PM, Patrick Palka wrote:

On Wed, 10 Feb 2021, Jason Merrill wrote:


On 2/9/21 5:12 PM, Patrick Palka wrote:

On Tue, 2 Feb 2021, Jason Merrill wrote:


On 2/2/21 12:19 AM, Patrick Palka wrote:

In this testcase, we're crashing because the lookup of operator+
from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding isn't prepared
to
handle.

Since we already discard the result of lookup_name when it returns a
class-scope binding here, it seems cleaner (and equivalent) to
instead
communicate to lookup_name that we don't want such bindings in the
first
place.  While this change seems like an improvement on its own, it
also
fixes the mentioned PR, because the call to lookup_name now returns
NULL_TREE rather than a TREE_LIST of (unwanted) class-scope
bindings.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for
trunk/9/10?

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Pass BLOCK_NAMESPACE
to
lookup_name in order to ignore class-scope bindings, rather
than discarding them after the fact.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
 gcc/cp/name-lookup.c  | 11
+++
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C |  8

 2 files changed, 11 insertions(+), 8 deletions(-)
 create mode 100644
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 52e4a630e25..46d6cc0dfa4 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9213,17 +9213,12 @@ op_unqualified_lookup (tree fnname)
return NULL_TREE;
 }
 -  tree fns = lookup_name (fnname);
+  /* We don't need to remember class-scope functions or
declarations,
+ normal unqualified lookup will find them again.  */
+  tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);


Hmm, I'd expect this to look past class-scope declarations to find
namespace-scope declarations, but we want class decls to hide decls in
an
outer scope.


D'oh, good point.  But IIUC, even if we did return (and later inject at
instantiation time) namespace-scope declarations that were hidden by
class-scope declarations, wouldn't the lookup at instantiation time
still find and prefer the class-scope bindings (as desired)?  It seems
to me that the end result might be the same, but I'm not sure.


The injection happens in the function parameter binding level, so I'd
expect
it to be found before class bindings.


Oops, I didn't look at push_operator_bindings closely enough.  Never
mind about that idea then.




Alternatively, would it be safe to assume that if lookup_name returns an
ambiguous result, then the result must consist of class-scope
declarations and so we can discard it?


That isn't true in general:

inline namespace A { int i; }
inline namespace B { int i; }
int main() { return i; } // ambiguous lookup

though I think it is true for functions.  But if the result is ambiguous,
you
can look at the first element to see if it's from class scope.


I see, that's good to know.  So something like this?

-- >8 --

Subject: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which op_unqualified_lookup (and
push_operator_bindings) isn't prepared to handle.

This patch makes op_unqualified_lookup and push_operator_bindings handle
an ambiguous lookup result appropriately.

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Handle an ambiguous
lookup result by discarding it if the first element is
a class-scope declaration, otherwise return it.
(push_operator_bindings): Handle an ambiguous lookup result by
doing push_local_binding on each element in the list.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
   gcc/cp/name-lookup.c | 16 
   .../g++.dg/cpp0x/lambda/lambda-template17.C  |  8 
   2 files changed, 20 insertions(+), 4 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 1f4a7ac1d0c..27af21d9ac9 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9219,11 +9219,15 @@ op_unqualified_lookup (tree fnname)
   /* Remember we found nothing!  */
   return error_mark_node;
   -  tree d = is_overloaded_fn (fns) ? 

Re: [PATCH v2] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

[Jason Merrill via Gcc-patches]

On 2/10/21 7:27 PM, Marek Polacek wrote:

On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote:

On 2/10/21 12:35 PM, Marek Polacek wrote:

Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.


OK, but if chain were an auto_vec, delete would work.


Yes.


Can we merge auto_vec with vec now that we're compiling as C++11?


Yeah, that works too, though I like how vec_free also sets its argument
to NULL...  Up to you.

Joseph, are you OK with this version too?

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

Verified that the leaks valgrind detected are gone.

-- >8 --
-Wduplicated-cond uses a simple vec for the condition chain and
it uses delete to destroy the chain, which doesn't call ->release,
resulting in memory leaks.

This patch makes it use auto_vec instead; we'll now call ->release
when deleting the chain.

gcc/c-family/ChangeLog:

* c-common.h (warn_duplicated_cond_add_or_warn): Use auto_vec
for the condition chain.
* c-warn.c (warn_duplicated_cond_add_or_warn): Likewise.

gcc/c/ChangeLog:

* c-parser.c (c_parser_statement_after_labels): Use auto_vec
for the condition chain.
(c_parser_if_statement): Likewise.
(c_parser_else_body): Likewise.

gcc/cp/ChangeLog:

* parser.c (cp_parser_statement): Use auto_vec for the condition chain.
(cp_parser_selection_statement): Likewise.
(cp_parser_implicitly_scoped_statement): Likewise.


Ah, I didn't think so many other functions would need to change their 
prototypes.  Let's go with your original patch.



---
  gcc/c-family/c-common.h |  3 ++-
  gcc/c-family/c-warn.c   |  3 ++-
  gcc/c/c-parser.c| 12 ++--
  gcc/cp/parser.c | 15 ---
  4 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f30b6c6ac33..bc02481a11e 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1430,7 +1430,8 @@ extern void maybe_record_typedef_use (tree);
  extern void maybe_warn_unused_local_typedefs (void);
  extern void maybe_warn_bool_compare (location_t, enum tree_code, tree, tree);
  extern bool maybe_warn_shift_overflow (location_t, tree, tree);
-extern void warn_duplicated_cond_add_or_warn (location_t, tree, vec **);
+extern void warn_duplicated_cond_add_or_warn (location_t, tree,
+ auto_vec **);
  extern bool diagnose_mismatched_attributes (tree, tree);
  extern tree do_warn_duplicated_branches_r (tree *, int *, void *);
  extern void warn_for_multistatement_macros (location_t, location_t,
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index e6e28d9b139..ce5d4890181 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -2499,7 +2499,8 @@ maybe_warn_unused_local_typedefs (void)
 of COND.  */
  
  void

-warn_duplicated_cond_add_or_warn (location_t loc, tree cond, vec **chain)
+warn_duplicated_cond_add_or_warn (location_t loc, tree cond,
+ auto_vec **chain)
  {
/* No chain has been created yet.  Do nothing.  */
if (*chain == NULL)
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index a8df208493c..0153f0805f8 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1524,10 +1524,10 @@ static location_t c_parser_compound_statement_nostart 
(c_parser *);
  static void c_parser_label (c_parser *, tree);
  static void c_parser_statement (c_parser *, bool *, location_t * = NULL);
  static void c_parser_statement_after_labels (c_parser *, bool *,
-vec * = NULL);
+auto_vec * = nullptr);
  static tree c_parser_c99_block_statement (c_parser *, bool *,
  location_t * = NULL);
-static void c_parser_if_statement (c_parser *, bool *, vec *);
+static void c_parser_if_statement (c_parser *, bool *, auto_vec *);
  static void c_parser_switch_statement (c_parser *, bool *);
  static void c_parser_while_statement (c_parser *, bool, unsigned short, bool 
*);
  static void c_parser_do_statement (c_parser *, bool, unsigned short);
@@ -6084,7 +6084,7 @@ c_parser_statement (c_parser *parser, bool *if_p, 
location_t *loc_after_labels)
  
  static void

  c_parser_statement_after_labels (c_parser *parser, bool *if_p,
-vec *chain)
+auto_vec *chain)
  {
location_t loc = c_parser_peek_token (parser)->location;
tree stmt = NULL_TREE;
@@ -6373,7 +6373,7 @@ c_parser_if_body (c_parser *parser, bool *if_p,
  
  static tree

  c_parser_else_body (c_parser *parser, const token_indent_info _tinfo,
-   vec *chain)
+   auto_vec *chain)
  {
location_t body_loc = c_parser_peek_token (parser)->location;
tree block = c_begin_compound_stmt (flag_isoc99);
@@ -6458,7 +6458,7 @@ c_parser_maybe_reclassify_token (c_parser 

Re: [PATCH v2] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

[Marek Polacek via Gcc-patches]

On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote:
> On 2/10/21 12:35 PM, Marek Polacek wrote:
> > Freeing the condition chain needs to use vec_free which does ->release,
> > or we leak memory.
> 
> OK, but if chain were an auto_vec, delete would work.

Yes.

> Can we merge auto_vec with vec now that we're compiling as C++11?

Yeah, that works too, though I like how vec_free also sets its argument
to NULL...  Up to you.

Joseph, are you OK with this version too?

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

Verified that the leaks valgrind detected are gone.

-- >8 --
-Wduplicated-cond uses a simple vec for the condition chain and
it uses delete to destroy the chain, which doesn't call ->release,
resulting in memory leaks.

This patch makes it use auto_vec instead; we'll now call ->release
when deleting the chain.

gcc/c-family/ChangeLog:

* c-common.h (warn_duplicated_cond_add_or_warn): Use auto_vec
for the condition chain.
* c-warn.c (warn_duplicated_cond_add_or_warn): Likewise.

gcc/c/ChangeLog:

* c-parser.c (c_parser_statement_after_labels): Use auto_vec
for the condition chain.
(c_parser_if_statement): Likewise.
(c_parser_else_body): Likewise.

gcc/cp/ChangeLog:

* parser.c (cp_parser_statement): Use auto_vec for the condition chain.
(cp_parser_selection_statement): Likewise.
(cp_parser_implicitly_scoped_statement): Likewise.
---
 gcc/c-family/c-common.h |  3 ++-
 gcc/c-family/c-warn.c   |  3 ++-
 gcc/c/c-parser.c| 12 ++--
 gcc/cp/parser.c | 15 ---
 4 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f30b6c6ac33..bc02481a11e 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1430,7 +1430,8 @@ extern void maybe_record_typedef_use (tree);
 extern void maybe_warn_unused_local_typedefs (void);
 extern void maybe_warn_bool_compare (location_t, enum tree_code, tree, tree);
 extern bool maybe_warn_shift_overflow (location_t, tree, tree);
-extern void warn_duplicated_cond_add_or_warn (location_t, tree, vec **);
+extern void warn_duplicated_cond_add_or_warn (location_t, tree,
+ auto_vec **);
 extern bool diagnose_mismatched_attributes (tree, tree);
 extern tree do_warn_duplicated_branches_r (tree *, int *, void *);
 extern void warn_for_multistatement_macros (location_t, location_t,
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index e6e28d9b139..ce5d4890181 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -2499,7 +2499,8 @@ maybe_warn_unused_local_typedefs (void)
of COND.  */
 
 void
-warn_duplicated_cond_add_or_warn (location_t loc, tree cond, vec **chain)
+warn_duplicated_cond_add_or_warn (location_t loc, tree cond,
+ auto_vec **chain)
 {
   /* No chain has been created yet.  Do nothing.  */
   if (*chain == NULL)
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index a8df208493c..0153f0805f8 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1524,10 +1524,10 @@ static location_t c_parser_compound_statement_nostart 
(c_parser *);
 static void c_parser_label (c_parser *, tree);
 static void c_parser_statement (c_parser *, bool *, location_t * = NULL);
 static void c_parser_statement_after_labels (c_parser *, bool *,
-vec * = NULL);
+auto_vec * = nullptr);
 static tree c_parser_c99_block_statement (c_parser *, bool *,
  location_t * = NULL);
-static void c_parser_if_statement (c_parser *, bool *, vec *);
+static void c_parser_if_statement (c_parser *, bool *, auto_vec *);
 static void c_parser_switch_statement (c_parser *, bool *);
 static void c_parser_while_statement (c_parser *, bool, unsigned short, bool 
*);
 static void c_parser_do_statement (c_parser *, bool, unsigned short);
@@ -6084,7 +6084,7 @@ c_parser_statement (c_parser *parser, bool *if_p, 
location_t *loc_after_labels)
 
 static void
 c_parser_statement_after_labels (c_parser *parser, bool *if_p,
-vec *chain)
+auto_vec *chain)
 {
   location_t loc = c_parser_peek_token (parser)->location;
   tree stmt = NULL_TREE;
@@ -6373,7 +6373,7 @@ c_parser_if_body (c_parser *parser, bool *if_p,
 
 static tree
 c_parser_else_body (c_parser *parser, const token_indent_info _tinfo,
-   vec *chain)
+   auto_vec *chain)
 {
   location_t body_loc = c_parser_peek_token (parser)->location;
   tree block = c_begin_compound_stmt (flag_isoc99);
@@ -6458,7 +6458,7 @@ c_parser_maybe_reclassify_token (c_parser *parser)
implement -Wparentheses.  */
 
 static void
-c_parser_if_statement (c_parser *parser, bool *if_p, vec *chain)
+c_parser_if_statement (c_parser *parser, bool *if_p, auto_vec *chain)
 {
  

Re: [PATCH v2] c-family: ICE with assume_aligned attribute [PR99062]

[Marek Polacek via Gcc-patches]

On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote:
> On 2/10/21 3:33 PM, Marek Polacek wrote:
> > We ICE in handle_assume_aligned_attribute since r271338 which added
> > 
> > @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree 
> > name, tree args, int,
> >/* The misalignment specified by the second argument
> >   must be non-negative and less than the alignment.  */
> >warning (OPT_Wattributes,
> > -  "%qE attribute argument %E is not in the range [0, %E)",
> > -  name, val, align);
> > +  "%qE attribute argument %E is not in the range [0, %wu]",
> > +  name, val, tree_to_uhwi (align) - 1);
> >*no_add_attrs = true;
> >return NULL_TREE;
> >  }
> > because align is INT_MIN and tree_to_uhwi asserts tree_fits_uhwi_p -- which
> > ALIGN does not and the prior tree_fits_shwi_p check is fine with it, as
> > well as the integer_pow2p check.
> > 
> > Since neither of the arguments to assume_aligned can be negative, I've
> > hoisted the tree_int_cst_sgn check.  And add the missing "argument"
> > word to an existing warning.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
> 
> Thanks for taking this on!  As I mentioned in the bug, I should
> relax the warning to understand that [x, y) is a half-open range
> so that these changes aren't necessary.
> 
> I'm surprised that integer_pow2p() returns true for negative values.
> That seems like a trap for the unwary.  The comment above the function
> says:
> 
>   Return 1 if EXPR is an integer constant that is a power of 2
>   (i.e., has only one bit on), or a location wrapper for such
>   a constant.
> 
> but an "integer power of 2" isn't the same as "has only one bit
> on."  I would suggest to rename the function (independently of
> the fix for the ICE).  There aren't too many uses of it so it
> shouldn't be too intrusive.  I can do that for GCC 12 if no-one
> objects.
> 
> Just one comment on the patch:
> 
> > 
> > gcc/c-family/ChangeLog:
> > 
> > PR c++/99062
> > * c-attribs.c (handle_assume_aligned_attribute): Check that the
> > alignment argument is non-negative.  Tweak a warning message.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/99062
> > * gcc.dg/attr-assume_aligned-4.c: Adjust dg-warning.
> > * g++.dg/ext/attr-assume-aligned.C: New test.
> > ---
> >   gcc/c-family/c-attribs.c   | 12 ++--
> >   gcc/testsuite/g++.dg/ext/attr-assume-aligned.C |  5 +
> >   gcc/testsuite/gcc.dg/attr-assume_aligned-4.c   |  4 ++--
> >   3 files changed, 17 insertions(+), 4 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/ext/attr-assume-aligned.C
> > 
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> > index 84ec86b2091..e343429f934 100644
> > --- a/gcc/c-family/c-attribs.c
> > +++ b/gcc/c-family/c-attribs.c
> > @@ -3536,7 +3536,15 @@ handle_assume_aligned_attribute (tree *node, tree 
> > name, tree args, int,
> > if (!tree_fits_shwi_p (val))
> > {
> >   warning (OPT_Wattributes,
> > -  "%qE attribute %E is not an integer constant",
> > +  "%qE attribute argument %E is not an integer constant",
> > +  name, val);
> > + *no_add_attrs = true;
> > + return NULL_TREE;
> > +   }
> > +  else if (tree_int_cst_sgn (val) < 0)
> > +   {
> > + warning (OPT_Wattributes,
> > +  "%qE attribute argument %E must be non-negative",
> >name, val);
> 
> The phrasing here doesn't sound quite right.  For the test case it
> will print:
> 
>   warning: 'assume_aligned' attribute argument -1 must be non-negative
> 
> which isn't possible: -1 can't be non-negative.  I'd suggest either
> making that descriptive rather than prescriptive (along the lines
> of the other warnings):
> 
> warning (OPT_Wattributes,
>  "%qE attribute argument %E is not positive",
>  name, val);
> 
> or referring to the positional argument instead.

Good point, that was very poor wording.  Fixed in v2:

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

-- >8 --
We ICE in handle_assume_aligned_attribute since r271338 which added

@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
  /* The misalignment specified by the second argument
 must be non-negative and less than the alignment.  */
  warning (OPT_Wattributes,
-  "%qE attribute argument %E is not in the range [0, %E)",
-  name, val, align);
+  "%qE attribute argument %E is not in the range [0, %wu]",
+  name, val, tree_to_uhwi (align) - 1);
  *no_add_attrs = true;
  return NULL_TREE;
}
because align is INT_MIN and tree_to_uhwi asserts tree_fits_uhwi_p -- which
ALIGN does not and the 

Re: [PATCH] c-family: ICE with assume_aligned attribute [PR99062]

[Martin Sebor via Gcc-patches]

On 2/10/21 3:33 PM, Marek Polacek wrote:

We ICE in handle_assume_aligned_attribute since r271338 which added

@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
   /* The misalignment specified by the second argument
  must be non-negative and less than the alignment.  */
   warning (OPT_Wattributes,
-  "%qE attribute argument %E is not in the range [0, %E)",
-  name, val, align);
+  "%qE attribute argument %E is not in the range [0, %wu]",
+  name, val, tree_to_uhwi (align) - 1);
   *no_add_attrs = true;
   return NULL_TREE;
 }
because align is INT_MIN and tree_to_uhwi asserts tree_fits_uhwi_p -- which
ALIGN does not and the prior tree_fits_shwi_p check is fine with it, as
well as the integer_pow2p check.

Since neither of the arguments to assume_aligned can be negative, I've
hoisted the tree_int_cst_sgn check.  And add the missing "argument"
word to an existing warning.

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


Thanks for taking this on!  As I mentioned in the bug, I should
relax the warning to understand that [x, y) is a half-open range
so that these changes aren't necessary.

I'm surprised that integer_pow2p() returns true for negative values.
That seems like a trap for the unwary.  The comment above the function
says:

  Return 1 if EXPR is an integer constant that is a power of 2
  (i.e., has only one bit on), or a location wrapper for such
  a constant.

but an "integer power of 2" isn't the same as "has only one bit
on."  I would suggest to rename the function (independently of
the fix for the ICE).  There aren't too many uses of it so it
shouldn't be too intrusive.  I can do that for GCC 12 if no-one
objects.

Just one comment on the patch:



gcc/c-family/ChangeLog:

PR c++/99062
* c-attribs.c (handle_assume_aligned_attribute): Check that the
alignment argument is non-negative.  Tweak a warning message.

gcc/testsuite/ChangeLog:

PR c++/99062
* gcc.dg/attr-assume_aligned-4.c: Adjust dg-warning.
* g++.dg/ext/attr-assume-aligned.C: New test.
---
  gcc/c-family/c-attribs.c   | 12 ++--
  gcc/testsuite/g++.dg/ext/attr-assume-aligned.C |  5 +
  gcc/testsuite/gcc.dg/attr-assume_aligned-4.c   |  4 ++--
  3 files changed, 17 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/ext/attr-assume-aligned.C

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 84ec86b2091..e343429f934 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -3536,7 +3536,15 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
if (!tree_fits_shwi_p (val))
{
  warning (OPT_Wattributes,
-  "%qE attribute %E is not an integer constant",
+  "%qE attribute argument %E is not an integer constant",
+  name, val);
+ *no_add_attrs = true;
+ return NULL_TREE;
+   }
+  else if (tree_int_cst_sgn (val) < 0)
+   {
+ warning (OPT_Wattributes,
+  "%qE attribute argument %E must be non-negative",
   name, val);


The phrasing here doesn't sound quite right.  For the test case it
will print:

  warning: 'assume_aligned' attribute argument -1 must be non-negative

which isn't possible: -1 can't be non-negative.  I'd suggest either
making that descriptive rather than prescriptive (along the lines
of the other warnings):

  warning (OPT_Wattributes,
   "%qE attribute argument %E is not positive",
   name, val);

or referring to the positional argument instead.

Martin


  *no_add_attrs = true;
  return NULL_TREE;
@@ -3556,7 +3564,7 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
  
  	  align = val;

}
-  else if (tree_int_cst_sgn (val) < 0 || tree_int_cst_le (align, val))
+  else if (tree_int_cst_le (align, val))
{
  /* The misalignment specified by the second argument
 must be non-negative and less than the alignment.  */
diff --git a/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C 
b/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C
new file mode 100644
index 000..7d073a90d74
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C
@@ -0,0 +1,5 @@
+// PR c++/99062
+// { dg-do compile }
+
+#define INT_MIN (-__INT_MAX__ - 1)
+void *f () __attribute__ ((assume_aligned (INT_MIN, 4))); // { dg-warning "must be 
non-negative" }
diff --git a/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c 
b/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
index 2571ab8a683..2c69c8b9f56 100644
--- a/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
+++ b/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
@@ -8,7 +8,7 @@ A (1) void fv_1 (void);   /* { dg-warning 

[PATCH] c-family: ICE with assume_aligned attribute [PR99062]

[Marek Polacek via Gcc-patches]

We ICE in handle_assume_aligned_attribute since r271338 which added

@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
  /* The misalignment specified by the second argument
 must be non-negative and less than the alignment.  */
  warning (OPT_Wattributes,
-  "%qE attribute argument %E is not in the range [0, %E)",
-  name, val, align);
+  "%qE attribute argument %E is not in the range [0, %wu]",
+  name, val, tree_to_uhwi (align) - 1);
  *no_add_attrs = true;
  return NULL_TREE;
}
because align is INT_MIN and tree_to_uhwi asserts tree_fits_uhwi_p -- which
ALIGN does not and the prior tree_fits_shwi_p check is fine with it, as
well as the integer_pow2p check.

Since neither of the arguments to assume_aligned can be negative, I've
hoisted the tree_int_cst_sgn check.  And add the missing "argument"
word to an existing warning.

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

gcc/c-family/ChangeLog:

PR c++/99062
* c-attribs.c (handle_assume_aligned_attribute): Check that the
alignment argument is non-negative.  Tweak a warning message.

gcc/testsuite/ChangeLog:

PR c++/99062
* gcc.dg/attr-assume_aligned-4.c: Adjust dg-warning.
* g++.dg/ext/attr-assume-aligned.C: New test.
---
 gcc/c-family/c-attribs.c   | 12 ++--
 gcc/testsuite/g++.dg/ext/attr-assume-aligned.C |  5 +
 gcc/testsuite/gcc.dg/attr-assume_aligned-4.c   |  4 ++--
 3 files changed, 17 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-assume-aligned.C

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 84ec86b2091..e343429f934 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -3536,7 +3536,15 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
   if (!tree_fits_shwi_p (val))
{
  warning (OPT_Wattributes,
-  "%qE attribute %E is not an integer constant",
+  "%qE attribute argument %E is not an integer constant",
+  name, val);
+ *no_add_attrs = true;
+ return NULL_TREE;
+   }
+  else if (tree_int_cst_sgn (val) < 0)
+   {
+ warning (OPT_Wattributes,
+  "%qE attribute argument %E must be non-negative",
   name, val);
  *no_add_attrs = true;
  return NULL_TREE;
@@ -3556,7 +3564,7 @@ handle_assume_aligned_attribute (tree *node, tree name, 
tree args, int,
 
  align = val;
}
-  else if (tree_int_cst_sgn (val) < 0 || tree_int_cst_le (align, val))
+  else if (tree_int_cst_le (align, val))
{
  /* The misalignment specified by the second argument
 must be non-negative and less than the alignment.  */
diff --git a/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C 
b/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C
new file mode 100644
index 000..7d073a90d74
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attr-assume-aligned.C
@@ -0,0 +1,5 @@
+// PR c++/99062
+// { dg-do compile }
+
+#define INT_MIN (-__INT_MAX__ - 1)
+void *f () __attribute__ ((assume_aligned (INT_MIN, 4))); // { dg-warning 
"must be non-negative" }
diff --git a/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c 
b/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
index 2571ab8a683..2c69c8b9f56 100644
--- a/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
+++ b/gcc/testsuite/gcc.dg/attr-assume_aligned-4.c
@@ -8,7 +8,7 @@ A (1) void fv_1 (void);   /* { dg-warning ".assume_aligned. 
attribute ignore
 
 A (1) int fi_1 (void);/* { dg-warning ".assume_aligned. attribute 
ignored on a function returning .int." } */
 
-A (-1) void* fpv_m1 (void);   /* { dg-warning ".assume_aligned. attribute 
argument -1 is not a power of 2" } */
+A (-1) void* fpv_m1 (void);   /* { dg-warning ".assume_aligned. attribute 
argument -1 must be non-negative" } */
 
 A (0) void* fpv_0 (void); /* { dg-warning ".assume_aligned. attribute 
argument 0 is not a power of 2" } */
 
@@ -23,7 +23,7 @@ A (16385) void* fpv_16kp1 (void);/* { dg-warning 
".assume_aligned. attribute
 
 A (32767) void* fpv_32km1 (void); /* { dg-warning ".assume_aligned. 
attribute argument 32767 is not a power of 2" } */
 
-A (4, -1) void* fpv_4_m1 (void);  /* { dg-warning ".assume_aligned. 
attribute argument -1 is not in the range \\\[0, 3]" } */
+A (4, -1) void* fpv_4_m1 (void);  /* { dg-warning ".assume_aligned. 
attribute argument -1 must be non-negative" } */
 
 A (4, 0) void* fpv_4_0 (void);
 A (4, 1) void* fpv_4_1 (void);

base-commit: 21c6ad7a12fecc4c85ac26289d9096379b550585
-- 
2.29.2

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

[Patrick Palka via Gcc-patches]

On Wed, 10 Feb 2021, Jason Merrill wrote:

> On 2/10/21 12:32 PM, Patrick Palka wrote:
> > On Wed, 10 Feb 2021, Jason Merrill wrote:
> > 
> > > On 2/9/21 5:12 PM, Patrick Palka wrote:
> > > > On Tue, 2 Feb 2021, Jason Merrill wrote:
> > > > 
> > > > > On 2/2/21 12:19 AM, Patrick Palka wrote:
> > > > > > In this testcase, we're crashing because the lookup of operator+
> > > > > > from
> > > > > > within the generic lambda via lookup_name finds multiple bindings
> > > > > > (namely C1::operator+ and C2::operator+) and returns a TREE_LIST
> > > > > > thereof, something which maybe_save_operator_binding isn't prepared
> > > > > > to
> > > > > > handle.
> > > > > > 
> > > > > > Since we already discard the result of lookup_name when it returns a
> > > > > > class-scope binding here, it seems cleaner (and equivalent) to
> > > > > > instead
> > > > > > communicate to lookup_name that we don't want such bindings in the
> > > > > > first
> > > > > > place.  While this change seems like an improvement on its own, it
> > > > > > also
> > > > > > fixes the mentioned PR, because the call to lookup_name now returns
> > > > > > NULL_TREE rather than a TREE_LIST of (unwanted) class-scope
> > > > > > bindings.
> > > > > > 
> > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > > > for
> > > > > > trunk/9/10?
> > > > > > 
> > > > > > gcc/cp/ChangeLog:
> > > > > > 
> > > > > > PR c++/97582
> > > > > > * name-lookup.c (op_unqualified_lookup): Pass BLOCK_NAMESPACE
> > > > > > to
> > > > > > lookup_name in order to ignore class-scope bindings, rather
> > > > > > than discarding them after the fact.
> > > > > > 
> > > > > > gcc/testsuite/ChangeLog:
> > > > > > 
> > > > > > PR c++/97582
> > > > > > * g++.dg/cpp0x/lambda/lambda-template17.C: New test.
> > > > > > ---
> > > > > > gcc/cp/name-lookup.c  | 11
> > > > > > +++
> > > > > > gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C |  8
> > > > > > 
> > > > > > 2 files changed, 11 insertions(+), 8 deletions(-)
> > > > > > create mode 100644
> > > > > > gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C
> > > > > > 
> > > > > > diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
> > > > > > index 52e4a630e25..46d6cc0dfa4 100644
> > > > > > --- a/gcc/cp/name-lookup.c
> > > > > > +++ b/gcc/cp/name-lookup.c
> > > > > > @@ -9213,17 +9213,12 @@ op_unqualified_lookup (tree fnname)
> > > > > > return NULL_TREE;
> > > > > > }
> > > > > > -  tree fns = lookup_name (fnname);
> > > > > > +  /* We don't need to remember class-scope functions or
> > > > > > declarations,
> > > > > > + normal unqualified lookup will find them again.  */
> > > > > > +  tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
> > > > > 
> > > > > Hmm, I'd expect this to look past class-scope declarations to find
> > > > > namespace-scope declarations, but we want class decls to hide decls in
> > > > > an
> > > > > outer scope.
> > > > 
> > > > D'oh, good point.  But IIUC, even if we did return (and later inject at
> > > > instantiation time) namespace-scope declarations that were hidden by
> > > > class-scope declarations, wouldn't the lookup at instantiation time
> > > > still find and prefer the class-scope bindings (as desired)?  It seems
> > > > to me that the end result might be the same, but I'm not sure.
> > > 
> > > The injection happens in the function parameter binding level, so I'd
> > > expect
> > > it to be found before class bindings.
> > 
> > Oops, I didn't look at push_operator_bindings closely enough.  Never
> > mind about that idea then.
> > 
> > > 
> > > > Alternatively, would it be safe to assume that if lookup_name returns an
> > > > ambiguous result, then the result must consist of class-scope
> > > > declarations and so we can discard it?
> > > 
> > > That isn't true in general:
> > > 
> > > inline namespace A { int i; }
> > > inline namespace B { int i; }
> > > int main() { return i; } // ambiguous lookup
> > > 
> > > though I think it is true for functions.  But if the result is ambiguous,
> > > you
> > > can look at the first element to see if it's from class scope.
> > 
> > I see, that's good to know.  So something like this?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]
> > 
> > In this testcase, we're crashing because the lookup of operator+ from
> > within the generic lambda via lookup_name finds multiple bindings
> > (namely C1::operator+ and C2::operator+) and returns a TREE_LIST
> > thereof, something which op_unqualified_lookup (and
> > push_operator_bindings) isn't prepared to handle.
> > 
> > This patch makes op_unqualified_lookup and push_operator_bindings handle
> > an ambiguous lookup result appropriately.
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/97582
> > * name-lookup.c (op_unqualified_lookup): Handle an ambiguous
> > lookup result by discarding 

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

[Jason Merrill via Gcc-patches]

On 2/10/21 12:32 PM, Patrick Palka wrote:

On Wed, 10 Feb 2021, Jason Merrill wrote:


On 2/9/21 5:12 PM, Patrick Palka wrote:

On Tue, 2 Feb 2021, Jason Merrill wrote:


On 2/2/21 12:19 AM, Patrick Palka wrote:

In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding isn't prepared to
handle.

Since we already discard the result of lookup_name when it returns a
class-scope binding here, it seems cleaner (and equivalent) to instead
communicate to lookup_name that we don't want such bindings in the first
place.  While this change seems like an improvement on its own, it also
fixes the mentioned PR, because the call to lookup_name now returns
NULL_TREE rather than a TREE_LIST of (unwanted) class-scope bindings.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/9/10?

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Pass BLOCK_NAMESPACE to
lookup_name in order to ignore class-scope bindings, rather
than discarding them after the fact.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
gcc/cp/name-lookup.c  | 11
+++
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C |  8 
2 files changed, 11 insertions(+), 8 deletions(-)
create mode 100644
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 52e4a630e25..46d6cc0dfa4 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9213,17 +9213,12 @@ op_unqualified_lookup (tree fnname)
return NULL_TREE;
}
-  tree fns = lookup_name (fnname);
+  /* We don't need to remember class-scope functions or declarations,
+ normal unqualified lookup will find them again.  */
+  tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);


Hmm, I'd expect this to look past class-scope declarations to find
namespace-scope declarations, but we want class decls to hide decls in an
outer scope.


D'oh, good point.  But IIUC, even if we did return (and later inject at
instantiation time) namespace-scope declarations that were hidden by
class-scope declarations, wouldn't the lookup at instantiation time
still find and prefer the class-scope bindings (as desired)?  It seems
to me that the end result might be the same, but I'm not sure.


The injection happens in the function parameter binding level, so I'd expect
it to be found before class bindings.


Oops, I didn't look at push_operator_bindings closely enough.  Never
mind about that idea then.




Alternatively, would it be safe to assume that if lookup_name returns an
ambiguous result, then the result must consist of class-scope
declarations and so we can discard it?


That isn't true in general:

inline namespace A { int i; }
inline namespace B { int i; }
int main() { return i; } // ambiguous lookup

though I think it is true for functions.  But if the result is ambiguous, you
can look at the first element to see if it's from class scope.


I see, that's good to know.  So something like this?

-- >8 --

Subject: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which op_unqualified_lookup (and
push_operator_bindings) isn't prepared to handle.

This patch makes op_unqualified_lookup and push_operator_bindings handle
an ambiguous lookup result appropriately.

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Handle an ambiguous
lookup result by discarding it if the first element is
a class-scope declaration, otherwise return it.
(push_operator_bindings): Handle an ambiguous lookup result by
doing push_local_binding on each element in the list.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
  gcc/cp/name-lookup.c | 16 
  .../g++.dg/cpp0x/lambda/lambda-template17.C  |  8 
  2 files changed, 20 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 1f4a7ac1d0c..27af21d9ac9 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9219,11 +9219,15 @@ op_unqualified_lookup (tree fnname)
  /* Remember we found nothing!  */
  return error_mark_node;
  
-  tree d = is_overloaded_fn (fns) ? get_first_fn (fns) : fns;

-  if (DECL_CLASS_SCOPE_P (d))
+  tree fn = fns;
+  if (TREE_CODE (fn) == TREE_LIST)

Re: [PATCH] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

[Jason Merrill via Gcc-patches]

On 2/10/21 12:35 PM, Marek Polacek wrote:

Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.


OK, but if chain were an auto_vec, delete would work.

Can we merge auto_vec with vec now that we're compiling as C++11?


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

gcc/c/ChangeLog:

* c-parser.c (c_parser_if_statement): Use vec_free.

gcc/cp/ChangeLog:

* parser.c (cp_parser_selection_statement): Use vec_free.
---
  gcc/c/c-parser.c | 18 ++
  gcc/cp/parser.c  | 27 +--
  2 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index a8df208493c..2a49d07bab4 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -6499,12 +6499,9 @@ c_parser_if_statement (c_parser *parser, bool *if_p, 
vec *chain)
chain->safe_push (cond);
}
  else if (!c_parser_next_token_is_keyword (parser, RID_IF))
-   {
- /* This is if-else without subsequent if.  Zap the condition
-chain; we would have already warned at this point.  */
- delete chain;
- chain = NULL;
-   }
+   /* This is if-else without subsequent if.  Zap the condition
+  chain; we would have already warned at this point.  */
+   vec_free (chain);
}
second_body = c_parser_else_body (parser, else_tinfo, chain);
/* Set IF_P to true to indicate that this if statement has an
@@ -6524,12 +6521,9 @@ c_parser_if_statement (c_parser *parser, bool *if_p, 
vec *chain)
"suggest explicit braces to avoid ambiguous %");
  
if (warn_duplicated_cond)

-   {
- /* This if statement does not have an else clause.  We don't
-need the condition chain anymore.  */
- delete chain;
- chain = NULL;
-   }
+   /* This if statement does not have an else clause.  We don't
+  need the condition chain anymore.  */
+   vec_free (chain);
  }
c_finish_if_stmt (loc, cond, first_body, second_body);
add_stmt (c_end_compound_stmt (loc, block, flag_isoc99));
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 5da8670f0e2..d68dcb7d74f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12247,12 +12247,9 @@ cp_parser_selection_statement (cp_parser* parser, bool 
*if_p,
   "init-statement in selection statements only available "
   "with %<-std=c++17%> or %<-std=gnu++17%>");
if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
- {
-   /* A non-empty init-statement can have arbitrary side
-  effects.  */
-   delete chain;
-   chain = NULL;
- }
+ /* A non-empty init-statement can have arbitrary side
+effects.  */
+ vec_free (chain);
cp_parser_init_statement (parser, );
  }
  
@@ -12343,13 +12340,10 @@ cp_parser_selection_statement (cp_parser* parser, bool *if_p,

  }
else if (!cp_lexer_next_token_is_keyword (parser->lexer,
  RID_IF))
- {
-   /* This is if-else without subsequent if.  Zap the
-  condition chain; we would have already warned at
-  this point.  */
-   delete chain;
-   chain = NULL;
- }
+ /* This is if-else without subsequent if.  Zap the
+condition chain; we would have already warned at
+this point.  */
+ vec_free (chain);
  }
begin_else_clause (statement);
/* Parse the else-clause.  */
@@ -12384,11 +12378,8 @@ cp_parser_selection_statement (cp_parser* parser, bool 
*if_p,
  "suggest explicit braces to avoid ambiguous"
  " %");
if (warn_duplicated_cond)
- {
-   /* We don't need the condition chain anymore.  */
-   delete chain;
-   chain = NULL;
- }
+ /* We don't need the condition chain anymore.  */
+ vec_free (chain);
  }
  
  	/* Now we're all done with the if-statement.  */


base-commit: 3df5b249b3c81e95cdcb293a388155ae5b168f9e

[committed] add test for PR 92879

[Martin Sebor via Gcc-patches]

The bug was resolved by r11-4745.  I pushed the test in r11-7180.

Martin
commit 21c6ad7a12fecc4c85ac26289d9096379b550585
Author: Martin Sebor 
Date:   Wed Feb 10 14:42:22 2021 -0700

Add test for PR tree-optimization/92879.

gcc/testsuite/ChangeLog:

PR tree-optimization/92879
* g++.dg/warn/Warray-bounds-16.C: New test.

diff --git a/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
new file mode 100644
index 000..17b4d0d194e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
@@ -0,0 +1,29 @@
+/* PR tree-optimization/92879 - incorrect warning of __builtin_memset
+   offset is out of the bounds on zero-size allocation and initialization
+   { dg-do compile }
+   { dg-options "-O2 -Wall -fdump-tree-optimized" } */
+
+inline void* operator new (__SIZE_TYPE__, void * v)
+{
+  return v;
+}
+
+struct S
+{
+  int* p;
+  int m;
+
+  S (int i)
+  {
+m = i;
+p = (int*) new unsigned char [sizeof (int) * m];
+
+for (int i = 0; i < m; i++)
+  new (p + i) int ();
+  }
+};
+
+S a (0);
+
+/* Verify the loop has been eliminated.
+   { dg-final { scan-tree-dump-not "goto" "optimized" } } */

Re: [PATCH] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

[Joseph Myers]

On Wed, 10 Feb 2021, Marek Polacek via Gcc-patches wrote:

> Freeing the condition chain needs to use vec_free which does ->release,
> or we leak memory.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
> gcc/c/ChangeLog:
> 
>   * c-parser.c (c_parser_if_statement): Use vec_free.

The C front-end changes are OK.

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

Re: [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns

[Richard Sandiford via Gcc-patches]

Joel Hutton  writes:
> @@ -277,6 +277,81 @@ optab_for_tree_code (enum tree_code code, const_tree 
> type,
>  }
>  }
>  
> +/* Function supportable_half_widening_operation
> +

I realise existing (related) functions do have a “Function foo” line,
but it's not generally the GCC style, so I think it would be better
to leave it out.

> +   Check whether an operation represented by code is a 'half' widening 
> operation

Nit: CODE should be in caps since it's a parameter name.

> +   using only half of the full vector width for the inputs. This allows the

I think this could be misread as saying that we only look at half the
input vector.  Maybe it would be clearer to say something like “in which
the input vectors contain half as many bits as the output vectors”
instead of “using…”.

> +   output to be stored in a single vector, as opposed to using the full width
> +   for input, where half the elements must be processed at a time into
> +   respective full-width vector outputs i.e. a 'hi'/'lo' pair using codes 
> such
> +   as VEC_WIDEN_MINUS_HI/LO. This is handled by widening the inputs and using
> +   non-widening instructions. RTL fusing converts these to the widening 
> hardware
> +   instructions if supported.

And here the contrast is with cases in which the input vectors have
the same number of bits as the output vectors, meaning that we need
a lo/hi pair to generate twice the amount of output data.

Might be clearer to make “This is handled…” a new paragraph.

> +
> +   Supported widening operations:
> +WIDEN_MINUS_EXPR
> +WIDEN_PLUS_EXPR
> +WIDEN_MULT_EXPR
> +WIDEN_LSHIFT_EXPR
> +
> +   Output:
> +   - CODE1 - The non-widened code, which will be used after the inputs are
> + converted to the wide type.
> +   */

Formatting nit, */ should be on the previous line, i.e. “.” + two spaces
+ “*/”.  (Sorry for all the formatting comments.)

> +bool
> +supportable_half_widening_operation (enum tree_code code,
> +tree vectype_out, tree vectype_in,
> +enum tree_code *code1)
> +{
> +  machine_mode m1,m2;
> +  bool truncp;
> +  enum tree_code dummy_code;
> +  optab op;
> +
> +  gcc_assert (VECTOR_TYPE_P (vectype_out) && VECTOR_TYPE_P (vectype_in));
> +
> +  m1 = TYPE_MODE (vectype_out);
> +  m2 = TYPE_MODE (vectype_in);
> +
> +  if (!VECTOR_MODE_P (m1) || !VECTOR_MODE_P (m2))
> +return false;
> +
> +  if(!known_eq (TYPE_VECTOR_SUBPARTS (vectype_in),
> +   TYPE_VECTOR_SUBPARTS (vectype_out)))
> +  return false;

Formatting nit: should be a space between “if” and “(”.  IMO
maybe_ne is more readable than !known_eq.  The return statement
should only be indented by 4 columns.

> +  if(!(code == WIDEN_MINUS_EXPR
> +   || code == WIDEN_PLUS_EXPR
> +   || code == WIDEN_MULT_EXPR
> +   || code == WIDEN_LSHIFT_EXPR))
> +return false;
> +
> +  switch (code)
> +  {
> +case WIDEN_LSHIFT_EXPR:
> +  *code1 = LSHIFT_EXPR;
> +  break;
> +case WIDEN_MINUS_EXPR:
> +  *code1 = MINUS_EXPR;
> +  break;
> +case WIDEN_PLUS_EXPR:
> +  *code1 = PLUS_EXPR;
> +  break;
> +case WIDEN_MULT_EXPR:
> +  *code1 = MULT_EXPR;
> +  break;
> +default:
> +  gcc_unreachable ();

I think it would be better to return false in the default case and remove
the “if” above, so that we only have one copy of the list of codes.

> +  }

Formatting nit: the { and } lines should be indented two spaces more.
(The contents of the switch are OK as-is.)

> +
> +  if (!supportable_convert_operation(NOP_EXPR, vectype_out, vectype_in,
> +  _code))

Nit: should be a space between the function name and ”(”.

> +return false;
> +
> +  op = optab_for_tree_code (*code1, vectype_out, optab_vector);
> +  return (optab_handler (op, TYPE_MODE (vectype_out)) != CODE_FOR_nothing);
> +}
> +
>  /* Function supportable_convert_operation
>  
> Check whether an operation represented by the code CODE is a

> […]
> @@ -4697,7 +4755,13 @@ vectorizable_conversion (vec_info *vinfo,
>nunits_in = TYPE_VECTOR_SUBPARTS (vectype_in);
>nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
>if (known_eq (nunits_out, nunits_in))
> -modifier = NONE;
> +if (code == WIDEN_MINUS_EXPR
> + || code == WIDEN_PLUS_EXPR
> + || code == WIDEN_LSHIFT_EXPR
> + || code == WIDEN_MULT_EXPR)
> + modifier = WIDEN;

The “modifier = WIDEN;” line is indented by a tab (i.e. 8 columns),
but it should only be indented by 6 spaces.

> +else
> +  modifier = NONE;
>else if (multiple_p (nunits_out, nunits_in))
>  modifier = NARROW;
>else
> @@ -4743,9 +4807,16 @@ vectorizable_conversion (vec_info *vinfo,
>return false;
>  
>  case WIDEN:
> -  if (supportable_widening_operation (vinfo, code, stmt_info, 
> vectype_out,
> -   vectype_in, , ,
> -   _step_cvt, _types))
> +  if 

Re: Patch for PR analyzer/98797

[brian.sobulefsky via Gcc-patches]

I apologize. I left a dangling space in the patch. I am guessing
that this is against whitespace policy. I had actually corrected
it but forgot to add the file to the commit. Please see the
attached.commit a9b60f36b499463b49095f28ce8053f6387c506d
Author: Brian Sobulefsky 
Date:   Tue Feb 9 16:25:43 2021 -0800

Address the bug found in test file gcc/testsuite/gcc.dg/analyzer/casts-1.c, as
recorded by the XFAIL, and some simpler and more complex versions found during
the investigation of it. PR analyzer/98797 was opened for these bugs.

The simplest manifestation of this bug can be replicated with:

char arr[] = {'A', 'B', 'C', 'D'};
char *pt = ar;
__analyzer_eval(*(pt + 0) == 'A');
__analyzer_eval(*(pt + 1) == 'B');
//etc

The result of the eval call is "UNKNOWN" because the analyzer is unable to
determine the value at the pointer. Note that array access (such as arr[0]) is
correctly handled. The code responsible for this is in file
region-model-manager.cc, function region_model_manager::maybe_fold_sub_svalue.
The relevant section is commented /* Handle getting individual chars from
STRING_CST */. This section only had a case for an element_region. A case
needed to be added for an offset_region.

Additionally, when the offset was 0, such as in *pt or *(pt + 0), the function
region_model_manager::get_offset_region was failing to make the needed offset
region at all. This was due to the test for a constant 0 pointer that was then
returning get_cast_region. A special case is needed for when PARENT is of type
array_type whose type matches TYPE. In this case, get_offset_region is allowed
to continue to normal conclusion.

The original bug noted in gcc/testsuite/gcc.dg/analyzer/casts-1.c was for the
case:

struct s1
{
  char a;
  char b;
  char c;
  char d;
};

struct s2
{
  char arr[4];
};

struct s2 x = {{'A', 'B', 'C', 'D'}};
struct s1 *p = (struct s1 *)
__analyzer_eval (p->a == 'A');
//etc

This requires a case added to region_model_manager::maybe_fold_sub_svalue in
the individual characters from string constant section for a field region.

Finally, the prior only works for the case where struct s2 was a single field
struct. The more general case is:

struct s2
{
  char arr1[2];
  char arr2[2];
};

struct s2 x = {{'A', 'B'}, {'C', 'D'}};

Here the array will never be found in the get_any_binding routines. A new
routine is added to class binding_cluster that checks if the region being
searched is a field_region of a cast_region, and if so, tries to find a field
of the original region that contains the region under examination. This new
function is named binding_cluster::get_parent_cast_binding. It is called from
get_binding_recursive.

gcc/analyzer/ChangeLog:
PR analyzer/98797
* region-model-manager.cc region_model_manager::get_offset_region: Add
check for a PARENT array whose type matches TYPE, and have this skip
returning get_cast_region and rather conclude the function normally.
* region-model-manager.cc region_model_manager::maybe_fold_sub_svalue
Update the get character from string_cst section to include cases for
an offset_region and a field_region.
* store.cc binding_cluster::get_binding_recursive: Add case for call
to new function get_parent_cast_binding.
* store.cc binding_cluster::get_parent_cast_binding: New function.
* store.h class binding_cluster: Add declaration for new member
function get_parent_class_binding and macros for bit to byte
conversion.

gcc/testsuite/ChangeLog:
PR analyzer/98797
* gcc.dg/analyzer/casts-1.c: Update file to no longer expect failures
and add test cases for additional bugs solved.

diff --git a/gcc/analyzer/region-model-manager.cc b/gcc/analyzer/region-model-manager.cc
index dfd2413e914..1fd6b94f20a 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -602,16 +602,46 @@ region_model_manager::maybe_fold_sub_svalue (tree type,
   /* Handle getting individual chars from a STRING_CST.  */
   if (tree cst = parent_svalue->maybe_get_constant ())
 if (TREE_CODE (cst) == STRING_CST)
-  if (const element_region *element_reg
+  {
+	if (const element_region *element_reg
 	= subregion->dyn_cast_element_region ())
-	{
-	  const svalue *idx_sval = element_reg->get_index ();
-	  if (tree cst_idx = idx_sval->maybe_get_constant ())
-	if (const svalue *char_sval
-		= maybe_get_char_from_string_cst (cst, cst_idx))
-	  return get_or_create_cast (type, char_sval);
-	}
-
+	  {
+	const svalue *idx_sval = element_reg->get_index ();
+	if (tree 

[committed] libcpp: fix ICE comparing macro locations without column info [PR96391]

[David Malcolm via Gcc-patches]

PR preprocessor/96391 describes an ICE in the C++ frontend on:

  #define CONST const
  #define VOID void
  typedef CONST VOID *PCVOID;

where the typedef line occurs after enough code has been compiled
that location_t values are beyond LINE_MAP_MAX_LOCATION_WITH_COLS,
and hence no column numbers are available.

The issue occurs in linemap_compare_locations when comparing the
locations of the "const" and "void" tokens.
Upon resolving the LRK_MACRO_EXPANSION_POINT, both have the same
location_t, the line of the "typedef" (with no column), and so
the l0 == l1 clause is triggered, but they are not from the
same macro expansion, leading first_map_in_common to return NULL
and triggering the "abort" condition.

This patch fixes the issue by checking when the two macro expansion
point location_t values are equal that the value
<= LINE_MAP_MAX_LOCATION_WITH_COLS and thus has column information,
fixing the issue.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7179-g1f5c80883efce5242d892eb771ebb60830d20e0f

gcc/testsuite/ChangeLog:
PR preprocessor/96391
* g++.dg/plugin/location-overflow-test-pr96391.c: New test.
* g++.dg/plugin/plugin.exp (plugin_test_list): Add it,
using the location_overflow_plugin.c from gcc.dg/plugin.

libcpp/ChangeLog:
PR preprocessor/96391
* line-map.c (linemap_compare_locations): Require that
the location be <= LINE_MAP_MAX_LOCATION_WITH_COLS when
treating locations as coming from the same macro expansion.
---
 .../g++.dg/plugin/location-overflow-test-pr96391.c   | 12 
 gcc/testsuite/g++.dg/plugin/plugin.exp   |  2 ++
 libcpp/line-map.c|  3 ++-
 3 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/plugin/location-overflow-test-pr96391.c

diff --git a/gcc/testsuite/g++.dg/plugin/location-overflow-test-pr96391.c 
b/gcc/testsuite/g++.dg/plugin/location-overflow-test-pr96391.c
new file mode 100644
index 000..18169617c0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/plugin/location-overflow-test-pr96391.c
@@ -0,0 +1,12 @@
+/* { dg-options "-fplugin-arg-location_overflow_plugin-value=0x6001" } */
+
+/* We use location_overflow_plugin.c, which injects the case that location_t
+   values have exceeded LINE_MAP_MAX_LOCATION_WITH_COLS, and hence no column
+   numbers are available.  */
+
+/* Verify that we're in column-less mode.  */
+extern unknown_type test; /* { dg-error "-:'unknown_type' does not name a 
type" } */
+
+#define CONST const
+#define VOID void
+typedef CONST VOID *PCVOID;
diff --git a/gcc/testsuite/g++.dg/plugin/plugin.exp 
b/gcc/testsuite/g++.dg/plugin/plugin.exp
index 80c5355fb5e..5cd4b4bff90 100644
--- a/gcc/testsuite/g++.dg/plugin/plugin.exp
+++ b/gcc/testsuite/g++.dg/plugin/plugin.exp
@@ -72,6 +72,8 @@ set plugin_test_list [list \
  ../../gcc.dg/plugin/diagnostic-test-string-literals-2.c \
  ../../gcc.dg/plugin/diagnostic-test-string-literals-3.c \
  ../../gcc.dg/plugin/diagnostic-test-string-literals-4.c } \
+{ ../../gcc.dg/plugin/location_overflow_plugin.c \
+ location-overflow-test-pr96391.c } \
 { show_template_tree_color_plugin.c \
  show-template-tree-color.C \
  show-template-tree-color-labels.C \
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 2432cd50d26..cccacf2fe5b 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -1417,7 +1417,8 @@ linemap_compare_locations (line_maps *set,
 
   if (l0 == l1
   && pre_virtual_p
-  && post_virtual_p)
+  && post_virtual_p
+  && l0 <= LINE_MAP_MAX_LOCATION_WITH_COLS)
 {
   /* So pre and post represent two tokens that are present in a
 same macro expansion.  Let's see if the token for pre was
-- 
2.26.2

Re: [PATCH] libstdc++: Update baseline symbols for {aarch64, ia64, m68k, powerpc, powerpc64, riscv64}-linux

[Jonathan Wakely via Gcc-patches]

There are some changes needed for ppc64 before the gcc11 release.



On Wed, 10 Feb 2021, 13:10 Andreas Schwab,  wrote:

> These are the lists I could test.
>
> libstdc++-v3/
> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
> Update.
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
> ---
>  .../aarch64-linux-gnu/baseline_symbols.txt| 104 +++
>  .../post/ia64-linux-gnu/baseline_symbols.txt  | 121 ++
>  .../post/m68k-linux-gnu/baseline_symbols.txt  | 121 ++
>  .../powerpc-linux-gnu/baseline_symbols.txt| 109 
>  .../32/baseline_symbols.txt   | 109 
>  .../powerpc64-linux-gnu/baseline_symbols.txt  | 109 
>  .../riscv64-linux-gnu/baseline_symbols.txt| 116 +
>  7 files changed, 789 insertions(+)
>
> diff --git
> a/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
> b/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
> index 089537d5ddf..45f1540ca11 100644
> --- a/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/aarch64-linux-gnu/baseline_symbols.txt
> @@ -199,6 +199,14 @@
> FUNC:_ZNK11__gnu_debug16_Error_formatter17_M_get_max_lengthEv@
> @GLIBCXX_3.4.10
>  FUNC:_ZNK11__gnu_debug16_Error_formatter8_M_errorEv@@GLIBCXX_3.4
>  FUNC:_ZNK11__gnu_debug19_Safe_iterator_base11_M_singularEv@@GLIBCXX_3.4
>  FUNC:_ZNK11__gnu_debug19_Safe_iterator_base14_M_can_compareERKS0_@
> @GLIBCXX_3.4
> +FUNC:_ZNKRSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.29
> +FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5
>  FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4
>  FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwm@@GLIBCXX_3.4
> @@ -856,19 +864,29 @@
> FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE8capacityEv@
> @GLIBCXX_
>  FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE8max_sizeEv@
> @GLIBCXX_3.4.21
>
>  
> FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEcvSt17basic_string_viewIwS2_EEv@
> @GLIBCXX_3.4.26
>  FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEixEm@
> @GLIBCXX_3.4.21
>
> +FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE4viewEv@
> @GLIBCXX_3.4.29
>
> +FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE4viewEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE4viewEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@
> @GLIBCXX_3.4.21
>  FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE4viewEv@
> @GLIBCXX_3.4.29
>  FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE5rdbufEv@
> @GLIBCXX_3.4.21
>  FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE4viewEv@
> @GLIBCXX_3.4.29
>
>  FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@
> @GLIBCXX_3.4.21
>  FUNC:_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv@
> @GLIBCXX_3.4.21
> +FUNC:_ZNKSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE4viewEv@
> @GLIBCXX_3.4.29
>
>  

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

[Martin Sebor via Gcc-patches]

On 2/10/21 3:39 AM, Richard Biener wrote:

On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor  wrote:


On 2/9/21 12:41 AM, Richard Biener wrote:

On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
 wrote:


On 2/8/21 12:09 PM, Jeff Law wrote:



On 2/3/21 3:45 PM, Martin Sebor wrote:

On 2/3/21 2:57 PM, Jeff Law wrote:



On 1/28/21 4:03 PM, Martin Sebor wrote:

The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion.  When the warning is issued for
an access to an in-bounds member via a pointer to a struct that's
larger than the pointed-to object, phrasing this strictly invalid
access in terms of array subscripts can be misleading, especially
when the source code doesn't involve any arrays or indexing.

Since the problem boils down to an aliasing violation much more
so than an actual out-of-bounds access, the attached patch adjusts
the code to issue a -Wstrict-aliasing warning in these cases instead
of -Warray-bounds.  In addition, since the aliasing assumptions in
GCC can be disabled by -fno-strict-aliasing, the patch also makes
these instances of the warning conditional on -fstrict-aliasing
being in effect.

Martin

gcc-98503.diff

PR middle-end/98503 -Warray-bounds when -Wstrict-aliasing would be
more appropriate

gcc/ChangeLog:

   PR middle-end/98503
   * gimple-array-bounds.cc (array_bounds_checker::check_mem_ref):
   Issue -Wstrict-aliasing for a subset of violations.
   (array_bounds_checker::check_array_bounds):  Set new member.
   * gimple-array-bounds.h (array_bounds_checker::cref_of_mref): New
   data member.

gcc/testsuite/ChangeLog:

   PR middle-end/98503
   * g++.dg/warn/Warray-bounds-10.C: Adjust text of expected warnings.
   * g++.dg/warn/Warray-bounds-11.C: Same.
   * g++.dg/warn/Warray-bounds-12.C: Same.
   * g++.dg/warn/Warray-bounds-13.C: Same.
   * gcc.dg/Warray-bounds-63.c: Avoid -Wstrict-aliasing.  Adjust text
   of expected warnings.
   * gcc.dg/Warray-bounds-66.c: Adjust text of expected warnings.
   * gcc.dg/Wstrict-aliasing-2.c: New test.
   * gcc.dg/Wstrict-aliasing-3.c: New test.

What I don't like here is the strict-aliasing warnings inside the file
and analysis phase for array bounds checking.

ISTM that catching this at cast time would be better.  So perhaps in
build_c_cast and the C++ equivalent?

It would mean we're warning at the cast site rather than the
dereference, but that may ultimately be better for the warning anyway.
I'm not sure.


I had actually experimented with a this (in the middle end, and only
for accesses) but even that caused so many warnings that I abandoned
it, at least for now.  -Warray-bounds has the benefit of flow analysis
(and dead code elimination).  In the front end it would have neither
and be both excessively noisy and ineffective at the same time.  For
example:

I think we agree that this really is an aliasing issue and I would go
further and claim that it has nothing to do with array bounds checking.
Therefore warning for it within gimple-array-bounds just seems wrong.

I realize that you like having DCE run and the ability to look at
offsets and such, but it really feels like the wrong place to do this.
Aliasing issues are also more of a front-end thing since the language
defines what is and what is not valid aliasing -- one might even argue
that any aliasing warning needs to be identified by the front-ends
exclusively (though possibly pruned away later).


The aliasing restrictions are on accesses, which are [defined in
C as] execution-time actions on objects.  Analyzing execution-time
actions unavoidably depends on flow analysis which the front ends
have only very limited support for (simple expressions only).
I gave one example showing how the current -Wstrict-aliasing in
the front end is ineffective against all but the most simplistic
bugs, but there are many more.  For instance:

 int i;
 void *p = // valid
 float *q = p;// valid
 *q = 0;  // aliasing violation

This bug is easily detectable in the middle end but impossible
to do in the front end (same as all other invalid accesses).


But the code is valid in GIMPLE which allows to re-use the 'int i' storage
with storing using a different type.


Presumably you're referring to using placement new?


No, I'm refering to the rules the GIMPLE IL follows.  GIMPLE is no
longer C or C++ and thus what is invalid in C or C++ doesn't
necessarily have to be invalid in GIMPLE.


  The warning
would have to be aware of it and either run before placement new
is inlined.  Alternatively, the inlining could add some annotation
into the IL that the warning would then use to differentiate valid
code from invalid.


At least in old versions of the C++ standard a simple "re-use" of
storage starts lifetime of a new object (for certain classes of types,
'int' for example), so no placement new is needed 

Re: PR 96391? Can we fix it for gcc11?

[Qing Zhao via Gcc-patches]

> On Feb 9, 2021, at 11:36 AM, Richard Biener  wrote:
> 
> On Tue, 9 Feb 2021, Qing Zhao wrote:
> 
>> Richard,
>> 
>> Thank you for the reply.
>> 
>> Yes, I understand that without a working testing case to repeat the error, 
>> it’s very hard to debug and fix the issue. 
>> 
>> However, providing a testing case for this bug is really challenging from 
>> our side due to multiple reasons…
>> 
>> I will discuss with our building engineer to see what we can do. Or, I will 
>> try to debug and fix this issue myself…
> 
> Note you can try reducing a proprietary testcase with tools like
> cvise or creduce.
Thanks for the suggestions. 

>  Does your case also happen in a mingw/windows
> environment?

Our application is compiled in linux environment. 
Right now, looks like that David Malcolm already can repeat the error and is 
able to debug it right now.

Hopefully this can be fixed soon.

Thanks a lot.

Qing
> 
> Richard.
> 
>> 
>> Qing
>> 
>>> On Feb 9, 2021, at 2:18 AM, Richard Biener >> > wrote:
>>> 
>>> On Mon, 8 Feb 2021, Qing Zhao wrote:
>>> 
 Hi, 
 
 The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 
  
 > 
 >>
 
 Bug 96391 - [10/11 Regression] internal compiler error: in 
 linemap_compare_locations, at libcpp/line-map.c:1359 
 
 has been opened on 7/30/2020, and multiple users reported the same issue. 
 
 For our important application, all the C++ modules failed with this bug 
 when we use gcc10 or gcc11. Then we have 
 To use icc to compile C++, and gcc to compile C, it’s very inconvenient. 
 
 I have raised the priority of this bug to P2 on 10/09/2020,  hope it can 
 be fixed in gcc11. 
 
 I see that Michael Cronenworth has attached a preprocessed file for the 
 reproducing purpose in comment 4. 
 
 So, can we have the fix of the bug in gcc11?
>>> 
>>> The issue is that the preprocessed source does not reproduce the issue and
>>> a mingw development environment is not easily accessible (to me at least).
>>> 
>>> So unless you can reproduce this in a standard linux environment and can
>>> provide a testcase I don't see a way to get this bug forward.
>>> 
>>> Richard.
>>> 
 Thanks a lot.
 
 Qing
>>> 
>>> -- 
>>> Richard Biener mailto:rguent...@suse.de> 
>>> >>
>>> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
>>> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
>> 
>> 
> 
> -- 
> Richard Biener mailto:rguent...@suse.de>>
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH v3] arm: Low overhead loop handle long range branches [PR98931]

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> "Richard Earnshaw (lists)"  writes:
>
>> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>>> Jakub Jelinek  writes:
>>> 
 On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches 
 wrote:
>>"TARGET_32BIT && TARGET_HAVE_LOB"
>> -  "le\t%|lr, %l0")
>> +  "*
>> +  if (get_attr_length (insn) == 4)
>> +return \"le\\t%|lr, %l0\";
>> +  else
>> +return \"subs\\t%|lr, #1\;bne\\t%l0\";
>> +  "
>
> Why not
> {
>   if (get_attr_length (insn) == 4)
> return "le\t%|lr, %l0";
>   else
> return "subs\t%|lr, #1;bne\t%l0";
> }
> instead?  Seems the arm backend uses "*..." more than the more modern {},
> but one needs to backslash prefix a lot which makes it less readable?

 Where "more modern" is introduced 19.5 years ago ;)

Jakub
>>> 
>>> I guess we really like traditions :)
>>> 
>>> Attached second version addressing this.
>>> 
>>> Thanks
>>> 
>>>   Andrea
>>> 
>>
>> You're missing a clobber of the condition codes in the RTL.  This wasn't
>> needed before, but is now.
>>
>> R.
>
> Hi Richard,
>
> thanks for reviewing, I guess this is going to be a good learning moment
> for me.
>
> What we originally expand is:
>
> (insn 2396 2360 2397 3 (parallel [
> (set (reg:CC_NZ 100 cc)
> (compare:CC_NZ (plus:SI (reg:SI 14 lr)
> (const_int -1 [0x]))
> (const_int 0 [0])))
> (set (reg:SI 14 lr)
> (plus:SI (reg:SI 14 lr)
> (const_int -1 [0x])))
> ]) "p1.c":4:21 -1
>  (nil))
> (jump_insn 2397 2396 2365 3 (set (pc)
> (if_then_else (ne (reg:CC_NZ 100 cc)
> (const_int 0 [0]))
> (label_ref:SI 2361)
> (pc))) "p1.c":4:21 273 {arm_cond_branch}
>  (expr_list:REG_DEAD (reg:CC_NZ 100 cc)
> (int_list:REG_BR_PROB 1062895996 (nil)))
>  -> 2361)
>
> Combine recognizing cc:CC_NZ as a dead reg and rewriting the two insns
> as:
>
> (jump_insn 2397 2396 2365 3 (parallel [
> (set (pc)
> (if_then_else (ne (reg:SI 14 lr)
> (const_int 1 [0x1]))
> (label_ref:SI 2361)
> (pc)))
> (set (reg:SI 14 lr)
> (plus:SI (reg:SI 14 lr)
> (const_int -1 [0x])))
> ]) "p1.c":4:21 1047 {*doloop_end_internal}
>  (int_list:REG_BR_PROB 1062895996 (nil))
>  -> 2361)
>
> I originally thought that because the write of reg:CC_NZ is explicit in
> the first pattern we expand this was sufficient, but I now understand
> I'm wrong and combine should produce a pattern still expressing this.
> Now the question is how to do that.
>
> If I add the clobber '(clobber (reg:CC CC_REGNUM))' inside the parallel
> of *doloop_end_internal as last element of the vector we ICE in
> 'add_clobbers' called during combine, apparently 'add_clobbers' does not
> handle the insn_code_number.
>
> If I add it as second element of the parallel combine is not combining
> the two insns.
>
> If I place the clobber outside the parallel as a second element of the
> insn vector combine is crashing in 'recog_for_combine_1'.
>
> So the question is probably: where should the clobber be positioned
> canonically to have this working?
>
> Thanks!
>
>   Andrea

Righ, I've been explained by a knowledgeable colleague that the
'parallel' is implicit in the 'define_insn' and there's no need to
express it (interestgly this is confusing the code generating
'add_clobbers').

The attached patch rewrites the pattern as such and adds the missing
clobber.

Tests are running, okay for trunk when done with these?

Regards

  Andrea

>From c822f9374f1c16a0f863ca521fd87a350b616db4 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 3 Feb 2021 15:21:54 +0100
Subject: [PATCH] arm: Low overhead loop handle long range branches [PR98931]

gcc/ChangeLog

2021-02-05  Andrea Corallo  

* config/arm/thumb2.md (*doloop_end_internal): Generate
alternative sequence to handle long range branches.

gcc/testsuite/Changelog

2021-02-08  Andrea Corallo  

 * gcc.target/arm/pr98931.c: New testcase.
---
 gcc/config/arm/thumb2.md   | 28 ++
 gcc/testsuite/gcc.target/arm/pr98931.c | 17 
 2 files changed, 37 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/pr98931.c

diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index bd53bf320de..320fe998075 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1711,15 +1711,27 @@
 
 ;; Originally expanded by 'doloop_end'.
 (define_insn "*doloop_end_internal"
-  [(parallel [(set (pc)
-   (if_then_else
-   (ne (reg:SI LR_REGNUM) (const_int 1))
- (label_ref 

[PATCH] c, c++: Plug -Wduplicated-cond memory leaks [PR99057]

[Marek Polacek via Gcc-patches]

Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.

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

gcc/c/ChangeLog:

* c-parser.c (c_parser_if_statement): Use vec_free.

gcc/cp/ChangeLog:

* parser.c (cp_parser_selection_statement): Use vec_free.
---
 gcc/c/c-parser.c | 18 ++
 gcc/cp/parser.c  | 27 +--
 2 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index a8df208493c..2a49d07bab4 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -6499,12 +6499,9 @@ c_parser_if_statement (c_parser *parser, bool *if_p, 
vec *chain)
chain->safe_push (cond);
}
  else if (!c_parser_next_token_is_keyword (parser, RID_IF))
-   {
- /* This is if-else without subsequent if.  Zap the condition
-chain; we would have already warned at this point.  */
- delete chain;
- chain = NULL;
-   }
+   /* This is if-else without subsequent if.  Zap the condition
+  chain; we would have already warned at this point.  */
+   vec_free (chain);
}
   second_body = c_parser_else_body (parser, else_tinfo, chain);
   /* Set IF_P to true to indicate that this if statement has an
@@ -6524,12 +6521,9 @@ c_parser_if_statement (c_parser *parser, bool *if_p, 
vec *chain)
"suggest explicit braces to avoid ambiguous %");
 
   if (warn_duplicated_cond)
-   {
- /* This if statement does not have an else clause.  We don't
-need the condition chain anymore.  */
- delete chain;
- chain = NULL;
-   }
+   /* This if statement does not have an else clause.  We don't
+  need the condition chain anymore.  */
+   vec_free (chain);
 }
   c_finish_if_stmt (loc, cond, first_body, second_body);
   add_stmt (c_end_compound_stmt (loc, block, flag_isoc99));
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 5da8670f0e2..d68dcb7d74f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12247,12 +12247,9 @@ cp_parser_selection_statement (cp_parser* parser, bool 
*if_p,
   "init-statement in selection statements only available "
   "with %<-std=c++17%> or %<-std=gnu++17%>");
if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
- {
-   /* A non-empty init-statement can have arbitrary side
-  effects.  */
-   delete chain;
-   chain = NULL;
- }
+ /* A non-empty init-statement can have arbitrary side
+effects.  */
+ vec_free (chain);
cp_parser_init_statement (parser, );
  }
 
@@ -12343,13 +12340,10 @@ cp_parser_selection_statement (cp_parser* parser, 
bool *if_p,
  }
else if (!cp_lexer_next_token_is_keyword (parser->lexer,
  RID_IF))
- {
-   /* This is if-else without subsequent if.  Zap the
-  condition chain; we would have already warned at
-  this point.  */
-   delete chain;
-   chain = NULL;
- }
+ /* This is if-else without subsequent if.  Zap the
+condition chain; we would have already warned at
+this point.  */
+ vec_free (chain);
  }
begin_else_clause (statement);
/* Parse the else-clause.  */
@@ -12384,11 +12378,8 @@ cp_parser_selection_statement (cp_parser* parser, bool 
*if_p,
  "suggest explicit braces to avoid ambiguous"
  " %");
if (warn_duplicated_cond)
- {
-   /* We don't need the condition chain anymore.  */
-   delete chain;
-   chain = NULL;
- }
+ /* We don't need the condition chain anymore.  */
+ vec_free (chain);
  }
 
/* Now we're all done with the if-statement.  */

base-commit: 3df5b249b3c81e95cdcb293a388155ae5b168f9e
-- 
2.29.2

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

[Patrick Palka via Gcc-patches]

On Wed, 10 Feb 2021, Jason Merrill wrote:

> On 2/9/21 5:12 PM, Patrick Palka wrote:
> > On Tue, 2 Feb 2021, Jason Merrill wrote:
> > 
> > > On 2/2/21 12:19 AM, Patrick Palka wrote:
> > > > In this testcase, we're crashing because the lookup of operator+ from
> > > > within the generic lambda via lookup_name finds multiple bindings
> > > > (namely C1::operator+ and C2::operator+) and returns a TREE_LIST
> > > > thereof, something which maybe_save_operator_binding isn't prepared to
> > > > handle.
> > > > 
> > > > Since we already discard the result of lookup_name when it returns a
> > > > class-scope binding here, it seems cleaner (and equivalent) to instead
> > > > communicate to lookup_name that we don't want such bindings in the first
> > > > place.  While this change seems like an improvement on its own, it also
> > > > fixes the mentioned PR, because the call to lookup_name now returns
> > > > NULL_TREE rather than a TREE_LIST of (unwanted) class-scope bindings.
> > > > 
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk/9/10?
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > PR c++/97582
> > > > * name-lookup.c (op_unqualified_lookup): Pass BLOCK_NAMESPACE to
> > > > lookup_name in order to ignore class-scope bindings, rather
> > > > than discarding them after the fact.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > PR c++/97582
> > > > * g++.dg/cpp0x/lambda/lambda-template17.C: New test.
> > > > ---
> > > >gcc/cp/name-lookup.c  | 11
> > > > +++
> > > >gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C |  8 
> > > >2 files changed, 11 insertions(+), 8 deletions(-)
> > > >create mode 100644
> > > > gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C
> > > > 
> > > > diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
> > > > index 52e4a630e25..46d6cc0dfa4 100644
> > > > --- a/gcc/cp/name-lookup.c
> > > > +++ b/gcc/cp/name-lookup.c
> > > > @@ -9213,17 +9213,12 @@ op_unqualified_lookup (tree fnname)
> > > > return NULL_TREE;
> > > >}
> > > >-  tree fns = lookup_name (fnname);
> > > > +  /* We don't need to remember class-scope functions or declarations,
> > > > + normal unqualified lookup will find them again.  */
> > > > +  tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);
> > > 
> > > Hmm, I'd expect this to look past class-scope declarations to find
> > > namespace-scope declarations, but we want class decls to hide decls in an
> > > outer scope.
> > 
> > D'oh, good point.  But IIUC, even if we did return (and later inject at
> > instantiation time) namespace-scope declarations that were hidden by
> > class-scope declarations, wouldn't the lookup at instantiation time
> > still find and prefer the class-scope bindings (as desired)?  It seems
> > to me that the end result might be the same, but I'm not sure.
> 
> The injection happens in the function parameter binding level, so I'd expect
> it to be found before class bindings.

Oops, I didn't look at push_operator_bindings closely enough.  Never
mind about that idea then.

> 
> > Alternatively, would it be safe to assume that if lookup_name returns an
> > ambiguous result, then the result must consist of class-scope
> > declarations and so we can discard it?
> 
> That isn't true in general:
> 
> inline namespace A { int i; }
> inline namespace B { int i; }
> int main() { return i; } // ambiguous lookup
> 
> though I think it is true for functions.  But if the result is ambiguous, you
> can look at the first element to see if it's from class scope.

I see, that's good to know.  So something like this?

-- >8 --

Subject: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which op_unqualified_lookup (and
push_operator_bindings) isn't prepared to handle.

This patch makes op_unqualified_lookup and push_operator_bindings handle
an ambiguous lookup result appropriately.

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Handle an ambiguous
lookup result by discarding it if the first element is
a class-scope declaration, otherwise return it.
(push_operator_bindings): Handle an ambiguous lookup result by
doing push_local_binding on each element in the list.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
 gcc/cp/name-lookup.c | 16 
 .../g++.dg/cpp0x/lambda/lambda-template17.C  |  8 
 2 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git 

[PATCH] plug memory leaks in warn_parm_array_mismatch (PR 99055)

[Martin Sebor via Gcc-patches]

The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns a std::string and releases the caller
from the responsibility to explicitly free memory.

With the patch installed, Valgrind shows more leaks in this code that
I'm not sure what to do about:

1) A tree built by build_type_attribute_qual_variant() called from
   attr_access::array_as_string() to build a temporary type only
   for the purposes of formatting it.

2) A tree (an attribute list) built by tree_cons() called from
   build_attr_access_from_parms() that's used only for the duration
   of the caller.

Do these temporary trees need to be released somehow or are the leaks
expected?

Martin

Leak 1:
==7112== 56 bytes in 1 blocks are still reachable in loss record 73 of 691
==7112==at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==7112==by 0x294ED71: xcalloc (xmalloc.c:162)
==7112==by 0xB8B21D: alloc_page(unsigned int) (ggc-page.c:918)
==7112==by 0xB8BAD1: ggc_internal_alloc(unsigned long, void 
(*)(void*), unsigned long, unsigned long) (ggc-page.c:1294)

==7112==by 0x9E1F33: ggc_internal_alloc(unsigned long) (ggc.h:130)
==7112==by 0x198AB1A: ggc_alloc_tree_node_stat(unsigned long) 
(ggc.h:309)

==7112==by 0x193BD18: copy_node(tree_node*) (tree.c:1223)
==7112==by 0x1953BDD: build_distinct_type_copy(tree_node*) (tree.c:6730)
==7112==by 0x9A1379: build_type_attribute_qual_variant(tree_node*, 
tree_node*, int) (attribs.c:1161)
==7112==by 0x9A483D: 
attr_access::array_as_string[abi:cxx11](tree_node*) const (attribs.c:2332)
==7112==by 0xB7C5A7: warn_parm_array_mismatch(unsigned int, 
tree_node*, tree_node*) (c-warn.c:3449)
==7112==by 0xA3EB57: c_parser_declaration_or_fndef(c_parser*, bool, 
bool, bool, bool, bool, tree_node**, vec, 
bool, tree_node*, oacc_routine_data*, bool*) (c-parser.c:2342)



Leak 2:
==7112== 64 bytes in 1 blocks are still reachable in loss record 150 of 691
==7112==at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==7112==by 0x294ED71: xcalloc (xmalloc.c:162)
==7112==by 0xB8B21D: alloc_page(unsigned int) (ggc-page.c:918)
==7112==by 0xB8BAD1: ggc_internal_alloc(unsigned long, void 
(*)(void*), unsigned long, unsigned long) (ggc-page.c:1294)

==7112==by 0x9E1F33: ggc_internal_alloc(unsigned long) (ggc.h:130)
==7112==by 0x198AB1A: ggc_alloc_tree_node_stat(unsigned long) 
(ggc.h:309)
==7112==by 0x19433E6: tree_cons(tree_node*, tree_node*, tree_node*) 
(tree.c:3331)
==7112==by 0xB67188: build_attr_access_from_parms(tree_node*, bool) 
(c-attribs.c:5060)
==7112==by 0xB7C008: warn_parm_array_mismatch(unsigned int, 
tree_node*, tree_node*) (c-warn.c:3364)
==7112==by 0xA3EB57: c_parser_declaration_or_fndef(c_parser*, bool, 
bool, bool, bool, bool, tree_node**, vec, 
bool, tree_node*, oacc_routine_data*, bool*) (c-parser.c:2342)
==7112==by 0xA3D5A9: c_parser_external_declaration(c_parser*) 
(c-parser.c:1777)
==7112==by 0xA3D06A: c_parser_translation_unit(c_parser*) 
(c-parser.c:1650)
PR c/99055 - memory leak in warn_parm_array_mismatch

gcc/c-family/ChangeLog:

	PR c/99055
	* c-warn.c (generic_expr_as_string): New function.
	(warn_parm_array_mismatch): Replace calls to print_generic_expr_to_str
	with generic_expr_as_string.

gcc/ChangeLog:

	* tree-pretty-print.c (print_generic_expr_to_str): Update comment.

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index e6e28d9b139..8cbc598bf6f 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -3319,6 +3319,20 @@ warn_parm_ptrarray_mismatch (location_t origloc, tree curparms, tree newparms)
 }
 }
 
+/* Same as print_generic_expr_to_str but returning std::string to keep
+   callers from having to free memory.  */
+
+static std::string
+generic_expr_as_string (tree expr, const char *dflt = "")
+{
+  if (!expr)
+return dflt;
+
+  pretty_printer pp;
+  dump_generic_node (, expr, 0, TDF_VOPS | TDF_MEMSYMS, false);
+  return std::string (pp_formatted_text ());
+}
+
 /* Detect and diagnose a mismatch between an attribute access specification
on the original declaration of FNDECL and that on the parameters NEWPARMS
from its refeclaration.  ORIGLOC is the location of the first declaration
@@ -3585,10 +3599,8 @@ warn_parm_array_mismatch (location_t origloc, tree fndecl, tree newparms)
 	   the same.  */
 	continue;
 
-	  const char* const newbndstr =
-	newbnd ? print_generic_expr_to_str (newbnd) : "*";
-	  const char* const curbndstr =
-	curbnd ? print_generic_expr_to_str (curbnd) : "*";
+	  std::string newbndstr = generic_expr_as_string (newbnd, "*");
+	  std::string curbndstr = generic_expr_as_string (curbnd, "*");
 
 	  if (!newpos != !curpos
 	  || (newpos && !tree_int_cst_equal (newpos, curpos)))
@@ -3619,7 +3631,7 @@ warn_parm_array_mismatch (location_t origloc, tree fndecl, tree newparms)
  "argument %u of type %s declared "
  "with mismatched bound %<%s%>",
  parmpos + 1, 

New Brazilian Portuguese PO file for 'cpplib' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/pt_BR.po

(This file, 'cpplib-11.1-b20210207.pt_BR.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-11.1-b20210207.pt_BR.po'

[Translation Project Robot]

cpplib-11.1-b20210207.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] c++, v2: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031]

[Jason Merrill via Gcc-patches]

On 2/10/21 10:05 AM, Jakub Jelinek wrote:

On Tue, Feb 09, 2021 at 04:08:03PM -0500, Jason Merrill via Gcc-patches wrote:

They are not in the symtab from the C++ FE.  And we don't allow those VAR_DECLs 
or their
addresses to leak into the IL anyway.
But, they are TREE_STATIC because pretending they are automatic didn't
really work (e.g. address of automatic variables is not a constant expression).
The generic folding code uses maybe_nonzero_address predicate which
apprently creates a symtab entry for them but as nothing uses them they
won't be emitted.


Ah.


If we wanted to avoid that, we'd need to either add some generic VAR_DECL
bit for those vars or add a target hook that would return true for them and
then handle them in the middle-end.


I'm surprised that nonzero_address has such a limited set of things it will
actually believe have non-zero addresses with
-fno-delete-null-pointer-checks.  But it seems that we should be able to
arrange to satisfy


   if (definition && !DECL_EXTERNAL (decl)


since these "variables" are indeed defined within the current translation
unit.


Doing that seems to work and as added benefit it fixes another PR that has
been filed recently.  I need to create the varpool node explicitly and call
a method that sets the definition member in there, but I can also unregister
those varpool nodes at the end of constexpr processing, as the processing
ensured they don't leak outside of the processing.

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

2021-02-10  Jakub Jelinek  

PR c++/98988
PR c++/99031
* constexpr.c: Include cgraph.h.
(cxx_eval_call_expression): Call varpool_node::finalize_decl on
heap artificial vars.
(cxx_eval_outermost_constant_expr): Remove varpool nodes for
heap artificial vars.

* g++.dg/cpp2a/constexpr-new16.C: New test.
* g++.dg/cpp2a/constexpr-new17.C: New test.

--- gcc/cp/constexpr.c.jj   2021-02-09 10:05:28.820833601 +0100
+++ gcc/cp/constexpr.c  2021-02-10 11:31:16.567984809 +0100
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.
  #include "timevar.h"
  #include "fold-const-call.h"
  #include "stor-layout.h"
+#include "cgraph.h"
  
  static bool verify_constant (tree, bool, bool *, bool *);

  #define VERIFY_CONSTANT(X)\
@@ -2340,6 +2341,7 @@ cxx_eval_call_expression (const constexp
 type);
  DECL_ARTIFICIAL (var) = 1;
  TREE_STATIC (var) = 1;
+ varpool_node::finalize_decl (var);


Please add a comment that this is for nonzero_address.  OK with that change.


  ctx->global->heap_vars.safe_push (var);
  ctx->global->values.put (var, NULL_TREE);
  return fold_convert (ptr_type_node, build_address (var));
@@ -7199,15 +7201,18 @@ cxx_eval_outermost_constant_expr (tree t
  non_constant_p = true;
}
FOR_EACH_VEC_ELT (global_ctx.heap_vars, i, heap_var)
-   if (DECL_NAME (heap_var) != heap_deleted_identifier)
- {
-   if (!allow_non_constant && !non_constant_p)
- error_at (DECL_SOURCE_LOCATION (heap_var),
-   "%qE is not a constant expression because allocated "
-   "storage has not been deallocated", t);
-   r = t;
-   non_constant_p = true;
- }
+   {
+ if (DECL_NAME (heap_var) != heap_deleted_identifier)
+   {
+ if (!allow_non_constant && !non_constant_p)
+   error_at (DECL_SOURCE_LOCATION (heap_var),
+ "%qE is not a constant expression because allocated "
+ "storage has not been deallocated", t);
+ r = t;
+ non_constant_p = true;
+   }
+ varpool_node::get (heap_var)->remove ();
+   }
  }
  
/* Check that immediate invocation does not return an expression referencing

--- gcc/testsuite/g++.dg/cpp2a/constexpr-new16.C.jj 2021-02-10 
11:11:00.117658382 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-new16.C2021-02-10 
11:11:00.117658382 +0100
@@ -0,0 +1,13 @@
+// PR c++/98988
+// { dg-do compile { target c++20 } }
+// { dg-options "-fno-delete-null-pointer-checks" }
+
+constexpr bool
+foo ()
+{
+  auto ptr = new int();
+  delete ptr;
+  return true;
+}
+
+static_assert (foo ());
--- gcc/testsuite/g++.dg/cpp2a/constexpr-new17.C.jj 2021-02-10 
13:04:17.947606440 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-new17.C2021-02-10 
13:04:06.417738050 +0100
@@ -0,0 +1,15 @@
+// PR c++/99031
+// { dg-do compile { target c++20 } }
+
+constexpr bool
+foo ()
+{
+  auto a = new int;
+  auto b = new int;
+  bool r = a == b;
+  delete b;
+  delete a;
+  return r;
+}
+
+static_assert (!foo ());


Jakub

[committed] libstdc++: Re-enable workaround for _wstat64 bug [PR 88881]

[Jonathan Wakely via Gcc-patches]

This wasn't fixed upstream for mingw-w64 so we still need the
workaround.

libstdc++-v3/ChangeLog:

PR libstdc++/1
* src/c++17/fs_ops.cc (fs::status): Re-enable workaround.

Tested x86_64-w64-mingw32. Committed to trunk.

commit 3df5b249b3c81e95cdcb293a388155ae5b168f9e
Author: Jonathan Wakely 
Date:   Wed Feb 10 16:51:34 2021

libstdc++: Re-enable workaround for _wstat64 bug [PR 1]

This wasn't fixed upstream for mingw-w64 so we still need the
workaround.

libstdc++-v3/ChangeLog:

PR libstdc++/1
* src/c++17/fs_ops.cc (fs::status): Re-enable workaround.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 7deb4c33447..3817655471c 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -1462,7 +1462,6 @@ fs::status(const fs::path& p, error_code& ec) noexcept
   auto str = p.c_str();
 
 #if _GLIBCXX_FILESYSTEM_IS_WINDOWS
-#if ! defined __MINGW64_VERSION_MAJOR || __MINGW64_VERSION_MAJOR < 6
   // stat() fails if there's a trailing slash (PR 1)
   path p2;
   if (p.has_relative_path() && !p.has_filename())
@@ -1479,7 +1478,6 @@ fs::status(const fs::path& p, error_code& ec) noexcept
}
   str = p2.c_str();
 }
-#endif
 #endif
 
   stat_type st;

[committed] libstdc++: Use correct error category for Windows error codes

[Jonathan Wakely via Gcc-patches]

When the result of GetLastError() is stored in a std::error_code it
should use std::system_category(), not std::generic_category() that is
used for POSIX errno values.

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (fs::create_hard_link, fs::equivalent)
(fs::remove): Use std::system_category() for error codes from
GetLastError().
* src/filesystem/ops.cc (fs::create_hard_link, fs::remove):
Likewise.

Tested x86_64-w64-mingw32. Committed to trunk.

commit 313e2dc377d07d5fae5a3fd666ad7000d7e8771d
Author: Jonathan Wakely 
Date:   Wed Feb 10 16:45:38 2021

libstdc++: Use correct error category for Windows error codes

When the result of GetLastError() is stored in a std::error_code it
should use std::system_category(), not std::generic_category() that is
used for POSIX errno values.

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (fs::create_hard_link, fs::equivalent)
(fs::remove): Use std::system_category() for error codes from
GetLastError().
* src/filesystem/ops.cc (fs::create_hard_link, fs::remove):
Likewise.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 04a559ab1d6..7deb4c33447 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -690,7 +690,7 @@ fs::create_hard_link(const path& to, const path& 
new_hard_link,
   if (CreateHardLinkW(new_hard_link.c_str(), to.c_str(), NULL))
 ec.clear();
   else
-ec.assign((int)GetLastError(), generic_category());
+ec.assign((int)GetLastError(), system_category());
 #else
   ec = std::make_error_code(std::errc::not_supported);
 #endif
@@ -882,12 +882,12 @@ fs::equivalent(const path& p1, const path& p2, 
error_code& ec) noexcept
   if (!h1 || !h2)
{
  if (!h1 && !h2)
-   ec.assign((int)GetLastError(), generic_category());
+   ec.assign((int)GetLastError(), system_category());
  return false;
}
   if (!h1.get_info() || !h2.get_info())
{
- ec.assign((int)GetLastError(), generic_category());
+ ec.assign((int)GetLastError(), system_category());
  return false;
}
   return h1.info.dwVolumeSerialNumber == h2.info.dwVolumeSerialNumber
@@ -1263,7 +1263,7 @@ fs::remove(const path& p, error_code& ec) noexcept
  return true;
}
   else if (!ec)
-   ec.assign((int)GetLastError(), generic_category());
+   ec.assign((int)GetLastError(), system_category());
 }
   else if (status_known(st))
 ec.clear();
diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index 779d73f13ad..c400376d224 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -590,7 +590,7 @@ fs::create_hard_link(const path& to, const path& 
new_hard_link,
   if (CreateHardLinkW(new_hard_link.c_str(), to.c_str(), NULL))
 ec.clear();
   else
-ec.assign((int)GetLastError(), generic_category());
+ec.assign((int)GetLastError(), system_category());
 #else
   ec = std::make_error_code(std::errc::not_supported);
 #endif
@@ -1062,7 +1062,7 @@ fs::remove(const path& p, error_code& ec) noexcept
  return true;
}
   else if (!ec)
-   ec.assign((int)GetLastError(), generic_category());
+   ec.assign((int)GetLastError(), system_category());
 }
   else if (status_known(st))
 ec.clear();

[committed] libstdc++: Fix spelling of __MINGW32__ macros

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/operations/proximate.cc: Fix typo
in __MINGW32__ macro name.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
* testsuite/27_io/filesystem/path/generation/proximate.cc:
Likewise.
* testsuite/27_io/filesystem/path/generation/relative.cc:
Likewise.
* testsuite/util/testsuite_fs.h: Likewise.

Tested x86_64-w64-mingw32. Committed to trunk.

commit 6a6f74be9d6891cb0c17c493b1f9bca20673e6a0
Author: Jonathan Wakely 
Date:   Wed Feb 10 16:37:39 2021

libstdc++: Fix spelling of __MINGW32__ macros

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/operations/proximate.cc: Fix typo
in __MINGW32__ macro name.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
* testsuite/27_io/filesystem/path/generation/proximate.cc:
Likewise.
* testsuite/27_io/filesystem/path/generation/relative.cc:
Likewise.
* testsuite/util/testsuite_fs.h: Likewise.

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
index 1ab2aa6603f..dc5b926b858 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/proximate.cc
@@ -30,7 +30,7 @@ using __gnu_test::compare_paths;
 std::string operator""_norm(const char* s, std::size_t n)
 {
   std::string str(s, n);
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
   for (auto& c : str)
 if (c == '/')
   c = '\\';
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
index 892b82ae621..998be2aad6d 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
@@ -59,7 +59,7 @@ test01()
   check("c:", "d:", -1);
   check("c:", "c:/", -1);
   check("d:", "c:/", +1);
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
   check("c:/a/b", "c:a/b", +1);
 #else
   check("c:/a/b", "c:a/b", -1);
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/proximate.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/proximate.cc
index 1851e5de790..6b463c3886a 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/proximate.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/proximate.cc
@@ -29,7 +29,7 @@ using __gnu_test::compare_paths;
 std::string operator""_norm(const char* s, std::size_t n)
 {
   std::string str(s, n);
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
   for (auto& c : str)
 if (c == '/')
   c = '\\';
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/relative.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/relative.cc
index 388c415fbaf..f56cf6ed452 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/relative.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/relative.cc
@@ -29,7 +29,7 @@ using __gnu_test::compare_paths;
 std::string operator""_norm(const char* s, std::size_t n)
 {
   std::string str(s, n);
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
   for (auto& c : str)
 if (c == '/')
   c = '\\';
@@ -80,7 +80,7 @@ test03()
 void
 test04()
 {
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
   // DR 3070
   compare_paths(path("c:/f:o/bar").lexically_relative("c:/f:o/bar"), ".");
   compare_paths(path("c:/foo/bar").lexically_relative("c:/foo/b:r"), 
"..\\bar");
diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 80774b69e99..4cda0eefeaf 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -82,7 +82,7 @@ namespace __gnu_test
   test_fs::path
   root_path()
   {
-#if defined(__MING32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
 return L"c:/";
 #else
 return "/";

Testing case for fix-point type auto variables?

[Qing Zhao via Gcc-patches]

Hi,

I am trying to add testing cases for verifing  pattern initialization or zero 
initialization to fix-point type auto variables.
Please let me know where in the test suite directory I can find a good example 
for fix-point type programming?

Thanks.

Qing

Re: [PATCH] i386: Fix ICEs due to simplify_gen_subreg returning NULL [PR99025]

[Uros Bizjak via Gcc-patches]

On Wed, Feb 10, 2021 at 4:12 PM Jakub Jelinek  wrote:
>
> Hi!
>
> In these patterns, we call simplify_gen_subreg on the input operand
> to create paradoxical subregs that have 2x, 4x or 8x elements as the input
> operand.  That works fine if the input operand is a REG, but when it is a
> SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg
> actually simplifying it.  And e.g. if the input operand is a SUBREG that
> changes the element mode (floating vs. non-floating) and then combined with
> a paradoxical subreg (i.e. different size) this can easily fail, then
> simplify_gen_subreg returns NULL but we still use it in instructions.
>
> Fixed by forcing the operands into REG.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2021-02-10  Jakub Jelinek  
>
> PR target/99025
> * config/i386/sse.md (fix_truncv2sfv2di2,
> v8qiv8hi2, v8qiv8si2, v4qiv4si2, v4hiv4si2,
> v8qiv8di2, v4qiv4di2, v2qiv2di2, v4hiv4di2,
> v2hiv2di2, v2siv2di2): Force operands[1] into REG before
> calling simplify_gen_subreg on it.
>
> * gcc.target/i386/pr99025.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/sse.md.jj   2021-02-10 07:52:32.673901634 +0100
> +++ gcc/config/i386/sse.md  2021-02-10 10:57:37.229665371 +0100
> @@ -6356,6 +6356,7 @@ (define_expand "fix_truncv
>   (match_operand:V2SF 1 "register_operand")))]
>"TARGET_AVX512DQ && TARGET_AVX512VL"
>  {
> +  operands[1] = force_reg (V2SFmode, operands[1]);
>operands[1] = simplify_gen_subreg (V4SFmode, operands[1], V2SFmode, 0);
>emit_insn (gen_avx512dq_fix_truncv2sfv2di2
>  (operands[0], operands[1]));
> @@ -18013,6 +18014,7 @@ (define_expand "v8qiv8hi2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V8QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 
> 0);
>emit_insn (gen_sse4_1_v8qiv8hi2 (operands[0], operands[1]));
>DONE;
> @@ -18090,6 +18092,7 @@ (define_expand "v8qiv8si2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V8QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 
> 0);
>emit_insn (gen_avx2_v8qiv8si2 (operands[0], operands[1]));
>DONE;
> @@ -18153,6 +18156,7 @@ (define_expand "v4qiv4si2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V4QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V4QImode, 
> 0);
>emit_insn (gen_sse4_1_v4qiv4si2 (operands[0], operands[1]));
>DONE;
> @@ -18279,6 +18283,7 @@ (define_expand "v4hiv4si2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V4HImode, operands[1]);
>operands[1] = simplify_gen_subreg (V8HImode, operands[1], V4HImode, 0);
>emit_insn (gen_sse4_1_v4hiv4si2 (operands[0], operands[1]));
>DONE;
> @@ -18366,6 +18371,7 @@ (define_expand "v8qiv8di2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V8QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 
> 0);
>emit_insn (gen_avx512f_v8qiv8di2 (operands[0], operands[1]));
>DONE;
> @@ -18427,6 +18433,7 @@ (define_expand "v4qiv4di2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V8QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 
> 0);
>emit_insn (gen_avx2_v4qiv4di2 (operands[0], operands[1]));
>DONE;
> @@ -18453,6 +18460,7 @@ (define_expand "v2qiv2di2"
>   (match_operand:V2QI 1 "register_operand")))]
>"TARGET_SSE4_1"
>  {
> +  operands[1] = force_reg (V2QImode, operands[1]);
>operands[1] = simplify_gen_subreg (V16QImode, operands[1], V2QImode, 0);
>emit_insn (gen_sse4_1_v2qiv2di2 (operands[0], operands[1]));
>DONE;
> @@ -18525,6 +18533,7 @@ (define_expand "v4hiv4di2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V4HImode, operands[1]);
>operands[1] = simplify_gen_subreg (V8HImode, operands[1], V4HImode, 0);
>emit_insn (gen_avx2_v4hiv4di2 (operands[0], operands[1]));
>DONE;
> @@ -18586,6 +18595,7 @@ (define_expand "v2hiv2di2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V2HImode, operands[1]);
>operands[1] = simplify_gen_subreg (V8HImode, operands[1], V2HImode, 0);
>emit_insn (gen_sse4_1_v2hiv2di2 (operands[0], operands[1]));
>DONE;
> @@ -18737,6 +18747,7 @@ (define_expand "v2siv2di2"
>  {
>if (!MEM_P (operands[1]))
>  {
> +  operands[1] = force_reg (V2SImode, operands[1]);
>operands[1] = simplify_gen_subreg (V4SImode, operands[1], V2SImode, 0);
>emit_insn (gen_sse4_1_v2siv2di2 (operands[0], operands[1]));
>DONE;
> --- 

Re: [PATCH] varasm: Fix ICE with -fsyntax-only [PR99035]

[Richard Biener]

On Wed, 10 Feb 2021, Jakub Jelinek wrote:

> Hi!
> 
> My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
> mode more aggressively to avoid "expanding" functions multiple times.
> With -fsyntax-only nothing is really expanded, so I think it is acceptable
> to adjust the assert and allow declare_weak at any time, with -fsyntax-only
> we know it is during parsing only anyway.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK if you add a comment.

Thanks,
Richrd.

> 2021-02-10  Jakub Jelinek  
> 
>   PR c++/99035
>   * varasm.c (declare_weak): For -fsyntax-only, allow even
>   TREE_ASM_WRITTEN function decls.
> 
>   * g++.dg/ext/weak6.C: New test.
> 
> --- gcc/varasm.c.jj   2021-01-04 10:25:38.824233926 +0100
> +++ gcc/varasm.c  2021-02-10 13:18:29.278890110 +0100
> @@ -5927,7 +5927,9 @@ merge_weak (tree newdecl, tree olddecl)
>  void
>  declare_weak (tree decl)
>  {
> -  gcc_assert (TREE_CODE (decl) != FUNCTION_DECL || !TREE_ASM_WRITTEN (decl));
> +  gcc_assert (TREE_CODE (decl) != FUNCTION_DECL
> +   || !TREE_ASM_WRITTEN (decl)
> +   || flag_syntax_only);
>if (! TREE_PUBLIC (decl))
>  {
>error ("weak declaration of %q+D must be public", decl);
> --- gcc/testsuite/g++.dg/ext/weak6.C.jj   2021-02-10 13:26:52.862203677 
> +0100
> +++ gcc/testsuite/g++.dg/ext/weak6.C  2021-02-10 13:26:46.439276213 +0100
> @@ -0,0 +1,8 @@
> +// PR c++/99035
> +// { dg-do compile }
> +// { dg-require-weak "" }
> +// { dg-options "-fsyntax-only" }
> +
> +extern void * foo (void);
> +void * foo (void) { return (void *)foo; }
> +#pragma weak foo
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH][GCC] IPA: Optionally allow double costing, restoring GCC 10 behavior

[Richard Biener via Gcc-patches]

On Wed, Feb 10, 2021 at 4:16 PM Tamar Christina via Gcc-patches
 wrote:
>
> Hi Honza and Martin,
>
> As explained in PR98782 the problem is that the behavior of IRA is quite 
> tightly
> bound to the frequencies that IPA puts out.  With the change introduced in
> g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92 some, but not all edge predictions
> changed.  This introduces a local problem which is impossible to fix using
> global flags or using any hooks to IRA.
>
> I propose this new parameter ipa-cp-allow-multi-edge-costing as a temporary 
> stop
> gap as something that is safe for stage4.
>
> This allows us to opt in to allow the double edge costing, and buys us some 
> time
> to properly look at RA in GCC 12 to see if there's a proper solution for this
> problem.
>
> Using --param ipa-cp-allow-multi-edge-costing=1 allows us to regain all the 
> loses
> compared to GCC 10, but also thanks to Martin's patches we get a tiny extra 
> gain
> as well.
>
> Would this be an acceptable stop-gap measure for the both of you?

With the --param defaulted to off this is solely a knob to get better benchmark
numbers?  Sorry, but GCC isn't a benchmark compiler.

Btw, even such kind of --params deserve documentation.  I guess if it
then states "Use this to speedup SPEC CPU 123.xyz" then the switch becomes
disallowed by SPEC rules even for PEAK, no?

Richard.

> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR rtl-optimization/98782
> * params.opt (ipa-cp-allow-multi-edge-costing): New.
> * predict.c (maybe_predict_edge): Use it.
>
> --- inline copy of patch --
> diff --git a/gcc/params.opt b/gcc/params.opt
> index 
> dff8a331f82e44c1b90e5b9f88ffc61e84f03d2d..f54eba2836f5d3a9b66489e3766f3d45eeaf5952
>  100644
> --- a/gcc/params.opt
> +++ b/gcc/params.opt
> @@ -277,6 +277,10 @@ The size of translation unit that IPA-CP pass considers 
> large.
>  Common Joined UInteger Var(param_ipa_cp_value_list_size) Init(8) Param 
> Optimization
>  Maximum size of a list of values associated with each parameter for 
> interprocedural constant propagation.
>
> +-param=ipa-cp-allow-multi-edge-costing=
> +Common Joined UInteger Var(param_ipa_cp_allow_multi_edge_costing) Init(0) 
> IntegerRange(0, 1) Param Optimization
> +Allow double prediction to happen during IPA edge analysis.
> +
>  -param=ipa-jump-function-lookups=
>  Common Joined UInteger Var(param_ipa_jump_function_lookups) Init(8) Param 
> Optimization
>  Maximum number of statements visited during jump function offset discovery.
> diff --git a/gcc/predict.c b/gcc/predict.c
> index 
> d0a8e5f8e04fc3d1ec770602589299b0a30b3b59..c15dd92310dfe77bedc50c027d000833c0a92315
>  100644
> --- a/gcc/predict.c
> +++ b/gcc/predict.c
> @@ -3171,16 +3171,22 @@ maybe_predict_edge (edge e, enum br_predictor pred, 
> enum prediction taken)
>  {
>if (edge_predicted_by_p (e, pred, taken))
>  return;
> -  if (pred == PRED_LOOP_GUARD
> -  && edge_predicted_by_p (e, PRED_LOOP_GUARD_WITH_RECURSION, taken))
> -return;
> -  /* Consider PRED_LOOP_GUARD_WITH_RECURSION superrior to LOOP_GUARD.  */
> -  if (pred == PRED_LOOP_GUARD_WITH_RECURSION)
> +
> +  /* Allow double prediction in certain circumstances. See PR98782.  */
> +  if (!param_ipa_cp_allow_multi_edge_costing)
>  {
> -  edge_prediction **preds = bb_predictions->get (e->src);
> -  if (preds)
> -   filter_predictions (preds, not_loop_guard_equal_edge_p, e);
> +  if (pred == PRED_LOOP_GUARD
> + && edge_predicted_by_p (e, PRED_LOOP_GUARD_WITH_RECURSION, taken))
> +   return;
> +  /* Consider PRED_LOOP_GUARD_WITH_RECURSION superrior to LOOP_GUARD.  */
> +  if (pred == PRED_LOOP_GUARD_WITH_RECURSION)
> +   {
> + edge_prediction **preds = bb_predictions->get (e->src);
> + if (preds)
> +   filter_predictions (preds, not_loop_guard_equal_edge_p, e);
> +   }
>  }
> +
>predict_edge_def (e, pred, taken);
>  }
>  /* Predict edges to successors of CUR whose sources are not postdominated by
>
>
> --

[PATCH] varasm: Fix ICE with -fsyntax-only [PR99035]

[Jakub Jelinek via Gcc-patches]

Hi!

My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
mode more aggressively to avoid "expanding" functions multiple times.
With -fsyntax-only nothing is really expanded, so I think it is acceptable
to adjust the assert and allow declare_weak at any time, with -fsyntax-only
we know it is during parsing only anyway.

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

2021-02-10  Jakub Jelinek  

PR c++/99035
* varasm.c (declare_weak): For -fsyntax-only, allow even
TREE_ASM_WRITTEN function decls.

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

--- gcc/varasm.c.jj 2021-01-04 10:25:38.824233926 +0100
+++ gcc/varasm.c2021-02-10 13:18:29.278890110 +0100
@@ -5927,7 +5927,9 @@ merge_weak (tree newdecl, tree olddecl)
 void
 declare_weak (tree decl)
 {
-  gcc_assert (TREE_CODE (decl) != FUNCTION_DECL || !TREE_ASM_WRITTEN (decl));
+  gcc_assert (TREE_CODE (decl) != FUNCTION_DECL
+ || !TREE_ASM_WRITTEN (decl)
+ || flag_syntax_only);
   if (! TREE_PUBLIC (decl))
 {
   error ("weak declaration of %q+D must be public", decl);
--- gcc/testsuite/g++.dg/ext/weak6.C.jj 2021-02-10 13:26:52.862203677 +0100
+++ gcc/testsuite/g++.dg/ext/weak6.C2021-02-10 13:26:46.439276213 +0100
@@ -0,0 +1,8 @@
+// PR c++/99035
+// { dg-do compile }
+// { dg-require-weak "" }
+// { dg-options "-fsyntax-only" }
+
+extern void * foo (void);
+void * foo (void) { return (void *)foo; }
+#pragma weak foo

Jakub

[PATCH] i386: Fix ICEs due to simplify_gen_subreg returning NULL [PR99025]

[Jakub Jelinek via Gcc-patches]

Hi!

In these patterns, we call simplify_gen_subreg on the input operand
to create paradoxical subregs that have 2x, 4x or 8x elements as the input
operand.  That works fine if the input operand is a REG, but when it is a
SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg
actually simplifying it.  And e.g. if the input operand is a SUBREG that
changes the element mode (floating vs. non-floating) and then combined with
a paradoxical subreg (i.e. different size) this can easily fail, then
simplify_gen_subreg returns NULL but we still use it in instructions.

Fixed by forcing the operands into REG.

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

2021-02-10  Jakub Jelinek  

PR target/99025
* config/i386/sse.md (fix_truncv2sfv2di2,
v8qiv8hi2, v8qiv8si2, v4qiv4si2, v4hiv4si2,
v8qiv8di2, v4qiv4di2, v2qiv2di2, v4hiv4di2,
v2hiv2di2, v2siv2di2): Force operands[1] into REG before
calling simplify_gen_subreg on it.

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

--- gcc/config/i386/sse.md.jj   2021-02-10 07:52:32.673901634 +0100
+++ gcc/config/i386/sse.md  2021-02-10 10:57:37.229665371 +0100
@@ -6356,6 +6356,7 @@ (define_expand "fix_truncv
  (match_operand:V2SF 1 "register_operand")))]
   "TARGET_AVX512DQ && TARGET_AVX512VL"
 {
+  operands[1] = force_reg (V2SFmode, operands[1]);
   operands[1] = simplify_gen_subreg (V4SFmode, operands[1], V2SFmode, 0);
   emit_insn (gen_avx512dq_fix_truncv2sfv2di2
 (operands[0], operands[1]));
@@ -18013,6 +18014,7 @@ (define_expand "v8qiv8hi2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V8QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 0);
   emit_insn (gen_sse4_1_v8qiv8hi2 (operands[0], operands[1]));
   DONE;
@@ -18090,6 +18092,7 @@ (define_expand "v8qiv8si2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V8QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 0);
   emit_insn (gen_avx2_v8qiv8si2 (operands[0], operands[1]));
   DONE;
@@ -18153,6 +18156,7 @@ (define_expand "v4qiv4si2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V4QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V4QImode, 0);
   emit_insn (gen_sse4_1_v4qiv4si2 (operands[0], operands[1]));
   DONE;
@@ -18279,6 +18283,7 @@ (define_expand "v4hiv4si2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V4HImode, operands[1]);
   operands[1] = simplify_gen_subreg (V8HImode, operands[1], V4HImode, 0);
   emit_insn (gen_sse4_1_v4hiv4si2 (operands[0], operands[1]));
   DONE;
@@ -18366,6 +18371,7 @@ (define_expand "v8qiv8di2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V8QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 0);
   emit_insn (gen_avx512f_v8qiv8di2 (operands[0], operands[1]));
   DONE;
@@ -18427,6 +18433,7 @@ (define_expand "v4qiv4di2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V8QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V8QImode, 0);
   emit_insn (gen_avx2_v4qiv4di2 (operands[0], operands[1]));
   DONE;
@@ -18453,6 +18460,7 @@ (define_expand "v2qiv2di2"
  (match_operand:V2QI 1 "register_operand")))]
   "TARGET_SSE4_1"
 {
+  operands[1] = force_reg (V2QImode, operands[1]);
   operands[1] = simplify_gen_subreg (V16QImode, operands[1], V2QImode, 0);
   emit_insn (gen_sse4_1_v2qiv2di2 (operands[0], operands[1]));
   DONE;
@@ -18525,6 +18533,7 @@ (define_expand "v4hiv4di2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V4HImode, operands[1]);
   operands[1] = simplify_gen_subreg (V8HImode, operands[1], V4HImode, 0);
   emit_insn (gen_avx2_v4hiv4di2 (operands[0], operands[1]));
   DONE;
@@ -18586,6 +18595,7 @@ (define_expand "v2hiv2di2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V2HImode, operands[1]);
   operands[1] = simplify_gen_subreg (V8HImode, operands[1], V2HImode, 0);
   emit_insn (gen_sse4_1_v2hiv2di2 (operands[0], operands[1]));
   DONE;
@@ -18737,6 +18747,7 @@ (define_expand "v2siv2di2"
 {
   if (!MEM_P (operands[1]))
 {
+  operands[1] = force_reg (V2SImode, operands[1]);
   operands[1] = simplify_gen_subreg (V4SImode, operands[1], V2SImode, 0);
   emit_insn (gen_sse4_1_v2siv2di2 (operands[0], operands[1]));
   DONE;
--- gcc/testsuite/gcc.target/i386/pr99025.c.jj  2021-02-09 19:17:29.705924814 
+0100
+++ gcc/testsuite/gcc.target/i386/pr99025.c 2021-02-09 19:17:10.687137688 
+0100
@@ -0,0 +1,17 @@
+/* PR target/99025 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -msse4" } */
+
+long v[16];
+int w;
+union U { float u; int r; } x;
+
+void
+foo (float y)
+{
+  

[PATCH] c++, v2: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031]

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 09, 2021 at 04:08:03PM -0500, Jason Merrill via Gcc-patches wrote:
> > They are not in the symtab from the C++ FE.  And we don't allow those 
> > VAR_DECLs or their
> > addresses to leak into the IL anyway.
> > But, they are TREE_STATIC because pretending they are automatic didn't
> > really work (e.g. address of automatic variables is not a constant 
> > expression).
> > The generic folding code uses maybe_nonzero_address predicate which
> > apprently creates a symtab entry for them but as nothing uses them they
> > won't be emitted.
> 
> Ah.
> 
> > If we wanted to avoid that, we'd need to either add some generic VAR_DECL
> > bit for those vars or add a target hook that would return true for them and
> > then handle them in the middle-end.
> 
> I'm surprised that nonzero_address has such a limited set of things it will
> actually believe have non-zero addresses with
> -fno-delete-null-pointer-checks.  But it seems that we should be able to
> arrange to satisfy
> 
> >   if (definition && !DECL_EXTERNAL (decl)
> 
> since these "variables" are indeed defined within the current translation
> unit.

Doing that seems to work and as added benefit it fixes another PR that has
been filed recently.  I need to create the varpool node explicitly and call
a method that sets the definition member in there, but I can also unregister
those varpool nodes at the end of constexpr processing, as the processing
ensured they don't leak outside of the processing.

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

2021-02-10  Jakub Jelinek  

PR c++/98988
PR c++/99031
* constexpr.c: Include cgraph.h.
(cxx_eval_call_expression): Call varpool_node::finalize_decl on
heap artificial vars.
(cxx_eval_outermost_constant_expr): Remove varpool nodes for
heap artificial vars.

* g++.dg/cpp2a/constexpr-new16.C: New test.
* g++.dg/cpp2a/constexpr-new17.C: New test.

--- gcc/cp/constexpr.c.jj   2021-02-09 10:05:28.820833601 +0100
+++ gcc/cp/constexpr.c  2021-02-10 11:31:16.567984809 +0100
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.
 #include "timevar.h"
 #include "fold-const-call.h"
 #include "stor-layout.h"
+#include "cgraph.h"
 
 static bool verify_constant (tree, bool, bool *, bool *);
 #define VERIFY_CONSTANT(X) \
@@ -2340,6 +2341,7 @@ cxx_eval_call_expression (const constexp
 type);
  DECL_ARTIFICIAL (var) = 1;
  TREE_STATIC (var) = 1;
+ varpool_node::finalize_decl (var);
  ctx->global->heap_vars.safe_push (var);
  ctx->global->values.put (var, NULL_TREE);
  return fold_convert (ptr_type_node, build_address (var));
@@ -7199,15 +7201,18 @@ cxx_eval_outermost_constant_expr (tree t
  non_constant_p = true;
}
   FOR_EACH_VEC_ELT (global_ctx.heap_vars, i, heap_var)
-   if (DECL_NAME (heap_var) != heap_deleted_identifier)
- {
-   if (!allow_non_constant && !non_constant_p)
- error_at (DECL_SOURCE_LOCATION (heap_var),
-   "%qE is not a constant expression because allocated "
-   "storage has not been deallocated", t);
-   r = t;
-   non_constant_p = true;
- }
+   {
+ if (DECL_NAME (heap_var) != heap_deleted_identifier)
+   {
+ if (!allow_non_constant && !non_constant_p)
+   error_at (DECL_SOURCE_LOCATION (heap_var),
+ "%qE is not a constant expression because allocated "
+ "storage has not been deallocated", t);
+ r = t;
+ non_constant_p = true;
+   }
+ varpool_node::get (heap_var)->remove ();
+   }
 }
 
   /* Check that immediate invocation does not return an expression referencing
--- gcc/testsuite/g++.dg/cpp2a/constexpr-new16.C.jj 2021-02-10 
11:11:00.117658382 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-new16.C2021-02-10 
11:11:00.117658382 +0100
@@ -0,0 +1,13 @@
+// PR c++/98988
+// { dg-do compile { target c++20 } }
+// { dg-options "-fno-delete-null-pointer-checks" }
+
+constexpr bool
+foo ()
+{
+  auto ptr = new int();
+  delete ptr;
+  return true;
+}
+
+static_assert (foo ());
--- gcc/testsuite/g++.dg/cpp2a/constexpr-new17.C.jj 2021-02-10 
13:04:17.947606440 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-new17.C2021-02-10 
13:04:06.417738050 +0100
@@ -0,0 +1,15 @@
+// PR c++/99031
+// { dg-do compile { target c++20 } }
+
+constexpr bool
+foo ()
+{
+  auto a = new int;
+  auto b = new int;
+  bool r = a == b;
+  delete b;
+  delete a;
+  return r;
+}
+
+static_assert (!foo ());


Jakub

Re: [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns

[Joel Hutton via Gcc-patches]

Thanks for the quick review.

Updated patch attached. I've addressed your comments below.

Tests are still running, OK for trunk assuming tests come out clean?

[aarch64][vect] Support V8QI->V8HI WIDEN_ patterns

In the case where 8 out of every 16 elements are widened using a
widening pattern and the next 8 are skipped the patterns are not
recognized. This is because they are normally used in a pair, such  as
VEC_WIDEN_MINUS_HI/LO, to achieve a v16qi->v16hi conversion for example.
This patch adds support for V8QI->V8HI patterns.

gcc/ChangeLog:

PR tree-optimisation/98772
* optabs-tree.c (supportable_half_widening_operation): New function
to check for supportable V8QI->V8HI widening patterns.
* optabs-tree.h (supportable_half_widening_operation): New function.
* tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): New
function to create promotion stmts for V8QI->V8HI widening patterns.
(vectorizable_conversion): Add case for V8QI->V8HI.

gcc/testsuite/ChangeLog:

PR tree-optimisation/98772
* gcc.target/aarch64/pr98772.c: New test.


>> +  /* The case where a widening operation is not making use of the full 
>> width of
>> + of the input vector, but using the full width of the output vector.
>> + Return the non-wided code, which will be used after the inputs are
>
>non-widened
Done.

>> + converted to the wide type.  */
>> +  if ((code == WIDEN_MINUS_EXPR
>> +  || code == WIDEN_PLUS_EXPR
>> +  || code == WIDEN_MULT_EXPR
>> +  || code == WIDEN_LSHIFT_EXPR)
>
>Minor formatting nit, but the ||s should be indented one space more.
Done.

>> +  && known_eq (TYPE_VECTOR_SUBPARTS (vectype_in),
>> +   TYPE_VECTOR_SUBPARTS (vectype_out)))
>> +  {
>> +switch (code)
>> +{
>> +  case WIDEN_LSHIFT_EXPR:
>> + *code1 = LSHIFT_EXPR;
>> + return true;
>> + break;
>> +  case WIDEN_MINUS_EXPR:
>> + *code1 = MINUS_EXPR;
>> + return true;
>> + break;
>> +  case WIDEN_PLUS_EXPR:
>> + *code1 = PLUS_EXPR;
>> + return true;
>> + break;
>> +  case WIDEN_MULT_EXPR:
>> + *code1 = MULT_EXPR;
>> + return true;
>> + break;
>> +  default:
>> + gcc_unreachable ();
>> +}
>> +  }
>
>Rather than return true, I think we should do something like:
>
>  if (!supportable_convert_operation (NOP_EXPR, vectype_out,
>  vectype_in, _code))
>return false;
>
>  optab = optab_for_tree_code (*code1, vectype_out, optab_default);
>  return (optab_handler (optab, TYPE_MODE (vectype_out))
>  != CODE_FOR_nothing);
>
>to make sure that the target really does support this.
Done. I used 'optab_vector' not 'optab_default', as I thought that was correct 
for this case and otherwise 'optab_for_tree_code' fails an assertion when 
'LSHIFT_EXPR' is used.

> AFAICT the caller always knows when it wants the “if” statement above
> to be used.  What it's doing is a bit different from what
> supportable_convert_operation normally does, so it might be better
> to put it into a separate function that tests whether the target
> supports the non-widening form of a widening operation.
Done.

>> +
>> +  vec_tmp.create (vec_oprnds0->length () * 2);
>
>It looks like the * 2 isn't needed.
Done.

>> +  if (is_gimple_call (new_stmt3))
>> + {
>> +   new_tmp = gimple_call_lhs (new_stmt3);
>> + }
>> +  else
>> + {
>> +   new_tmp = gimple_assign_lhs (new_stmt3);
>> + }
>
>The lhs is always new_tmp3, so it's not necessary to read it back.
Done.

>> +
>> +  /* Store the results for the next step.  */
>> +  vec_tmp.quick_push (new_tmp);
>
>FWIW, you could just assign to vec_oprnds[i] and not have vec_tmp,
>but I don't know whether that's more or less confusing.  Either way's
>fine with me.
I chose to keep vec_tmp, but I don't feel strongly about it.

>> +}
>> +
>> +  vec_oprnds0->release ();
>> +  *vec_oprnds0 = vec_tmp;
>> +}
>> +
>>  
>>  /* Check if STMT_INFO performs a conversion operation that can be 
>> vectorized.
>> If VEC_STMT is also passed, vectorize STMT_INFO: create a vectorized
>> @@ -4697,7 +4763,13 @@ vectorizable_conversion (vec_info *vinfo,
>>nunits_in = TYPE_VECTOR_SUBPARTS (vectype_in);
>>nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
>>if (known_eq (nunits_out, nunits_in))
>> -modifier = NONE;
>> +if (code == WIDEN_MINUS_EXPR
>> + || code == WIDEN_PLUS_EXPR
>> + || code == WIDEN_LSHIFT_EXPR
>> + || code == WIDEN_MULT_EXPR)
>> + modifier = WIDEN;
>
>Formatting nit: the last line should be indented by 6 spaces rather than 8.
Done.

>> @@ -4743,9 +4815,21 @@ vectorizable_conversion (vec_info *vinfo,
>>return false;
>> 
>>  case WIDEN:
>> -  if (supportable_widening_operation (vinfo, code, stmt_info, 
>> vectype_out,
>> -   vectype_in, , ,
>> -   _step_cvt, _types))
>> 

Re: [PATCH 3/4] c++: Delay normalizing nested requirements until satisfaction

[Patrick Palka via Gcc-patches]

On Tue, 9 Feb 2021, Jason Merrill wrote:

> On 2/8/21 2:03 PM, Patrick Palka wrote:
> > This sets up the functionality for controlling the initial set of
> > template parameters to pass to normalization when dealing with a
> > constraint-expression that is not associated with some constrained
> > declaration, for instance when normalizing a nested requirement of a
> > requires expression, or the constraints on a placeholder type.
> > 
> > The main new ingredient here is the data member norm_info::initial_parms
> > which can be set by callers of the normalization routines to communicate
> > the in-scope template parameters for the supplied constraint-expression,
> > rather than always falling back to using current_template_parms.
> > 
> > This patch then uses this functionality in our handling of nested
> > requirements so that we can delay normalizing them until needed for
> > satisfaction.  We currently immediately normalize nested requirements at
> > parse time, where we have the necessary template context, and cache the
> > normal form in their TREE_TYPE node.  With this patch, we now delay
> > normalization until needed (as with other constraint expressions), and
> > instead store the current value of current_template_parms in their
> > TREE_TYPE node (which we use to restore the template context at
> > normalization time).
> > 
> > In the subsequent patch, this functionality will also be used to
> > normalize placeholder type constraints during auto deduction.
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constraint.cc (build_parameter_mapping): Rely on the caller to
> > determine the in-scope template parameters.
> > (norm_info::norm_info): Delegate the one-parameter constructor
> > to the two-parameter constructor.  In the two-parameter
> > constructor, fold in the definition of make_context, set
> > initial_parms appropriately, and don't set the now-removed
> > orig_decl member.
> > (norm_info::make_context): Remove, now that its only use is
> > inlined into the caller.
> > (norm_info::update_context): Adjust call to
> > build_parameter_mapping to pass in the relevant set of in-scope
> > template parameters.
> > (norm_info::ctx_parms): Define this member function.
> > (norm_info::context): Initialize to NULL_TREE.
> > (norm_info::orig_decl): Remove this data member.
> > (norm_info::initial_parms): Define this data member.
> > (normalize_atom): Adjust call to build_parameter_mapping to pass
> > in the relevant set of in-scope template parameters.  Use
> > info.initial_parms instead of info.orig_decl.
> > (normalize_constraint_expression): Define an overload that takes
> > a norm_info object.  Cache the result of normalization.  Define
> > the other overload in terms of this one, and handle a NESTED_REQ
> > argument by setting info.initial_parms appropriately.
> > (tsubst_nested_requirement): Go through
> > satisfy_constraint_expression so that we normalize on demand.
> > (finish_nested_requirement): Set the TREE_TYPE of the NESTED_REQ
> > to current_template_parms.
> > (diagnose_nested_requirements): Go through
> > satisfy_constraint_expression, as with tsubst_nested_requirement.
> > ---
> >   gcc/cp/constraint.cc | 140 +++
> >   gcc/cp/cp-tree.h |   4 +-
> >   2 files changed, 78 insertions(+), 66 deletions(-)
> > 
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index 39c97986082..56134f8b2bf 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -133,7 +133,7 @@ struct sat_info : subst_info
> > bool diagnose_unsatisfaction;
> >   };
> >   -static tree satisfy_constraint (tree, tree, sat_info);
> > +static tree satisfy_constraint_expression (tree, tree, sat_info);
> > /* True if T is known to be some type other than bool. Note that this
> >  is false for dependent types and errors.  */
> > @@ -594,26 +594,12 @@ map_arguments (tree parms, tree args)
> > return parms;
> >   }
> >   -/* Build the parameter mapping for EXPR using ARGS.  */
> > +/* Build the parameter mapping for EXPR using ARGS, where CTX_PARMS
> > +   are the template parameters in scope for EXPR.  */
> > static tree
> > -build_parameter_mapping (tree expr, tree args, tree decl)
> > +build_parameter_mapping (tree expr, tree args, tree ctx_parms)
> >   {
> > -  tree ctx_parms = NULL_TREE;
> > -  if (decl)
> > -{
> > -  gcc_assert (TREE_CODE (decl) == TEMPLATE_DECL);
> > -  ctx_parms = DECL_TEMPLATE_PARMS (decl);
> > -}
> > -  else if (current_template_parms)
> > -{
> > -  /* TODO: This should probably be the only case, but because the
> > -point of declaration of concepts is currently set after the
> > -initializer, the template parameter lists are not available
> > -when normalizing concept definitions, hence the case above.  */
> > -  ctx_parms = current_template_parms;
> > -}
> > -

Re: ***SPAM*** [PATCH] libgcc: allocate extra space for morestack expansion

[Ian Lance Taylor]

Rain Mark  writes:

> After enabling -fsplit-stack, dynamic stack expansion of the coroutine
> is realized, but calling functions without -fsplit-stack will directly
> expand the space by 1M, which is too wasteful for a system with a large
> number of coroutines running under the 128K stack size. We hope to give
> users more control over the size of stack expansion to adapt to
> more complex scenarios.
>
> Apply for more space each time the stack is expanded, which
> can also reduce the frequency of morestack being called.
> When calling the non-split function, we do not need additional
> checks and apply for 1M space.  At this time, we can turn off
> the conversion of linker to __morestack_non_split.  This is more friendly
> to a large number of small stack coroutines running below 128K.
>
> Later we need to add an option to the gold linker to turn off
> the __morestack_non_split conversion.

Why is the new variable thread local?

At first glance it seems like this might make more sense as a compiler
option or compiler function attribute, rather than as a function to
call.  When would you want to dynamically change the value?

Ian

[PATCH][GCC] IPA: Optionally allow double costing, restoring GCC 10 behavior

[Tamar Christina via Gcc-patches]

Hi Honza and Martin,

As explained in PR98782 the problem is that the behavior of IRA is quite tightly
bound to the frequencies that IPA puts out.  With the change introduced in
g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92 some, but not all edge predictions
changed.  This introduces a local problem which is impossible to fix using
global flags or using any hooks to IRA.

I propose this new parameter ipa-cp-allow-multi-edge-costing as a temporary stop
gap as something that is safe for stage4.

This allows us to opt in to allow the double edge costing, and buys us some time
to properly look at RA in GCC 12 to see if there's a proper solution for this
problem.

Using --param ipa-cp-allow-multi-edge-costing=1 allows us to regain all the 
loses
compared to GCC 10, but also thanks to Martin's patches we get a tiny extra gain
as well.

Would this be an acceptable stop-gap measure for the both of you?

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

PR rtl-optimization/98782
* params.opt (ipa-cp-allow-multi-edge-costing): New.
* predict.c (maybe_predict_edge): Use it.

--- inline copy of patch -- 
diff --git a/gcc/params.opt b/gcc/params.opt
index 
dff8a331f82e44c1b90e5b9f88ffc61e84f03d2d..f54eba2836f5d3a9b66489e3766f3d45eeaf5952
 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -277,6 +277,10 @@ The size of translation unit that IPA-CP pass considers 
large.
 Common Joined UInteger Var(param_ipa_cp_value_list_size) Init(8) Param 
Optimization
 Maximum size of a list of values associated with each parameter for 
interprocedural constant propagation.
 
+-param=ipa-cp-allow-multi-edge-costing=
+Common Joined UInteger Var(param_ipa_cp_allow_multi_edge_costing) Init(0) 
IntegerRange(0, 1) Param Optimization
+Allow double prediction to happen during IPA edge analysis.
+
 -param=ipa-jump-function-lookups=
 Common Joined UInteger Var(param_ipa_jump_function_lookups) Init(8) Param 
Optimization
 Maximum number of statements visited during jump function offset discovery.
diff --git a/gcc/predict.c b/gcc/predict.c
index 
d0a8e5f8e04fc3d1ec770602589299b0a30b3b59..c15dd92310dfe77bedc50c027d000833c0a92315
 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -3171,16 +3171,22 @@ maybe_predict_edge (edge e, enum br_predictor pred, 
enum prediction taken)
 {
   if (edge_predicted_by_p (e, pred, taken))
 return;
-  if (pred == PRED_LOOP_GUARD
-  && edge_predicted_by_p (e, PRED_LOOP_GUARD_WITH_RECURSION, taken))
-return;
-  /* Consider PRED_LOOP_GUARD_WITH_RECURSION superrior to LOOP_GUARD.  */
-  if (pred == PRED_LOOP_GUARD_WITH_RECURSION)
+
+  /* Allow double prediction in certain circumstances. See PR98782.  */
+  if (!param_ipa_cp_allow_multi_edge_costing)
 {
-  edge_prediction **preds = bb_predictions->get (e->src);
-  if (preds)
-   filter_predictions (preds, not_loop_guard_equal_edge_p, e);
+  if (pred == PRED_LOOP_GUARD
+ && edge_predicted_by_p (e, PRED_LOOP_GUARD_WITH_RECURSION, taken))
+   return;
+  /* Consider PRED_LOOP_GUARD_WITH_RECURSION superrior to LOOP_GUARD.  */
+  if (pred == PRED_LOOP_GUARD_WITH_RECURSION)
+   {
+ edge_prediction **preds = bb_predictions->get (e->src);
+ if (preds)
+   filter_predictions (preds, not_loop_guard_equal_edge_p, e);
+   }
 }
+
   predict_edge_def (e, pred, taken);
 }
 /* Predict edges to successors of CUR whose sources are not postdominated by


-- 
diff --git a/gcc/params.opt b/gcc/params.opt
index dff8a331f82e44c1b90e5b9f88ffc61e84f03d2d..f54eba2836f5d3a9b66489e3766f3d45eeaf5952 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -277,6 +277,10 @@ The size of translation unit that IPA-CP pass considers large.
 Common Joined UInteger Var(param_ipa_cp_value_list_size) Init(8) Param Optimization
 Maximum size of a list of values associated with each parameter for interprocedural constant propagation.
 
+-param=ipa-cp-allow-multi-edge-costing=
+Common Joined UInteger Var(param_ipa_cp_allow_multi_edge_costing) Init(0) IntegerRange(0, 1) Param Optimization
+Allow double prediction to happen during IPA edge analysis.
+
 -param=ipa-jump-function-lookups=
 Common Joined UInteger Var(param_ipa_jump_function_lookups) Init(8) Param Optimization
 Maximum number of statements visited during jump function offset discovery.
diff --git a/gcc/predict.c b/gcc/predict.c
index d0a8e5f8e04fc3d1ec770602589299b0a30b3b59..c15dd92310dfe77bedc50c027d000833c0a92315 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -3171,16 +3171,22 @@ maybe_predict_edge (edge e, enum br_predictor pred, enum prediction taken)
 {
   if (edge_predicted_by_p (e, pred, taken))
 return;
-  if (pred == PRED_LOOP_GUARD
-  && edge_predicted_by_p (e, PRED_LOOP_GUARD_WITH_RECURSION, taken))
-return;
-  /* Consider PRED_LOOP_GUARD_WITH_RECURSION superrior to LOOP_GUARD.  */
-  if (pred == PRED_LOOP_GUARD_WITH_RECURSION)
+
+  /* Allow double prediction 

[PATCH] testsuite: Skip some tests on arm when overriding -mcpu/-march

[Christophe Lyon via Gcc-patches]

When running the testsuite with -mcpu=XXX/-march=YYY, some tests fail
because they specify -mcpu or -march (or both), which can be
incompatible with values used to run the tests.  There is no easy way
to check such cases, so skip such tests.

Unfortunately this means the tests might be skipped in cases where
they would pass, but this avoids pointless errors in the testsuite.

Combinations where this patch made such failures disappear:

* arm-linux-gnueabi --with-cpu cortex-a9, testing with -march=armv5t 
(cortex-m55*, fma.c, pr97327.c)

* arm-linux-gnueabihf --with-cpu cortex-a9, testing with 
-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard (cortex-m55*)

* arm-eabi, testing with -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd 
(pr41574.c, pr59418.c, pr59575.c, pr60650-2.c, pr60657.c, pr60663.c, pr81863.c)

* arm-eabi, testing with 
-mthumb/-mcpu=cortex-m4/-mfloat-abi=hard/-march=armv7e-m+fp (same list)

2021-02-10  Christophe Lyon  

gcc/testsuite/
* gcc.dg/pr41574.c: Add dg-skip-if clause.
* gcc.dg/pr59418.c: Likewise.
* gcc.target/arm/cortex-m55-nodsp-flag-hard.c: Likewise.
* gcc.target/arm/cortex-m55-nodsp-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nodsp-nofp-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nofp-flag-hard.c: Likewise.
* gcc.target/arm/cortex-m55-nofp-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nomve-flag-hard.c: Likewise.
* gcc.target/arm/cortex-m55-nomve-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nomve.fp-flag-hard.c: Likewise.
* gcc.target/arm/cortex-m55-nomve.fp-flag-softfp.c: Likewise.
* gcc.target/arm/fma.c: Likewise.
* gcc.target/arm/mve/intrinsics/pr97327.c: Likewise.
* gcc.target/arm/pr59575.c: Likewise.
* gcc.target/arm/pr60650-2.c: Likewise.
* gcc.target/arm/pr60657.c: Likewise.
* gcc.target/arm/pr60663.c: Likewise.
* gcc.target/arm/pr81863.c: Likewise.
---
 gcc/testsuite/gcc.dg/pr41574.c   | 2 ++
 gcc/testsuite/gcc.dg/pr59418.c   | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nodsp-flag-hard.c| 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nodsp-flag-softfp.c  | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nodsp-nofp-flag-softfp.c | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nofp-flag-hard.c | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nofp-flag-softfp.c   | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nomve-flag-hard.c| 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nomve-flag-softfp.c  | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nomve.fp-flag-hard.c | 2 ++
 gcc/testsuite/gcc.target/arm/cortex-m55-nomve.fp-flag-softfp.c   | 2 ++
 gcc/testsuite/gcc.target/arm/fma.c   | 1 +
 gcc/testsuite/gcc.target/arm/mve/intrinsics/pr97327.c| 1 +
 gcc/testsuite/gcc.target/arm/pr59575.c   | 2 ++
 gcc/testsuite/gcc.target/arm/pr60650-2.c | 1 +
 gcc/testsuite/gcc.target/arm/pr60657.c   | 1 +
 gcc/testsuite/gcc.target/arm/pr60663.c   | 1 +
 gcc/testsuite/gcc.target/arm/pr81863.c   | 1 +
 19 files changed, 32 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/pr41574.c b/gcc/testsuite/gcc.dg/pr41574.c
index 062c004..1273ed3 100644
--- a/gcc/testsuite/gcc.dg/pr41574.c
+++ b/gcc/testsuite/gcc.dg/pr41574.c
@@ -1,4 +1,6 @@
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-mcpu=*" } { "" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { arm*-*-* } { "-mfloat-abi=*" } 
{ "-mfloat-abi=softfp" } } */
 /* { dg-options "-O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon 
-fno-unsafe-math-optimizations -fdump-rtl-combine" { target { arm*-*-* } } } */
 /* { dg-options "-O2 -fno-unsafe-math-optimizations -fdump-rtl-combine" { 
target { ! arm*-*-* } } } */
 
diff --git a/gcc/testsuite/gcc.dg/pr59418.c b/gcc/testsuite/gcc.dg/pr59418.c
index 4b54ef2..2dd3379 100644
--- a/gcc/testsuite/gcc.dg/pr59418.c
+++ b/gcc/testsuite/gcc.dg/pr59418.c
@@ -2,6 +2,8 @@
 /* Reported by Ryan Mansfield  */
 
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-mcpu=*" } { "" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { arm*-*-* } { "-mfloat-abi=*" } 
{ "-mfloat-abi=hard" } } */
 /* { dg-options "-Os -g" } */
 /* { dg-options "-march=armv7-a+fp -mfloat-abi=hard -Os -g" { target { 
arm*-*-* && { ! arm_thumb1 } } } } */
 
diff --git a/gcc/testsuite/gcc.target/arm/cortex-m55-nodsp-flag-hard.c 
b/gcc/testsuite/gcc.target/arm/cortex-m55-nodsp-flag-hard.c
index 92c1511..826bc41 100644
--- 

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

[Jason Merrill via Gcc-patches]

On 2/9/21 5:12 PM, Patrick Palka wrote:

On Tue, 2 Feb 2021, Jason Merrill wrote:


On 2/2/21 12:19 AM, Patrick Palka wrote:

In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding isn't prepared to
handle.

Since we already discard the result of lookup_name when it returns a
class-scope binding here, it seems cleaner (and equivalent) to instead
communicate to lookup_name that we don't want such bindings in the first
place.  While this change seems like an improvement on its own, it also
fixes the mentioned PR, because the call to lookup_name now returns
NULL_TREE rather than a TREE_LIST of (unwanted) class-scope bindings.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/9/10?

gcc/cp/ChangeLog:

PR c++/97582
* name-lookup.c (op_unqualified_lookup): Pass BLOCK_NAMESPACE to
lookup_name in order to ignore class-scope bindings, rather
than discarding them after the fact.

gcc/testsuite/ChangeLog:

PR c++/97582
* g++.dg/cpp0x/lambda/lambda-template17.C: New test.
---
   gcc/cp/name-lookup.c  | 11 +++
   gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C |  8 
   2 files changed, 11 insertions(+), 8 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 52e4a630e25..46d6cc0dfa4 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9213,17 +9213,12 @@ op_unqualified_lookup (tree fnname)
return NULL_TREE;
   }
   -  tree fns = lookup_name (fnname);
+  /* We don't need to remember class-scope functions or declarations,
+ normal unqualified lookup will find them again.  */
+  tree fns = lookup_name (fnname, LOOK_where::BLOCK_NAMESPACE);


Hmm, I'd expect this to look past class-scope declarations to find
namespace-scope declarations, but we want class decls to hide decls in an
outer scope.


D'oh, good point.  But IIUC, even if we did return (and later inject at
instantiation time) namespace-scope declarations that were hidden by
class-scope declarations, wouldn't the lookup at instantiation time
still find and prefer the class-scope bindings (as desired)?  It seems
to me that the end result might be the same, but I'm not sure.


The injection happens in the function parameter binding level, so I'd 
expect it to be found before class bindings.



Alternatively, would it be safe to assume that if lookup_name returns an
ambiguous result, then the result must consist of class-scope
declarations and so we can discard it?


That isn't true in general:

inline namespace A { int i; }
inline namespace B { int i; }
int main() { return i; } // ambiguous lookup

though I think it is true for functions.  But if the result is 
ambiguous, you can look at the first element to see if it's from class 
scope.





 if (!fns)
   /* Remember we found nothing!  */
   return error_mark_node;
-
-  tree d = is_overloaded_fn (fns) ? get_first_fn (fns) : fns;
-  if (DECL_CLASS_SCOPE_P (d))
-/* We don't need to remember class-scope functions or declarations,
-   normal unqualified lookup will find them again.  */
-fns = NULL_TREE;
-
 return fns;
   }
   diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C
new file mode 100644
index 000..6cafbab8cb0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template17.C
@@ -0,0 +1,8 @@
+// PR c++/97582
+// { dg-do compile { target c++11 } }
+
+struct C1 { void operator+(); };
+struct C2 { void operator+(); };
+struct C3 : C1, C2 {
+  template  void get() { [] (T x) { +x; }; }
+};

Re: [PATCH] nvptx: properly use flag_patchable_function_entry

[Richard Biener via Gcc-patches]

On Wed, Feb 10, 2021 at 3:04 PM Martin Liška  wrote:
>
> It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
> Tobias tested the patch for me.
>
> Ready to be installed?

ok

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/nvptx/nvptx.c (nvptx_option_override): Use
> flag_patchable_function_entry instead of the removed
> function_entry_patch_area_size.
> ---
>   gcc/config/nvptx/nvptx.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index f08b6791069..794c5a69db0 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -74,6 +74,7 @@
>   #include "cfgloop.h"
>   #include "fold-const.h"
>   #include "intl.h"
> +#include "opts.h"
>
>   /* This file should be included last.  */
>   #include "target-def.h"
> @@ -219,7 +220,10 @@ nvptx_option_override (void)
>   flag_no_common = 1;
>
> /* The patch area requires nops, which we don't have.  */
> -  if (function_entry_patch_area_size > 0)
> +  HOST_WIDE_INT patch_area_size, patch_area_entry;
> +  parse_and_check_patch_area (flag_patchable_function_entry, false,
> + _area_size, _area_entry);
> +  if (patch_area_size > 0)
>   sorry ("not generating patch area, nops not supported");
>
> /* Assumes that it will see only hard registers.  */
> --
> 2.30.0
>

Re: [PATCH] nvptx: properly use flag_patchable_function_entry

[Tom de Vries]

On 2/10/21 2:17 PM, Martin Liška wrote:
> It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
> Tobias tested the patch for me.
> 
> Ready to be installed?

LGTM.

Thanks,
- Tom

> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> * config/nvptx/nvptx.c (nvptx_option_override): Use
> flag_patchable_function_entry instead of the removed
> function_entry_patch_area_size.
> ---
>  gcc/config/nvptx/nvptx.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index f08b6791069..794c5a69db0 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -74,6 +74,7 @@
>  #include "cfgloop.h"
>  #include "fold-const.h"
>  #include "intl.h"
> +#include "opts.h"
>  
>  /* This file should be included last.  */
>  #include "target-def.h"
> @@ -219,7 +220,10 @@ nvptx_option_override (void)
>  flag_no_common = 1;
>  
>    /* The patch area requires nops, which we don't have.  */
> -  if (function_entry_patch_area_size > 0)
> +  HOST_WIDE_INT patch_area_size, patch_area_entry;
> +  parse_and_check_patch_area (flag_patchable_function_entry, false,
> +  _area_size, _area_entry);
> +  if (patch_area_size > 0)
>  sorry ("not generating patch area, nops not supported");
>  
>    /* Assumes that it will see only hard registers.  */

c++: generic lambdas and local-externs from outer scopes [PR 99030]

[Nathan Sidwell]

Lambdas can refer to local externs from their enclosing scope.  When
the lambda's generic but the containing function is not a temploid,
we'll never have tsubsted the declaring decl so won't have a local
specialization.  But in that case we can just use the decl we
tsubsting directly -- it's not dependent.

PR c++/99030
gcc/cp
* pt.c (tsubst_copy) [VAR_DECL]: For a DECL_LOCAL_DECL_P T is the
answer if there's no local specialization.
gcc/testsuite/
* g++.dg/lookup/pr99030.C: New.

--
Nathan Sidwell
diff --git c/gcc/cp/pt.c w/gcc/cp/pt.c
index f73deb3aee3..d8574f649b2 100644
--- c/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -16650,11 +16650,16 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 	r = tsubst (t, args, complain, in_decl);
   else if (DECL_LOCAL_DECL_P (t))
 	{
-	  /* Local specialization will have been created when we
-	 instantiated the DECL_EXPR_DECL. */
+	  /* Local specialization will usually have been created when
+	 we instantiated the DECL_EXPR_DECL. */
 	  r = retrieve_local_specialization (t);
 	  if (!r)
-	r = error_mark_node;
+	{
+	  /* We're in a generic lambda referencing a local extern
+		 from an outer block-scope of a non-template.  */
+	  gcc_checking_assert (LAMBDA_FUNCTION_P (current_function_decl));
+	  r = t;
+	}
 	}
   else if (local_variable_p (t)
 	   && uses_template_parms (DECL_CONTEXT (t)))
diff --git c/gcc/testsuite/g++.dg/lookup/pr99030.C w/gcc/testsuite/g++.dg/lookup/pr99030.C
new file mode 100644
index 000..080847ca11c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/lookup/pr99030.C
@@ -0,0 +1,16 @@
+// PR 99030 ICE with generic lambda accessing local extern
+// { dg-do compile { target c++14 } }
+
+void foo ()
+{
+  extern int a;
+  [] (auto b) { a; } (1);
+}
+
+template void bar ()
+{
+  extern T a;
+  [] (auto b) { a; } (1);
+}
+
+template void bar ();

[PATCH] nvptx: properly use flag_patchable_function_entry

[Martin Liška]

It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
Tobias tested the patch for me.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* config/nvptx/nvptx.c (nvptx_option_override): Use
flag_patchable_function_entry instead of the removed
function_entry_patch_area_size.
---
 gcc/config/nvptx/nvptx.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index f08b6791069..794c5a69db0 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -74,6 +74,7 @@
 #include "cfgloop.h"
 #include "fold-const.h"
 #include "intl.h"
+#include "opts.h"
 
 /* This file should be included last.  */

 #include "target-def.h"
@@ -219,7 +220,10 @@ nvptx_option_override (void)
 flag_no_common = 1;
 
   /* The patch area requires nops, which we don't have.  */

-  if (function_entry_patch_area_size > 0)
+  HOST_WIDE_INT patch_area_size, patch_area_entry;
+  parse_and_check_patch_area (flag_patchable_function_entry, false,
+ _area_size, _area_entry);
+  if (patch_area_size > 0)
 sorry ("not generating patch area, nops not supported");
 
   /* Assumes that it will see only hard registers.  */

--
2.30.0

Re: [PATCH] if-to-switch: fix memory leak in case merging

[Richard Biener via Gcc-patches]

On Wed, Feb 10, 2021 at 12:44 PM Martin Liška  wrote:
>
> This one fixes 2 more memory leaks.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I also tested that building postgresql with valgrind does not display
> anything related to the affected files.
>
> Ready to be installed?

OK.

Thanks.
Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR tree-optimization/99002
> PR tree-optimization/99026
> * gimple-if-to-switch.cc (if_chain::is_beneficial): Fix memory
> leak when adjacent cases are merged.
> * tree-switch-conversion.c 
> (switch_decision_tree::analyze_switch_statement): Use
> release_clusters.
> (make_pass_lower_switch): Remove trailing whitespace.
> * tree-switch-conversion.h (release_clusters): New.
> ---
>   gcc/gimple-if-to-switch.cc   | 17 +
>   gcc/tree-switch-conversion.c |  9 +
>   gcc/tree-switch-conversion.h | 10 ++
>   3 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
> index f39662be3e6..16fabef7ca0 100644
> --- a/gcc/gimple-if-to-switch.cc
> +++ b/gcc/gimple-if-to-switch.cc
> @@ -227,6 +227,7 @@ if_chain::is_beneficial ()
> (left->get_high ()), wi::one (TYPE_PRECISION (type
> {
>   left->set_high (right->get_high ());
> + delete right;
>   continue;
> }
> }
> @@ -241,20 +242,20 @@ if_chain::is_beneficial ()
>   = jump_table_cluster::find_jump_tables (filtered_clusters);
> bool r = output.length () < filtered_clusters.length ();
> if (r)
> -dump_clusters (, "JT can be built");
> -  output.release ();
> -  if (r)
> -return true;
> +{
> +  dump_clusters (, "JT can be built");
> +  release_clusters (output);
> +  return true;
> +}
> +  else
> +output.release ();
>
> output = bit_test_cluster::find_bit_tests (filtered_clusters);
> r = output.length () < filtered_clusters.length ();
> if (r)
>   dump_clusters (, "BT can be built");
>
> -  for (unsigned i = 0; i < output.length (); i++)
> -delete output[i];
> -
> -  output.release ();
> +  release_clusters (output);
> return r;
>   }
>
> diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
> index a4798812dbf..7f65c4ce839 100644
> --- a/gcc/tree-switch-conversion.c
> +++ b/gcc/tree-switch-conversion.c
> @@ -1824,12 +1824,7 @@ switch_decision_tree::analyze_switch_statement ()
> output.release ();
>
> bool expanded = try_switch_expansion (output2);
> -
> -  for (unsigned i = 0; i < output2.length (); i++)
> -delete output2[i];
> -
> -  output2.release ();
> -
> +  release_clusters (output2);
> return expanded;
>   }
>
> @@ -2597,5 +2592,3 @@ make_pass_lower_switch (gcc::context *ctxt)
>   {
> return new pass_lower_switch (ctxt);
>   }
> -
> -
> diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h
> index d3d568e84cc..d76f19b57f6 100644
> --- a/gcc/tree-switch-conversion.h
> +++ b/gcc/tree-switch-conversion.h
> @@ -893,6 +893,16 @@ switch_decision_tree::reset_out_edges_aux (gswitch 
> *swtch)
>   e->aux = (void *) 0;
>   }
>
> +/* Release CLUSTERS vector and destruct all dynamically allocated items.  */
> +
> +static inline void
> +release_clusters (vec )
> +{
> +  for (unsigned i = 0; i < clusters.length (); i++)
> +delete clusters[i];
> +  clusters.release ();
> +}
> +
>   } // tree_switch_conversion namespace
>
>   #endif // TREE_SWITCH_CONVERSION_H
> --
> 2.30.0
>

[PATCH] ipa/97346 - fix leak of reference_vars_to_consider

[Richard Biener]

This cleans up allocation/deallocation of reference_vars_to_consider,
specifically always releasing the vector allocated in ipa_init and
also making sure to release it before re-allocating it in
ipa_reference_write_optimization_summary.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

2021-02-10  Richard Biener  

PR ipa/97346
* ipa-reference.c (propagate): Always free
reference_vars_to_consider.
(ipa_reference_write_optimization_summary): Free
reference_vars_to_consider before re-allocating it.
(ipa_reference_write_optimization_summary): Use vec_free
and NULL reference_vars_to_consider.
---
 gcc/ipa-reference.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 2ea2a6d5327..a6b79fb9381 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -966,8 +966,7 @@ propagate (void)
   ipa_ref_var_info_summaries = NULL;
 }
 
-  if (dump_file)
-vec_free (reference_vars_to_consider);
+  vec_free (reference_vars_to_consider);
   reference_vars_to_consider = NULL;
   return remove_p ? TODO_remove_functions : 0;
 }
@@ -1059,6 +1058,7 @@ ipa_reference_write_optimization_summary (void)
   auto_bitmap ltrans_statics;
   int i;
 
+  vec_free (reference_vars_to_consider);
   vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids);
   reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true);
 
@@ -1117,7 +1117,8 @@ ipa_reference_write_optimization_summary (void)
  }
   }
   lto_destroy_simple_output_block (ob);
-  delete reference_vars_to_consider;
+  vec_free (reference_vars_to_consider);
+  reference_vars_to_consider = NULL;
 }
 
 /* Deserialize the ipa info for lto.  */
-- 
2.26.2

Re: [PATCH] fix memory leak in optimize pragma parsing

[Richard Biener]

On Wed, 10 Feb 2021, Jakub Jelinek wrote:

> On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> > The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> > but doesn't free the array.  The following fixes that.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> > 
> > Thanks,
> > Richard.
> > 
> > 2021-02-10  Richard Biener  
> > 
> > gcc/c-family/
> > * c-common.c (parse_optimize_options): Free decoded_options.
> > ---
> >  gcc/c-family/c-common.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> > index 813212cc21d..088626d1e09 100644
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -5770,6 +5770,7 @@ parse_optimize_options (tree args, bool attr_p)
> >decode_options (_options, _options_set,
> >   decoded_options, decoded_options_count,
> >   input_location, global_dc, NULL);
> > +  free (decoded_options);
> >  
> >targetm.override_options_after_change();
> 
> If the option processing can't remember pointers into that array, sure.
> But if something would do that, it would show up at least in valgrind or
> asan-bootstrap.

option processing shouldn't remember pointers to a cl_decoded_option,
it might remember entries but not by reference either and we just
free the array here.

I'm not sure asan-bootstrap would show anything since it requries
optimize pragmas or attributes but the testsuite has quite some cases
and that went clean.

So pushed.

Richard.

New Japanese PO file for 'gcc' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Japanese team of translators.  The file is available at:

https://translationproject.org/latest/gcc/ja.po

(This file, 'gcc-11.1-b20210207.ja.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] fix memory leak in optimize pragma parsing

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> but doesn't free the array.  The following fixes that.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> 
> Thanks,
> Richard.
> 
> 2021-02-10  Richard Biener  
> 
> gcc/c-family/
>   * c-common.c (parse_optimize_options): Free decoded_options.
> ---
>  gcc/c-family/c-common.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 813212cc21d..088626d1e09 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -5770,6 +5770,7 @@ parse_optimize_options (tree args, bool attr_p)
>decode_options (_options, _options_set,
> decoded_options, decoded_options_count,
> input_location, global_dc, NULL);
> +  free (decoded_options);
>  
>targetm.override_options_after_change();

If the option processing can't remember pointers into that array, sure.
But if something would do that, it would show up at least in valgrind or
asan-bootstrap.

Jakub

[PATCH] if-to-switch: fix memory leak in case merging

[Martin Liška]

This one fixes 2 more memory leaks.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I also tested that building postgresql with valgrind does not display
anything related to the affected files.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR tree-optimization/99002
PR tree-optimization/99026
* gimple-if-to-switch.cc (if_chain::is_beneficial): Fix memory
leak when adjacent cases are merged.
* tree-switch-conversion.c 
(switch_decision_tree::analyze_switch_statement): Use
release_clusters.
(make_pass_lower_switch): Remove trailing whitespace.
* tree-switch-conversion.h (release_clusters): New.
---
 gcc/gimple-if-to-switch.cc   | 17 +
 gcc/tree-switch-conversion.c |  9 +
 gcc/tree-switch-conversion.h | 10 ++
 3 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index f39662be3e6..16fabef7ca0 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -227,6 +227,7 @@ if_chain::is_beneficial ()
(left->get_high ()), wi::one (TYPE_PRECISION (type
{
  left->set_high (right->get_high ());
+ delete right;
  continue;
}
}
@@ -241,20 +242,20 @@ if_chain::is_beneficial ()
 = jump_table_cluster::find_jump_tables (filtered_clusters);
   bool r = output.length () < filtered_clusters.length ();
   if (r)
-dump_clusters (, "JT can be built");
-  output.release ();
-  if (r)
-return true;
+{
+  dump_clusters (, "JT can be built");
+  release_clusters (output);
+  return true;
+}
+  else
+output.release ();
 
   output = bit_test_cluster::find_bit_tests (filtered_clusters);

   r = output.length () < filtered_clusters.length ();
   if (r)
 dump_clusters (, "BT can be built");
 
-  for (unsigned i = 0; i < output.length (); i++)

-delete output[i];
-
-  output.release ();
+  release_clusters (output);
   return r;
 }
 
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c

index a4798812dbf..7f65c4ce839 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -1824,12 +1824,7 @@ switch_decision_tree::analyze_switch_statement ()
   output.release ();
 
   bool expanded = try_switch_expansion (output2);

-
-  for (unsigned i = 0; i < output2.length (); i++)
-delete output2[i];
-
-  output2.release ();
-
+  release_clusters (output2);
   return expanded;
 }
 
@@ -2597,5 +2592,3 @@ make_pass_lower_switch (gcc::context *ctxt)

 {
   return new pass_lower_switch (ctxt);
 }
-
-
diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h
index d3d568e84cc..d76f19b57f6 100644
--- a/gcc/tree-switch-conversion.h
+++ b/gcc/tree-switch-conversion.h
@@ -893,6 +893,16 @@ switch_decision_tree::reset_out_edges_aux (gswitch *swtch)
 e->aux = (void *) 0;
 }
 
+/* Release CLUSTERS vector and destruct all dynamically allocated items.  */

+
+static inline void
+release_clusters (vec )
+{
+  for (unsigned i = 0; i < clusters.length (); i++)
+delete clusters[i];
+  clusters.release ();
+}
+
 } // tree_switch_conversion namespace
 
 #endif // TREE_SWITCH_CONVERSION_H

--
2.30.0

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

[Richard Biener via Gcc-patches]

On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor  wrote:
>
> On 2/9/21 12:41 AM, Richard Biener wrote:
> > On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
> >  wrote:
> >>
> >> On 2/8/21 12:09 PM, Jeff Law wrote:
> >>>
> >>>
> >>> On 2/3/21 3:45 PM, Martin Sebor wrote:
>  On 2/3/21 2:57 PM, Jeff Law wrote:
> >
> >
> > On 1/28/21 4:03 PM, Martin Sebor wrote:
> >> The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
> >> leading offset is in bounds but whose trailing offset is not has
> >> been causing some confusion.  When the warning is issued for
> >> an access to an in-bounds member via a pointer to a struct that's
> >> larger than the pointed-to object, phrasing this strictly invalid
> >> access in terms of array subscripts can be misleading, especially
> >> when the source code doesn't involve any arrays or indexing.
> >>
> >> Since the problem boils down to an aliasing violation much more
> >> so than an actual out-of-bounds access, the attached patch adjusts
> >> the code to issue a -Wstrict-aliasing warning in these cases instead
> >> of -Warray-bounds.  In addition, since the aliasing assumptions in
> >> GCC can be disabled by -fno-strict-aliasing, the patch also makes
> >> these instances of the warning conditional on -fstrict-aliasing
> >> being in effect.
> >>
> >> Martin
> >>
> >> gcc-98503.diff
> >>
> >> PR middle-end/98503 -Warray-bounds when -Wstrict-aliasing would be
> >> more appropriate
> >>
> >> gcc/ChangeLog:
> >>
> >>   PR middle-end/98503
> >>   * gimple-array-bounds.cc (array_bounds_checker::check_mem_ref):
> >>   Issue -Wstrict-aliasing for a subset of violations.
> >>   (array_bounds_checker::check_array_bounds):  Set new member.
> >>   * gimple-array-bounds.h (array_bounds_checker::cref_of_mref): New
> >>   data member.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >>   PR middle-end/98503
> >>   * g++.dg/warn/Warray-bounds-10.C: Adjust text of expected 
> >> warnings.
> >>   * g++.dg/warn/Warray-bounds-11.C: Same.
> >>   * g++.dg/warn/Warray-bounds-12.C: Same.
> >>   * g++.dg/warn/Warray-bounds-13.C: Same.
> >>   * gcc.dg/Warray-bounds-63.c: Avoid -Wstrict-aliasing.  Adjust 
> >> text
> >>   of expected warnings.
> >>   * gcc.dg/Warray-bounds-66.c: Adjust text of expected warnings.
> >>   * gcc.dg/Wstrict-aliasing-2.c: New test.
> >>   * gcc.dg/Wstrict-aliasing-3.c: New test.
> > What I don't like here is the strict-aliasing warnings inside the file
> > and analysis phase for array bounds checking.
> >
> > ISTM that catching this at cast time would be better.  So perhaps in
> > build_c_cast and the C++ equivalent?
> >
> > It would mean we're warning at the cast site rather than the
> > dereference, but that may ultimately be better for the warning anyway.
> > I'm not sure.
> 
>  I had actually experimented with a this (in the middle end, and only
>  for accesses) but even that caused so many warnings that I abandoned
>  it, at least for now.  -Warray-bounds has the benefit of flow analysis
>  (and dead code elimination).  In the front end it would have neither
>  and be both excessively noisy and ineffective at the same time.  For
>  example:
> >>> I think we agree that this really is an aliasing issue and I would go
> >>> further and claim that it has nothing to do with array bounds checking.
> >>> Therefore warning for it within gimple-array-bounds just seems wrong.
> >>>
> >>> I realize that you like having DCE run and the ability to look at
> >>> offsets and such, but it really feels like the wrong place to do this.
> >>> Aliasing issues are also more of a front-end thing since the language
> >>> defines what is and what is not valid aliasing -- one might even argue
> >>> that any aliasing warning needs to be identified by the front-ends
> >>> exclusively (though possibly pruned away later).
> >>
> >> The aliasing restrictions are on accesses, which are [defined in
> >> C as] execution-time actions on objects.  Analyzing execution-time
> >> actions unavoidably depends on flow analysis which the front ends
> >> have only very limited support for (simple expressions only).
> >> I gave one example showing how the current -Wstrict-aliasing in
> >> the front end is ineffective against all but the most simplistic
> >> bugs, but there are many more.  For instance:
> >>
> >> int i;
> >> void *p = // valid
> >> float *q = p;// valid
> >> *q = 0;  // aliasing violation
> >>
> >> This bug is easily detectable in the middle end but impossible
> >> to do in the front end (same as all other invalid accesses).
> >
> > But the code is valid in GIMPLE which allows to re-use the 'int i' storage
> > with storing using a 

[PATCH] rtl-optimization/99054 - fix leak in fixup_partitions

[Richard Biener]

This fixes a leak of the vector retured by find_partition_fixes
by turning it into an auto_vec.

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

2021-02-10  Richard Biener  

PR rtl-optimization/99054
* cfgrtl.c (rtl-optimization/99054): Return an auto_vec.
(fixup_partitions): Adjust.
(rtl_verify_edges): Likewise.
---
 gcc/cfgrtl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 1d512128eeb..3f55a3265f2 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -2381,11 +2381,11 @@ find_bbs_reachable_by_hot_paths (hash_set 
*set)
cfg optimizations that may make hot blocks previously reached
by both hot and cold blocks now only reachable along cold paths.  */
 
-static vec
+static auto_vec
 find_partition_fixes (bool flag_only)
 {
   basic_block bb;
-  vec bbs_to_fix = vNULL;
+  auto_vec bbs_to_fix;
   hash_set set;
 
   /* Callers check this.  */
@@ -2431,7 +2431,7 @@ fixup_partitions (void)
?? a cold partition cannot dominate a basic block in a hot partition.
  Fixup any that now violate this requirement, as a result of edge
  forwarding and unreachable block deletion. ??*/
-  vec bbs_to_fix = find_partition_fixes (false);
+  auto_vec bbs_to_fix = find_partition_fixes (false);
 
   /* Do the partition fixup after all necessary blocks have been converted to
  cold, so that we only update the region crossings the minimum number of
@@ -2682,7 +2682,7 @@ rtl_verify_edges (void)
   if (crtl->has_bb_partition && !err
   && current_ir_type () == IR_RTL_CFGLAYOUT)
 {
-  vec bbs_to_fix = find_partition_fixes (true);
+  auto_vec bbs_to_fix = find_partition_fixes (true);
   err = !bbs_to_fix.is_empty ();
 }
 
-- 
2.26.2

[PATCH] fix memory leak in optimize pragma parsing

[Richard Biener]

The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
but doesn't free the array.  The following fixes that.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

2021-02-10  Richard Biener  

gcc/c-family/
* c-common.c (parse_optimize_options): Free decoded_options.
---
 gcc/c-family/c-common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 813212cc21d..088626d1e09 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5770,6 +5770,7 @@ parse_optimize_options (tree args, bool attr_p)
   decode_options (_options, _options_set,
  decoded_options, decoded_options_count,
  input_location, global_dc, NULL);
+  free (decoded_options);
 
   targetm.override_options_after_change();
 
-- 
2.26.2

Re: [PATCH v2] arm: Low overhead loop handle long range branches [PR98931]

[Andrea Corallo via Gcc-patches]

"Richard Earnshaw (lists)"  writes:

> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>> Jakub Jelinek  writes:
>> 
>>> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches 
>>> wrote:
>"TARGET_32BIT && TARGET_HAVE_LOB"
> -  "le\t%|lr, %l0")
> +  "*
> +  if (get_attr_length (insn) == 4)
> +return \"le\\t%|lr, %l0\";
> +  else
> +return \"subs\\t%|lr, #1\;bne\\t%l0\";
> +  "

 Why not
 {
   if (get_attr_length (insn) == 4)
 return "le\t%|lr, %l0";
   else
 return "subs\t%|lr, #1;bne\t%l0";
 }
 instead?  Seems the arm backend uses "*..." more than the more modern {},
 but one needs to backslash prefix a lot which makes it less readable?
>>>
>>> Where "more modern" is introduced 19.5 years ago ;)
>>>
>>> Jakub
>> 
>> I guess we really like traditions :)
>> 
>> Attached second version addressing this.
>> 
>> Thanks
>> 
>>   Andrea
>> 
>
> You're missing a clobber of the condition codes in the RTL.  This wasn't
> needed before, but is now.
>
> R.

Hi Richard,

thanks for reviewing, I guess this is going to be a good learning moment
for me.

What we originally expand is:

(insn 2396 2360 2397 3 (parallel [
(set (reg:CC_NZ 100 cc)
(compare:CC_NZ (plus:SI (reg:SI 14 lr)
(const_int -1 [0x]))
(const_int 0 [0])))
(set (reg:SI 14 lr)
(plus:SI (reg:SI 14 lr)
(const_int -1 [0x])))
]) "p1.c":4:21 -1
 (nil))
(jump_insn 2397 2396 2365 3 (set (pc)
(if_then_else (ne (reg:CC_NZ 100 cc)
(const_int 0 [0]))
(label_ref:SI 2361)
(pc))) "p1.c":4:21 273 {arm_cond_branch}
 (expr_list:REG_DEAD (reg:CC_NZ 100 cc)
(int_list:REG_BR_PROB 1062895996 (nil)))
 -> 2361)

Combine recognizing cc:CC_NZ as a dead reg and rewriting the two insns
as:

(jump_insn 2397 2396 2365 3 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 14 lr)
(const_int 1 [0x1]))
(label_ref:SI 2361)
(pc)))
(set (reg:SI 14 lr)
(plus:SI (reg:SI 14 lr)
(const_int -1 [0x])))
]) "p1.c":4:21 1047 {*doloop_end_internal}
 (int_list:REG_BR_PROB 1062895996 (nil))
 -> 2361)

I originally thought that because the write of reg:CC_NZ is explicit in
the first pattern we expand this was sufficient, but I now understand
I'm wrong and combine should produce a pattern still expressing this.
Now the question is how to do that.

If I add the clobber '(clobber (reg:CC CC_REGNUM))' inside the parallel
of *doloop_end_internal as last element of the vector we ICE in
'add_clobbers' called during combine, apparently 'add_clobbers' does not
handle the insn_code_number.

If I add it as second element of the parallel combine is not combining
the two insns.

If I place the clobber outside the parallel as a second element of the
insn vector combine is crashing in 'recog_for_combine_1'.

So the question is probably: where should the clobber be positioned
canonically to have this working?

Thanks!

  Andrea

[committed] openmp: Temporarily disable into_ssa when gimplifying OpenMP reduction clauses [PR99007]

[Jakub Jelinek via Gcc-patches]

Hi!

gimplify_scan_omp_clauses was already calling gimplify_expr with false as
last argument to make sure it is not an SSA_NAME, but as the testcases show,
that is not enough, SSA_NAME temporaries created during that gimplification
can be reused too and we can't allow SSA_NAMEs to be used across OpenMP
region boundaries, as we can only firstprivatize decls.

Fixed by temporarily disabling into_ssa.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2021-02-10  Jakub Jelinek  

PR middle-end/99007
* gimplify.c (gimplify_scan_omp_clauses): For MEM_REF on reductions,
temporarily disable gimplify_ctxp->into_ssa around gimplify_expr
calls.

* g++.dg/gomp/pr99007.C: New test.
* gcc.dg/gomp/pr99007-1.c: New test.
* gcc.dg/gomp/pr99007-2.c: New test.
* gcc.dg/gomp/pr99007-3.c: New test.

--- gcc/gimplify.c.jj   2021-01-26 08:57:46.473172059 +0100
+++ gcc/gimplify.c  2021-02-09 17:15:29.391887803 +0100
@@ -8781,13 +8781,17 @@ gimplify_scan_omp_clauses (tree *list_p,
  if (TREE_CODE (decl) == MEM_REF)
{
  tree type = TREE_TYPE (decl);
+ bool saved_into_ssa = gimplify_ctxp->into_ssa;
+ gimplify_ctxp->into_ssa = false;
  if (gimplify_expr (_MAX_VALUE (TYPE_DOMAIN (type)), pre_p,
 NULL, is_gimple_val, fb_rvalue, false)
  == GS_ERROR)
{
+ gimplify_ctxp->into_ssa = saved_into_ssa;
  remove = true;
  break;
}
+ gimplify_ctxp->into_ssa = saved_into_ssa;
  tree v = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
  if (DECL_P (v))
{
@@ -8797,13 +8801,16 @@ gimplify_scan_omp_clauses (tree *list_p,
  decl = TREE_OPERAND (decl, 0);
  if (TREE_CODE (decl) == POINTER_PLUS_EXPR)
{
+ gimplify_ctxp->into_ssa = false;
  if (gimplify_expr (_OPERAND (decl, 1), pre_p,
 NULL, is_gimple_val, fb_rvalue, false)
  == GS_ERROR)
{
+ gimplify_ctxp->into_ssa = saved_into_ssa;
  remove = true;
  break;
}
+ gimplify_ctxp->into_ssa = saved_into_ssa;
  v = TREE_OPERAND (decl, 1);
  if (DECL_P (v))
{
--- gcc/testsuite/g++.dg/gomp/pr99007.C.jj  2021-02-09 17:20:36.487454483 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr99007.C 2021-02-09 17:26:08.779739476 +0100
@@ -0,0 +1,18 @@
+// PR middle-end/99007
+// { dg-additional-options "-Wno-div-by-zero" }
+
+template 
+void
+bar (T *)
+{
+  T s[0/0];
+  #pragma omp teams distribute parallel for reduction(+:s) allocate(s)
+  for (int i = 0; i < 8; i++)
+;
+}
+
+void
+foo (long *a)
+{
+  bar (a);
+}
--- gcc/testsuite/gcc.dg/gomp/pr99007-1.c.jj2021-02-09 17:22:57.456878452 
+0100
+++ gcc/testsuite/gcc.dg/gomp/pr99007-1.c   2021-02-09 17:22:38.101094856 
+0100
@@ -0,0 +1,13 @@
+/* PR middle-end/99007 */
+
+void
+bar (int n)
+{
+  int i;
+  long s[n];
+  for (i = 0; i < n; i++)
+s[i] = 0;
+  #pragma omp teams distribute parallel for reduction(+:s) allocate(s)
+  for (i = 0; i < 8; i++)
+s[3]++;
+}
--- gcc/testsuite/gcc.dg/gomp/pr99007-2.c.jj2021-02-09 17:23:00.449844997 
+0100
+++ gcc/testsuite/gcc.dg/gomp/pr99007-2.c   2021-02-09 17:22:44.682021286 
+0100
@@ -0,0 +1,15 @@
+/* PR middle-end/99007 */
+
+int
+bar (int n)
+{
+  int s[n];
+  int i, j;
+  for (i = 0; i < n; i++)
+s[i] = 0;
+  #pragma omp teams distribute parallel for reduction(+:s) private (j)
+  for (i = 0; i < 8; i++)
+for (j = 0; j < n; j++)
+  s[j] += i;
+  return s[0] + s[n - 1];
+}
--- gcc/testsuite/gcc.dg/gomp/pr99007-3.c.jj2021-02-09 17:23:03.315812951 
+0100
+++ gcc/testsuite/gcc.dg/gomp/pr99007-3.c   2021-02-09 17:22:52.281936308 
+0100
@@ -0,0 +1,16 @@
+/* PR middle-end/99007 */
+
+int
+bar (int n)
+{
+  int s[n];
+  int i, j;
+  for (i = 0; i < n; i++)
+s[i] = 0;
+  #pragma omp parallel reduction(+:s) num_threads(2)
+  #pragma omp parallel for reduction(+:s) private (j)
+  for (i = 0; i < 8; i++)
+for (j = 0; j < n; j++)
+  s[j] += i;
+  return s[0] + s[n - 1];
+}

Jakub

Re: [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns

[Richard Sandiford via Gcc-patches]

Joel Hutton  writes:
> Hi Richards,
>
> This patch adds support for the V8QI->V8HI case from widening vect patterns 
> as discussed to target PR98772.

Thanks, the approach looks good to me.  Mostly just minor comments below.

> Bootstrapped and regression tested on aarch64.
>
>
> [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns
>
> In the case where 8 out of every 16 elements are widened using a
> widening pattern and the next 8 are skipped the patterns are not
> recognized. This is because they are normally used in a pair, such  as
> VEC_WIDEN_MINUS_HI/LO, to achieve a v16qi->v16hi conversion for example.
> This patch adds support for V8HI->V8QI patterns.
>
> gcc/ChangeLog:
> PR tree-optimisation/98772
> * optabs-tree.c (supportable_convert_operation): Add case for 
> V8QI->V8HI
> * tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): New 
> function to generate promotion stmts for V8QI->V8HI
> (vectorizable_conversion): Add case for V8QI->V8HI
>
> gcc/testsuite/ChangeLog:
> PR tree-optimisation/98772
> * gcc.target/aarch64/pr98772.c: New test.
>
> diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c
> index 
> c94073e3ed98f8c4cab65891f65dedebdb1ec274..b91ce3af6f0d4b3a62110bdb38f68ecc53765cad
>  100644
> --- a/gcc/optabs-tree.c
> +++ b/gcc/optabs-tree.c
> @@ -308,6 +308,40 @@ supportable_convert_operation (enum tree_code code,
>if (!VECTOR_MODE_P (m1) || !VECTOR_MODE_P (m2))
>  return false;
>  
> +  /* The case where a widening operation is not making use of the full width 
> of
> + of the input vector, but using the full width of the output vector.
> + Return the non-wided code, which will be used after the inputs are

non-widened

> + converted to the wide type.  */
> +  if ((code == WIDEN_MINUS_EXPR
> +  || code == WIDEN_PLUS_EXPR
> +  || code == WIDEN_MULT_EXPR
> +  || code == WIDEN_LSHIFT_EXPR)

Minor formatting nit, but the ||s should be indented one space more.

> +  && known_eq (TYPE_VECTOR_SUBPARTS (vectype_in),
> +   TYPE_VECTOR_SUBPARTS (vectype_out)))
> +  {
> +switch (code)
> +{
> +  case WIDEN_LSHIFT_EXPR:
> + *code1 = LSHIFT_EXPR;
> + return true;
> + break;
> +  case WIDEN_MINUS_EXPR:
> + *code1 = MINUS_EXPR;
> + return true;
> + break;
> +  case WIDEN_PLUS_EXPR:
> + *code1 = PLUS_EXPR;
> + return true;
> + break;
> +  case WIDEN_MULT_EXPR:
> + *code1 = MULT_EXPR;
> + return true;
> + break;
> +  default:
> + gcc_unreachable ();
> +}
> +  }

Rather than return true, I think we should do something like:

  if (!supportable_convert_operation (NOP_EXPR, vectype_out,
  vectype_in, _code))
return false;

  optab = optab_for_tree_code (*code1, vectype_out, optab_default);
  return (optab_handler (optab, TYPE_MODE (vectype_out))
  != CODE_FOR_nothing);

to make sure that the target really does support this.

AFAICT the caller always knows when it wants the “if” statement above
to be used.  What it's doing is a bit different from what
supportable_convert_operation normally does, so it might be better
to put it into a separate function that tests whether the target
supports the non-widening form of a widening operation.

> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 
> f180ced312443ba1e698932d5e8362208690b3fc..b34b00f67ea67943dee7023ab9bfd19c1be5ccbe
>  100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -4545,6 +4545,72 @@ vect_create_vectorized_promotion_stmts (vec_info 
> *vinfo,
>*vec_oprnds0 = vec_tmp;
>  }
>  
> +/* Create vectorized promotion stmts for widening stmts using only half the
> +   potential vector size for input.  */
> +static void
> +vect_create_vectorized_promotion_stmts (vec_info *vinfo,
> + vec *vec_oprnds0,
> + vec *vec_oprnds1,
> + stmt_vec_info stmt_info, tree vec_dest,
> + gimple_stmt_iterator *gsi,
> + enum tree_code code1,
> + int op_type)
> +{
> +  int i;
> +  tree vop0, vop1, new_tmp;
> +  gimple *new_stmt1;
> +  gimple *new_stmt2;
> +  gimple *new_stmt3;
> +  vec vec_tmp = vNULL;
> +
> +  vec_tmp.create (vec_oprnds0->length () * 2);

It looks like the * 2 isn't needed.

> +  FOR_EACH_VEC_ELT (*vec_oprnds0, i, vop0)
> +{
> +  tree new_tmp1, new_tmp2, new_tmp3, out_type;
> +
> +  gcc_assert (op_type == binary_op);
> +  vop1 = (*vec_oprnds1)[i];
> +
> +  /* Widen the first vector input.  */
> +  out_type = TREE_TYPE (vec_dest);
> +  new_tmp1 = make_ssa_name (out_type);
> +  new_stmt1 = gimple_build_assign (new_tmp1, NOP_EXPR, vop0);
> +  vect_finish_stmt_generation (vinfo, stmt_info, new_stmt1, gsi);
> +  if 

[PATCH] ipa/99029 - fix memory leak in propagate_malloc

[Richard Biener]

This makes sure to release the vec<> of callees.

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

2021-02-10  Richard Biener  

PR ipa/99029
* ipa-pure-const.c (propagate_malloc): Use an auto_vec<>
for callees.
---
 gcc/ipa-pure-const.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 957217ae4ae..f045108af21 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1937,7 +1937,7 @@ propagate_malloc (void)
  if (l->malloc_state == STATE_MALLOC_BOTTOM)
continue;
 
- vec callees = vNULL;
+ auto_vec callees;
  for (cgraph_edge *cs = node->callees; cs; cs = cs->next_callee)
{
  ipa_call_summary *es = ipa_call_summaries->get_create (cs);
-- 
2.26.2

[PATCH] tree-optimization/99024 - fix leak in loop vect analysis

[Richard Biener]

When we analyzed a loop as epilogue but later in peeling decide
we're not going to use it then in the DTOR we clear the original
loops ->aux which causes us to leak the main loop vinfo.

Fixed by only clearing aux if it is associated with the vinfo
we're destroying.

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

2021-02-10  Richard Biener  

PR tree-optimization/99024
* tree-vect-loop.c (_loop_vec_info::~_loop_vec_info): Only
clear loop->aux if it is associated with the destroyed loop_vinfo.
---
 gcc/tree-vect-loop.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index f1f16e3b1b9..27845c01430 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -927,7 +927,11 @@ _loop_vec_info::~_loop_vec_info ()
   delete scan_map;
   epilogue_vinfos.release ();
 
-  loop->aux = NULL;
+  /* When we release an epiloge vinfo that we do not intend to use
+ avoid clearing AUX of the main loop which should continue to
+ point to the main loop vinfo since otherwise we'll leak that.  */
+  if (loop->aux == this)
+loop->aux = NULL;
 }
 
 /* Return an invariant or register for EXPR and emit necessary
-- 
2.26.2

New Vietnamese PO file for 'cpplib' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Vietnamese team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/vi.po

(This file, 'cpplib-11.1-b20210207.vi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-11.1-b20210207.vi.po'

[Translation Project Robot]

cpplib-11.1-b20210207.vi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH 4/8] intl: turn LIBINTL into -L / -l form

[Alan Modra via Gcc-patches]

On Mon, Feb 08, 2021 at 11:16:31AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-04  Nick Alcock  
> 
>   * configure.ac (LIBINTL): Transform into -L/-lintl form.
>   * configure: Regenerate.

OK for binutils.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH 3/8] intl: always picify

[Alan Modra via Gcc-patches]

On Mon, Feb 08, 2021 at 11:16:30AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-02  Nick Alcock  
> 
>   * aclocal.m4: include picflag.m4.
>   * configure.ac (PICFLAG): Add and substitute.
>   * Makefile.in (PICFLAG): New.
>   (COMPILE): Use it.
>   * configure: Regenerate.

OK for binutils.

-- 
Alan Modra
Australia Development Lab, IBM