https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407
Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.j.odwyer at gmail dot com --- Comment #1 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- According to Richard's comment on https://bugs.llvm.org/show_bug.cgi?id=46036 , http://cwg-issue-browser.herokuapp.com/cwg1873 indicates that Clang may be correct according to the Standard as written. HOWEVER... The "misbehavior" here isn't really about `friend`; it's about the interaction between `static` and `protected`. If you change your test case to make `value` non-static, then all vendors agree that the non-static `value` is inaccessible. With a static protected member (Clang rejects, GCC and MSVC accept): https://godbolt.org/z/essofs With a non-static protected member (all three correctly reject): https://godbolt.org/z/T1GWTP And here's a test case that doesn't use `friend` at all, but rather uses a private inheritance path, so that `C` is derived from `A`, but `C` itself is not aware of the fact. This case came up on Slack on 2020-08-14: https://cpplang.slack.com/archives/C5GN4SP41/p1597391677014800 With a static protected member (GCC and Clang accept, MSVC rejects): https://godbolt.org/z/6d786M With a non-static protected member (all three correctly reject): https://godbolt.org/z/MeTxeW // https://godbolt.org/z/6d786M struct A { protected: static int sf(); }; struct B : private A {}; struct C : public B { static void test(); }; void C::test() { &::A::sf; }