public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]
Date: Wed, 8 Mar 2023 11:54:07 -0500	[thread overview]
Message-ID: <cc6f7895-a860-d44b-e438-c8476c055998@redhat.com> (raw)
In-Reply-To: <4d1a02da-b1b5-1cdb-c435-ba0299d8bd9b@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3518 bytes --]

On 3/8/23 11:15, Jason Merrill wrote:
> On 3/8/23 10:53, Jan Hubicka wrote:
>>> Tested x86_64-pc-linux-gnu.  Does this look good, or do we want to 
>>> factor the
>>> flag clearing into a symtab_node counterpart to cgraph_node::reset?
>>>
>>> -- 8< --
>>>
>>> In 107897, by the time we are looking at the mangling clash, the
>>> alias has already been removed from the symbol table by 
>>> analyze_functions,
>>> so we can't look at n->cpp_implicit_alias.  So just assume that it's an
>>> alias if it's internal.
>>>
>>> In 108887 the problem is that removing the mangling alias from the 
>>> symbol
>>> table confuses analyze_functions, because it ended up as first_analyzed
>>> somehow, so it becomes a dangling pointer.  Fixed by clearing various 
>>> flags
>>> to neutralize the alias.
>>>
>>>     PR c++/107897
>>>     PR c++/108887
>>>
>>> gcc/cp/ChangeLog:
>>>
>>>     * decl2.cc (record_mangling): Improve symbol table handling.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>     * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported.
>>>     * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
>>> ---
>>>   gcc/cp/decl2.cc                               | 25 +++++--
>>>   .../g++.dg/cpp0x/lambda/lambda-mangle7.C      | 70 +++++++++++++++++++
>>>   gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C |  1 +
>>>   3 files changed, 91 insertions(+), 5 deletions(-)
>>>   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C
>>>
>>> diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
>>> index 387e24542cd..e6e58b08de4 100644
>>> --- a/gcc/cp/decl2.cc
>>> +++ b/gcc/cp/decl2.cc
>>> @@ -4742,15 +4742,30 @@ record_mangling (tree decl, bool need_warning)
>>>       = mangled_decls->find_slot_with_hash (id, IDENTIFIER_HASH_VALUE 
>>> (id),
>>>                         INSERT);
>>> -  /* If this is already an alias, remove the alias, because the real
>>> +  /* If this is already an alias, cancel the alias, because the real
>>>        decl takes precedence.  */
>>>     if (*slot && DECL_ARTIFICIAL (*slot) && DECL_IGNORED_P (*slot))
>>> -    if (symtab_node *n = symtab_node::get (*slot))
>>> -      if (n->cpp_implicit_alias)
>>> +    {
>>> +      if (symtab_node *n = symtab_node::get (*slot))
>>>       {
>>> -      n->remove ();
>>> -      *slot = NULL_TREE;
>>> +      if (n->cpp_implicit_alias)
>>> +        {
>>> +          /* Actually removing the node isn't safe if other code is 
>>> already
>>> +         holding a pointer to it, so just neutralize it.  */
>>> +          n->remove_from_same_comdat_group ();
>>> +          n->analyzed = false;
>>> +          n->definition = false;
>>> +          n->alias = false;
>>> +          n->cpp_implicit_alias = false;
>> We have n->reset () for that which is used in similar situation when
>> frontends overwrites extern inline function by its different offline
>> implementation.
> 
> The problem there is that reset() is a member of cgraph_node, not 
> symtab_node, and I need something that works for variables as well.
> 
>> reset doesn't call remove_from_same_comdat_group probably because it was
>> never used on anything in comdat group.  So I think it would make sense
>> to call n->reset() here and add remove_from_same_comdat_group into that.

How about moving it to symtab_node and using dyn_cast for the cgraph 
bits, like this:

[-- Attachment #2: 0001-c-lambda-mangling-alias-issues-PR107897.patch --]
[-- Type: text/x-patch, Size: 9043 bytes --]

From 1d869ceb04573727e59be6518903133c8654069a Mon Sep 17 00:00:00 2001
From: Jason Merrill <jason@redhat.com>
Date: Mon, 6 Mar 2023 15:33:45 -0500
Subject: [PATCH] c++: lambda mangling alias issues [PR107897]
To: gcc-patches@gcc.gnu.org

In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the symbol table by analyze_functions,
so we can't look at n->cpp_implicit_alias.  So just assume that it's an
alias if it's internal.

In 108887 the problem is that removing the mangling alias from the symbol
table confuses analyze_functions, because it ended up as first_analyzed
somehow, so it becomes a dangling pointer.  Fixed by clearing various flags
to neutralize the alias.

	PR c++/107897
	PR c++/108887

gcc/ChangeLog:

	* cgraph.h: Move reset() from cgraph_node to symtab_node.
	* cgraphunit.cc (symtab_node::reset): Adjust.

gcc/cp/ChangeLog:

	* decl2.cc (record_mangling): Use symtab_node::reset.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported.
	* g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
---
 gcc/cgraph.h                                  | 16 ++---
 gcc/cgraphunit.cc                             | 27 ++++---
 gcc/cp/decl2.cc                               | 19 +++--
 .../g++.dg/cpp0x/lambda/lambda-mangle7.C      | 70 +++++++++++++++++++
 gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C |  1 +
 5 files changed, 109 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index b5fc739f1b0..fb938470be9 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -149,6 +149,14 @@ public:
      cgraph/varpool node creation routines.  */
   void register_symbol (void);
 
+  /* As an GCC extension we allow redefinition of the function.  The
+     semantics when both copies of bodies differ is not well defined.
+     We replace the old body with new body so in unit at a time mode
+     we always use new body, while in normal mode we may end up with
+     old body inlined into some functions and new body expanded and
+     inlined in others.  */
+  void reset (void);
+
   /* Remove symbol from symbol table.  */
   void remove (void);
 
@@ -1066,14 +1074,6 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public symtab_node
   /* Expand function specified by node.  */
   void expand (void);
 
-  /* As an GCC extension we allow redefinition of the function.  The
-     semantics when both copies of bodies differ is not well defined.
-     We replace the old body with new body so in unit at a time mode
-     we always use new body, while in normal mode we may end up with
-     old body inlined into some functions and new body expanded and
-     inlined in others.  */
-  void reset (void);
-
   /* Creates a wrapper from cgraph_node to TARGET node. Thunk is used for this
      kind of wrapper method.  */
   void create_wrapper (cgraph_node *target);
diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
index a972900900b..2bce529ac81 100644
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -381,18 +381,9 @@ symbol_table::process_new_functions (void)
    body for expanding the function but this is difficult to do.  */
 
 void
-cgraph_node::reset (void)
+symtab_node::reset (void)
 {
-  /* If process is set, then we have already begun whole-unit analysis.
-     This is *not* testing for whether we've already emitted the function.
-     That case can be sort-of legitimately seen with real function redefinition
-     errors.  I would argue that the front end should never present us with
-     such a case, but don't enforce that for now.  */
-  gcc_assert (!process);
-
   /* Reset our data structures so we can analyze the function again.  */
-  inlined_to = NULL;
-  memset (&rtl, 0, sizeof (rtl));
   analyzed = false;
   definition = false;
   alias = false;
@@ -400,8 +391,22 @@ cgraph_node::reset (void)
   weakref = false;
   cpp_implicit_alias = false;
 
-  remove_callees ();
   remove_all_references ();
+  remove_from_same_comdat_group ();
+
+  if (cgraph_node *cn = dyn_cast <cgraph_node *> (this))
+    {
+      /* If process is set, then we have already begun whole-unit analysis.
+	 This is *not* testing for whether we've already emitted the function.
+	 That case can be sort-of legitimately seen with real function
+	 redefinition errors.  I would argue that the front end should never
+	 present us with such a case, but don't enforce that for now.  */
+      gcc_assert (!cn->process);
+
+      memset (&cn->rtl, 0, sizeof (cn->rtl));
+      cn->inlined_to = NULL;
+      cn->remove_callees ();
+    }
 }
 
 /* Return true when there are references to the node.  INCLUDE_SELF is
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 387e24542cd..57713d2ffdc 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -4742,15 +4742,24 @@ record_mangling (tree decl, bool need_warning)
     = mangled_decls->find_slot_with_hash (id, IDENTIFIER_HASH_VALUE (id),
 					  INSERT);
 
-  /* If this is already an alias, remove the alias, because the real
+  /* If this is already an alias, cancel the alias, because the real
      decl takes precedence.  */
   if (*slot && DECL_ARTIFICIAL (*slot) && DECL_IGNORED_P (*slot))
-    if (symtab_node *n = symtab_node::get (*slot))
-      if (n->cpp_implicit_alias)
+    {
+      if (symtab_node *n = symtab_node::get (*slot))
 	{
-	  n->remove ();
-	  *slot = NULL_TREE;
+	  if (n->cpp_implicit_alias)
+	    /* Actually removing the node isn't safe if other code is already
+	       holding a pointer to it, so just neutralize it.  */
+	    n->reset ();
 	}
+      else
+	/* analyze_functions might have already removed the alias from the
+	   symbol table if it's internal.  */
+	gcc_checking_assert (!TREE_PUBLIC (*slot));
+
+      *slot = NULL_TREE;
+    }
 
   if (!*slot)
     *slot = decl;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C
new file mode 100644
index 00000000000..c7946a2be08
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C
@@ -0,0 +1,70 @@
+// PR c++/108887
+// { dg-do compile { target c++11 } }
+
+template <int __v> struct integral_constant {
+  static constexpr int value = __v;
+};
+using false_type = integral_constant<false>;
+template <bool, bool, typename...> struct __result_of_impl;
+template <typename _Functor, typename... _ArgTypes>
+struct __result_of_impl<false, false, _Functor, _ArgTypes...> {
+  typedef decltype(0) type;
+};
+template <typename... _ArgTypes>
+struct __invoke_result
+    : __result_of_impl<false_type::value, false_type::value, _ArgTypes...> {};
+template <typename, typename _Fn, typename... _Args>
+void __invoke_impl(_Fn __f, _Args... __args) {
+  __f(__args...);
+}
+template <typename, typename _Callable, typename... _Args>
+void __invoke_r(_Callable __fn, _Args... __args) {
+  using __result = __invoke_result<_Args...>;
+  using __type = typename __result::type;
+  __invoke_impl<__type>(__fn, __args...);
+}
+struct QString {
+  QString(const char *);
+};
+template <typename> class function;
+template <typename _Functor> struct _Base_manager {
+  static _Functor _M_get_pointer(int) { __builtin_abort (); }
+};
+template <typename, typename> class _Function_handler;
+template <typename _Res, typename _Functor, typename... _ArgTypes>
+struct _Function_handler<_Res(_ArgTypes...), _Functor> {
+  using _Base = _Base_manager<_Functor>;
+  static _Res _M_invoke(const int &__functor, _ArgTypes &&...__args) {
+    auto __trans_tmp_1 = _Base::_M_get_pointer(__functor);
+    __invoke_r<_Res>(__trans_tmp_1, __args...);
+  }
+};
+template <typename _Res, typename... _ArgTypes>
+struct function<_Res(_ArgTypes...)> {
+  template <typename _Functor>
+  using _Handler = _Function_handler<_Res(_ArgTypes...), _Functor>;
+  template <typename _Functor> function(_Functor) {
+    using _My_handler = _Handler<_Functor>;
+    _M_invoker = _My_handler::_M_invoke;
+  }
+  using _Invoker_type = _Res (*)(const int &, _ArgTypes &&...);
+  _Invoker_type _M_invoker;
+};
+struct QRegularExpression {
+  QRegularExpression(QString);
+};
+struct AbstractAccount {
+  void get(function<void(AbstractAccount *)>,
+           function<void(AbstractAccount *)>);
+};
+struct AbstractTimelineModel {
+  AbstractAccount m_account;
+};
+struct LinkPaginationTimelineModel : AbstractTimelineModel {
+  void fillTimeline();
+};
+void LinkPaginationTimelineModel::fillTimeline() {
+  [] {};
+  m_account.get([](AbstractAccount *) { static QRegularExpression re(""); },
+                [](AbstractAccount *) {});
+}
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C
index 291e451ca1a..a7cb6c5dece 100644
--- a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C
@@ -1,4 +1,5 @@
 // { dg-do run { target c++20 } }
+// { dg-additional-options "-flto" { target lto } } (PR107897)
 
 template<typename T>
 concept C1 = __is_same_as(T, int)
-- 
2.31.1


  reply	other threads:[~2023-03-08 16:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08  2:59 Jason Merrill
2023-03-08 15:53 ` Jan Hubicka
2023-03-08 16:15   ` Jason Merrill
2023-03-08 16:54     ` Jason Merrill [this message]
2023-03-14 15:16       ` Ping " Jason Merrill
2023-03-28 15:32         ` PING^2 " Jason Merrill
2023-03-29 22:33       ` Martin Jambor
2023-03-30 11:54       ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc6f7895-a860-d44b-e438-c8476c055998@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).