This compiles fine in 11.3 but selects the non-const `BaseClass` overload in 12.1: ``` struct BaseClass { // Commenting out this non-const function out will fix the compilation: int baseDevice() { return 1; } int baseDevice() const { return 2; } }; template <class ObjectClass> struct DerivedClass : BaseClass {}; template <class ObjectClass> struct TopClass : DerivedClass<ObjectClass> { public: virtual int failsToCompile() const { // This should choose to call the const function, but it tries to call // the non-const version. return BaseClass::baseDevice(); // error! //return this->baseDevice(); // works //return DerivedClass<ObjectClass>::baseDevice(); // works } }; int main() { TopClass<int> x; } ```
Started with r12-6075-g2decd2cabe5a4f.
This came from my project via a stack overflow post. Thanks to Ted for submitting it. FYI, this is from an older version of the Teigha DXF libraries, now called Drawings I think, https://www.opendesign.com/products/drawings.
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:44a5bd6d933d86ed988fc4695aa00f122cf83eb4 commit r13-984-g44a5bd6d933d86ed988fc4695aa00f122cf83eb4 Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jun 3 12:06:59 2022 -0400 c++: cv-quals of dummy obj for non-dep memfn call [PR105637] In non-dependent23.C below we expect the Base::foo calls to resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens because the calls to Base::foo are all deemed non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this' dependence when considering the dependence of a non-static memfn call), hence we end up checking the call ahead of time, using as the object argument a dummy object of type Base. Since this object argument is cv-unqualified, the calls in turn resolve to the unqualified overload of baseDevice. Before r12-6075 this incorrect result would just get silently discarded and we'd end up redoing OR at instantiation time using 'this' as the object argument. But after r12-6075 we now reuse this incorrect result at instantiation time. This patch fixes this by making maybe_dummy_object respect the cv-quals of (the non-lambda) 'this' when returning a dummy object. Thus, ahead of time OR using a dummy object will give us the right answer that's consistent with the instantiation time answer. An earlier version of this patch didn't handle 'this'-capturing lambdas correctly, which broke lambda-this22.C below. PR c++/105637 gcc/cp/ChangeLog: * tree.cc (maybe_dummy_object): When returning a dummy object, respect the cv-quals of 'this' if available. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-this22.C: New test. * g++.dg/template/non-dependent23.C: New test.
Fixed on trunk so far.
Excellent and thanks!
Thank you!
The releases/gcc-12 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:41487bff13fa98607ab5548bc1a0dca71147a5ac commit r12-8603-g41487bff13fa98607ab5548bc1a0dca71147a5ac Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jun 3 12:06:59 2022 -0400 c++: cv-quals of dummy obj for non-dep memfn call [PR105637] In non-dependent23.C below we expect the Base::foo calls to resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens because the calls to Base::foo are all deemed non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this' dependence when considering the dependence of a non-static memfn call), hence we end up checking the call ahead of time, using as the object argument a dummy object of type Base. Since this object argument is cv-unqualified, the calls in turn resolve to the unqualified overload of baseDevice. Before r12-6075 this incorrect result would just get silently discarded and we'd end up redoing OR at instantiation time using 'this' as the object argument. But after r12-6075 we now reuse this incorrect result at instantiation time. This patch fixes this by making maybe_dummy_object respect the cv-quals of (the non-lambda) 'this' when returning a dummy object. Thus, ahead of time OR using a dummy object will give us the right answer that's consistent with the instantiation time answer. An earlier version of this patch didn't handle 'this'-capturing lambdas correctly, which broke lambda-this22.C below. PR c++/105637 gcc/cp/ChangeLog: * tree.cc (maybe_dummy_object): When returning a dummy object, respect the cv-quals of 'this' if available. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-this22.C: New test. * g++.dg/template/non-dependent23.C: New test. (cherry picked from commit 44a5bd6d933d86ed988fc4695aa00f122cf83eb4)
Fixed for GCC 12.2/13