gcc 12 OK, not gcc 13

[prlw1]

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.

[bustercopley]

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() 0

[bustercopley]

make test gives about 300KB of diagnostics

By "make test", I mean cmake --build build --verbose, with -fconcepts-diagnostics-depth=999.

[bustercopley]

I can confirm this helps with @prlw1's original issue on Compiler Explorer: https://godbolt.org/z/MGx4d3sWM

[prlw1]

Thanks - with your patch even my old code compiles once again with g++ (GCC) 14.0.0 20230610 (experimental).

[ericniebler]

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

EDIT 2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111018