I'm not sure how libc should be configuring this in bazel, but for now
it seems like `LIBC_THREAD_MODE_PLATFORM` restores the default behavior.
Defining this param is required:
```
ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/c9d34ded3a9d94cc250207948aceadfc/external/llvm-project/libc/BUILD.bazel:5788:14: Compiling libc/src/stdio/generic/vprintf.cpp failed: (Exit 1): clang failed: error executing CppCompile command (from target @@llvm-project//libc:vprintf) /usr/lib/llvm-18/bin/clang -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer ... (remaining 31 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from external/llvm-project/libc/src/stdio/generic/vprintf.cpp:11:
In file included from external/llvm-project/libc/src/__support/File/file.h:19:
external/llvm-project/libc/src/__support/threads/mutex.h:25:2: error: LIBC_THREAD_MODE is undefined
25 | #error LIBC_THREAD_MODE is undefined
| ^
```
As an alternative to this PR, we could make the libc header default to
`LIBC_THREAD_MODE_PLATFORM` if not provided, instead of an `#error`
Reverts llvm/llvm-project#151125
Broke the gcc-7 build:
include/mlir/Target/LLVMIR/ModuleTranslation.h:318:34: error: no type
named 'CallBase' in namespace 'llvm'
llvm::CallBase *call,
~~~~~~^
…… (#151099)
This reverts commit 2780b8f22058b35a8e70045858b87a1966df8df3 to reland
59013d44058ef423a117f95092150e16e16fdb09.
In addition to the original commit this one includes:
- This includes a bazel fix
- Use `let methods` instead of `list<InterfaceMethod> methods`
The original commit message was:
This patch extends the LLVM dialect's intrinsic infra to support
argument and result attributes. Initial support is added for the memory
intrinsics llvm.intr.memcpy, llvm.intr.memmove, and llvm.intr.memset.
Additionally, an ArgAndResultAttrsOpInterface is factored out of
CallOpInterface and CallableOpInterface, enabling operations to have
argument and result attributes without requiring them to be a call or a
callable operation.
We already use cc rules from `@rules_cc//cc:defs.bzl` in a few files,
but this uses it everywhere. Done automatically by running `buildifier
--lint=fix
--warnings=native-cc-binary,native-cc-library,native-cc-test,load` over
all the files. I also ran `buildifier` once more to ensure there wasn't
any missing formatting, so that caused a few unrelated diffs.
This adds two dependencies that I wanted to be part of #151090 but
forgot to add them before the last push, which related to `wcschr.cpp`
and were originally broken by #150661.
Signed-off-by: Ingo Müller <ingomueller@google.com>
This was broken by #150661, which added includes to `wcspbrk.cpp` and
`wcschr.cpp` that weren't in the dependencies of the corresponding
targets.
Signed-off-by: Ingo Müller <ingomueller@google.com>
This relands PRs #143108 and #144538.
The original PR was reverted due to a mistake that made all the mlir
tests run only if SPIRV target was enabled. This is now resolved since
enabling spirv-tools does not required SPIRV target any longer.
spirv-tools are not required by default to run SPIRV mlir tests, but
they can be optionally enabled in some SPIRV mlir test to verify that
the produced SPIRV assembly pass validation.
The other reverted PR #144685 is not longer needed and not part of this
relanding.
Original commit message:
> At the MLIR level unsigned integer and signless integers are different
types. Indeed when looking up the two types in type definition cache
they do not match.
> Hence when translating a SPIR-V module which contains both usign and
signless integers will contain the same type declaration twice
(something like OpTypeInt 32 0) which is not permitted in SPIR-V and
such generated modules fail validation.
> This patch solves the problem by mapping unisgned integer types to
singless integer types before looking up in the type definition cache.
---------
Signed-off-by: Davide Grohmann <davide.grohmann@arm.com>
This PR adds the `#cmakedefine LLVM_ENABLE_PROFCHECK` in
`llvm-config.h.cmake` introduced in #147418 to the copy of that file in
the bazel overlay directory such that that define is also avalable in
the bazel build. Not having the define broke the bazel build.
Signed-off-by: Ingo Müller <ingomueller@google.com>
This target was marked as Linux-only in
51a4ab287f43c129dd531867be880480a85ecb1e to make "bazel build
@llvm-project//libc/..." clean (which it still is).
There's nothing Linux-specific about this header library, we just use
"target_incompatible_with" clause here to ensure that all libc functions
for float128 types won't be built on Mac, in lieu of a better exclusion
mechanism in Bazel.
However, since llvm_libc_types_float128 is now a transitive dependency
of ":libcxx_shared_headers" used for hand-in-hand code sharing with
libc++, we may need to build this target even on platforms that don't
have float128.
Fow now, mark this target Windows-compatible to unlock the downstream
Windows Bazel build of ":libcxx_shared_headers".
See https://bazel.build/docs/bazel-and-cpp#toolchain-features for why
this feature is recommended for C++ projects.
215dbcb2bc5c1b1bc8775db2a7c22f67f3949fd7 added the necessary default
Bazel flag to make this feature functional. It can be enabled on a
per-project basis. Do this now for llvm-libc.
After enabling this feature, Blaze tries to parse headers from all
header-only libraries, even if the headers are not explicitly used in
tests, which allows to detect the issues early on.
Fix a couple of -Wunused-function warnings by marking the static
functions as constexpr or inline.
LIBC_HAS_SANITIZER (which is defined if ASan, MSan, or UBSan is enabled)
is currently used to implicitly disable null checks, normally enabled
via LIBC_ADD_NULL_CHECKS config value. Remove this condition, and rely
purely on the config value instead:
* LIBC_HAS_SANITIZER will be true even for UBSan modes which doesn't
rely on null checks at all (e.g. -fsanitize=alignment)
* null checks today (implemented via __builtin_trap) should function
normally today even when sanitizer is enabled - trap is still a trap
* tests have been migrated to WITH_SIGNAL(-1) which doesn't prescript a
particular signal / exit-code, and thus should pass even if sanitizers
override the default ones.
Mostly just adding tests that are in clang/unittests/CMakeLists.txt, but
there a couple other cleanups here:
* Add `directory_watcher` targets in clang so we can add tests for it
* Add some library targets (e.g. `dataflow_testing_support`) for
downstream use (e.g. unit tests outside of LLVM that use these headers
in tests)
* Remove `rename_tests_tooling_hdrs` which has been unused since
`rename_tests` itself was deleted
The InterpreterTest target added here passes on our internal CI, but
fails when I run it w/ bazel for some reason:
```
[ RUN ] InterpreterTest.InstantiateTemplate
JIT session error: Symbols not found: [ __clang_Interpreter_SetValueWithAlloc, _ZnwmPv26__clang_Interpreter_NewTag ]
Failure value returned from cantFail wrapped call
Failed to materialize symbols: { (main, { __orc_init_func.incr_module_133, $.incr_module_133.__inits.0 }) }
```
I'd like to figure out what's going on, but for now I just excluded it
w/ a test filter
This is a reapply of patch #149851. The reapply also fixes a CMake/Bazel
build issue, which was the reason of the revert. (Thanks @rupprecht )
Original patch (#149851) message:
-----
This PR adds a new optimization pass to fold
`memref.subview/expand_shape/collapse_shape` ops into consumer
`amdgpu.gather_to_lds` operations.
* Implements a new pass `AmdgpuFoldMemRefOpsPass` with pattern
`FoldMemRefOpsIntoGatherToLDSOp`
* Adds corresponding folding tests
