History log of /llvm-project-15.0.7/libcxx/include/charconv (Results 1 – 25 of 44)
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
# b7aa9c4a 24-Jul-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize some more type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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


# b48c5010 08-Jul-2022 Nikolas Klauser <[email protected]>

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spie

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits, miyuki

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

show more ...


# 3f786833 30-Jun-2022 Mark de Wever <[email protected]>

[libc++] Implements 128-bit support in to_chars.

This is required by the Standard and makes it possible to add full
128-bit support to format.

The patch also fixes 128-bit from_chars "support". One

[libc++] Implements 128-bit support in to_chars.

This is required by the Standard and makes it possible to add full
128-bit support to format.

The patch also fixes 128-bit from_chars "support". One unit test
required a too large value, this failed on 128-bit; the fix was to add
more characters to the input.

Note only base 10 has been optimized. Other bases can be optimized.

Note the 128-bit lookup table could be made smaller. This will be done later. I
really want to get 128-bit working in to_chars and format in the upcomming
LLVM 15 release, these optimizations aren't critical.

Reviewed By: #libc, ldionne

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

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
# cf927669 20-Jun-2022 Mark de Wever <[email protected]>

[libc++] Reduces std::to_chars instantiations.

Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This resu

[libc++] Reduces std::to_chars instantiations.

Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This results in a smaller binary when using different types.

In an example using the types: signed char, short, int, long, long long,
unsigned char, unsigned short, unsigned int, unsigned long, and
unsigned long long this saved 2792 bytes of code size. For libc++.so.1
is saves 688 bytes of code size (64-bit Linux).

This was discovered while investigating a solution for #52709.

Reviewed By: #libc, ldionne

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

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4
# 3561ee58 16-May-2022 Mark de Wever <[email protected]>

[libc++] Improve charconv base10 algorithm.

This change is a preparation to add the 128-bit integral output.

