After 3801bf6164f570a145e3ebd20cf9114782ae0329, SPIRVAnalysis needs to
include SPIRV.h provided by SPIRVCodegen, but the CodeGen target already
depends on Analysis, so that would cause a circular dependency.
Analysis is a subdirectory of CodeGen so it makes sense as a part of the
main CodeGen target too.
Fix two instances of libcxx_shared_headers depending on .cpp files (in
Bazel build):
* Don't depend on exit syscall in LIBC_ASSERT implementation. This
dependency is not used, since LIBC_ASSERT always uses system <assert.h>
in the overlay mode, which is the only mode supported by Bazel.
* Don't depend on libc_errno in str-to-float and str-to-integer
conversions. We only need the ERANGE value, which can be obtained from
the proxy header instead.
MacOS platforms using mlir-runner in lit tests consistently hit the
following error:
```
# .---command stderr------------
# | JIT session error: Symbols not found: [ __mlir_ciface_printMemrefI32 ]
# | Error: Failed to materialize symbols: { (main, { __mlir_printMemrefI32, ... }) }
# `-----------------------------
```
https://github.com/google/heir/issues/1521#issuecomment-2751303404
confirms the issue is fixed by using `alwayslink` on these two targets,
and I confirmed on a separate Apple M1 (OSX version Sequoia 15.3.2.).
I'm not an expert on the mlir runner internals, but given the
mlir-runner is purely for testing, and alwayslink at worst adds some
overhead by not removing symbols, it seems low risk.
Create a proper way to build header-only libraries for llvm-libc code
sharing. Use it to group headers that can be shared with libcxx for
std::from_chars() implementation.
It mostly works, though the macro needs to be updated to enforce that no
.cpp files are listed in dependencies (it's not the case now) - see PR
#133126.
All downstream users are migrated, so we no longer need to produce
"public"/"release" cc_library target for each libc_function macro
invocation. Instead, we only create internal target (for testing), and
some filegroups, which will be picked up by the libc_release_library
invocation.
This allows us to get rid of "weak" argument to libc_function - this
decision is also postponed to libc_release_library configuration.
Fixes#130327.
This is similar to PR #132107 but for tests for sys/epoll.h functions.
ErrnoCheckingTest ensures that errno is properly reset at the beginning
of the test case, and is validated at the end of it, so that the manual
code such as the one proposed in PR #131650 would not be necessary.
Also use ErrnoSetterMatcher to verify the function return values and
verify/clear out errno values. Fix the bug in ErrnoSetterMatcher error
reporting machinery to properly convert errno values into errno names to
make error messages easier to debug.
Use ErrnoCheckingTest harness added in
d039af33096c0a83b03475a240d5e281e2271c44 for all unistd tests that
verify errno values. Stop explicitly setting it to zero in test code, as
harness does it.
It also verifies that the errno is zero at the end of each test case, so
update the ASSERT_ERRNO_EQ and ASSERT_ERRNO_FAILURE macro to clear out
its value after the verification (similar to how ErrnoSetterMatcher
does).
Update the CMake and Bazel rules for those tests. In the latter case,
remove commented out tests that are currently unsupported in Bazel,
since they get stale quickly.
Rather than requiring users to pass `-m64` to the `llvm-ml` driver to
get 64-bit behavior, we add the `llvm-ml64` alias, matching the behavior
of `ML.EXE` and `ML64.EXE`.
The original flavor/bitness flags still work, but the alias should make
some workflows easier.
NOTE: The logic for this already existed in the code; we're just finally
adding the build/install instructions to match.
When using parse_headers validation, rpc_server.h fails to build, since
we don't expose any of the RPC deps in the Bazel build.
So at least for now, just exclude it.
See the discussion in PR
https://github.com/llvm/llvm-project/pull/131650 on why we need to clear
the errno at the beginning of some tests, and outlining the various solutions.
Introduce ErrnoCheckingTest base class and use it for unlink_test as an example.
This reverts commit f9146ccbe940d8b8eb15e7686a511a28eb0abc6b
([libc][bazel] explicitly use system-provided errno in Bazel builds.
(#130663))
This change causes problems in Bazel builds where system errno is set to
non-zero before the tests even begin to run - see PR #131650 for the
disucssion on how to address this.
The Windows toolchain needs to build libc targets in order to support
libc++. Currently, some targets fail to resolve, due to non-exhaustive
select statements, not accounting for Windows builds.
This change adds clauses to select statements so that Windows builds can
proceed.
Additionally, `__support_osutil_exit`, is configured to pass nothing to
`srcs` for non-Linux builds. `__support_osutil_exit `is unconditionally
included in the transitive dependencies of `extern_libc_shared`.
---------
Co-authored-by: Brian Ledger <brianpl@google.com>
See PR #130327 for background and motivation. This change expands the
libc_support_library and libc_function rules to create filegroups that
allow building a collection of llvm-libc functions together, from
sources, as a part of a single cc_library that can then be used by the
downstream clients.
This change also adds an example use of this macro under
libc/test/BUILD.bazel to confirm that this macro works as expected.
Addressing the comments from PR #130368 review. Since Bazel builds are
effectively overlay mode, switch to explicitly setting
-DLIBC_ERRNO_MODE=LIBC_ERRNO_MODE_SYSTEM configuration option, so that
unit tests and release builds are consistent. Verified that all the unit
tests pass with this flag specified.
