This is the first of patches doing similar cleanup. A section in the
code style doc has been added explaining where and how LIBC_INLINE is to
be used.
Reviewed By: jeffbailey, lntue
Differential Revision: https://reviews.llvm.org/D142434
This implements the same behavior as D141997 but makes sure that the same detection mechanism is used between CMake and source code.
Differential Revision: https://reviews.llvm.org/D142108
This patch reduces CMake configuration time drastically by removing a non-linear behavior.
Time to execute CMake configure step goes from 45s to 15s.
Differential Revision: https://reviews.llvm.org/D142374
This implements the same behavior as D141997 but makes sure that the same detection mechanism is used between CMake and source code.
Differential Revision: https://reviews.llvm.org/D142108
This is first of a few patches which will do similar mechanical changes.
LIBC_INLINE is a simple macro which is default defined as just `inline`.
The idea is that, different downstream contexts can define the macro as
suitable to their use case and context. For example, one can choose to
define LIBC_INLINE as `[[clang::internal_linkage]] inline`.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D142154
This patch adds the %f/F/e/E/g/G/a/A conversions for scanf, as well as
accompanying tests. This implementation matches the definition set forth
in the standard, which may conflict with some other implementations.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141091
The scanf implementation needs a dynamically resizing string class. This
patch adds a minimal version of that class along with tests to check the
current functionality.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141162
This will be used to implement the case insensitive str{,n}casecmp
This was initially reverted because it broke tests on arm platforms.
Unfortunately, it didn't break on my arm machine, but I suspect the
problem was the old comparator returned char and not int.
Differential Revision: https://reviews.llvm.org/D141235
Implement double precision log10 function correctly rounded for all
rounding modes. This implementation currently needs FMA instructions for
correctness.
Use 2 passes:
Fast pass:
- 1 step range reduction with a lookup table of `2^7 = 128` elements to reduce the ranges to `[-2^-7, 2^-7]`.
- Use a degree-7 minimax polynomial generated by Sollya, evaluated using a mixed of double-double and double precisions.
- Apply Ziv's test for accuracy.
Accurate pass:
- Apply 5 more range reduction steps to reduce the ranges further to [-2^-27, 2^-27].
- Use a degree-4 minimax polynomial generated by Sollya, evaluated using 192-bit precisions.
- By the result of Lefevre (add quote), this is more than enough for correct rounding to all rounding modes.
In progress: Adding detail documentations about the algorithm.
Depend on: https://reviews.llvm.org/D136799
Reviewed By: zimmermann6
Differential Revision: https://reviews.llvm.org/D139846
To improve code generation for C++ code that directly includes our
headers, the external function definitions will now be marked noexcept.
This may not be necessary for the internal definitions since we build
with the -fno-exceptions flag.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141095
GCC complains about if conditions not being constant expressions.
As-is get_table_negative cannot be marked constexpr.
Differential Revision: https://reviews.llvm.org/D140967
