Hi gcc-team, a recent report of mine https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549 fixed my reduced example, but my unreduced test case is still failing. This is the second attempt at reducing my test case and this came out of it: ```c++ #include <utility> template <typename T, typename U> concept same_as = std::is_same_v<T, U>; template <typename T, typename U> concept convertible_to = std::is_convertible_v<T, U>; template <typename... component_types> struct alphabet_tuple_base { template <typename type> static constexpr bool is_component = (same_as<type, component_types> || ...); template <typename type> static constexpr bool is_indirect_component = !is_component<type> && (convertible_to<type, component_types> || ...); // commenting out constexpr works?! template <typename component_type> requires is_component<component_type> constexpr alphabet_tuple_base(component_type) {} template <typename indirect_component_type> requires is_indirect_component<indirect_component_type> alphabet_tuple_base(indirect_component_type); }; template <typename sequence_alphabet_t, typename structure_alphabet_t> struct structured_rna : alphabet_tuple_base<sequence_alphabet_t, structure_alphabet_t> { using base_type = alphabet_tuple_base<sequence_alphabet_t, structure_alphabet_t>; using base_type::base_type; }; struct dna4 {}; struct rna4 { rna4(dna4); }; struct wuss51 {}; // commenting out any of these works?! structured_rna<rna4, wuss51> t1{wuss51{}}; structured_rna<rna4, wuss51> t2{dna4{}}; structured_rna<rna4, wuss51> t3{wuss51{}}; ``` https://godbolt.org/z/WVvSxb Note that `is_component` and `is_indirect_component` are mutual exclusive, so there isn't any ambiguity even if they don't subsume each other. This worked in gcc-9 with `-fconcepts` and apparently in msvc and clang, too. ``` > g++-git -std=c++2a <source>:41:41: error: call of overloaded 'structured_rna(<brace-enclosed initializer list>)' is ambiguous 41 | structured_rna<rna4, wuss51> t3{wuss51{}}; // commenting out any of these works?! | ^ <source>:20:15: note: candidate: 'constexpr alphabet_tuple_base<component_types>::alphabet_tuple_base(component_type) [with component_type = wuss51; component_types = {rna4, wuss51}]' 20 | constexpr alphabet_tuple_base(component_type) {} // commenting out constexpr works?! | ^~~~~~~~~~~~~~~~~~~ <source>:30:20: note: inherited here 30 | using base_type::base_type; | ^~~~~~~~~ <source>:24:5: note: candidate: 'alphabet_tuple_base<component_types>::alphabet_tuple_base(indirect_component_type) [with indirect_component_type = indirect_component_type; component_types = {rna4, wuss51}]' 24 | alphabet_tuple_base(indirect_component_type); | ^~~~~~~~~~~~~~~~~~~ <source>:30:20: note: inherited here 30 | using base_type::base_type; | ^~~~~~~~~ <source>:28:8: note: candidate: 'constexpr structured_rna<rna4, wuss51>::structured_rna(const structured_rna<rna4, wuss51>&)' 28 | struct structured_rna : alphabet_tuple_base<sequence_alphabet_t, structure_alphabet_t> { | ^~~~~~~~~~~~~~ <source>:28:8: note: candidate: 'constexpr structured_rna<rna4, wuss51>::structured_rna(structured_rna<rna4, wuss51>&&)' Compiler returned: 1 ```
A slightly more reduced example: ```c++ #include <utility> template <typename component_types> struct alphabet_tuple_base { template <typename component_type> requires std::is_same_v<component_type, component_types> constexpr alphabet_tuple_base(component_type) {} // commenting out constexpr works?! template <typename indirect_component_type> requires (!std::is_same_v<indirect_component_type, component_types>) alphabet_tuple_base(indirect_component_type) {}; }; template <typename sequence_alphabet_t> struct structured_rna : alphabet_tuple_base<sequence_alphabet_t> { using base_type = alphabet_tuple_base<sequence_alphabet_t>; using base_type::base_type; }; struct dna4 {}; struct rna4 {}; structured_rna<rna4> t1{rna4{}}; // commenting out any of these works?! structured_rna<rna4> t2{dna4{}}; // commenting out any of these works?! structured_rna<rna4> t3{rna4{}}; // commenting out any of these works?! ``` https://godbolt.org/z/VACou9
After removal of any library dependencies: ```c++ template<class, class> inline constexpr bool is_same_v = false; template<class T> inline constexpr bool is_same_v<T, T> = true; template <typename component_types> struct alphabet_tuple_base { template <typename component_type> requires is_same_v<component_type, component_types> constexpr alphabet_tuple_base(component_type) {} // commenting out constexpr works?! template <typename indirect_component_type> requires (!is_same_v<indirect_component_type, component_types>) alphabet_tuple_base(indirect_component_type) {} }; template <typename sequence_alphabet_t> struct structured_rna : alphabet_tuple_base<sequence_alphabet_t> { using base_type = alphabet_tuple_base<sequence_alphabet_t>; using base_type::base_type; }; struct dna4 {}; struct rna4 {}; structured_rna<rna4> t1{rna4{}}; // commenting out any of these works?! structured_rna<rna4> t2{dna4{}}; // commenting out any of these works?! structured_rna<rna4> t3{rna4{}}; // commenting out any of these works?! int main() {} ```
Confirmed, thanks for the nice testcase. I think the problem lies with how we cache the constraints of an inherited constructor. I am testing the following: --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -2752,7 +2752,7 @@ satisfy_declaration_constraints (tree t, subst_info info) info.in_decl = t; if (info.quiet ()) - if (tree *result = hash_map_safe_get (decl_satisfied_cache, t)) + if (tree *result = hash_map_safe_get (decl_satisfied_cache, saved_t)) return *result; /* Get the normalized constraints. */ @@ -2787,7 +2787,7 @@ satisfy_declaration_constraints (tree t, subst_info info) } if (info.quiet ()) - hash_map_safe_put<hm_ggc> (decl_satisfied_cache, t, result); + hash_map_safe_put<hm_ggc> (decl_satisfied_cache, saved_t, result); return result; }
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:1d2290caad0dba52b285b47057b7c0e4e8d21feb commit r10-8025-g1d2290caad0dba52b285b47057b7c0e4e8d21feb Author: Patrick Palka <ppalka@redhat.com> Date: Tue Apr 28 21:45:59 2020 -0400 c++: Satisfaction caching of inherited ctor [PR94819] As observed in PR94719, an inherited constructor for an instantiation of a constructor template confusingly has as its DECL_INHERITED_CTOR the TEMPLATE_DECL of the constructor template rather than the particular instantiation of the template. This means two inherited constructors for two different instantiations of the same constructor template have the same DECL_INHERITED_CTOR. And since in satisfy_declaration_constraints our decl satisfaction cache is keyed off of the result of strip_inheriting_ctors, we may end up conflating the satisfaction values of the two inherited constructors' constraints. This patch fixes this issue by using the original tree, not the result of strip_inheriting_ctors, as the key to the decl satisfaction cache. gcc/cp/ChangeLog: PR c++/94819 * constraint.cc (satisfy_declaration_constraints): Use saved_t instead of t as the key to decl_satisfied_cache. gcc/testsuite/ChangeLog: PR c++/94819 * g++.dg/cpp2a/concepts-inherit-ctor10.C: New test. * g++.dg/cpp2a/concepts-inherit-ctor11.C: New test.
Fixed.