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:
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?
Ah yes, that seems fine.
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?
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.
Ah, yes, the pragma won't undef and re-define a macro, so only the
presence or absence of -Wdeprecated on the command line affects it.
The #undef seems fine then.
+if [ -f "$1" ]; then
Why not [ ! -d "$1" ] ?
To allow arguments that don't exist because we haven't done make
install yet.
Ah yes.
