Add verification that VPHeaderPHIRecipes are only in header VPBBs. Also
adds missing checks for VPPointerInductionRecipe to
VPHeaderPHIRecipe::classof.
Split off from D119661.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D131989
Fixed a false positive where a lambda expression in the condition which contained an assignement would trigger a warning.
Fixes#56729
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D132786
Otherwise when we visit all libcalls in
updateCGAndAnalysisManagerForPass(), the old libcall is dead and doesn't
have a node.
We treat libcalls conservatively in LazyCallGraph because any function
may introduce calls to them out of thin air.
It is weird to change the signature of a libcall since introducing calls
to the libcall with a different signature may break, but other passes
like deadargelim already do it, so let's preserve this behavior for now.
Fixes an issue found in D128830.
Reviewed By: psamolysov
Differential Revision: https://reviews.llvm.org/D132764
This patch replaces getLCMSize with std::lcm, a C++17 feature.
Note that all the arguments are of unsigned with no implicit type
conversion as they are passed to getLCMSize.
This patch replaces mlir::lcm with std::lcm, a C++17 feature.
Note that all the arguments to mlir::lcm are of int64_t with no
implicit type conversion as they are passed to mlir::lcm, which I've
verified by modifying mlir::lcm as:
template <typename TA, typename TB>
inline int64_t lcm(TA a, TB b) {
static_assert(std::is_same_v<TA, int64_t>);
static_assert(std::is_same_v<TB, int64_t>);
:
This patch replaces clamp idioms with std::clamp where the range is
obviously valid from the source code (that is, low <= high) to avoid
introducing undefined behavior.
SAVE statements referencing COMMON block names are not allowed in BLOCK
constructs. If they occur, an error is correctly emitted, but then flang
gets confused by the illegal SAVE and produces a faulty warning. This
patch removes that warning.
Consider this piece of Fortran (from the test blockconstruct02.f90):
program main
real r, s, t
common /argmnt2/ r, s, t
block
save /argmnt2/
end block
end program
Here flang (in addition to the error about the illegal SAVE) emits a
portability warning saying that the two definitions of argmnt2 have
different size, which does not make much sense.
This patch is a prerequisite for D125804, which in turn will make
blockconstruct02.f90 test this patch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D132403
If the shift constant has undefined lanes, we can assume those
are the same as the defined lanes in these transforms:
https://alive2.llvm.org/ce/z/t6TTJ2
Replace undef with poison in the test while here to support
the transition away from undef.
If we run into a first usage or definition of a mangled name, and
there's a DeferredDecl that associated with it, we should remember it we
need to emit it later on.
Without this patch, clang-repl hits a JIT symbol not found error:
clang-repl> extern "C" int printf(const char *, ...);
clang-repl> auto l1 = []() { printf("ONE\n"); return 42; };
clang-repl> auto l2 = []() { printf("TWO\n"); return 17; };
clang-repl> auto r1 = l1();
ONE
clang-repl> auto r2 = l2();
TWO
clang-repl> auto r3 = l2();
JIT session error: Symbols not found: [ l2 ]
error: Failed to materialize symbols: { (main,
{ r3, orc_init_func.incr_module_5, $.incr_module_5.inits.0 }) }
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D130831
Changes the CI to use the Clang 16 nightly builds instead of Clang 14.
(The libc++15 branch was accidentally build using Clang 14 instead of
Clang 15; hence the skipping of a number.)
Also adds a Clang 15 build to the test matrix.
Based on the private discussion with @ldionne we decided to move
the configuration parameters from the `run-buildbot` script to the
CI configuration `buildkite-pipeline.yml`. Other hard-coded values
from the Dockerfile should be move to the CI configuration too. That
will be done in another commit.
C++17 will use Clang-15 since D131479 causes a test to fail.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131174
This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant
that on arm64, we were unnecessarily preserving FDEs if we e.g. had
multiple weak definitions for a function. Worse, we would actually
produce an invalid `__eh_frame` section in that case, because the CIE
associated with the unnecessary FDE would still get dead-stripped and
we'd end up with a dangling FDE. We set up associations from functions
to their FDEs, so dead-stripping will just work naturally, and we can
clear S_ATTR_LIVE_SUPPORT from our input `__eh_frame` sections to fix
dead-stripping.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D132489
I noticed that `test/asan/Unit/lit.site.cfg.py.in` contains two typos,
using the FreeBSD forms of the `LD_*LIBRARY_PATH*` variables on Solaris.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D132736
MapperJITLinkMemoryManager has slab allocation. Combined with
InProcessMapper, it can replace InProcessMemoryManager.
It can also replace JITLinkSlabAllocator through the InProcessDeltaMapper
that adds an offset to the executor addresses for use in tests.
Differential Revision: https://reviews.llvm.org/D132315
SharedMemoryMapper assumed each reservation will have its corresponding
allocations starting from the beginning. However with the introduction
of the slab allocator, there can be a possible offset from the start
from where the initialization is being performed.
This commit also simplifies the logic for finding the parent reservation
and makes the assert messages consistent.
The command to detect whether the stash is needed is `git status --porcelain`
which includes untracked files by default. We want to stash untracked files
as well as they may affect compilation (LLVM CMake checks that all source files
should be included in CMakeLists).
Update the stash command to include untracked files as well.
Reviewed By: #bolt, rafauler
Differential Revision: https://reviews.llvm.org/D132610
This commit adds a new page to the LLDB HTML documentation for the LLDB
fuzzers. The page primarily explains what the fuzzers are as well as how
to build them, run them and investigate and reproduce bugs.
Differential revision: https://reviews.llvm.org/D132148
Fixes this test compile error:
```
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:54:7: error: no matching function for call to '__tsan_get_alloc_stack'
__tsan_get_alloc_stack(mem, trace, num_frames, &thread_id, &thread_os_id);
^~~~~~~~~~~~~~~~~~~~~~
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:17:16: note: candidate function not viable: no known conversion from 'uint64_t **' (aka 'unsigned long long **') to 'uint64_t *' (aka 'unsigned long long *') for 5th argument; remove &
extern "C" int __tsan_get_alloc_stack(void *addr, void **trace, size_t size,
^
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:61:46: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t *' (aka 'unsigned long long *') [-Wformat]
fprintf(stderr, "thread os id = 0x%llx\n", thread_os_id);
~~~~ ^~~~~~~~~~~~
1 warning and 1 error generated.
```
The wrap/unwrap operations are applied to pointers after/before conversion to/from
raw addresses. They can be used to tag, untag, sign, or strip signing from
pointers. They currently default to 'rawPtr' (identity) on all platforms, but it
is expected that the default will be set based on the host architecture, e.g.
they would default to signing/stripping for arm64e.
This is the ORC runtime counterpart to f14cb494a34:
If constant shadown enabled we had false reports because
!isZeroValue() does not guaranty that the values is actually not zero.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D132761
Xcode 13's clang has them. For the included testcase, Xcode's clang
behaves like the implementation in this patch.
Availability.h in the macOS 12.0 SDK (part of Xcode 13, and the current
stable version of the macOS SDK) does something like:
#if defined(__has_builtin)
...
#if __has_builtin(__is_target_os)
#if __has_builtin(__is_target_environment)
#if __has_builtin(__is_target_variant_os)
#if __has_builtin(__is_target_variant_environment)
#if (... && ((__is_target_os(ios) && __is_target_environment(macabi)) || (__is_target_variant_os(ios) && __is_target_variant_environment(macabi))))
#define __OSX_AVAILABLE_STARTING(_osx, _ios) ...
#define __OSX_AVAILABLE_BUT_DEPRECATED(_osxIntro, _osxDep, _iosIntro, _iosDep) ...
#define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(_osxIntro, _osxDep, _iosIntro, _iosDep, _msg) ...
So if __has_builtin(__is_target_variant_os) or
__has_builtin(__is_target_variant_environment) are false, these defines are not
defined.
Most of the time, this doesn't matter. But open-source clang currently fails
to commpile a file containing only `#include <Security/cssmtype.h>` when
building for catalyst by adding a `-target arm64-apple-ios13.1-macabi` triple,
due to those __OSX_AVAILABLE macros not being set correctly.
If a potential future SDK version were to include cssmtype.h transitively
from a common header such as `<Foundation/Foundation.h>`, then it would become
close to impossible to build Catalyst binaries with open-source clang.
To fix this for normal catalyst builds, it's only necessary that
__has_builtin() evaluates to true for these two built-ins -- the implementation
of them doesn't matter. But as a courtesy, a correct (at least on the test
cases I tried) implementation is provided. (This should also help people who
try to build zippered code, where having the correct implementation does
matter.)
Differential Revision: https://reviews.llvm.org/D132754
Reapplies f14cb494a3 (which was reverted in 2f08f8426c) with a fix for UB in
the ExecutorAddr::Unwrap::Unwrap constructor (which caused failures on some
bots).
owenca