PR #101009 exposed a semantic check issue with OPTIONAL dummy
arguments.
Another issue occurred when using %{re,im,len,kind}, as these also
need to be skipped when handling variables with implicitly defined
DSAs.
These issues were found by Fujitsu testsuite.
I assume the intent of the initial `*/*.py` was to also collect things
in `*.py`, but that's not what bazel does unless you use `**/*.py` which
is what we're doing now. A few of these tests fail so I explicitly
disabled them until someone has time to debug.
This PR fixes a potential race condition in
https://github.com/llvm/llvm-project/pull/90930.
This race can happen because the original code set `m_info->m_isAlive =
true` **after** the timer thread is created. So if there is a context
switch happens and timer thread checks `m_info->m_isAlive` before main
thread got a chance to run `m_info->m_isAlive = true`, the timer thread
may treat `ThreadPlanSingleThreadTimeout` as not alive and simply exit
resulting in async interrupt never being sent to resume all threads
(deadlock).
The PR fixes the race by initializing all states **before** worker timer
thread creates.
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Implement handling for `-m(no-)v8plus` flags to allow the user to switch
between V8 and V8+ mode with 32-bit code.
Currently it only toggles the V8+ feature bit, ABI and codegen changes
will be done in future patches.
This patch adds support for pause resource with a new enumerator
omp_pause_stop_tool. The expected behavior of this enumerator is
* omp_pause_resource: not allowed
* omp_pause_resource_all: equivalent to omp_pause_hard
We were missing the signed flag on the negative value, so the
range was incorrectly interpreted for integers larger than 64-bit.
Split out from https://github.com/llvm/llvm-project/pull/80309.
This reverts commit 5ae9faa538d100ab38f6f4f99c924de0e4270272.
RelocationResolver is only supposed to handle static relocation types.
Introducing GLOB_DAT could negatively impact other RelocationResolver
users who solely handle static relocations and want to report errors for
dynamic relocations.
If GLOB_DAT is the sole required relocation, explicitly checking for it
in the caller would be more reliable. Additionally, the caller should
handle GLOB_DAT on other architectures.
Previously, the type of explicit object parameters was not considered
for relational operators. This was defined by CWG2586,
<https://cplusplus.github.io/CWG/issues/2586.html>. This fix also means
CWG2547 <https://cplusplus.github.io/CWG/issues/2547.html> is now fully
implemented. Fixes#100329, fixes#104413.
Now start rejecting invalid rvalue reference parameters, which weren't
checked for, and start accepting non-reference explicit object
parameters (like `bool operator==(this C, C) = default;`) which were
previously rejected for the object param not being a reference.
Also start rejecting non-reference explicit object parameters for
defaulted copy/move assign operators (`A& operator=(this A, const A&) =
default;` is invalid but was previously accepted). Fixes#104414.
The minbitwidth restrictions can be skipped only for immediate reduced
values, for other nodes still need to check if external users allow
bitwidth reduction.
Fixes https://github.com/llvm/llvm-project/issues/104422
Without this patch compiler-rt ubsan library has a bug displaying
incorrect values for variables of the _BitInt (previously called
_ExtInt) type. This patch affects affects both: generation of metadata
inside code generator and runtime part. The runtime part provided only
for i386 and x86_64 runtimes. Other runtimes should be updated to take
full benefit of this patch.
The patch is constructed the way to be backward compatible and int and
float type runtime diagnostics should be unaffected for not yet updated
runtimes.
This patch fixes issue
https://github.com/llvm/llvm-project/issues/64100.
Co-authored-by: Eänolituri Lómitaurë <vladislav.aranov@ericsson.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: Paul Kirth <paulkirth@google.com>
Fix profile/darwin-proof-of-concept.c on AppleSilicon Mac where there is
a different page alignment. The previous fix to drop alignment is
actually breaking the tests on Apple Silicon Mac. Revert to the original
section alignment and requires an ARM64 target for this test to run.
Walks over the MCExpr and uses KnownBits to deduce whether an expression
is known and if so, prints said known value. Should support the most
common MCExpr cases for AMDGPU metadata.
Continues the work for disabling fixed-point iteration in the Combiner
(#94291).
This introduces improved Observer-based heuristics in the
GISel Combiner to retry combining defs/uses of modified instructions and
for performing sparse dead code elimination.
I have experimented a lot with the heuristics and this seems to be the
minimal set of heuristics that allows disabling fixed-point iteration
for AArch64 CTMark O2 without regressions.
Enabling this globally would pass all regression tests for all official
targets (apart from small benign diffs), but I have made this fully
opt-in for now, because I can't quantify the impact for other targets.
This should mostly be on-par with how the WorkList-aware functions
in the InstCombiner and DAGCombiner handle rescheduling instructions
for recombining.
For performance numbers see my follow-up patch for AArch64 (#102167)
Pull Request: https://github.com/llvm/llvm-project/pull/102163
Summary:
The `aligned_alloc` function is the C11 replacement for
`posix_memalign`. We should favor the C standard over the POSIX standard
so more C library implementations can run the tests.
The only change vs. the first version of the patch is that I've made
DWARFUnit linking thread-safe/unit. This was necessary because, during
the
indexing step, two skeleton units could attempt to associate themselves
with the split unit.
The original commit message was:
I ran into this when LTO completely emptied two compile units, so they
ended up with the same hash (see #100375). Although, ideally, the
compiler would try to ensure we don't end up with a hash collision even
in this case, guaranteeing their absence is practically impossible. This
patch ensures this situation does not bring down lldb.
lldb-dap already supports a log file which can be enabled by setting the
`LLDBDAP_LOG` environment variable. With this commit, the log location
can be set directly through the VS-Code extension settings.
Also, this commit bumps the version number, such that the new VS Code
extension gets published to the Marketplace.
Corrupted live interval information can cause window scheduling to crash
in some cases. By adding the missing MBB's live interval information in the
ModuloScheduleExpander, the information can be correctly analyzed in
the window scheduler.
A case for this transformation, https://gcc.godbolt.org/z/nhYcWq1WE
Fold
mov w8, #56952
movk w8, #15, lsl #16
ldrb w0, [x0, x8]
into
add x0, x0, 1036288
ldrb w0, [x0, 3704]
Only LDRBBroX is supported for the first time.
Fix https://github.com/llvm/llvm-project/issues/71917
Note: This PR is try relanding the commit 32878c2065 with fix crash for PR79756
this crash is exposes when there is MOVKWi instruction in the head of a block,
but without MOVZWi
This adds an implementation of AArch64InstrInfo::verifyInstruction for
AArch64, and adds some basic verification of the range of immediate
ranges of memory operations using the information from getMemOpInfo.
Some extra memory operations have been added to getMemOpInfo, along with
the equivalent opcodes to getLoadStoreImmIdx to ensure we use the
correct index.
Please let us know if this starts reporting verification failures, Thanks.
It cause builds to start failing with
Invalid type expected
UNREACHABLE executed at clang/lib/AST/MicrosoftMangle.cpp:2551!
see comments on the PR.
> Partial fix for https://github.com/llvm/llvm-project/issues/92204.
> This PR just fixes VS2019+ since that is the suite of compilers that I
> require link compatibility with at the moment.
> I still intend to fix VS2017 and to update llvm-undname in future PRs.
> Once those are also finished and merged I'll close out
> https://github.com/llvm/llvm-project/issues/92204.
> I am hoping to get the llvm-undname PR up in a couple of weeks to be
> able to demangle the VS2019+ name mangling.
>
> MSVC 1920+ mangles placeholder return types for non-templated functions
> with "@".
> For example `auto foo() { return 0; }` is mangled as `?foo@@YA@XZ`.
>
> MSVC 1920+ mangles placeholder return types for templated functions as
> the qualifiers of the AutoType followed by "_P" for `auto` and "_T" for
> `decltype(auto)`.
> For example `template<class T> auto foo() { return 0; }` is mangled as
> `??$foo@H@@YA?A_PXZ` when `foo` is instantiated as follows `foo<int>()`.
>
> Lambdas with placeholder return types are still mangled with clang's
> custom mangling since MSVC lambda mangling hasn't been deciphered yet.
> Similarly any pointers in the return type with an address space are
> mangled with clang's custom mangling since that is a clang extension.
>
> We cannot augment `mangleType` to support this mangling scheme as the
> mangling schemes for variables and functions differ.
> auto variables are encoded with the fully deduced type where auto return
> types are not.
> The following two functions with a static variable are mangled the same
> ```
> template<class T>
> int test()
> {
> static int i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
> return i;
> }
>
> template<class T>
> int test()
> {
> static auto i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
> return i;
> }
> ```
> Inside `mangleType` once we get to mangling the `AutoType` we have no
> context if we are from a variable encoding or some other encoding.
> Therefore it was easier to handle any special casing for `AutoType`
> return types with a separate function instead of using the `mangleType`
> infrastructure.
This reverts commit e0d173d44161bf9b68243845666d58999e74f759
and the wollow-up fa343be414f9364911b947f109f3df5539e23068.
