public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error
@ 2022-04-11 16:10 mpolacek at gcc dot gnu.org
2022-04-11 16:10 ` [Bug c++/105223] " mpolacek at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2022-04-11 16:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
Bug ID: 105223
Summary: [12 Regression] filter_memfn_lookup internal compiler
error
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Started with r12-7714-g47da5198766256:
commit 47da5198766256be658b4c321cecfd6039b0b91b
Author: Jason Merrill <jason@redhat.com>
Date: Fri Feb 25 15:07:15 2022 -0400
c++: using lookup within class defn [PR104476]
$ ./cc1plus -quiet ice.C
ice.C: In instantiation of ‘ServiceReference< <template-parameter-1-1>
>::ServiceReference(ServiceReferenceBase) [with <template-parameter-1-1> = int;
ServiceReferenceBase = ServiceReferenceBase]’:
ice.C:75:54: required from here
ice.C:50:53: internal compiler error: Segmentation fault
50 | ServiceReference(ServiceReferenceBase) { operator=(0); }
| ~~~~~~~~~^~~
0x1773b61 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:322
0xae557e tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3456
0xe17756 operator()
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16411
0xe1799d filter_memfn_lookup
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16417
0xe180ce tsubst_baselink
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16506
0xe32588 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21028
0xe30427 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20658
0xe2ae60 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19473
0xe22d0e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18486
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe22a79 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18458
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe49a1f instantiate_body
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26393
0xe4b3eb instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26685
0xe4b787 instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26764
0xc4a2b6 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.cc:5113
0xf9f06d c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.cc:1262
$ cat ice.C
namespace std {
template <typename _Iterator> class reverse_iterator {
public:
typename _Iterator::pointer operator->();
};
template <typename _Iterator>
bool operator!=(reverse_iterator<_Iterator>, reverse_iterator<_Iterator>);
} // namespace std
template <typename _Iterator> class __normal_iterator {
public:
typedef _Iterator pointer;
};
namespace std {
template <typename> class allocator;
template <typename> struct allocator_traits;
template <typename _Tp> struct allocator_traits<allocator<_Tp>> {
using pointer = _Tp *;
};
} // namespace std
class ServiceRegistrationBase;
struct __alloc_traits
: std::allocator_traits<std::allocator<ServiceRegistrationBase>> {};
namespace std {
class __shared_ptr {
public:
using element_type = int;
element_type *get();
};
struct _Vector_base {
typedef __alloc_traits::pointer pointer;
};
class vector {
public:
typedef std::reverse_iterator<__normal_iterator<_Vector_base::pointer>>
reverse_iterator;
reverse_iterator rbegin();
reverse_iterator rend();
};
template <typename> struct atomic;
template <typename _Tp> struct atomic<_Tp *> { _Tp *load(); };
} // namespace std
class ServiceReferenceBasePrivate;
class ServiceReferenceBase {
public:
void operator=(decltype(nullptr));
std::atomic<ServiceReferenceBasePrivate *> d;
};
template <class> class ServiceReference : public ServiceReferenceBase {
public:
ServiceReference(ServiceReferenceBase) { operator=(0); }
using ServiceReferenceBase::operator=;
};
class Bundle {
friend std::__shared_ptr GetPrivate(Bundle);
};
class ServiceRegistrationBase {
public:
ServiceReferenceBase GetReference();
};
class BundleContext {
public:
Bundle GetBundle();
};
class ServiceReferenceBasePrivate {
public:
std::__shared_ptr GetService(int *);
};
void ServiceHooksFilterServiceEventReceivers() {
BundleContext __trans_tmp_3;
std::vector eventListenerHooks;
auto selfBundle = __trans_tmp_3.GetBundle();
for (auto sriIter = eventListenerHooks.rbegin(),
sriEnd = eventListenerHooks.rend();
sriIter != sriEnd;) {
ServiceReference<int> sr = sriIter->GetReference();
int __trans_tmp_2 = *GetPrivate(selfBundle).get();
std::__shared_ptr __trans_tmp_1 = sr.d.load()->GetService(&__trans_tmp_2),
elh(__trans_tmp_1);
}
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
@ 2022-04-11 16:10 ` mpolacek at gcc dot gnu.org
2022-04-11 16:40 ` ppalka at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2022-04-11 16:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Target Milestone|--- |12.0
CC| |jason at gcc dot gnu.org
Keywords| |ice-on-valid-code
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
2022-04-11 16:10 ` [Bug c++/105223] " mpolacek at gcc dot gnu.org
@ 2022-04-11 16:40 ` ppalka at gcc dot gnu.org
2022-04-11 17:22 ` ppalka at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-04-11 16:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
struct ServiceReferenceBase {
void operator=(int);
};
template<class>
struct ServiceReference : ServiceReferenceBase {
void foo() { operator=(0); }
using ServiceReferenceBase::operator=;
};
int main() {
ServiceReference<int> sr;
sr.foo();
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
2022-04-11 16:10 ` [Bug c++/105223] " mpolacek at gcc dot gnu.org
2022-04-11 16:40 ` ppalka at gcc dot gnu.org
@ 2022-04-11 17:22 ` ppalka at gcc dot gnu.org
2022-04-11 17:36 ` ppalka at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-04-11 17:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The implicitly declared ServiceReference<int>::operator= members lack a
TEMPLATE_INFO, but filter_memfn_lookup expects it (along with all other
non-template member functions from the instantiated class) to have one.
Not sure what the best solution here is, but we can at least work around this
by making filter_memfn_lookup tolerate missing TEMPLATE_INFO in this case:
gcc/cp/pt.cc | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 78519562953..f359e596846 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -16404,6 +16404,13 @@ filter_memfn_lookup (tree oldfns, tree newfns, tree
newtype)
look in the old lookup set for the TEMPLATE_DECL from which
it was specialized. */
return visible_set.contains (DECL_TI_TEMPLATE (fn));
+ else if (!DECL_TEMPLATE_INFO (fn))
+ {
+ /* FN is an implicitly declared special member function and thus
+ could not have been in the old lookup set. */
+ gcc_checking_assert (DECL_ARTIFICIAL (fn) && DECL_DEFAULTED_FN (fn));
+ return false;
+ }
else
/* FN is a non-template member function from the current class;
look in the old lookup set for the FUNCTION_DECL from which
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
` (2 preceding siblings ...)
2022-04-11 17:22 ` ppalka at gcc dot gnu.org
@ 2022-04-11 17:36 ` ppalka at gcc dot gnu.org
2022-04-11 21:46 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-04-11 17:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW, the problematic hunk from r12-7714 appears to be:
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
...
@@ -7700,14 +7723,17 @@ finish_struct (tree t, tree attributes)
lookup not to fail or recurse into bases. This isn't added
to the template decl list so we drop this at instantiation
time. */
- tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
- NULL_TREE);
- DECL_CONTEXT (ass_op) = t;
- USING_DECL_SCOPE (ass_op) = t;
- DECL_DEPENDENT_P (ass_op) = true;
- DECL_ARTIFICIAL (ass_op) = true;
- DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
- TYPE_FIELDS (t) = ass_op;
+ if (!get_class_binding_direct (t, assign_op_identifier, false))
+ {
+ tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
+ NULL_TREE);
+ DECL_CONTEXT (ass_op) = t;
+ USING_DECL_SCOPE (ass_op) = t;
+ DECL_DEPENDENT_P (ass_op) = true;
+ DECL_ARTIFICIAL (ass_op) = true;
+ DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
+ TYPE_FIELDS (t) = ass_op;
+ }
TYPE_SIZE (t) = bitsize_zero_node;
TYPE_SIZE_UNIT (t) = size_zero_node;
This hunk causes us to no longer create a dependent USING_DECL representing the
implicitly declared operator= for ServiceReference<T>, which means name lookup
for operator= at parse time yields only the ServiceReferenceBase::operator=
members. This allows us to prune the overload set for the call 'operator=(0)'
ahead of time and hence we end up calling filter_memfn_lookup later at
instantiation time where we crash due comment #2.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
` (3 preceding siblings ...)
2022-04-11 17:36 ` ppalka at gcc dot gnu.org
@ 2022-04-11 21:46 ` jason at gcc dot gnu.org
2022-04-12 3:57 ` cvs-commit at gcc dot gnu.org
2022-04-12 3:59 ` jason at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2022-04-11 21:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2022-04-11
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
` (4 preceding siblings ...)
2022-04-11 21:46 ` jason at gcc dot gnu.org
@ 2022-04-12 3:57 ` cvs-commit at gcc dot gnu.org
2022-04-12 3:59 ` jason at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-12 3:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:
https://gcc.gnu.org/g:4195fced8a13422db94e179404588d9d887a036a
commit r12-8098-g4195fced8a13422db94e179404588d9d887a036a
Author: Jason Merrill <jason@redhat.com>
Date: Mon Apr 11 17:51:43 2022 -0400
c++: using operator= [PR105223]
In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet. In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
type doesn't prevent the implicit declaration.
When I was working on that patch, the change was necessary to avoid another
regression, but apparently it is no longer needed.
PR c++/105223
PR c++/92918
gcc/cp/ChangeLog:
* class.cc (finish_struct): Always using op=.
gcc/testsuite/ChangeLog:
* g++.dg/template/using31.C: New test.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
` (5 preceding siblings ...)
2022-04-12 3:57 ` cvs-commit at gcc dot gnu.org
@ 2022-04-12 3:59 ` jason at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2022-04-12 3:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105223
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-04-12 3:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-11 16:10 [Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error mpolacek at gcc dot gnu.org
2022-04-11 16:10 ` [Bug c++/105223] " mpolacek at gcc dot gnu.org
2022-04-11 16:40 ` ppalka at gcc dot gnu.org
2022-04-11 17:22 ` ppalka at gcc dot gnu.org
2022-04-11 17:36 ` ppalka at gcc dot gnu.org
2022-04-11 21:46 ` jason at gcc dot gnu.org
2022-04-12 3:57 ` cvs-commit at gcc dot gnu.org
2022-04-12 3:59 ` jason at gcc dot gnu.org
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).