Before
```
--------------------------------------------------------------
Benchmark

[libc++] Improve charconv base10 algorithm.

This change is a preparation to add the 128-bit integral output.

Before
```
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
BM_to_chars_good/2 20.1 ns 20.1 ns 35045000
BM_to_chars_good/3 117 ns 117 ns 5916000
BM_to_chars_good/4 83.7 ns 83.7 ns 8401000
BM_to_chars_good/5 70.6 ns 70.6 ns 9915000
BM_to_chars_good/6 59.9 ns 59.9 ns 11678000
BM_to_chars_good/7 53.9 ns 53.8 ns 12995000
BM_to_chars_good/8 19.0 ns 19.0 ns 37110000
BM_to_chars_good/9 45.9 ns 45.8 ns 15278000
BM_to_chars_good/10 9.24 ns 9.24 ns 75343000
BM_to_chars_good/11 42.6 ns 42.6 ns 16449000
BM_to_chars_good/12 38.8 ns 38.8 ns 18101000
BM_to_chars_good/13 38.8 ns 38.8 ns 17999000
BM_to_chars_good/14 37.7 ns 37.6 ns 18571000
BM_to_chars_good/15 35.8 ns 35.8 ns 19660000
BM_to_chars_good/16 15.4 ns 15.4 ns 46129000
BM_to_chars_good/17 32.3 ns 32.3 ns 21763000
BM_to_chars_good/18 32.8 ns 32.8 ns 21396000
BM_to_chars_good/19 33.4 ns 33.4 ns 21078000
BM_to_chars_good/20 33.3 ns 33.3 ns 21020000
BM_to_chars_good/21 32.3 ns 32.3 ns 21807000
BM_to_chars_good/22 31.6 ns 31.6 ns 22057000
BM_to_chars_good/23 30.7 ns 30.7 ns 22938000
BM_to_chars_good/24 28.3 ns 28.3 ns 24659000
BM_to_chars_good/25 28.2 ns 28.2 ns 24790000
BM_to_chars_good/26 28.4 ns 28.4 ns 24410000
BM_to_chars_good/27 28.7 ns 28.7 ns 24423000
BM_to_chars_good/28 28.9 ns 28.9 ns 24139000
BM_to_chars_good/29 28.9 ns 28.9 ns 24347000
BM_to_chars_good/30 29.2 ns 29.2 ns 24141000
BM_to_chars_good/31 29.6 ns 29.6 ns 23699000
BM_to_chars_good/32 29.5 ns 29.5 ns 23933000
BM_to_chars_good/33 28.9 ns 28.9 ns 24042000
BM_to_chars_good/34 28.7 ns 28.7 ns 24361000
BM_to_chars_good/35 28.3 ns 28.3 ns 24703000
BM_to_chars_good/36 28.1 ns 28.1 ns 24924000
BM_to_chars_bad/2 6.16 ns 6.15 ns 114101000
BM_to_chars_bad/3 14.5 ns 14.5 ns 48244000
BM_to_chars_bad/4 16.9 ns 16.9 ns 41974000
BM_to_chars_bad/5 12.5 ns 12.5 ns 56080000
BM_to_chars_bad/6 10.9 ns 10.9 ns 64036000
BM_to_chars_bad/7 14.5 ns 14.5 ns 47294000
BM_to_chars_bad/8 6.36 ns 6.35 ns 110430000
BM_to_chars_bad/9 12.4 ns 12.4 ns 56448000
BM_to_chars_bad/10 5.13 ns 5.13 ns 137596000
BM_to_chars_bad/11 9.88 ns 9.88 ns 69015000
BM_to_chars_bad/12 10.8 ns 10.8 ns 63990000
BM_to_chars_bad/13 10.7 ns 10.7 ns 65066000
BM_to_chars_bad/14 9.71 ns 9.71 ns 71775000
BM_to_chars_bad/15 9.18 ns 9.18 ns 75267000
BM_to_chars_bad/16 6.12 ns 6.12 ns 115000000
BM_to_chars_bad/17 10.7 ns 10.7 ns 65504000
BM_to_chars_bad/18 10.6 ns 10.6 ns 65685000
BM_to_chars_bad/19 9.98 ns 9.98 ns 69894000
BM_to_chars_bad/20 9.74 ns 9.74 ns 72098000
BM_to_chars_bad/21 9.25 ns 9.25 ns 75184000
BM_to_chars_bad/22 9.10 ns 9.10 ns 75602000
BM_to_chars_bad/23 9.48 ns 9.48 ns 72824000
BM_to_chars_bad/24 9.27 ns 9.27 ns 75112000
BM_to_chars_bad/25 9.61 ns 9.61 ns 72080000
BM_to_chars_bad/26 9.72 ns 9.72 ns 72178000
BM_to_chars_bad/27 10.0 ns 10.0 ns 69733000
BM_to_chars_bad/28 10.3 ns 10.3 ns 67409000
BM_to_chars_bad/29 9.97 ns 9.97 ns 69193000
BM_to_chars_bad/30 10.1 ns 10.1 ns 69007000
BM_to_chars_bad/31 9.68 ns 9.68 ns 72232000
BM_to_chars_bad/32 8.99 ns 8.99 ns 76825000
BM_to_chars_bad/33 8.82 ns 8.82 ns 79293000
BM_to_chars_bad/34 8.64 ns 8.64 ns 80441000
BM_to_chars_bad/35 8.96 ns 8.96 ns 75320000
BM_to_chars_bad/36 8.87 ns 8.87 ns 77293000

