The check for whether a tail call is supported calls
determineAssignments(), which may modify argument flags. As such, even
though the check fails and a non-tail call will be emitted, it will not
have a different (incorrect) ABI.
Fix this by operating on a separate copy of the arguments.
Fixes https://github.com/llvm/llvm-project/issues/70207.
(cherry picked from commit 292f34b0d3cb2a04be5ebb85aaeb838b29f71323)
replaceValuesPerBlockEntry() only handled simple and coerced load
values, however the load may also be referenced by a select value.
Additionally, I suspect that the previous code might have been incorrect
if a load had an offset, as it always constructed the AvailableValue
from scratch.
Fixes https://github.com/llvm/llvm-project/issues/69301.
(cherry picked from commit 7f1733a252cbbad74445bd54dc95aeec52bb3199)
Resolved the crash that occurred during the use of a user-defined
C-style string literal. The fix entails checking whether the identifier
is non-empty before attempting to read its name.
(cherry picked from commit a396fb247e0719f56a830a9e4aab0449be7f843a)
This fixes a bug where functions generated by the MLIR Math dialect, for
example ipowi, would fail to link with link.exe on Windows due to having
linkonce linkage but no associated comdat. Adding the comdat on ELF also
allows linkers to perform better garbage collection in the binary.
Simply adding comdats to all functions with this linkage type should
also cover future cases where linkonce or linkonce_odr functions might
be necessary.
(cherry picked from commit 5f476b80e3d472f672f5f6a719eebe2c0aadf52c)
This adds a new pass to add an Any comdat to each linkonce
and linkonce_odr function in the LLVM dialect. These comdats are
necessary on Windows
to allow the default system linker to link binaries containing these
functions.
(cherry picked from commit a6857156df9a73720fbd9633067d1a61c32dd74e)
When partially packing an offset into an SVE load/store instruction we
are incorrectly calculating the remainder.
(cherry picked from commit 7c90be2857fc4c6a2e67f203ca289ed7773fae03)
As explained in `__config`, we have an ABI tag that we use to ensure
that we don't run into ODR issues when mixing different versions of
libc++ in multiple TUs. However, the reasoning behind that extends not
only to different versions of libc++, but also to different
configurations of the same version of libc++. In fact, we've been aware
of this for a while but never really bothered to make the change because
ODR issues are often thought to be benign.
Well, it turns out that I just spent over an hour banging my head
against an issue that boils down to our lack of encoding of some ODR
properties in the ABI tag, so here's the patch we should have done a
long time ago.
For now, the ODR properties we encode in the ABI tag are:
- library version
- exceptions vs no-exceptions
- hardening mode
Those are all things that we support different values for on a per-TU
basis and they definitely affect ODR in a meaningful way. We can add
more properties later as we see fit.
(cherry picked from commit bc792a284362696c91599f9ab01f74eda4b9108f)
This patch prevents argument promotion from promoting pointers to
fixed-length vector types larger than 128 bits like `<8 x float>` into
the values of the pointees.
Such vector types are used for SVE VLS but there is no ABI for SVE VLS
arguments and the backend cannot lower such value arguments.
Fixes#69147
(cherry picked from commit 926173c614784149889b2c975adccf52bcece75b)
When implementing thread_local as a keyword in C23, we accidentally
started using C++11 thread_local semantics when using that keyword
instead of using C11 _Thread_local semantics.
This oversight is fixed by pretending the user wrote _Thread_local
instead. This doesn't have the best behavior in terms of diagnostics,
but it does correct the semantic behavior.
Fixes https://github.com/llvm/llvm-project/issues/70068
Fixes https://github.com/llvm/llvm-project/issues/69167
Our coefficients are 64-bits, so adding/multiplying them can wrap in
64-bits even if there would be no wrapping the full bit width.
The alternative would be to check for overflows during all adds/muls in
decomposition. I assume that we don't particularly care about handling
wide integers here, so I've opted to bail out.
Fixes https://github.com/llvm/llvm-project/issues/68751.
(cherry picked from commit 1d43096e16ff7288c7feac1ae81fd4f745ce10bb)
Specifically, the test std/input.output/string.streams/stringstream/stringstream.members/gcount.pass.cpp
allocates a std::string with INT_MAX-1 elements, and then writes this to
a std::stringstream. On Linux, running this test consumes around 5.0 GB
of memory; on Windows, it ends up using up to 6.8 GB of memory.
This limits whether such tests can run on e.g. GitHub Actions runners,
where the free runners are limited to 8 GB of memory.
This is somewhat similar to, but still notably different, from the
existing test parameter long_tests.
(cherry picked from commit 122064a6303eb9c06e0af231f5a4ce145d9a2e67)
On ELF platforms, when there is no global variable and the unique module ID is
non-empty, COMDAT asan.module_ctor is created with no
`__asan_register_elf_globals` calls. If this COMDAT is the prevailing copy
selected by the linker, the linkage unit will have no
`__asan_register_elf_globals` call: the redzone will not be poisoned and ODR
violation checker will not work (#67677).
This behavior is benign for -fno-sanitize-address-globals-dead-stripping because
asan.module_ctor functions that call `__asan_register_globals`
(`InstrumentGlobalsWithMetadataArray`) do not use COMDAT.
To fix#67677:
* Use COMDAT for -fsanitize-address-globals-dead-stripping on ELF platforms.
* Call `__asan_register_elf_globals` even if there is no global variable.
* If the unique module ID is empty, don't call SetComdatForGlobalMetadata:
placing `@.str` in a COMDAT would incorrectly discard internal COMDAT `@.str`
in other compile units.
Alternatively, when there is no global variable, asan.module_ctor is not COMDAT
and does not call `__asan_register_elf_globals`. However, the asan.module_ctor
function cannot be eliminated by the linker.
Tested the following script. Only ELF -fsanitize-address-globals-dead-stripping has changed behaviors.
```
echo > a.cc # no global variable, empty uniqueModuleId
echo 'void f() {}' > b.cc # with global variable, with uniqueModuleId
echo 'int g;' > c.cc # with global variable
for t in x86_64-linux-gnu arm64-apple-macosx x86_64-windows-msvc; do
for gc in -f{,no-}sanitize-address-globals-dead-stripping; do
for f in a.cc b.cc c.cc; do
echo /tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o -
/tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o - | sed -n '/asan.module_ctor/,/ret/p'
done
done
done
```
---
Identical to commit 16eed8c906875e748c3cb610f3dc4b875f3882aa.
6420d3301cd4f0793adcf11f59e8398db73737d8 is an incorrect revert for genuine
purely internal issues.
When applying format changes to staged files, git-clang-format
erroneously checks out all files in the index and thus may overwrite
unstaged changes.
Fixes#65643.
(cherry picked from commit 743659be87daff4cc8861c525d4a6229d787ef14)
It started to fail in a flaky manner a few days ago on GreenDragon buildbots
(i.e. x86_64-darwin). I didn't track down the root cause but LSan isn't
actually supported on darwin anyway, so UNSUPPORTED seems appropriate.
Prior art: 3ff080b5.
(cherry picked from commit 0a3519d5a27b9400250b5f6656b50148021e7496)
This custom combine currently converts `and(anyext(x),c)` into
`anyext(and(x,c))`. This is not correct, because the original expression
guaranteed that the high bits are zero, while the new one sets them to
undef.
Emit `zext(and(x,c))` instead.
Fixes https://github.com/llvm/llvm-project/issues/68783.
(cherry picked from commit 127ed9ae266ead58aa525f74f4c86841f6674793)
Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.
Fixed#67892.
(cherry picked from commit 75441a684273268ce91036aa2c770e669d39f501)
Prior logic would remove the shuffle iff all of the elements in `x`
where used. This is incorrect.
The issue is `movmsk` only cares about the highbits, so if the width
of the elements in `x` is smaller than the width of the elements
for the `movmsk`, then the shuffle, even if it preserves all the elements,
may change which ones are used by the highbits.
For example:
`movmsk64(bitcast(shuffle32(x, (1,0,3,2))))`
Even though the shuffle mask `(1,0,3,2)` preserves all the elements, it
flips which will be relevant to the `movmsk64` (x[1] and x[3]
before and x[0] and x[2] after).
The fix here, is to ensure that the shuffle mask can be scaled to the
element width of the `movmsk` instruction. This ensure that the
"high" elements stay "high". This is overly conservative as it
misses cases like `(1,1,3,3)` where the "high" elements stay
intact despite not be scalable, but for an relatively edge-case
optimization that should generally be handled during
simplifyDemandedBits, it seems okay.
(cherry picked from commit 1684c65bc997a8ce0ecf96a493784fe39def75de)
On MinGW targets, the .ctors section is always used for constructors.
When using the .ctors section, the constructors need to be emitted in
reverse order to get them execute in the right order. (Constructors with
a specific priority are sorted separately by the linker later.) In LLVM,
in CodeGen/AsmPrinter/AsmPrinter.cpp, there's code that reverses them
before writing them out, executed when using the .ctors section. This
logic is done whenever TM.Options.UseInitArray is set to false. Thus,
make sure to set UseInitArray to false for this target.
This fixes https://github.com/llvm/llvm-project/issues/55938.
(cherry picked from commit a2b8c49c1839076b540c542c024fcfe2361a3e47)
When converting to ConstantRange, we should treat undef like a full range.
Fixes#68381.
(cherry picked from commit 81857940f278e21f7957a2833d4b6ec72819e79f)
We could maybe extend this by allowing the lowest subop to have multiple uses and extract the lowest subvector result of the concatenated op, but let's just get the fix in first.
Fixes#67333
This can happen when manually emitting strings into .drectve sections
with `__attribute__((section(".drectve")))`, which is a way to emulate
`#pragma comment(linker, "...")` for mingw compilers, without requiring
building with -fms-extensions.
Normally, this doesn't generate any comdat, but if compiled with
-fsanitize=address, this section does get turned into a comdat section.
This fixes#67261. This issue can be seen as a regression; a change in
the "lli" tool in 17.x triggers this case, if compiled with ASAN
enabled, triggering this unsupported corner case in LLD. With this
change, LLD can handle it.
(cherry picked from commit 503bc5f66111f7e4fc79972bb9bfec8bb5606bab)
This should fix#66912. When emitting SEH unwind info, we need to be
able to calculate the exact length of functions before alignments are
fixed. Until that limitation is overcome, just disable all loop
alignment on Windows targets.
(cherry picked from commit 6ae36c012728a274a78a771e4506681732f85a6d)
Right now, `-Wformat` for a scoped enum will suggest a cast based on the
format specifier being used. This can lead to incorrect results, e.g.
attempting to format a scoped enum with `%s` would suggest casting to
`char *` instead of fixing the specifier. Change the logic to treat the
scoped enum's underlying type as the intended type to be printed, and
suggest format specifier changes and casts based on that.
(cherry picked from commit 0b07b06effe5fdf779b75bb5ac6cf15e477cb0be)
