Summary:
The standard says the following: The <time.h> header shall define the
clock_t, size_t, time_t, types as described in <sys/types.h>. I couldn't
find one for `uchar.h` but it needs it once we define things like
`mbrtoc8`.
Summary:
If the implementation supports floating-point infinities, the macro
INFINITY expands to constant expression of type float which evaluates to
positive or unsigned infinity.
Currently this is a double, this makes it a float.
This is based on @izaakschroeder previous patch but I only select macro
definitions for now. We need these definitions for VDSO work, which has
been delayed for a very long time.
Co-authored-by: Izaak Schroeder <izaak.schroeder@gmail.com>
Summary:
According to the C++ standard, The main function shall not be declared
with a linkage-specification. after some changes in
https://github.com/llvm/llvm-project/pull/101853 this started emitting
warnings when building / testing the C library. This source file is
shared with the overlay tests as well as the full build tests. The full
build tests are compiled with `-ffreestanding`, as are all the startup /
integration files. The standard says freestanding environment are all
implementation defined, so this is valid in those cases. This patch
simply prevents adding the linkage when we are compiling unit tests,
which are hosted. This is a continuation on
https://github.com/llvm/llvm-project/pull/102825.
Summary:
Simply copies the x64 versions to the GPU directory. Ignoring f128 for
now, but adding long double entrypoints which are identical to `double`
on the target.
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.
Sin/cos/tan fuzzers were having issues with ONE_TWENTY_EIGHT_OVER_PI, so
the LIBC_TARGET_CPU_HAS_FMA ifdef statement got moved from the
sin/cos/tan .cpp files to the range_reduction_double_common.cpp file.
The previous patch removing the fenv requirement for str to float had an
error that got missed due to a lack of tests. This patch fixes the issue
and adds tests, as well as updating the existing tests.
The previous change replaced INT_WIDTH with
cpp::numberic_limits<int>::digits, but these don't have the same
value. While INT_WIDTH == UINT_WIDTH, not so for ::digits, so
use cpp::numberic_limits<unsigned int>::digits et al instead for
the intended effects.
Bug: https://issues.fuchsia.dev/358196552
This updates some code to consistently use cpp::numeric_limits,
the src/__support polyfill for std::numeric_limits, rather than
the C <limits.h> macros. This is in keeping with the general
C++-oriented style in libc code, and also sidesteps issues about
the new C23 *_WIDTH macros that the compiler-provided header does
not define outside C23 mode.
Bug: https://issues.fuchsia.dev/358196552
The str_to_float conversion code doesn't need the features provided by
fenv and the dependency is creating a blocker for hand-in-hand. This
patch uses a workaround to remove this dependency.
Previously, `AmdgpuSinTwoPow_128` and others were too large for their
table cells. This PR shortens the name to `AmdSin...`
There were also some `-` missing in the separator. This PR instead
creates the separator string using the length of the headers.
This PR implements
2a158426d4
to provide better throughput benchmarking for libc `sin()` and
`__nv_sin()`.
These changes have not been tested on AMDGPU yet, only compiled.
The 32-bit Arm builds of libc define time_t to be `__INTPTR_TYPE__`,
i.e. a 32-bit integer. This is commented in the commit introducing it
(75398f28ebdb600) as being for compatibility with glibc. But in the near
future not even every AArch32 build of glibc will have a 32-bit time_t:
Debian is planning that their next release (trixie) will have switched
to 64-bit. And non-Linux builds of this libc (e.g. baremetal) have no
reason to need glibc compatibility in the first place – and every reason
_not_ to want to start using a 32-bit time_t in 2024 or later.
So I've replaced the `#ifdef` in `llvm-libc-types/time_t.h` with two
versions of the header file, chosen in `CMakeLists.txt` via a new
configuration option. This involved adding an extra parameter to the
cmake `add_header` function to specify different names for the header
file in the source and destination directories.
Summary:
This patch implements 'getenv'. I was torn on how to implement this,
since realistically we only have access to this environment pointer in
the "loader" interface. An alternative would be to use an RPC call every
time, but I think that's overkill for what this will be used for. A
better solution is just to emit a common `DataEnvironment` that contains
all of the host visible resources to initialize. Right now this is the
`env_ptr`, `clock_freq`, and `rpc_client`.
I did this by making the `app.h` interface that Linux uses more general,
could possibly move that into a separate patch, but I figured it's
easier to see with the usage.
Summary:
This is supposed to define the maximum bytes required to store a char in
any locale. There's some question about what this should be set to. I
believe because the proposed solution for `locale.h` is to only support
the default locale, we should do what `musl` does and set it to `4`
which covers up to UTF-32.
Fixes https://github.com/llvm/llvm-project/issues/79358
The `<time.h>` functions `asctime`, `gmtime`, `mktime` and their `_r`
variants are purely computational functions which convert between well
defined time representations and/or strings. There's no reason these
shouldn't be available in bare-metal builds of the library as well as
hosted ones: even if the library has no way to find out the time in
POSIX format, it might still see POSIX-style `time_t` values in input
data (e.g. network protocols) and need to interpret them.
The only obstacle to this was that the `out_of_range()` helper function
set `errno` to `EOVERFLOW`, which fails in a bare-metal build because
the extra POSIX error values aren't defined, including `EOVERFLOW`. So
I've made that assignment conditional on `EOVERFLOW` being defined.
Fixes#85556.
