This was mistakely changed by #109579, which doesn't match with other
EVEX decoding.
(cherry picked from commit 70529b24a30943d46e361d2990268499921e28a2)
Promoted KMOV* was encoded with CD8 incorrectly, see
https://godbolt.org/z/cax513hG1
(cherry picked from commit 0d334d83a4c7ce16fa1bc0e5e56bbdeaf01c2b2d)
Multiple invocations of the pass could interfere with eachother,
preventing some undefs being initialised.
I found it very difficult to create a unit test for this due to it being
dependent on particular allocations of a previous function. However, the
bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the
creation of the illegal instruction `vnsrl.wi v9, v8, 0`
Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.
This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.
Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.
(cherry picked from commit 6f6422f4a2b8647a59936c131e50a79906d89510)
Use i32 for offset instead of i16, this way it does not get interpreted
as negative 16 bit offset.
(cherry picked from commit 83fe85115da9dc25fa270d2ea8140113c8d49670)
Large scratch offset with one on highest bit selected as negative,
negative offset has same binary representation in 16 bits as large
unsigned offset.
(cherry picked from commit e9d12a6b451bd403d95105aa976a011dc821f126)
In ExpandFPLibCall, an assumption is made that all floating point
libcalls that take integer arguments use unsigned integers. In the case
of ldexp and frexp, this assumption is incorrect, leading to
miscompilation and subsequent target-dependent incorrect operation.
Indicate that ldexp and frexp utilize signed arguments in
ExpandFPLibCall.
Fixes#108904
Signed-off-by: Timothy Pearson <tpearson@solidsilicon.com>
(cherry picked from commit 90c14748638f1e10e31173b145fdbb5c4529c922)
Since a26ec542371652e1d774696e90016fd5b0b1c191, we expand the executable
name to an absolute path, if it isn't already one, if found in path.
This broke a couple tests in some environments; when the clang workdir
resides in a path under e.g. /opt. Tests that only use a tool name like
"clang-cl" would get expanded to the absolute path in the build tree.
The loop for finding the last "-o" like option for clang-cl command
lines would inspect all arguments, including Args[0] which is the
executable name itself. As an /opt path matches Arg.starts_with("/o"),
this would get detected as an object file output name in cases where
there was no other explicit output argument.
Thus, this fixes those tests in workdirs under e.g. /opt.
(cherry picked from commit cead9044a995910306e2e64b426fcc8042d7e0ef)
This allows the clang driver to know which tool is meant to be executed,
which allows the clang driver to load the right clang config files, and
allows clang to find colocated sysroots.
This makes sure that doing `clang-scan-deps -- <tool> ...` looks up
things in the same way as if one just would execute `<tool> ...`, when
`<tool>` isn't an absolute or relative path.
(cherry picked from commit a26ec542371652e1d774696e90016fd5b0b1c191)
This fixes building in this configuration after
87e1104cf0e2de0d04bee2944893fa7897277b2f.
(cherry picked from commit aa3465793a250faa5426ac626989375465256658)
This allows clang-scan-deps to work correctly when using cross compilers
with names like <triple>-clang.
(cherry picked from commit 87e1104cf0e2de0d04bee2944893fa7897277b2f)
In the test case, the BECount of the second loop uses %load,
but we only have an LCSSA phi node for %add, so that is what
gets invalidated. Use the forgetLcssaPhiWithNewPredecessor()
API instead, which will invalidate the roots of the expression
instead.
Fixes https://github.com/llvm/llvm-project/issues/109333.
(cherry picked from commit 5bcc82d43388bb0daa122d5fe7ecda5eca27fc16)
If all incoming values of `div.d` are sign-extended and all users only
use the lower 32 bits, then convert them to W versions.
Fixes: #107946
(cherry picked from commit 0f47e3aebdd2a4a938468a272ea4224552dbf176)
After https://github.com/llvm/llvm-project/pull/92205, LoongArch ISel
selects `div.w` for `trunc i64 (sdiv i64 3202030857, (sext i32 X to
i64)) to i32`. It is incorrect since `3202030857` is not a signed 32-bit
constant. It will produce wrong result when `X == 2`:
https://alive2.llvm.org/ce/z/pzfGZZ
This patch adds additional `sexti32` checks to operands of
`PatGprGpr_32`.
Alive2 proof: https://alive2.llvm.org/ce/z/AkH5MpFix#107414.
(cherry picked from commit a111f9119a5ec77c19a514ec09454218f739454f)
Cache negative search result from getStoreMergeCandidates() so that
mergeConsecutiveStores() does not iterate quadratically over a
potentially long sequence of unmergeable stores.
(cherry picked from commit 8f77d37f256809766fd83a09c6d144b785e9165a)
The CI has been a complete mess for the past week, and the only thing
preventing it from being back is the Clang tidy checks. Disable them (as
a total hack) to get CI back.
(cherry picked from commit 78c6506543dee13c9335edc5c85bc73c4853fbd7)
Dependant lists hold raw pointers back to EDUs that depend on them. We need to
remove these entries before destroying the EDU or we'll be left with a dangling
reference that can result in use-after-free bugs.
No testcase: This has only been observed in multi-threaded setups that
reproduce the issue inconsistently.
rdar://135403614
(cherry picked from commit 7034ec491251e598d2867199f89fefa3eb16a1a0)
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
(cherry picked from commit 8927576b8f6442bb6129bda597efee46176f8aec)
- **[Inliner] Add tests for incorrect propagation of return attrs; NFC**
- **[Inliner] Fix bug where attributes are propagated incorrectly**
The bug stems from the fact that we assume the new (inlined) callsite
is calling the same function as the original (callee) callsite. While
this is typically the case, since `VMap` simplifies the new
instructions, callee intrinsics callsites can end up not corresponding
with the same function.
This can lead to buggy propagation.
(cherry picked from commit a9352a0d31862c15146ca863bde165498e9a80e8)
C++23 has stricter rules for forward declarations around
std::unique_ptr, this means that the inline declaration of the
constructor was failing under clang in C++23 mode, switching to an
out-of-line definition of the constructor fixes this.
This was fairly major impact as it blocked inclusion of a lot of headers
under clang in C++23 mode.
Fixes#106597.
(cherry picked from commit 76bc1eddb2cf8b6cc073649ade21b59bbed438a2)
Previous code was checking that rotate and shift where equivilent when
transforming shift -> rotate but not the other way around.
Closes#108767
(cherry picked from commit 81279bf97f187eee0446af00d8ae9ec32a22e878)
This is a revert of b1fcc1840c312472cb9ccb8c4e5e02ca13b31113.
These tests weren't working on Ubuntu 22.04 or Fedora 37-40. I'm not
sure exactly why, but it seems like they may be incompatible with
libstdc++. Also, despite the fact that the tests were using the system
libstdc++, the tests were only run when libcxx was enabled.
I tested this with a RelWithDebInfo build and the tests passed.
Fixes#106475
(cherry picked from commit adf44d5c3ea03569f019740e1140c3205810b3fa)
16-bit loads are expanded into a pair of 8-bit loads, so the maximum
offset of such 16-bit loads must be 62, not 63.
(cherry picked from commit c7a4efa4294789b1116f0c4a320c16fcb27cb62c)
We established an instantiation scope in order for constraint
equivalence checking to properly map the uninstantiated parameters.
That mechanism mapped even packs to themselves. Consequently, parameter
packs e.g. appearing in a function call, were not expanded. So they
would end up becoming `SubstTemplateTypeParmPackType`s that circularly
depend on the canonical declaration of the function template, which is
not yet determined, hence the spurious error.
No release note as I plan to backport it to 19.
Fixes https://github.com/llvm/llvm-project/issues/101735
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
(cherry picked from commit e6974daa7bc100c8b88057d50f3ec3eca7282243)
Similar to commit 686cff17cc310884e48ae963bf7507f96950cc90 for SHT_REL (#57693).
CREL hasn't been tested with ICF before.
And avoid a pitfall that eqClass[0] might interfere with ICF.
(cherry picked from commit e82f0838ae88ad69515ebec234765e3e2607bebf)
Relands #107618 with fix for assertion triggered by OpenMP runtime MASM
assembly source.
(cherry picked from commit 7574e1ddc4be63628cb7617857cc8938058a79d2)
On the GitHub Action runners, perf always fails with the error below ,
so we need to skip the perf tests on platforms like this that have
limited access to the perf counters.
```
Access to performance monitoring and observability operations is limited.
Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open
access to performance monitoring and observability operations for processes
without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
More information can be found at 'Perf events and tool security' document:
https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
perf_event_paranoid setting is 4:
-1: Allow use of (almost) all events by all users
Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow raw and ftrace function tracepoint access
>= 1: Disallow CPU event access
>= 2: Disallow kernel profiling
To make the adjusted perf_event_paranoid setting permanent preserve it
in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = <setting>)
```
(cherry picked from commit 773353b20a49bfa0dab608d415c1b4734d037fce)
This fixes a regression from f58330cbe44598eb2de0cca3b812f67fea0a71ca.
That commit changed the clang-cl options /Zi and /Z7 to be implemented
as aliases of -g rather than having separate handling.
This had the unintended effect, that when assembling .s files with
clang-cl, the /Z7 option (which implies using CodeView debug info) was
treated as a -g option, which causes `ClangAs::ConstructJob` to pick up
the option as part of `Args.getLastArg(options::OPT_g_Group)`, which
sets the `WantDebug` variable.
Within `Clang::ConstructJob`, we check for whether explicit `-gdwarf` or
`-gcodeview` options have been set, and if not, we pick the default
debug format for the current toolchain. However, in `ClangAs`, if debug
info has been enabled, it always adds DWARF debug info.
Add similar logic in `ClangAs` - check if the user has explicitly
requested either DWARF or CodeView, otherwise look up the toolchain
default. If we (either implicitly or explicitly) should be producing
CodeView, don't enable the default `ClangAs` DWARF generation.
This fixes the issue, where assembling a single `.s` file with clang-cl,
with the /Z7 option, causes the file to contain some DWARF sections.
This causes the output executable to contain DWARF, in addition to the
separate intended main PDB file.
By having the output executable contain DWARF sections, LLDB only looks
at the (very little) DWARF info in the executable, rather than looking
for a separate standalone PDB file. This caused an issue with LLDB's
tests, https://github.com/llvm/llvm-project/issues/101710.
(cherry picked from commit fcb7b390ccd5b4cfc71f13b5e16a846f3f400c10)
Hit Assertion failed: Num < NumOperands && "Invalid child # of SDNode!"
Fix by checking opcode and value type before calling getOperand.
(cherry picked from commit 22067a8eb43a7194e65913b47a9c724fde3ed68f)
Empty archives are apparently routine in linux kernel builds, so instead
of asserting, we should handle this case with a sane default value.
(cherry picked from commit d1ba432533aafc52fc59158350af937a8b6b9538)
GNU ld will error when encountering a pcrel_lo whose corresponding
pcrel_hi is in a different section. [1] introduced a check to help
prevent this issue by preventing outlining in a few circumstances.
However, we can also hit this same issue when outlining from functions
with prefixes ("hot"/"unlikely"/"unknown" from profile information, for
example) as the outlined function might not have the same prefix,
possibly resulting in a "paired" pcrel_lo and pcrel_hi ending up in
different sections.
To prevent this issue, take a similar approach as [1] and additionally
prevent outlining when we see a pcrel_lo and the function has a prefix.
[1]
96c85f80f0Fixes#107520
(cherry picked from commit 866b93e6b33fac9a4bc62bbc32199bd98f434784)
