Skip to content
Snippets Groups Projects
  1. Mar 05, 2025
    • yxj-github-437's avatar
      libstdc++: fix possible undefined std::timespec in module std · a08a5bc4
      yxj-github-437 authored
      I notice std::timespec and std::timespec_get are used in preprocessor
      condition _GLIBCXX_HAVE_TIMESPEC_GET. So in module std, it should be
      the same.
      
      libstdc++-v3:
      
      	* src/c++23/std-clib.cc.in (timespec): Move within preprocessor
      	group guarded by _GLIBCXX_HAVE_TIMESPEC_GET.
      a08a5bc4
  2. Jan 08, 2025
    • Jonathan Wakely's avatar
      libstdc++: Use preprocessor conditions in std module [PR118177] · a37cd4f9
      Jonathan Wakely authored
      The std-clib.cc module definition file assumes that all names are
      available unconditionally, but that's not true for all targets. Use the
      same preprocessor conditions as are present in the <cxxx> headers.
      
      A similar change is needed in std.cc.in for the <chrono> features that
      depend on the SSO std::string, guarded with a __cpp_lib_chrono value
      indicating full C++20 support.
      
      The conditions for <cmath> are omitted from this change, as there are a
      large number of them. That probably needs to be fixed.
      
      libstdc++-v3/ChangeLog:
      
      	PR libstdc++/118177
      	* src/c++23/std-clib.cc.in: Use preprocessor conditions for
      	names which are not always defined.
      	* src/c++23/std.cc.in: Likewise.
      a37cd4f9
  3. Nov 17, 2024
    • Jason Merrill's avatar
      libstdc++: add module std [PR106852] · 7db55c0b
      Jason Merrill authored
      This patch introduces an installed source form of module std and std.compat.
      To help a build system find them, we install a libstdc++.modules.json file
      alongside libstdc++.so, which tells the build system where the files are and
      any special flags it should use when compiling them (none, in this case).
      The format is from a proposal in SG15.  The build system can find this file
      with 'gcc -print-file-name=libstdc++.modules.json'.
      
      It seems preferable to use a relative path from this file to the sources so
      that moving the installation doesn't break the reference, but I didn't see
      any obvious way to compute that without relying on coreutils, perl, or
      python, so I wrote a POSIX shell script for it.  The .. canonicalization
      bits aren't necessary since I discovered $(abspath), but I guess I might as
      well leave them in.
      
      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.  Note
      that if someone actually tries to #include <bits/std.cc> it will fail with
      "error: module control-line cannot be in included file".
      
      Any ideas about a more user-friendly way to express "compile module std" are
      welcome.
      
      The sources currently have the extension .cc, like other source files.
      
      std.cc started with m.cencora's implementation in PR114600.  I've made some
      adjustments, but more is probably desirable, e.g. of the <algorithm>
      handling of namespace ranges, and to remove exports of templates that are
      only specialized in a particular header.  I've filled in a bunch of missing
      exports, and added some FIXMEs where I noticed bits that are not implemented
      yet.
      
      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>,
      due to TBB issues; I include it separately and suppress TBB usage, so module
      std won't currently provide parallel execution.
      
      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 :: are a block of code that is
      appended to both files, adjusted based on whether the macro STD_COMPAT is
      defined before the block.
      
      In this implementation std.compat imports std; it would also be valid for it
      to duplicate everything in std.  I see the libc++ std.compat also imports
      std.
      
      As discussed in the PR, module std is supported in C++20 mode even though it
      was added in C++23.
      
      Changes to test module std will follow in a separate patch.  In my testing
      I've noticed a few compiler bugs that break various testcases, so I don't
      expect to enable module std testing by default at first.
      
      	PR libstdc++/106852
      
      libstdc++-v3/ChangeLog:
      
      	* include/bits/version.def: Add __cpp_lib_modules.
      	* include/bits/version.h: Regenerate.
      	* src/c++23/Makefile.am: Add modules std and std.compat.
      	* src/c++23/Makefile.in: Regenerate.
      	* src/c++23/std-clib.cc.in: New file.
      	* src/c++23/std.cc.in: New file.
      	* src/c++23/std.compat.cc.in: New file.
      	* src/c++23/libstdc++.modules.json.in: New file.
      
      contrib/ChangeLog:
      
      	* relpath.sh: New file.
      7db55c0b
Loading