[WIP RFC] libstdc++: add module std

Jonathan Wakely jwakely@redhat.com
Fri Nov 15 17:08:04 GMT 2024


On 15/11/24 11:43 -0500, Jason Merrill wrote:
>On 11/15/24 10:21 AM, Jonathan Wakely wrote:
>>On Fri, 15 Nov 2024 at 15:20, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>
>>>On Fri, 15 Nov 2024 at 15:12, Jason Merrill <jason@redhat.com> wrote:
>>>>
>>>>On 11/15/24 9:20 AM, Jonathan Wakely wrote:
>>>>>On 15/11/24 08:53 -0500, Jason Merrill wrote:
>>>>>>On 11/15/24 6:04 AM, Jonathan Wakely wrote:
>>>>>>>On 14/11/24 23:09 -0500, Jason Merrill wrote:
>>>>
>>>>>>>>Since bits/stdc++.h also intends to include the whole standard
>>>>>>>>library, I
>>>>>>>>include it rather than duplicate it.  But stdc++.h comments out
>>>>>>>><execution>,
>>>>>>>>so I include it separately.  Alternatively, we could uncomment it in
>>>>>>>>stdc++.h.
>>>>>>>
>>>>>>>It's not included by default because it pulls in a dependency on
>>>>>>>libtbb.so even if you don't use the parallel algos:
>>>>>>>
>>>>>>>$ g++ -include algorithm -include execution -x c++ - <<< 'int main()
>>>>>>>{ }'
>>>>>>>/usr/bin/ld: /tmp/ccA76qrz.o: in function
>>>>>>>`tbb::detail::d1::execution_slot(tbb::detail::d1::execution_data
>>>>>>>const&)':
>>>>>>><stdin>:
>>>>>>>(.text._ZN3tbb6detail2d114execution_slotERKNS1_14execution_dataE[_ZN3tbb6detail2d114execution_slotERKNS1_14execution_dataE]+0x14): undefined reference to `tbb::detail::r1::execution_slot(tbb::detail::d1::execution_data const*)'
>>>>>>>/usr/bin/ld: /tmp/ccA76qrz.o: in function
>>>>>>>`tbb::detail::d1::current_thread_index()':
>>>>>>><stdin>:
>>>>>>>(.text._ZN3tbb6detail2d120current_thread_indexEv[_ZN3tbb6detail2d120current_thread_indexEv]+0xe): undefined reference to `tbb::detail::r1::execution_slot(tbb::detail::d1::execution_data const*)'
>>>>>>>collect2: error: ld returned 1 exit status
>>>>>>>
>>>>>>>The way we arranged the PSTL inclusion is that you only get a
>>>>>>>dependeny on TBB if you include a header containing a parallel algo
>>>>>>>(<algorithm>, <numeric>) *and* include <execution>. Since including
>>>>>>><execution> is formally required by the standard in order to pass one
>>>>>>>of std::execution::par, std::execution::seq etc. to a parallel algo,
>>>>>>>we switch on whether <execution> has been included or not to detect
>>>>>>>whether the user actually wants to use parallel algos.
>>>>>>>
>>>>>>>Is this not a problem for 'import std;'?
>>>>>>
>>>>>>Hmm, I haven't been seeing that in my testing, std.o only contains the
>>>>>>reference to ios_base_library_init.
>>>>>>
>>>>>>But then, I don't get that error with your testcase above, either.
>>>>>>With trunk, the compiler output for that only contains main for me.
>>>>>
>>>>>Then I assume you don't have tbb-devel installed. If the tbb headers
>>>>>aren't present, then <execution> doesn't include them.
>>>>>
>>>>>Could you do 'dnf install tbb-devel' and try again?
>>>>
>>>>Indeed, that's what the difference was.  With tbb-devel installed,
>>>>compiling std.cc fails with an error about TBB code exposing
>>>>task_ptr_or_nullptr in the anonymous namespace.
>>>>
>>>>tbb-devel also isn't installed on tor/torsion, and I don't seem to have
>>>>sudo on them anymore.
>>>>
>>>>>Maybe we should figure out how to fix it for #include <execution>
>>>>>anyway. When we eventually support senders/receivers in <execution>
>>>>>for C++26, users are going to want to include that for reasons other
>>>>>than using the parallel algos and their execution policies.
>>>>
>>>>Is there a way I can suppress pstl with a macro?  If not, I guess I'll
>>>>just leave <execution> out for now.
>>>
>>>Defining _GLIBCXX_USE_TBB_PAR_BACKEND to 0 will work.
>>
>>That only suppresses the TBB backend, so you can still use the
>>execution policies in <execution> and call parallel algos ... they
>>just don't run in parallel :-)
>>All the declarations required by the standard will be present.
>
>Hmm, I'm not sure whether that is preferable to leaving them out 
>entirely.

That would be possible, but I don't think we currently have any
mechanism to do that.

>But here's a v3 that does that, along with your other 
>suggestions:

Looks great. OK for trunk, if you think it's ready.




More information about the Libstdc++ mailing list