NVIDIA / stdexec

`std::execution`, the proposed C++ framework for asynchronous and parallel programming.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

subobject-linkage error with GCC

williamspatrick opened this issue · comments

This could very well be something wrong with my code. Using the latest stdexec, I'm started seeing this subobject-linkage warning in GCC. It isn't obvious which type is even being called out as a problem.

../include/sdbusplus/async/timer.hpp:109:5: error: ‘sdbusplus::async::timer_ns::sleep_sender::sleep_for(sdbusplus::async::context&, sdbusplus::event::event::time_resolution)::_ZN9sdbusplus5async8timer_ns12sleep_sender9sleep_forERNS0_7contextENSt6chrono8durationIlSt5ratioILl1ELl1000000EEEE.Frame’ has a field ‘stdexec::__as_awaitable::__sender_awaitable<stdexec::_Yp<exec::__task::basic_task<void, exec::__task::__default_task_context_impl<exec::__task::__scheduler_affinity::__sticky> >::__promise>, stdexec::__sexpr<stdexec::__detail::{anonymous}::<lambda(_Tag, _Captures&& ...)>::<lambda(_Cvref, _Fun&&)> > >::__t sdbusplus::async::timer_ns::sleep_sender::sleep_for(sdbusplus::async::context&, sdbusplus::event::event::time_resolution)::_ZN9sdbusplus5async8timer_ns12sleep_sender9sleep_forERNS0_7contextENSt6chrono8durationIlSt5ratioILl1ELl1000000EEEE.Frame::Aw1_2_4’ whose type has internal linkage [-Werror=subobject-linkage]

The affected code is a rather simple co-routine using the stdexec task.

    static task<> sleep_for(context& ctx, event_t::time_resolution time)
    {
        // Run the delay sender and then switch back to the worker thread.
        // The delay completion happens from the sd-event handler, which is
        // ran on the 'caller' thread.
        co_await sleep_sender(ctx, time);
        co_await execution::schedule(get_scheduler(ctx));
    }

Both co_awaits have this subobject-linkage problem, so even if I comment out the first one I still end up with it.

I think this is https://stackoverflow.com/questions/55881676/werror-subobject-linkage-for-lambda-as-a-template-parameter-in-header-what-i.

It's unclear to me if this is a gcc bug, or if I'm legitimately doing something wrong by using anonymous types / lambdas as template parameters. I don't think there is much I can do about it, though.

If I'm not mistaken, -Wsubobject-linkage is a warning. You're probably seeing it as an error because you are also specifying -Werror, is that right? If so, would you be willing to exclude this warning?

UPDATE: possibly relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111423

Thanks for investigating, @ericniebler

I managed to work around it by changing from co_awaits/tasks to senders here. So it isn't pressing right now.

    static auto sleep_for(context& ctx, event_t::time_resolution time)
    {
        // Run the delay sender and then switch back to the worker thread.
        // The delay completion happens from the sd-event handler, which is
        // ran on the 'caller' thread.
        return execution::transfer(sleep_sender(ctx, time), get_scheduler(ctx));
    }

I'm surprised I'm not currently seeing this in any other code using tasks though.

You're probably seeing it as an error because you are also specifying -Werror, is that right? If so, would you be willing to exclude this warning?

Correct. I'm writing a library though so I can't totally control what consumers end up compiling/linking with. Most of the projects in our organization use Meson's warning_level=3 which turns on quite a bit of warnings. In some cases I've pragma'd out some warnings from stdexec, but since this ends up being a linker warning I'm not sure that helps in this case.

Let me add some info here since this is one of the first relevant links while searching for this bug.

code like template<typename T = decltype([] {})> is legitimate and part of C++20 standard see cppreference and paper

This is a gcc bug and has been fixed in gcc 14 bugzilla. While this is indeed generates a warning, compilers produce the wrong linkage type for these types and thus failing during linkage, while clang works correctly and gcc will be released at some point, this bug appears to be present in msvc.

P.S. @ericniebler you have extra / in the bugzilla link