gcc 12 OK, not gcc 13
prlw1 opened this issue · 5 comments
Wondering why I could no longer compile examples/hello_world.cpp, I just tried visiting the godbolt page of your example https://godbolt.org/z/3cseorf7M which works fine with gcc 12, but fails to compile with gcc 13.
The first failing commit is
2fc4f7b4be1f3704cdaaf34421d4e06d00dcd34d
Author: Eric Niebler <eniebler@nvidia.com>
AuthorDate: Mon Jun 19 12:48:55 2023 -0700
Commit: Eric Niebler <eniebler@nvidia.com>
CommitDate: Wed Jul 26 12:31:39 2023 -0700
implement a generic sender type for use with the default sender
algorithm implementations
make test gives about 300KB of diagnostics, one of which is
S:/projects/stdexec/test/stdexec/algos/adaptors/test_on.cpp:74:24: required from here
S:/projects/stdexec/include/stdexec/__detail/__sender_utils.hpp:84:58: error: 'static auto stdexec::__then::then_t::get_completion_signatures(_Sender&&, _Env&&) [with _Sender = stdexec::__basic_sender<stdexec::__make_basic_sender<__then::then_t, ____C_A_T_C_H____T_E_S_T____0()::<lambda()>, __basic_sender<__make_basic_sender<__just::__just_t, std::tuple<> >(std::tuple<>)::<lambda(_Cvref, _Fun&&)> > >(____C_A_T_C_H____T_E_S_T____0()::<lambda()>, __basic_sender<__make_basic_sender<__just::__just_t, std::tuple<> >(std::tuple<>)::<lambda(_Cvref, _Fun&&)> >)::<lambda(_Cvref, _Fun&&)> >; _Env = stdexec::__env::__env_fn<stdexec::__env::__with_<stdexec::__queries::get_scheduler_t, impulse_scheduler>(stdexec::__queries::get_scheduler_t, impulse_scheduler)::<lambda(stdexec::__queries::get_scheduler_t)> >]' is private within this context
84 | decltype(__self.__tag().get_completion_signatures((_Self&&) __self, (_Env&&) __env))>;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
S:/projects/stdexec/include/stdexec/execution.hpp:3108:19: note: declared private here
3108 | static auto get_completion_signatures(_Sender&& __sndr, _Env&&) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
It seems like GCC 13's idea of friendship still doesn't quite meet expectations. With the change below (based on current main), building and testing succeeds.
diff --git a/include/stdexec/__detail/__config.hpp b/include/stdexec/__detail/__config.hpp
index ded55ed5..04b1a499 100644
--- a/include/stdexec/__detail/__config.hpp
+++ b/include/stdexec/__detail/__config.hpp
@@ -193,7 +193,7 @@
return __VA_ARGS__; \
}
-#if STDEXEC_CLANG() || (STDEXEC_GCC() && __GNUC__ >= 13)
+#if STDEXEC_CLANG()
#define STDEXEC_FRIENDSHIP_IS_LEXICAL() 1
#else
#define STDEXEC_FRIENDSHIP_IS_LEXICAL() 0make test gives about 300KB of diagnostics
By "make test", I mean cmake --build build --verbose, with -fconcepts-diagnostics-depth=999.
I can confirm this helps with @prlw1's original issue on Compiler Explorer: https://godbolt.org/z/MGx4d3sWM
Thanks - with your patch even my old code compiles once again with g++ (GCC) 14.0.0 20230610 (experimental).
Interesting! I know something changed with regards to how gcc-13 implements friendship (see e.g. https://godbolt.org/z/948x7vjT5), but it clearly doesn't go far enough for stdexec. I need to investigate.
EDIT: It looks like it's a gcc bug that depends on whether the friend function in question has a definition or not. https://godbolt.org/z/WT9P37Wba