On 11/15/24 6:04 AM, Jonathan Wakely wrote:
On 14/11/24 23:09 -0500, Jason Merrill wrote:
On 10/18/24 9:38 AM, Jason Merrill wrote:
Currently this installs the sources under $(gxx_include_dir)/bits/,
i.e. /usr/include/c++/15/bits. So with my -fsearch-include-path change,
std.cc can be compiled with g++ -fsearch-include-path bits/std.cc.
Would there be a way to give a diagnostic if a translation unit does
#include <bits/std.cc> ?
We get "error: module control-line cannot be in included file" if
someone tries that, is that enough?
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.
It seemed most convenient for the two files to be monolithic so we don't
need to worry about include paths. So the C library names that module
std.compat exports in both namespace std and :: in module are a block of
code that is identical in both files, adjusted based on whether the macro
STD_COMPAT is defined before the block.
We could split std.cc and std.compat.cc into several *.in files and
build them on the fly during installation, so that the verbatim part
is not duplicated. Something like:
cat std.head.in std.clib.in std.tail.in > std.cc
cat std.compat.head.in std.clib.in > std.compat.cc
Sure.
+#undef __DEPRECATED
Could this be done with:
#pragma GCC diagnostic ignored "-Wdeprecated"
instead?
+#include <strstream>
That doesn't work; suppressing the warning doesn't affect __DEPRECATED,
and backward_warning.h uses #warning if that macro is defined.
+if [ -f "$1" ]; then
Why not [ ! -d "$1" ] ?
To allow arguments that don't exist because we haven't done make install
yet.
Jason
