This is the first step in preparation for: https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450
This has been added in 0071a79532e8d664b734956a431d8c8c942cc25e to support TLS destructors. Return value of __cxa_thread_atexit is supposed to be the same as std::atexit - zero on success, non-zero on failure. Update the code to do just that (also be consistent with llvm-libc's existing atexit / at_quick_exit implementations).
Fixes #118231
- Updated the method name to `has_active_owner` in
`llvm-project/libc/src/__support/threads/linux/rwlock.h`
- Verified usage and updated all references to the method.
- Ran tests:
- `check-llvm-unit`
- `check-all`
- migrate more `-O3` to `${libc_opt_high_flag}`
- workaround a issue with `LLP64` in test. The overflow testing is
guarded by a constexpr but the literal overflow itself will still
trigger warnings.
Notice that for math smoke test, for some reasons, the
`${libc_opt_high_flag}` will be passed into `lld-link` which confuses
the linker so there are still some warnings leftover there. I can
investigate more when I have time.
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.
This PR: - add entrypoints for `pthread_spin_*` - additionally, the fixes a typo that has been disabling lock related tests
The codegen for non-inlined version is "quite ugly" as it emits some checks to make sure the initialization routine is properly executed because the compiler does not see how the TLS object is initialized. This leads to some `callq 0x0` junk in the final outputs. For codegen details, see https://godbolt.org/z/rb5qYj3vY.