This code fails to compile with the current gcc (commit d9be9f34fbb018c448dc5a02aaa95d6a6932135c) class Base { protected: Base(); }; class Derived : public Base { public: using Base::Base; }; Derived d; test.ii:11:9: error: ‘Base::Base()’ is protected within this context 11 | Derived d; | ^ test.ii:3:5: note: declared protected here 3 | Base(); | ^~~~ The error is emitted for any standard from c++11 to c++2a. No optimization or other flags are needed. The same code is compiled without any errors by gcc 9.2.1. Testing on godbolt.org shows that all other compilers accept it - all recent versions of clang, msvc, icc. I don't see any relevant changes mentioned in the GCC 10 release notes https://gcc.gnu.org/gcc-10/changes.html An inline implementation of the protected constructor fails too: class Base { protected: Base() {} }; class Derived : public Base { public: using Base::Base; }; Derived d; However, the code compiles with the default constructor: class Base { protected: Base() = default; }; class Derived : public Base { public: using Base::Base; }; Derived d;
Regressed with r276968: PR c++/91930 - ICE with constrained inherited default ctor. The testcase was crashing because lazily_declare_fn was failing to add a defaulted constructor, because the implicit declaration was less constrained than the inherited default constructor. But when we have an inherited constructor, we shouldn't be trying to declare a default constructor in the first place, because it counts as "a user-declared constructor". With that fixed I needed to adjust a couple of inherited constructor testcases that previously had been diagnosing the default constructor as deleted rather than not declared. * name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR for inherited constructor.
This is a consequence of the change Jonathan cites, to treat the inherited constructor as a user-declared constructor that prevents the implicit declaration of a default constructor in Derived. The difference in access behavior follows from this; the standard says, "A synonym created by a using-declaration has the usual accessibility for a member-declaration. A using-declarator that names a constructor does not create a synonym; instead, the additional constructors are accessible if they would be accessible when used to construct an object of the corresponding base class, and the accessibility of the using-declaration is ignored." So if constructing 'd' calls the inherited constructor, it's ill-formed; if it calls the implicitly-declared default constructor, it's well-formed. I thought my change was an obvious bug fix, but it seems that other compilers have the old semantics, so I should probably undo it.
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:08c8c973c082457a7d6192673e87475f1fdfdbef commit r10-5949-g08c8c973c082457a7d6192673e87475f1fdfdbef Author: Jason Merrill <jason@redhat.com> Date: Tue Jan 14 13:59:54 2020 -0500 PR c++/92590 - wrong handling of inherited default ctor. I thought my earlier fix for 91930 was an obvious bug fix, but apparently an inherited constructor does not count as user-declared. So this patch reverts that change and the other follow-on patches, and fixes 91930 differently, by not letting the inherited default constructor hide the implicitly-declared default constructor. * class.c (add_method): A constrained inherited ctor doesn't hide an implicit derived ctor. Revert: PR c++/91930 - ICE with constrained inherited default ctor. * name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR for inherited constructor. PR c++/92552 - ICE with inherited constrained default ctor. * pt.c (instantiate_class_template_1): Copy TYPE_HAS_USER_CONSTRUCTOR. PR c++/92594 - ICE with inherited trivial default ctor. * method.c (trivial_fn_p): Treat an inherited default constructor like a normal default constructor.
Fixed.
Confirming fix on the original code. Thank you!