`__libcpp_popcount` was previously used as a fallback for `__builtin_popcountg` to ensure compatibility with older compilers (Clang 18 and earlier), as `__builtin_popcountg` became available in Clang 19. Now that support for Clang 18 has been officially dropped in #130142, we can now safely replace all instances of `__libcpp_popcount` with `__builtin_popcountg` and eliminate the fallback logic.
This avoids instantiating multiple classes, reducing compile times. This
patch also introduces `__underyling_type_t` for internal use, similar to
other type traits.
Some test files for flat container adaptors redundantly include
`<iostream>` and, surprisingly, `<cstddef>`. This patch removes the
redundant inclusions.
Inclusions of `<vector>` is also removed since a sane implementation is
expected to make instantiation of `flat_(multi)map<K, V>` or
`flat_(multi)set<K>` valid when only `<flat_map>` or `<flat_set>` is
included.
The `__log2i` function template in `<algorithm/sort.h>` is basically
equivalent to `__bit_log2` in `<__bit/bit_log2.h>`. It seems better to
avoid duplication.
Copies the not-yet-implemented items planned for removal from the
LLVM-20 to the LLVM-21 release notes. This allows to better keep track
of the status of the next release.
Adjusting the existing script to match the new output makes it easy to
review the new script works correctly.
This adjusts the tests to match the changes in the new tests, Notably
- removes the synopsis uses 2 spaces indent in `# if`
It does not implement the conditional include part. This would be quite
some effort and these diffs are easy to review manually.
Note there are no tests for the changes; the existing script will be
phased out when the next generators are complete.
At the moment the ftm macro for __cpp_lib_to_chars will have the
following values:
standard_ftms: {
"c++17": "201611L",
"c++20": "201611L",
"c++23": "201611L",
"c++26": "201611L",
}
implemented_ftms: {
"c++17": None,
}
This is an issue with the test whether the FTM is implemented it does:
self.implemented_ftms[ftm][std] == self.standard_ftms[ftm][std]
This will fail in C++20 since implemented_ftms[ftm] does not have the
key c++20. This adds a new helper function and removes the None entries
when a FTM is not implemented.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The Apple runners automatically pick up newer XCode versions breaking
the CI. This disables the test to get the CI green which allows us to
investigate the issue properly later on.
This reverts commit d1156fcb56891fb1a426c3e8331a51d47f98a1b8.
This patch fixes the reported incorrect formatting changes and adds
tests for them. The performance should be unaffected, since there are no
significant changes required to fix the bugs.
Specifically, a `>` was changed to a `>=` to also add a `+` in the zero
case, and we're checking for zero now before printing the octal and
hexadecimal prefixes.
Closes#131710
The type traits are always `struct`s, so the `public` isn't necessary.
We're currently using `public` in some places, while we omit it in
others. This makes us consistent across the type traits.
The existing version check can lead to test failures on some distribution
packages of gdb where not all components of the version number are
integers, such as Fedora where gdb.VERSION can be something like
"15.2-4.fc41". Fix it by replacing the version check with a feature check.
Reviewers: philnik777
Reviewed By: philnik777
Pull Request: https://github.com/llvm/llvm-project/pull/132291
Summary:
Previously, we removed the special handling for the code object version
global. I erroneously thought that this meant we cold get rid of this
weird `-Xclang` option. However, this also emits an LLVM IR module flag,
which will then cause linking issues.
Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.
libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.
This macro isn't required if we define all the functions inline. In
fact, quite a few of the marked functions have already been inlined.
This patch basically only moves code around and adds
`_LIBCPP_HIDE_FROM_ABI` to the places where it's been missing so far.
This also removes inlining hints, since it dropps `inline` in some
places, but that shouldn't make much of a difference. The functions tend
to be either really small, so should be inlined anyways, or are big
enough that they shouldn't be inlined even with an inlinehint.
Currently when printing a template argument of expression type, the
expression is converted immediately into a string to be sent to the
diagnostic engine, unsing a fake LangOpts.
This makes the expression printing look incorrect for the current
language, besides being inneficient, as we don't actually need to print
the expression if the diagnostic would be ignored.
This fixes a nastiness with the TemplateArgument constructor for
expressions being implicit, and all current users just passing an
expression to a diagnostic were implicitly going through the template
argument path.
The expressions are also being printed unquoted. This will be fixed in a
subsequent patch, as the test churn is much larger.
When attempting to instantiate `std::atomic` with a non trivially
copyable type, one gets errors from instantiating internals before the
actual static assertion that check the template parameter type
requirements.
The `verify` test for it had a `// ADDITIONAL_COMPILE_FLAGS: -Xclang
-verify-ignore-unexpected=error` directive to work around this issue.
The changes I propose enable us to drop that directive.
As I understand it, the `verify` test was misplaced so I moved it to
`test/{std -> libcxx}/atomics`.
(I ran into this while working on #121414 in which we would add another
static assertion in `__check_atomic_mandates`)
In 0547e573c555, I introduced backdeployment testing on macOS using
Github-provided builders. This was done by basically building libc++ on
a slightly older macOS (like macOS 13) and then running against the
system library on that machine. However, that created a dependency that
libc++ must keep working on macOS 13, which doesn't support the
latest-released Xcode.
This patch solves that problem by moving the deployment testing to a
newer version of macOS which supports the latest-released version of
Xcode.
Sadly, that also reduces the backdeployment coverage we have since we're
not actually testing on older OSes, but is necessary to satisfy the
documented libc++ support policy. In the future, we could improve the
situation by providing a Lit configuration that allows compiling (but
not running) all the tests, building the tests on a supported macOS, and
then shipping those tests on an older backdeployment target in order to
run them against the system library. Since that requires significant
engineering, this isn't done at this time.
# Overview
As a disclaimer, this is my first PR to LLVM and while I've tried to
ensure I've followed the LLVM and libc++ contributing guidelines,
there's probably a good chance I missed something. If I have, just let
me know and I'll try to correct it as soon as I can.
This PR implements `std::ranges::iota` and
`std::ranges::out_value_result` outlined in
[P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html).
As outlined in the paper above, I've:
- Implemented `out_value_result` and added to `<algorithm>`
- Added `out_value_result`, `iota_result`, and two overloads of `iota`
to `std::ranges` in `<numeric>`
- Updated the version macro `__cpp_lib_ranges_iota` in `<version>`
I've also added tests for `ranges::iota` and `ranges::out_value_result`.
Lastly, I added those structs to the appropriate module files.
Partially implements #105184
EDIT: Forgot to mention in the original post, thanks to @hawkinsw for
taking a look at a preliminary version of this PR!
# TODOs
- [x] Updating the range [status
doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv)
- [x] Ensure all comments from https://reviews.llvm.org/D121436 are
addressed here
- [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing
the rest of P2440r1 (`ranges::shift_left` and `ranges::shift_right`) if
that's ok, I just wanted to get feedback on `ranges::iota` first~~
- [x] I've been having trouble building the modules locally and want to
make sure that's working properly
Closes: #134060
When I introduced the various `_LIBCPP_INTRODUCED_IN_LLVM_XY_ATTRIBUTE`
macros in 182f5e9b2f03, I tried to correlate them to the right OS
versions, but it seems that I made a few mistakes. This wasn't caught in
the CI because we don't test back-deployment that far.
rdar://148405946
There were some remaining headers that were not guarded with
_LIBCPP_HAS_LOCALIZATION, leading to errors when trying to use modules
on platforms that don't support localization (since all the headers get
pulled in when building the 'std' module). This patch brings these
headers in line with what we do for every other header that depends on
localization.
This patch also requires including <picolibc.h> from
<__configuration/platform.h> in order to define _NEWLIB_VERSION. In the
long term, we should use a better approach for doing that, such as
defining a macro in the __config_site header.
We should have had a release note in LLVM 20 about implementing P2165R4
since that is technically an ABI and API break for zip_view. We don't
expect anyone to actually hit the ABI issue, but we've come across some
(fairly small) breakage due to the API change, so this should at least
be mentioned in the release notes.
This allows us to remove the need for `_LIBCPP_TEMPLATE_VIS` and fixes a
bunch of missing annotations for RTTI when used across dylib boundaries.
`_LIBCPP_TEMPLATE_VIS` itself will be removed in a separate patch, since
it touches a lot of code.
This patch is a no-op for Clang. Only GCC is affected.
We only use `_LIBCPP_DISABLE_EXTENSION_WARNINGS` in a single place while
we use extensions all over the place. The warnings are already disabled,
since libc++'s headers are system headers, so this shouldn't be in any
way observable by users.
This macro is only ever used inside the definiton for the various
visibility macros on windows. There, it's defined in multiple places
with different expansions, which makes it more confusing than helpful
when trying to figure out what macro expands to what.
Using the C++11 attribute syntax makes it more strict where attributes
can be applied, reducing the number of possible positions an attribute
can appear in.
Unlike `flat_map` and `flat_multimap`, The two function template
overloads `flat_set::insert`'s wording strongly suggest we should use
the transparent comparator
https://eel.is/c++draft/flat.set#modifiers-1
Both the code and the tests were not using the transparent comparator,
which needs to be fixed
Instead, make the few functions `map` relies on public. This makes it
more clear what is private to `__tree` and what is part of the
library-internal interface.
clang-19 changed how Arm triples were normalised and so while we
supported 18 and 19, we could not hard code the path here.
Now that Linaro's bots are running clang-19, and libcxx is going to drop
clang-18 support (https://github.com/llvm/llvm-project/pull/130142) I
have simplified it by hard coding the path again.
I also looked into why this exists in the first place. It was added in
https://reviews.llvm.org/D154246 but not questioned at the time.
It is due to the way we build compiler-rt, which is due to the final
layout we need in the install:
1. The builtins library must be called libclang_rt.builtins.a for clang
to find it. There must not be an architecture name in the filename.
2. That builtins library must be directly in lib/, next to picolib's
installed files.
To achieve number 1 we must set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
However, that causes the file to be installed in a per-target dir which
breaks number 2. So to fix that, we move the builtins library up one
level into lib/.
The alternative is to turn off per-target dirs, which results in a
builtin file with an arch in the name, then rename and move that file
(since it gets installed into lib/generic/).
So in the end, it's the same amount of hacks. I think it's best to keep
the one that uses LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON, as this is the
recommended way to built these days.
Summary:
When we were first porting to COV5, this lead to some ABI issues due to
a change in how we looked up the work group size. Bitcode libraries
relied on the builtins to emit code, but this was changed between
versions. This prevented the bitcode libraries, like OpenMP or libc,
from being used for both COV4 and COV5. The solution was to have this
'none' functionality which effectively emitted code that branched off of
a global to resolve to either version.
This isn't a great solution because it forced every TU to have this
variable in it. The patch in
https://github.com/llvm/llvm-project/pull/131033 removed support for
COV4 from OpenMP, which was the only consumer of this functionality.
Other users like HIP and OpenCL did not use this because they linked the
ROCm Device Library directly which has its own handling (The name was
borrowed from it after all).
So, now that we don't need to worry about backward compatibility with
COV4, we can remove this special handling. Users can still emit COV4
code, this simply removes the special handling used to make the OpenMP
device runtime bitcode version agnostic.
