Due to the differences between the types of long double, this function
is effectively three functions in one. This patch adds basic support for
the types of long double, although it's just using the fast path and the
fallback for the moment. I still need to implement a version of
Eisel-Lemire for performance, but the existing algorithms should be
correct.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D113710
Adds an implementation for stpcpy and stpncpy, which are posix extension
functions.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D111913
malloc, calloc, realloc, and free are all functions that other libc
functions depend on, but are pulled from external sources, instead of
having an internal implementation. This patch adds a way to include
functions like that as entrypoints in the list of external entrypoints,
and includes the malloc functions using this new path.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D112104
Add an implementation for memccpy and mempcpy. These functions are
posix extensions for the moment.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D111762
This adds strncat to llvm libc. In addition, an error was found with
strcat and that was fixed.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D111583
This patch adds a skeleton as a preparatory step for the next patch which
adds the actual implementations of the condition variable functions.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D108947
Add inttypes.h to llvm libc. As its first functions strtoimax and
strtoumax are included.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D108736
Adds atoi, atol, atoll, strtol, strtoll, strtoul, and strtoull to the
list of entrypoints for Windows and aarch64 linux, as well as moving
them out of the LLVM_LIBC_FULL_BUILD condition for x86_64 linux.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D108477
This is based on the work done to add strtoll and the other strto
functions. The atoi functions also were added to stdc and
entrypoints.txt.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D108330
Updates the internal string conversion function so that it
uses the new Limits.h added in a previous commit for max and min values,
and has a templated type. This makes implementing the other strto*
functions very simple.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D107999
This change adds the stroll function, but most of the implementation is
in the new file str_conv_utils.h since many of the other integer
conversion functions are implemented through what are effectively calls
to strtoll.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D107792
Add strncmp as a function to strings.h. Also adds unit tests, and adds
strncmp as an entrypoint for all current platforms.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106901
Use expm1f(x) = exp(x) - 1 for |x| > ln(2).
For |x| <= ln(2), divide it into 3 subintervals: [-ln2, -1/8], [-1/8, 1/8], [1/8, ln2]
and use a degree-6 polynomial approximation generated by Sollya's fpminmax for each interval.
Errors < 1.5 ULPs when we use fma to evaluate the polynomials.
Differential Revision: https://reviews.llvm.org/D101134
They require clang-11 or above for building and hence had to be disabled
as the bots did not have clang-11 or higher. Bots have now been upgraded
so we can enable these functions now.
The implementations use the x86_64 FPU instructions. These instructions
are extremely slow compared to a polynomial based software
implementation. Also, their accuracy falls drastically once the input
goes beyond 2PI. To improve both the speed and accuracy, we will be
taking the following approach going forward:
1. As a follow up to this CL, we will implement a range reduction algorithm
which will expand the accuracy to the entire double precision range.
2. After that, we will replace the HW instructions with a polynomial
implementation to improve the run time.
After step 2, the implementations will be accurate, performant and target
architecture independent.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D102384
Current implementation defines LIBC_TARGET_MACHINE with the use of CMAKE_SYSTEM_PROCESSOR.
Unfortunately CMAKE_SYSTEM_PROCESSOR is OS dependent and can produce different results.
An evidence of this is the various matchers used to detect whether the architecture is x86.
This patch normalizes LIBC_TARGET_MACHINE and renames it LIBC_TARGET_ARCHITECTURE.
I've added many architectures but we may want to limit ourselves to x86 and ARM.
Differential Revision: https://reviews.llvm.org/D101524
[libc] Introduce asctime, asctime_r to LLVM libc
asctime and asctime_r share the same common code. They call asctime_internal
a static inline function.
asctime uses snprintf to return the string representation in a buffer.
It uses the following format (26 characters is the buffer size) as per
7.27.3.1 section in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf.
The buf parameter for asctime_r shall point to a buffer of at least 26 bytes.
snprintf(buf, 26, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",...)
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D99686
The version of clang installed on the buildbot workers is not able to
compile them. However, the version of gcc installed is able to compile
them fine. So, this change disables them until we can find a way to
compile them using clang on the buildbot workers.
The current generic implementation of the fmaf function has been moved
to the FPUtil directory. This allows one use the fma operation from
implementations of other math functions like the trignometric functions
without depending on/requiring the fma/fmaf/fmal function targets. If
this pattern ends being convenient, we will switch all generic math
implementations to this pattern.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D100811
gmtime and gmtime_r share the same common code. They call gmtime_internal
a static inline function. Thus added only validation tests for gmtime_r.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D99046
This change doesn't handle TIMEZONE, tm_isdst and leap seconds.
Moved shared code between mktime and gmtime into time_utils.cpp.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D98467
This option will build LLVM libc as a full libc by itself. In this mode,
it is not expected that it will be mixed with other libcs. The
non-full-build mode will be the default LLVM libc build mode. In a future
where LLVM libc is complete enough, the full libc build will be made the
default mode.
Namely, implementations of fegetexceptfflag, fesetexceptflag,
fegetenv, fesetenv, feholdexcept and feupdateenv have been added.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D96935
Namely, these are the functions enabled: rint*, lrint*, llrint*, lround*,
llround*, nearbyint*. They were previously not enabled because they
required rounding mode and FP exception support. Now that rounding mode
and FP exception support is available for Aarch64, they can be enabled.
This change does not try to move the common parts of x86 and aarch64 and
build few abstractions over them. While this is possible, x86 story
needs a bit of cleanup, especially around manipulation of the mxcsr
register. Moreover, on x86 one can raise exceptions without performing
exception raising operations. So, all of this can be done in follow up
patches.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D94947
Use `memcpy` rather than copying bytes one by one, for there might be large
size structs to move.
Reviewed By: gchatelet, sivachandra
Differential Revision: https://reviews.llvm.org/D93195
A differential fuzzer for these functions has also been added.
Along the way, a small correction has been done to the normal/subnormal
limits of x86 long double values.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D94109
The implementation is exactly the same as rint* as even rint does not
raise any floating point exceptions currently. [Note that the standards
do not specify that floating point exceptions must be raised - they
leave it up to the implementation to choose to raise FE_INEXACT when
rounding non-integral values.]
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D94112
Michael Jones