https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117993
--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:57904dc27d5b27226912838cdd6b5272cec4d050 commit r15-6737-g57904dc27d5b27226912838cdd6b5272cec4d050 Author: Patrick Palka <ppa...@redhat.com> Date: Thu Jan 9 10:50:06 2025 -0500 c++: current inst w/ indirect dependent bases [PR117993] In the first testcase we're overeagerly diagnosing qualified name lookup failure for f from the current instantiation B<T>::C ahead of time because we (correctly) deem C to not have any direct dependent bases: its direct base B<T> is part of the current instantiation and therefore not a dependent base, and we decide it's safe to diagnose name lookup failure ahead of time. But this testcase demonstrates it's not enough to consider only direct dependent bases: f is defined in A<T> which is a dependent base of B<T>, so qualified name lookup from C won't search it ahead of time and in turn won't be exhaustive, and so it's wrong to diagnose lookup failure ahead of time. This ultimately suggests that any_dependent_bases_p needs to consider indirect bases as well. To that end it seems sufficient to make the predicate recurse into any !BINFO_DEPENDENT_BASE_P base since the recursive call will exit early for non-dependent types. So effectively we'll only recurse into bases belonging to the current instantiation. I considered more narrowly making only dependentish_scope_p consider indirect dependent bases, but it seems other any_dependent_bases_p callers also want this behavior, e.g. build_new_method_call for benefit of the second testcase (which is an even older regression since GCC 7). PR c++/117993 gcc/cp/ChangeLog: * search.cc (any_dependent_bases_p): Recurse into bases (of dependent type) that are not BINFO_DEPENDENT_BASE_P. Document default argument. gcc/testsuite/ChangeLog: * g++.dg/template/dependent-base4.C: New test. * g++.dg/template/dependent-base5.C: New test. Reviewed-by: Jason Merrill <ja...@redhat.com>