[libc] Change rand implementation so all tests pass in both 32- and 64-bit systems (#98692)

This patch makes rand select different algorithms depending on the arch.
This is needed to avoid a test f

[libc] Change rand implementation so all tests pass in both 32- and 64-bit systems (#98692)

This patch makes rand select different algorithms depending on the arch.
This is needed to avoid a test failure in 32-bit systems where the LSB
of rand was not uniform enough when the 64-bit constants are used in
32-bit systems.

show more ...

[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98597)

This is a part of #97655.

Revert "[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration" (#98593)

Reverts llvm/llvm-project#98075

bots are broken

[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98075)

This is a part of #97655.

[libc] Remove atomic alignment diagnostics globally (#96803)

Summary:
These warnings mean that it will lower to a libcall. Previously we just
disabled it locally, which didn't work with GCC. This pa

[libc] Remove atomic alignment diagnostics globally (#96803)

Summary:
These warnings mean that it will lower to a libcall. Previously we just
disabled it locally, which didn't work with GCC. This patch does it
globally in the compiler options if the compiler is clang.

show more ...

[libc] Fix Fuscia builder failing on atomic warnings (#96791)

Summary:
This function uses atomics now, which emit warnings on some platforms
that don't support full lock-free atomics. These aren't s

[libc] Fix Fuscia builder failing on atomic warnings (#96791)

Summary:
This function uses atomics now, which emit warnings on some platforms
that don't support full lock-free atomics. These aren't specifically
wrong, and in the future we could investigate a libc configuration
specialized for single-threaded microprocessors, but for now we should
get the bot running again.

show more ...

[libc] Make 'rand()' thread-safe using atomics instead of TLS (#96692)

Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every

[libc] Make 'rand()' thread-safe using atomics instead of TLS (#96692)

Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every target supports TLS, and
even more do not support non-zero initializers on TLS.

The C standard states that the `rand()` function need not be thread,
safe. However, many implementations provide thread-safety anyway.
There's some confusing language in the 'rationale' section of
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html,
but given that `glibc` uses a lock, I think we should make this thread
safe as well. it mentions that threaded behavior is desirable and can be
done in the two ways:

1. A single per-process sequence of pseudo-random numbers that is shared
by all threads that call rand()
2. A different sequence of pseudo-random numbers for each thread that
calls rand()

The current implementation is (2.) and this patch moves it to (1.). This
is beneficial for the GPU case and more generic support. The downside is
that it's slightly slower to do these atomic operations, the fast path
will be two atomic reads and an atomic write.

show more ...

[libc] Partially implement 'rand' for the GPU (#66167)

Summary:
This patch partially implements the `rand` function on the GPU. This is
partial because the GPU currently doesn't support thread local

[libc] Partially implement 'rand' for the GPU (#66167)

Summary:
This patch partially implements the `rand` function on the GPU. This is
partial because the GPU currently doesn't support thread local storage
or static initializers. To implement this on the GPU. I use 1/8th of the
local / shared memory quota to treak the shared memory as thread local
storage. This is done by simply allocating enough storage for each
thread in the block and indexing into this based off of the thread id.
The downside to this is that it does not initialize `srand` correctly to
be `1` as the standard says, it is also wasteful. In the future we
should figure out a way to support TLS on the GPU so that this can be
completely common and less resource intensive.

show more ...

[libc] Mass replace enclosing namespace (#67032)

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

[libc] Improve the implementation of the rand() function (#66131)

Summary:
This patch improves the implementation of the standard `rand()` function
by implementing it in terms of the xorshift64star

[libc] Improve the implementation of the rand() function (#66131)

Summary:
This patch improves the implementation of the standard `rand()` function
by implementing it in terms of the xorshift64star pRNG as described in
https://en.wikipedia.org/wiki/Xorshift#xorshift*. This is a good,
general purpose random number generator that is sufficient for most
applications that do not require an extremely long period. This patch
also correctly initializes the seed to be `1` as described by the
standard. We also increase the `RAND_MAX` value to be `INT_MAX` as the
standard only specifies that it can be larger than 32768.

show more ...

[libc] implement basic rand and srand

This provides the reference implementation of rand and srand. In future
this will likely be upgraded to something that supports full ints.

Reviewed By: sivacha

[libc] implement basic rand and srand

This provides the reference implementation of rand and srand. In future
this will likely be upgraded to something that supports full ints.

Reviewed By: sivachandra

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

show more ...