The 'execution' header is defined in C++17: https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag The clang status page doesn't mention it: https://clang.llvm.org/cxx_status.html Does this mean that is should be supported?
First a direct answer . . . https://en.cppreference.com/w/cpp/compiler_support/17 reports: Parallel algorithms and execution policies (P0024R2) for: Clang libc++ as being based on LLVM version: 17 (partial)* https://libcxx.llvm.org/Status/Cxx17.html still reports: P0024R2 LWG The Parallelism TS Should be Standardized Jacksonville Partial I doubt that 13.2 STABLE is based on LLVM17+ materials at this point.
(In reply to Mark Millard from comment #1) FYI: the other part after the "direct answer" was done outside bugzilla (also: off list). I forgot to remove that 1st line.
More from the stndard places for libc++ status information, in this case: https://libcxx.llvm.org/UsingLibcxx.html reports (probably for llvm17 or so at this point): QUOTE . . . Those are disabled by default because they are neither API nor ABI stable. However, the -fexperimental-library compiler flag can be defined to turn those features on. The following features are currently considered experimental and are only provided when -fexperimental-library is passed: The parallel algorithms library (<execution> and the associated algorithms) std::stop_token, std::stop_source and std::stop_callback std::jthread std::chrono::tzdb and related time zone functionality std::ranges::join_view END QUOTE This need to use -fexperimental-library to enable features has been mentioned in various prior submittals of supposedly missing features in FreeBSD's LLVM (but are really things that still have an API or ABI that is not yet known stable in libc++: not yet known to be well implemented). At this point I do not know if FreeBSD has -fexperimental-library working for use of <execution> or not for stable/13 . I may see about setting up an experiment based on a snapshot image at some point. I'm also not sure of the LLVM 16 status vs. LLVM17+ status upstream.
(In reply to Mark Millard from comment #3) The file "execution" is not missing from 13.2-STABLE as of what I just checked. It is in an expected sort of place: # uname -apKU FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256634-c4dfacd0b3c3 GENERIC arm64 aarch64 1302508 1302508 # find /usr/include -name '*execution*' -print /usr/include/c++/v1/execution The actual "problem" looks to be that other files are missing: # grep -r _LIBCPP_HAS_PARALLEL_ALGORITHMS /usr/include /usr/include/c++/v1/algorithm:#if defined(_LIBCPP_HAS_PARALLEL_ALGORITHMS) && _LIBCPP_STD_VER >= 17 /usr/include/c++/v1/execution:#if defined(_LIBCPP_HAS_PARALLEL_ALGORITHMS) && _LIBCPP_STD_VER >= 17 /usr/include/c++/v1/memory:#if defined(_LIBCPP_HAS_PARALLEL_ALGORITHMS) && _LIBCPP_STD_VER >= 17 /usr/include/c++/v1/numeric:#if defined(_LIBCPP_HAS_PARALLEL_ALGORITHMS) && _LIBCPP_STD_VER >= 17 /usr/include/c++/v1/__config_site:/* #undef _LIBCPP_HAS_PARALLEL_ALGORITHMS */ and has /usr/include/c++/v1/__config_site with: #ifndef _LIBCPP___CONFIG_SITE #define _LIBCPP___CONFIG_SITE #define _LIBCPP_ABI_VERSION 1 #define _LIBCPP_ABI_NAMESPACE __1 /* #undef _LIBCPP_ABI_FORCE_ITANIUM */ /* #undef _LIBCPP_ABI_FORCE_MICROSOFT */ /* #undef _LIBCPP_HAS_NO_THREADS */ /* #undef _LIBCPP_HAS_NO_MONOTONIC_CLOCK */ /* #undef _LIBCPP_HAS_MUSL_LIBC */ /* #undef _LIBCPP_HAS_THREAD_API_PTHREAD */ /* #undef _LIBCPP_HAS_THREAD_API_EXTERNAL */ /* #undef _LIBCPP_HAS_THREAD_API_WIN32 */ /* #undef _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL */ /* #undef _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS */ #define _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS /* #undef _LIBCPP_NO_VCRUNTIME */ /* #undef _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION */ /* #undef _LIBCPP_HAS_NO_FILESYSTEM_LIBRARY */ /* #undef _LIBCPP_HAS_PARALLEL_ALGORITHMS */ /* #undef _LIBCPP_HAS_NO_RANDOM_DEVICE */ /* #undef _LIBCPP_HAS_NO_LOCALIZATION */ /* #undef _LIBCPP_HAS_NO_FSTREAM */ /* #undef _LIBCPP_HAS_NO_WIDE_CHARACTERS */ #define _LIBCPP_ENABLE_ASSERTIONS_DEFAULT 0 /* #undef _LIBCPP_ENABLE_DEBUG_MODE */ . . . #endif // _LIBCPP___CONFIG_SITE so _LIBCPP_HAS_PARALLEL_ALGORITHMS is not defined by default. That in turn disables execution's content. (That source looks to predate the -fexperimental-library mechanism.) # c++ -std=c++17 -D_LIBCPP_HAS_PARALLEL_ALGORITHMS execution_test.cpp In file included from execution_test.cpp:1: In file included from /usr/include/c++/v1/mutex:192: In file included from /usr/include/c++/v1/__mutex_base:20: In file included from /usr/include/c++/v1/system_error:154: In file included from /usr/include/c++/v1/string:576: In file included from /usr/include/c++/v1/string_view:1025: /usr/include/c++/v1/algorithm:1909:12: fatal error: '__pstl_algorithm' file not found # include <__pstl_algorithm> ^~~~~~~~~~~~~~~~~~ 1 error generated. # find /usr/include -name '*pstl*' -print # But: # grep -r pstl /usr/include/c++/v1/ /usr/include/c++/v1/algorithm:# include <__pstl_algorithm> /usr/include/c++/v1/execution:# include <__pstl_execution> /usr/include/c++/v1/memory:# include <__pstl_memory> /usr/include/c++/v1/numeric:# include <__pstl_numeric> So it is the __pstl_* material that is missing, not execution itself. I've not checked, but it may be that the c++ language was updated to LLVM16 without updating libc++ to also be based on LLVM16's assoicated libc++ source. I will note that: # uname -apKU FreeBSD CA72-16Gp-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #120 main-n266130-d521abdff236-dirty: Tue Oct 24 18:26:23 PDT 2023 root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1500002 1500002 has the same basic status: # find /usr/include -name '*pstl*' -print # # grep -r pstl /usr/include/c++/v1/ /usr/include/c++/v1/numeric:# include <__pstl_numeric> /usr/include/c++/v1/memory:# include <__pstl_memory> /usr/include/c++/v1/algorithm:# include <__pstl_algorithm> /usr/include/c++/v1/execution:# include <__pstl_execution>
(In reply to Mark Millard from comment #4) As for upstream LLVM related materials: https://github.com/llvm/llvm-project/blob/release/16.x/libcxx/include/execution looks to agree with what FreeBSD has for the execution file content and related material (or lack of it). By contrast, https://github.com/llvm/llvm-project/blob/release/17.x/libcxx/include/execution is the first version with the content of the execution file filled in (in the normal manor). Net result for this bugzilla submittal: it is reporting that 13.2-STABLE is not using LLVM17+ related materials yet, 17 being the first version to have the some useful content for the execution header. As noted elsewhere in the comments, LLVM 17's related libc++ still has -fexperimental-library status for the likes of the execution file.
(In reply to Mark Millard from comment #5) The libcxx/include/execution file support may be rather incomplete, even in llvm17: https://libcxx.llvm.org/Status/?C=M;O=D reports: Parallelism.html 2023-11-01 07:53 17K and the content reports: [parallel.execpol], Execution policies, None, unassigned, Not Started