| Age | Commit message (Collapse) | Author |
|
(#143767)
* Get rid of libc_errno assignments in str_to_* __support tests, since
those API have been migrated to return error in a struct instead.
* Migrate tests for atof and to strto* functions from <stdlib.h> and for
strdup from <string.h> to use ErrnoCheckingTest harness.
|
|
The C standard specifies
n-char-sequence:
digit
nondigit
n-char-sequence digit
n-char-sequence nondigit
nondigit is specified as one of:
_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
This means nondigit includes the underscore character. This patch
clarifies this status in the comments and the test.
Note C17 specifies n-char-sequence for NaN() as optional, and an empty
sequence is not a valid n-char-sequence. However the current comment has
the same effect as using the pedantic wording. So I left that part
unchanged.
|
|
Having libc_errno outside of the namespace causes versioning issues when
trying to link the tests against LLVM-libc. Most of this patch is just
moving libc_errno inside the namespace in tests. This isn't necessary in
the function implementations since those are already inside the
namespace.
|
|
This patch provides specific test macros to deal with `errno`.
This will help abstract away the differences between unit test and integration/hermetic tests in #79319.
In one case we use `libc_errno` which is a struct, in the other case we deal directly with `errno`.
|
|
|
|
The semantics for casting can range from "bitcast" (same representation)
to "different representation", to "type promotion". Here we remove the
cast operator and force usage of `get_val` as the only function to get
the floating point value, making the intent clearer and more consistent.
|
|
This is step 4 of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
|
|
Other libc implementations support underscores in NaN(n-char-sequence)
strings. Us not supporting that is causing fuzz failures, so this patch
solves the problem.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D156927
|
|
There were regressions in the testing framework due to none of the
functioning buildbots having a 32 bit long. This allowed the 32 bit
version of the strtointeger function to go untested. This patch adds
tests for strtoint32 and strtoint64, which are internal testing
functions that use constant integer sizes. It also fixes the tests to
properly handle these situations.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D151935
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D148602
|
|
Fixes https://github.com/llvm/llvm-project/issues/61071
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D145191
|
|
This part of the effort to make all test related pieces into the `test`
directory. This helps is excluding test related pieces in a straight
forward manner if LLVM_INCLUDE_TESTS is OFF. Future patches will also move
the MPFR wrapper and testutils into the 'test' directory.
|
|
The specified rounding mode will be used and restored
to what it was before the test ran.
Additionally, it moves ForceRoundingMode and RoundingMode
out of MPFRUtils to be used in more places.
Differential Revision: https://reviews.llvm.org/D129685
|
|
Apply the formatting rules that were applied to the libc/src directory
to the libc/test directory, as well as the files in libc/utils that are
included by the tests. This does not include automated enforcement.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D116127
|
|
This patch applies the lint rules described in the previous patch. There
was also a significant amount of effort put into manually fixing things,
since all of the templated functions, or structs defined in /spec, were
not updated and had to be handled manually.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D114302
|
|
Fix the fact that previously strtof/d/ld would only accept a NaN as
having parentheses if the thing in the parentheses was a valid number,
now it will accept any combination of letters and numbers, but will only
put valid numbers in the mantissa.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D113790
|
|
Update binaryExpTofloat so that it will round correctly for long inputs when converting hexadecimal strings to floating points.
Differential Revision: https://reviews.llvm.org/D113815
|
|
When strtof/d/ld return a subnormal number they may set errno to
ERANGE. This change makes this behavior more consistent by making any
decimal number converting to a subnormal set errno to ERANGE. This
brings it in line with hexadecimals, which currently only set errno to
ERANGE if the number is truncated when converting to a subnormal.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D113626
|
|
Split the code for parsing hexadecimal floating point numbers from the
code for parsing the decimal floating point numbers so that the parsing
can be faster for both of them.
This decreases the time for the benchmark in release mode by about 15%,
which noticeably beats GLibc.
Old version: 2.299s
New version: 1.893s
GLibc: 2.133s
Tests run by running the following command 10 times for each version:
time ~/llvm-project/build/bin/libc_str_to_float_comparison_test ~/parse-number-fxx-test-data/data/*
the parse-number-fxx-test-data-repository is here:
https://github.com/nigeltao/parse-number-fxx-test-data/tree/fe94de252c691900982050c8e7c503d1efd1299a
It's important to build llvm-libc in Release mode for accurate
performance comparisons against glibc (set -DCMAKE_BUILD_TYPE=Release in
your cmake).
You also have to build the libc_str_to_float_comparison_test target.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D113036
|
|
Add the string to floating point conversion functions.
Long doubles aren't supported yet, but floats and doubles are. The
primary algorithm used is the Eisel-Lemire ParseNumberF64 algorithm,
with the Simple Decimal Conversion algorithm as backup.
Links for more information on the algorithms:
Number Parsing at a Gigabyte per Second, Software: Practice and
Experience 51 (8), 2021 (https://arxiv.org/abs/2101.11408)
https://nigeltao.github.io/blog/2020/eisel-lemire.html
https://nigeltao.github.io/blog/2020/parse-number-f64-simple.html
Differential Revision: https://reviews.llvm.org/D109261
|