History log of /llvm-project-15.0.7/libcxx/include/bit (Results 1 – 25 of 31)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# a83004f4 11-Jul-2022 David Tenty <[email protected]>

[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`

D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
_

[libcxx][AIX][z/OS] Remove headers included via `_IBMCPP__`

D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
__IBMCPP__ macro. This change cleans this up by deleting these headers.

Reviewed By: hubert.reinterpretcast, fanbo-meng

Differential Revision: https://reviews.llvm.org/D129491

show more ...


# de4a57cb 27-Jun-2022 Louis Dionne <[email protected]>

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

Differential Revision: https://reviews.llvm.org/D128661

show more ...


Revision tags: llvmorg-14.0.6
# 21ba9d0b 14-Jun-2022 Mark de Wever <[email protected]>

[libc++][NFC] Merges unused functions in callers.

This is a follow up based on a request of @jloser in D127594.

As drive-by qualified the function calls in the <bit> header.

Reviewed By: #libc, Er

[libc++][NFC] Merges unused functions in callers.

This is a follow up based on a request of @jloser in D127594.

As drive-by qualified the function calls in the <bit> header.

Reviewed By: #libc, EricWF

Differential Revision: https://reviews.llvm.org/D127760

show more ...


# 23b10a4a 12-Jun-2022 Mark de Wever <[email protected]>

[libc++][NFC] Use concepts in <bit>.

All supported compilers have concepts support so use that in the C++20
functions in <bit>.

s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.

[libc++][NFC] Use concepts in <bit>.

All supported compilers have concepts support so use that in the C++20
functions in <bit>.

s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D127594

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 385cc25a 25-Mar-2022 Louis Dionne <[email protected]>

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

Differential Revision: https://reviews.llvm.org/D122506

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# 3347e7d4 24-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] [LWG3656] Update the return type of std::bit_width.

Fixes LWG3656, "Inconsistent bit operations returning a count".
https://cplusplus.github.io/LWG/issue3656

The fix has been approved for

[libc++] [LWG3656] Update the return type of std::bit_width.

Fixes LWG3656, "Inconsistent bit operations returning a count".
https://cplusplus.github.io/LWG/issue3656

The fix has been approved for C++23 and left to vendors' discretion
in C++20 (but it sounds like everyone's on the same page that
of course it should be DR'ed back to C++20 too).

Differential Revision: https://reviews.llvm.org/D120444

show more ...


# f87aa19b 14-Feb-2022 Louis Dionne <[email protected]>

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

Differential Revision: https://reviews.llvm.org/D119769

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init
# fa6b9e40 02-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D1188

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D118800

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# 5675b611 16-Dec-2021 Nikolas Klauser <[email protected]>

[libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluation

Disable `_LIBCPP_DEBUG_ASSERT` and debug iterators in <string> during constant evaluation

Reviewed By: ldionne, #libc

Spies: goncha

[libc++] Disable _LIBCPP_DEBUG_ASSERT during constant evaluation

Disable `_LIBCPP_DEBUG_ASSERT` and debug iterators in <string> during constant evaluation

Reviewed By: ldionne, #libc

Spies: goncharov, libcxx-commits

Differential Revision: https://reviews.llvm.org/D115788

show more ...


Revision tags: llvmorg-13.0.1-rc1
# 1dc62f26 21-Nov-2021 Nikolas Klauser <[email protected]>

[libc++] Implement P1272R4 (std::byteswap)

Implement P1274R4

Reviewed By: Quuxplusone, Mordante, #libc

Spies: jloser, lebedev.ri, mgorny, libcxx-commits, arichardson

Differential Revision: https:

[libc++] Implement P1272R4 (std::byteswap)

Implement P1274R4

Reviewed By: Quuxplusone, Mordante, #libc

Spies: jloser, lebedev.ri, mgorny, libcxx-commits, arichardson

Differential Revision: https://reviews.llvm.org/D114074

show more ...


# eb8650a7 17-Nov-2021 Louis Dionne <[email protected]>

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2
# b1fb3d75 28-May-2020 Louis Dionne <[email protected]>

[libc++] Implement C++20's P0476R2: std::bit_cast

Thanks to Arthur O'Dwyer for fixing up some of the tests.

Differential Revision: https://reviews.llvm.org/D75960


# 4e0ea2cf 17-Aug-2021 Louis Dionne <[email protected]>

[libc++] Use enable_if_t instead of _EnableIf

I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was

[libc++] Use enable_if_t instead of _EnableIf

I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was quite bad and did not mention the reason for the overload being
excluded. Specifically, the error looked like this:

candidate template ignored: substitution failure [with _Args =
<ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'

Instead, when using enable_if or enable_if_t, the compiler is clever and
can produce better diagnostics, like so:

candidate template ignored: requirement 'is_invocable_v<
std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>,
std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &,
ContiguousView>' was not satisfied [with _Args = <ContiguousView>]

Basically, it tries to do a poor man's implementation of concepts, which
is already a lot better than simply complaining about substitution failure.

Hence, this commit uses enable_if_t instead of _EnableIf whenever
possible. That is both more straightforward than using the internal
helper, and also leads to better error messages in those cases.

I understand the motivation for _EnableIf's implementation was to improve
compile-time performance, however I believe striving to improve error
messages is even more important for our QOI, hence this patch. Furthermore,
it is unclear that _EnableIf actually improved compile-time performance
in any noticeable way (see discussion in the review for details).

Differential Revision: https://reviews.llvm.org/D108216

show more ...


# bfbd73f8 19-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Alphabetize and include-what-you-use. NFCI.

Differential Revision: https://reviews.llvm.org/D102781


# 06b40e80 13-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI.


# e130fbe2 12-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Some fixes to the <bit> utilities.

Fix __bitop_unsigned_integer and rename to __libcpp_is_unsigned_integer.
There are only five unsigned integer types, so we should just list them out.
Also

[libc++] Some fixes to the <bit> utilities.

Fix __bitop_unsigned_integer and rename to __libcpp_is_unsigned_integer.
There are only five unsigned integer types, so we should just list them out.
Also provide `__libcpp_is_signed_integer`, even though the Standard doesn't
consume that trait anywhere yet.

Notice that `concept uniform_random_bit_generator` is specifically specified
to rely on `concept unsigned_integral` and *not* `__is_unsigned_integer`.
Instantiating `std::ranges::sample` with a type `U` satisfying
`uniform_random_bit_generator` where `unsigned_integral<U::result_type>`
and not `__is_unsigned_integer<U::result_type>` is simply IFNDR.

Orthogonally, fix an undefined behavior in std::countr_zero(__uint128_t).

Orthogonally, improve tests for the <bit> manipulation functions.
It was these new tests that detected the bug in countr_zero.

Differential Revision: https://reviews.llvm.org/D102328

show more ...


# b5175681 02-Feb-2021 Louis Dionne <[email protected]>

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differentia

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differential Revision: https://reviews.llvm.org/D95956

show more ...


# b973e2e2 18-Jan-2021 Thorsten Schütt <[email protected]>

[libc++] Introduce __bits

It has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches.

[libc++] Introduce __bits

It has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D94908

show more ...


# d586f92c 27-Nov-2020 Arthur O'Dwyer <[email protected]>

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. T

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

Differential Revision: https://reviews.llvm.org/D92250

show more ...


# 1a036e9c 24-Nov-2020 Mark de Wever <[email protected]>

[libcxx] Implement P1956 rename low-level bit functions

Implements P1956: On the names of low-level bit manipulation functions.

Users may use older versions of libc++ or other standard libraries wi

[libcxx] Implement P1956 rename low-level bit functions

Implements P1956: On the names of low-level bit manipulation functions.

Users may use older versions of libc++ or other standard libraries with the old names. In order to keep compatibility the old functions are kept, but marked as deprecated.

The patch also adds a new config macro `_LIBCPP_DEPRECATED_MSG`. Do you prefer a this is a separate patch?

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D90551

show more ...


# ebddf90a 28-May-2020 Louis Dionne <[email protected]>

[libc++] NFC: Remove outdated numbering in <bit> synopsis


Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# 6b77ebdc 23-Oct-2019 Louis Dionne <[email protected]>

[NFC] Strip trailing whitespace from libc++


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1
# 30f12a42 23-Jul-2019 Marshall Clow <[email protected]>

Implement most of P1612R1: Relocate endian. Moves the std::endian functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a featur

Implement most of P1612R1: Relocate endian. Moves the std::endian functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a feature-test macro, but I don't have the value for that one yet. In a month or so, I'll add that

llvm-svn: 366776

show more ...


Revision tags: llvmorg-10-init
# f3b851f0 12-Jul-2019 Marshall Clow <[email protected]>

Reorganize the 'bit' header to make most of the facilities available for internal use pre-C++20. NFC for external users

llvm-svn: 365854


Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4
# bd7f84a4 02-Jul-2019 Marshall Clow <[email protected]>

Use new '__libcpp_is_constant_evaluated' call to remove an '#ifdef' from the bit code. NFC

llvm-svn: 364884


12