https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80962
Bug ID: 80962 Summary: No more access violation control after certain declarations using concepts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: okannen at gmail dot com Target Milestone: --- Created attachment 41462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41462&action=edit The buggy code as described in the comment. GCC VERSION: (gcc -v) Utilisation des specs internes. COLLECT_GCC=3Dgcc COLLECT_LTO_WRAPPER=3D/usr/local/gcc7/libexec/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper Cible : x86_64-pc-linux-gnu Configur=C3=A9 avec: ../configure --prefix=3D/usr/local/gcc7 --disable-=multilib Mod=C3=A8le de thread: posix gcc version 7.1.1 20170503 (GCC) BUG DESCRIPTION: gcc stops to perform member access violation rule checking: If in a compound requirement using a partialy specialized concept as placeholder, then gcc stop any access schecking test (one can have access to private member of classes). COMMAND LINE: c++ -fconcepts file.cpp BUGGY CODE: This code should not compile, but it does (no access violation performed). class a_class { int f(int){return 33;} //private member }; template<class T,class Y> concept bool AnyConcept =true; template<class T> concept bool OtherConcept = requires(const T& a) { //Gcc do not bug without the the following line. //{a && a} -> AnyConcept<bool>; {a && a} -> bool; }; int main() { a_class obj; obj.f(10); //Error not reported by gcc. } BUGGY CODE: This code shows normal gcc behavior, an error is reported: "int a_class::f(int) is private in this context" class a_class { int f(int){return 33;} //private member }; template<class T,class Y> concept bool AnyConcept =true; template<class T> concept bool OtherConcept = requires(const T& a) { //Gcc do not bug without the the following line. //{a && a} -> AnyConcept<bool>; {a && a} -> bool; }; int main() { a_class obj; obj.f(10); //Error not reported by gcc. } OTHER PROBABLY RELATED ISSUES: with larger code I have observed that the same issue could happen if any of the following code line occurs: 1. partialy specialized concept used as placeholder inside function argument list template<class T,class U> concept bool Same = std::is_same<T,U>::value; int afunc(Same<int>&& x); 2. partialy specialized concept used as placeholder inside template argument list template<Same<int> T> void afunc(T&&); 3. concept inside if constexpr (not sure it is inside the concept TS, but it causes the exact same trouble, + command line option -std=c++17) template<class...Args> concept bool Constructible = std::is_constructible<Args...>::value; ... if constexpr(Constructible<int,int>)