```

After
```
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
BM_to_chars_good/2 14.7 ns 14.7 ns 47583000
BM_to_chars_good/3 101 ns 101 ns 6901000
BM_to_chars_good/4 68.4 ns 68.4 ns 10088000
BM_to_chars_good/5 58.2 ns 58.2 ns 12007000
BM_to_chars_good/6 51.1 ns 51.1 ns 13687000
BM_to_chars_good/7 45.6 ns 45.6 ns 15323000
BM_to_chars_good/8 14.6 ns 14.6 ns 47795000
BM_to_chars_good/9 40.7 ns 40.7 ns 17371000
BM_to_chars_good/10 7.48 ns 7.48 ns 90931000
BM_to_chars_good/11 37.6 ns 37.6 ns 18542000
BM_to_chars_good/12 35.2 ns 35.2 ns 19922000
BM_to_chars_good/13 34.9 ns 34.9 ns 20105000
BM_to_chars_good/14 33.5 ns 33.5 ns 20863000
BM_to_chars_good/15 31.9 ns 31.9 ns 22014000
BM_to_chars_good/16 11.7 ns 11.7 ns 60012000
BM_to_chars_good/17 28.9 ns 28.9 ns 24148000
BM_to_chars_good/18 29.0 ns 29.0 ns 24317000
BM_to_chars_good/19 28.7 ns 28.7 ns 24363000
BM_to_chars_good/20 28.1 ns 28.1 ns 24899000
BM_to_chars_good/21 27.5 ns 27.5 ns 25499000
BM_to_chars_good/22 26.9 ns 26.9 ns 25929000
BM_to_chars_good/23 26.2 ns 26.2 ns 26828000
BM_to_chars_good/24 25.1 ns 25.1 ns 27742000
BM_to_chars_good/25 25.3 ns 25.3 ns 27720000
BM_to_chars_good/26 25.2 ns 25.2 ns 27789000
BM_to_chars_good/27 25.3 ns 25.3 ns 27777000
BM_to_chars_good/28 25.3 ns 25.3 ns 27643000
BM_to_chars_good/29 25.3 ns 25.3 ns 27750000
BM_to_chars_good/30 25.4 ns 25.4 ns 27566000
BM_to_chars_good/31 25.4 ns 25.4 ns 27611000
BM_to_chars_good/32 25.8 ns 25.8 ns 27218000
BM_to_chars_good/33 25.7 ns 25.7 ns 27070000
BM_to_chars_good/34 26.1 ns 26.1 ns 26693000
BM_to_chars_good/35 26.4 ns 26.4 ns 26486000
BM_to_chars_good/36 26.3 ns 26.3 ns 26619000
BM_to_chars_bad/2 5.99 ns 5.99 ns 118787000
BM_to_chars_bad/3 14.3 ns 14.3 ns 48567000
BM_to_chars_bad/4 16.0 ns 16.0 ns 43239000
BM_to_chars_bad/5 12.6 ns 12.6 ns 55354000
BM_to_chars_bad/6 10.7 ns 10.7 ns 65491000
BM_to_chars_bad/7 14.4 ns 14.4 ns 48723000
BM_to_chars_bad/8 6.50 ns 6.50 ns 104967000
BM_to_chars_bad/9 12.0 ns 12.0 ns 56552000
BM_to_chars_bad/10 5.16 ns 5.16 ns 136380000
BM_to_chars_bad/11 10.5 ns 10.5 ns 66764000
BM_to_chars_bad/12 10.7 ns 10.7 ns 65534000
BM_to_chars_bad/13 11.0 ns 11.0 ns 63426000
BM_to_chars_bad/14 9.90 ns 9.90 ns 68575000
BM_to_chars_bad/15 9.52 ns 9.52 ns 70932000
BM_to_chars_bad/16 6.14 ns 6.14 ns 111762000
BM_to_chars_bad/17 10.6 ns 10.6 ns 65883000
BM_to_chars_bad/18 10.5 ns 10.5 ns 67606000
BM_to_chars_bad/19 9.96 ns 9.96 ns 68898000
BM_to_chars_bad/20 9.40 ns 9.41 ns 73116000
BM_to_chars_bad/21 9.12 ns 9.12 ns 78647000
BM_to_chars_bad/22 8.95 ns 8.95 ns 80211000
BM_to_chars_bad/23 9.50 ns 9.49 ns 73571000
BM_to_chars_bad/24 9.29 ns 9.29 ns 74690000
BM_to_chars_bad/25 9.65 ns 9.65 ns 72877000
BM_to_chars_bad/26 9.78 ns 9.78 ns 70171000
BM_to_chars_bad/27 10.1 ns 10.1 ns 69543000
BM_to_chars_bad/28 10.4 ns 10.4 ns 67582000
BM_to_chars_bad/29 10.00 ns 10.00 ns 70806000
BM_to_chars_bad/30 9.99 ns 9.99 ns 70340000
BM_to_chars_bad/31 9.56 ns 9.56 ns 74159000
BM_to_chars_bad/32 8.97 ns 8.97 ns 78052000
BM_to_chars_bad/33 8.86 ns 8.86 ns 78586000
BM_to_chars_bad/34 8.81 ns 8.81 ns 78562000
BM_to_chars_bad/35 8.90 ns 8.90 ns 77384000
BM_to_chars_bad/36 9.04 ns 9.04 ns 77263000

