| Issue |
138927
|
| Summary |
[libc++] macos: when -mmacosx-version-min < 11, std::latch compiles, although __cpp_lib_latch is undefined
|
| Labels |
libc++
|
| Assignees |
|
| Reporter |
asakovets
|
This issue was discovered using Apple toolchain, but its roots is in the upstream.
Steps to reproduce:
Consider a code snippet:
```cpp
#include <iostream>
#include <latch>
#include <version>
int main()
{
#if !__cpp_lib_latch
std::latch this_must_not_compile {42};
std::cout << "std::latch compiles, although __cpp_lib_latch is undefined\n";
#endif
}
```
Using Apple clang:
```bash
% xcrun clang++ --version
Apple clang version 16.0.0 (clang-1600.0.26.4)
Target: arm64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% xcrun clang++ -std=c++20 -mmacosx-version-min=10.15 latch.cpp
% ./a.out
std::latch compiles, although __cpp_lib_latch is undefined
```
Using upstream clang:
Reproducing the issue with upstream clang is not as straightforward. We must tell the compiler that vendor availability annotations are enabled (even if they are not). Passing `-D_LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS=1` does not work. The easiest solution, though a little messy, is to modify `${llvm_prefix}/include/c++/v1/__config_site` file and set `#define _LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS 1`. This should suffice to reproduce the issue:
```bash
% /opt/homebrew/Cellar/llvm/20.1.4/bin/clang++ --version
Homebrew clang version 20.1.4
Target: arm64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/20.1.4/bin
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg
% /opt/homebrew/Cellar/llvm/20.1.4/bin/clang++ -std=c++20 -mmacosx-version-min=10.15 latch.cpp
% ./a.out
std::latch compiles, although __cpp_lib_latch is undefined
```
-------------------------------------------------------------------------------------------------------------
My little bits of investigation:
`__cpp_lib_latch` is defined when both `_LIBCPP_HAS_THREADS` and `_LIBCPP_AVAILABILITY_HAS_SYNC` are true:
https://github.com/llvm/llvm-project/blob/0db040576d4ccb313fc58a90e1b4149f7589cc8c/libcxx/include/version#L438-L440
However, the definition of `std::latch` is only protected by `_LIBCPP_HAS_THREADS` macro:
https://github.com/llvm/llvm-project/blob/32752913b12103431dc392242c3c808afb70bd15/libcxx/include/latch#L48-L50
When compiling for MacOS < 11, if availability annotations are enabled, i.e. `_LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS = 1`, then `_LIBCPP_INTRODUCED_IN_LLVM_11` is defined as 0:
https://github.com/llvm/llvm-project/blob/960221623f54b87c0ce786d551111573810c8ac8/libcxx/include/__configuration/availability.h#L222-L226
This macro in turn is used to define `_LIBCPP_AVAILABILITY_HAS_SYNC`:
https://github.com/llvm/llvm-project/blob/960221623f54b87c0ce786d551111573810c8ac8/libcxx/include/__configuration/availability.h#L308
As a result, when `-mmacosx-version-min < 11` and vendor availability annotations are enabled, then `_LIBCPP_HAS_THREADS = 1` and `_LIBCPP_AVAILABILITY_HAS_SYNC = 0`. This makes `__cpp_lib_latch` undefined, but std::latch compiles nevertheless.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
