https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #18 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Alexander Monakov from comment #17) > The bug is tagged 'rejects-valid', I think there's consensus the testcases > represent valid code, and GCC should not produce an error. Yes. The problem is that the G++ implementation of this pattern still carries the legacy of the pre-C++98 access declaration, which would change the access to the inherited member--so it doesn't matter (and we don't track) which declaration was found by name lookup. See alter_access in class.cc. I think we need to drop alter_access entirely and instead keep the USING_DECL around longer; here it doesn't matter whether you wrote A::i, B::i, or just i; either way we end up checking the (adjusted) access for A::i, and we should instead check the access to the using-declaration if that's what was found by name lookup. Alternatively, we could keep track of the nested-name-specifier further and use it in resolving access; currently check_accessibility_of_qualified_id overwrites it with the currently open derived class. But this seems like a workaround that probably isn't actually any less work than properly modelling the standard semantics.