```

Reviewed By: #libc, ldionne

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

show more ...


# b968c345 31-May-2022 Mark de Wever <[email protected]>

[libc++] Removes _LIBCPP_AVAILABILITY_TO_CHARS.

After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platfo

[libc++] Removes _LIBCPP_AVAILABILITY_TO_CHARS.

After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platforms.

Remove the _LIBCPP_AVAILABILITY_TO_CHARS availability macro and update
the tests.

Depends on D125704

Reviewed By: ldionne, #libc

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

show more ...


# dea7a8e6 02-Jun-2022 Mark de Wever <[email protected]>

[libc++] Don't use static constexpr in headers.

This was noticed in the review of D125704. In that commit only the new
table has been adapted. This adapts the existing tables.

Note since libc++'s c

[libc++] Don't use static constexpr in headers.

This was noticed in the review of D125704. In that commit only the new
table has been adapted. This adapts the existing tables.

Note since libc++'s charconv is backported to C++11 it's not possible to
use inline constexpr variables. The were introduced in C++17.

Reviewed By: #libc, ldionne

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

show more ...


# a15ae413 16-May-2022 Mark de Wever <[email protected]>

[libc++] Make to_chars base 10 header only.

The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 1

[libc++] Make to_chars base 10 header only.

The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 128-bit support the current code will be polished.

This moves the code from the dylib to the header in prepartion of

P2291 "Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header"

Note some more cleanups will be done in follow-up commits
- Remove the _LIBCPP_AVAILABILITY_TO_CHARS from to_chars. With all code
in the header the availablilty macro is no longer needed. This
requires enabling the unit tests for additional platforms.
- The code in the dylib can switch to using the header implementation.
This allows removing the code duplicated in the header and the dylib.

Reviewed By: #libc, ldionne

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

show more ...


Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, 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
# 6c11aebd 27-Feb-2021 Mark de Wever <[email protected]>

[libc++] Improve std::to_chars for base != 10.

This improves the speed of `to_chars` for bases 2, 8, and 16.
These bases are common and used in `<format>`. This change
uses a lookup table, like done

[libc++] Improve std::to_chars for base != 10.

This improves the speed of `to_chars` for bases 2, 8, and 16.
These bases are common and used in `<format>`. This change
uses a lookup table, like done in base 10 and causes an increase
in code size. The change has a small overhead for the other bases.

```
Benchmark Time CPU Time Old Time New CPU Old CPU New
------------------------------------------------------------------------------------------------------------------
BM_to_chars_good/2 -0.9476 -0.9476 252 13 252 13
BM_to_chars_good/3 +0.0018 +0.0018 145 145 145 145
BM_to_chars_good/4 +0.0108 +0.0108 104 105 104 105
BM_to_chars_good/5 +0.0159 +0.0160 89 91 89 91
BM_to_chars_good/6 +0.0162 +0.0162 80 81 80 81
BM_to_chars_good/7 +0.0117 +0.0117 72 73 72 73
BM_to_chars_good/8 -0.8643 -0.8643 64 9 64 9
BM_to_chars_good/9 +0.0095 +0.0095 60 60 60 60
BM_to_chars_good/10 +0.0540 +0.0540 6 6 6 6
BM_to_chars_good/11 +0.0299 +0.0299 55 57 55 57
BM_to_chars_good/12 +0.0060 +0.0060 48 49 49 49
BM_to_chars_good/13 +0.0102 +0.0102 48 48 48 48
BM_to_chars_good/14 +0.0184 +0.0185 47 48 47 48
BM_to_chars_good/15 +0.0269 +0.0269 44 45 44 45
BM_to_chars_good/16 -0.8207 -0.8207 37 7 37 7
BM_to_chars_good/17 +0.0241 +0.0241 37 38 37 38
BM_to_chars_good/18 +0.0221 +0.0221 37 38 37 38
BM_to_chars_good/19 +0.0222 +0.0223 37 38 37 38
BM_to_chars_good/20 +0.0317 +0.0317 38 39 38 39
BM_to_chars_good/21 +0.0342 +0.0341 38 39 38 39
BM_to_chars_good/22 +0.0336 +0.0336 36 38 36 38
BM_to_chars_good/23 +0.0222 +0.0222 34 35 34 35
BM_to_chars_good/24 +0.0185 +0.0185 31 32 31 32
BM_to_chars_good/25 +0.0157 +0.0157 32 32 32 32
BM_to_chars_good/26 +0.0181 +0.0181 32 32 32 32
BM_to_chars_good/27 +0.0153 +0.0153 32 32 32 32
BM_to_chars_good/28 +0.0179 +0.0179 32 32 32 32
BM_to_chars_good/29 +0.0189 +0.0189 32 33 32 33
BM_to_chars_good/30 +0.0212 +0.0212 32 33 32 33
BM_to_chars_good/31 +0.0221 +0.0221 32 33 32 33
BM_to_chars_good/32 +0.0292 +0.0292 32 33 32 33
BM_to_chars_good/33 +0.0319 +0.0319 32 33 32 33
BM_to_chars_good/34 +0.0411 +0.0410 33 34 33 34
BM_to_chars_good/35 +0.0515 +0.0515 33 34 33 34
BM_to_chars_good/36 +0.0502 +0.0502 32 34 32 34
BM_to_chars_bad/2 -0.8752 -0.8752 40 5 40 5
BM_to_chars_bad/3 +0.1952 +0.1952 21 26 21 26
BM_to_chars_bad/4 +0.3626 +0.3626 16 22 16 22
BM_to_chars_bad/5 +0.2267 +0.2268 17 21 17 21
BM_to_chars_bad/6 +0.3560 +0.3559 14 19 14 19
BM_to_chars_bad/7 +0.4599 +0.4600 12 18 12 18
BM_to_chars_bad/8 -0.5074 -0.5074 11 5 11 5
BM_to_chars_bad/9 +0.4814 +0.4814 10 15 10 15
BM_to_chars_bad/10 +0.7761 +0.7761 2 4 2 4
BM_to_chars_bad/11 +0.3948 +0.3948 12 16 12 16
BM_to_chars_bad/12 +0.3203 +0.3203 10 13 10 13
BM_to_chars_bad/13 +0.3067 +0.3067 11 14 11 14
BM_to_chars_bad/14 +0.2235 +0.2235 12 14 12 14
BM_to_chars_bad/15 +0.2675 +0.2675 11 14 11 14
BM_to_chars_bad/16 -0.1801 -0.1801 7 5 7 5
BM_to_chars_bad/17 +0.5651 +0.5651 7 11 7 11
BM_to_chars_bad/18 +0.5407 +0.5406 7 11 7 11
BM_to_chars_bad/19 +0.5593 +0.5593 8 12 8 12
BM_to_chars_bad/20 +0.5823 +0.5823 8 13 8 13
BM_to_chars_bad/21 +0.6032 +0.6032 9 15 9 15
BM_to_chars_bad/22 +0.6407 +0.6408 9 14 9 14
BM_to_chars_bad/23 +0.6292 +0.6292 7 12 7 12
BM_to_chars_bad/24 +0.5784 +0.5784 6 10 6 10
BM_to_chars_bad/25 +0.5784 +0.5784 6 10 6 10
BM_to_chars_bad/26 +0.5713 +0.5713 7 10 7 10
BM_to_chars_bad/27 +0.5969 +0.5969 7 11 7 11
BM_to_chars_bad/28 +0.6131 +0.6131 7 11 7 11
BM_to_chars_bad/29 +0.6937 +0.6937 7 11 7 11
BM_to_chars_bad/30 +0.7655 +0.7656 7 12 7 12
BM_to_chars_bad/31 +0.8939 +0.8939 6 12 6 12
BM_to_chars_bad/32 +1.0157 +1.0157 6 13 6 13
BM_to_chars_bad/33 +1.0279 +1.0279 7 14 7 14
BM_to_chars_bad/34 +1.0388 +1.0388 7 14 7 14
BM_to_chars_bad/35 +1.0990 +1.0990 7 15 7 15
BM_to_chars_bad/36 +1.1503 +1.1503 7 15 7 15
```

Reviewed By: ldionne, #libc

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

show more ...


# 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 ...


# e39095a3 03-Mar-2022 Louis Dionne <[email protected]>

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around

[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suite

This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.

After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.

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

show more ...


# 3925f98d 08-Mar-2022 Mark de Wever <[email protected]>

[libc++][NFC] Cleanups in <charconv>.

Based on review comments in D97705 applied some code cleanups in
<charconv>. The header now uses a more recent libc++ style.

Reviewed By: Quuxplusone, #libc, p

[libc++][NFC] Cleanups in <charconv>.

Based on review comments in D97705 applied some code cleanups in
<charconv>. The header now uses a more recent libc++ style.

Reviewed By: Quuxplusone, #libc, philnik

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

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 ...


# 2a8f9a5e 14-Feb-2022 Nikolas Klauser <[email protected]>

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

Differential Revision: https://reviews.

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

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

show more ...


# 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-12.0.0-rc2
# abb5dd6e 09-Feb-2021 Mark de Wever <[email protected]>

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ry

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .

Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.

This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .

Notes:

* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)

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

show more ...


# ae53d02f 07-Dec-2021 Petr Hosek <[email protected]>

Revert "Microsoft's floating-point to_chars powered by Ryu and Ryu Printf"

This reverts commit a8025e06fc0f2fe1bbee9e1a6f15c336bfbdcb05 since
it triggers PR52584 with debug info enabled.


# a8025e06 09-Feb-2021 Mark de Wever <[email protected]>

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ry

Microsoft's floating-point to_chars powered by Ryu and Ryu Printf

Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .

Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.

This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .

Notes:

* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)

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

show more ...


# d2b0df35 02-Dec-2021 Nikolas Klauser <[email protected]>

[libc++][NFC] Update namespace comments in include/

update the namspace comments in include/

Reviewed By: ldionne, #libc

Spies: smeenai, libcxx-commits

Differential Revision: https://reviews.llvm

[libc++][NFC] Update namespace comments in include/

update the namspace comments in include/

Reviewed By: ldionne, #libc

Spies: smeenai, libcxx-commits

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

show more ...


# 3624c4d8 23-Oct-2021 Mark de Wever <[email protected]>

[libc++] Adds (to|from)_chars_result operator==.

Implements part of P1614 The Mothership has Landed.

Reviewed By: #libc, Quuxplusone, Mordante

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

[libc++] Adds (to|from)_chars_result operator==.

Implements part of P1614 The Mothership has Landed.

Reviewed By: #libc, Quuxplusone, Mordante

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

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 ...


# bfc253c0 16-Nov-2021 Mark de Wever <[email protected]>

[libc++][nfc] Improve standard conformance.

The return type of the deleted functions doesn't match the synopsis in
the standard.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.

[libc++][nfc] Improve standard conformance.

The return type of the deleted functions doesn't match the synopsis in
the standard.

Reviewed By: #libc, ldionne

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

show more ...


# a59c1a21 15-Oct-2021 Konstantin Varlamov <[email protected]>

[libc++] LWG3266: delete the to_chars(bool) overload.

This PR only updates the synopsis in `<charconv>` -- the current
implementation already [deletes](https://github.com/llvm/llvm-project/blob/e9e6

[libc++] LWG3266: delete the to_chars(bool) overload.

This PR only updates the synopsis in `<charconv>` -- the current
implementation already [deletes](https://github.com/llvm/llvm-project/blob/e9e6266c704df43e2c52308e1b653dccefa89e04/libcxx/include/charconv#L108)
the overload and has a [test](https://github.com/llvm/llvm-project/blob/main/libcxx/test/std/utilities/charconv/charconv.to.chars/integral.bool.fail.cpp)
for it (and this has been the case from the first [commit](https://reviews.llvm.org/D41458)
where `<charconv>` was added).

Reviewed By: #libc, Mordante

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

show more ...


# e983a659 30-Aug-2021 Mark de Wever <[email protected]>

[libc++][NFC] split <charconv>.

This move the helper types `chars_format`, `to_chars_result` and
`from_chars_result` to a separate header. The first two are needed for
D70631 the third for consisten

[libc++][NFC] split <charconv>.

This move the helper types `chars_format`, `to_chars_result` and
`from_chars_result` to a separate header. The first two are needed for
D70631 the third for consistency.

The header `__charconv/ryu.h` uses these types and it can't depend on the
types in `<charconv>` in a modular build. Moving them to the ryu header
would be an odd place and doesn't work since the header is included in the
middle of `<charconv>`.

Reviewed By: #libc, ldionne, Quuxplusone

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

show more ...


12