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)
The helper function `__pair_like_explicit_wknd` is only SFINAE-ed with
`tuple_size<remove_cvref_t<_PairLike>>::value == 2`, but its function
body assumes `std::get` being valid.
Fixes#65620
(cherry picked from commit 054f9c55c6b4520d3feb8b4354b9b942026b5124)
Otherwise they may mistakenly get the large section flag.
(cherry picked from commit b915f60678c3033c466611be1119a46ba4b0869c)
(fix was slightly different since cherry-pick didn't apply well)
Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.
After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.
This was fixed for -mthreads in
a79995ca6004082774a87f7a58ab6be5343364b7, while the other options didn't
seem to be commonly used during compilation.
After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.
Thus, this fixes#64464.
(cherry picked from commit e39de2b8862ae43459324da84279366997265078)
Adapted from the original commit; the test in the original commit
depended on f39c399d9d15efe8309d8aa3d0ecf62205e6c474. Instead of
using -###, when we're not actually using the printed output of
-###, instead use -fdriver-only.
Before af744f0b84e2b6410be65277068b9033124c73b2, the first entry
among the search paths was the empty string, indicating searching
in (or starting from) the current directory. After
af744f0b84e2b6410be65277068b9033124c73b2, the toolchain/clang
specific lib directories were added at the head of the search path.
This would cause lookups of literal file names or relative paths
to match paths in the toolchain, if there are coincidental files
with similar names there, even if they would be find in the current
directory as well.
Change addClangLibSearchPaths to append to the list like all other
operations on searchPaths - but move the invocation of the
function to the right place in the sequence.
This fixes#67779.
(cherry picked from commit f906fd53b5ce12f07aec394ddf900c7f9f583405)
This reverts one part of commit
9f4dfcb795bb0ecf9944553f49371164801cd83f, with a modified comment added
about the code.
Ideally, this would only be reinstated temporarily - but given the
situation in vcpkg, it looks likely that they would keep passing the
duplicate options for quite some time. The conflicting CRT choice
usually are benign but only would cause warnings about one option
overriding the other, if passing e.g. "/MDd /MT".
However when vcpkg currently sets these options in CMAKE_*_FLAGS_DEBUG,
it passes the redundant option /D_DEBUG; thus the compiler finally ends
up with e.g. "/D_DEBUG /MDd /MT", which has the effect of defining
_DEBUG while using a release mode CRT, which allegedly breaks the build.
There's a PR up for removing this redundant /D_DEBUG option in vcpkg in
https://github.com/microsoft/vcpkg/pull/34123. With that in place, this
change wouldn't be strictly needed.
(cherry picked from commit 7bc09a471fbc274d8632d1379d4134bec63fecc4)
Previously a relative path would be used as a key for cache lookup and
if the same relative path was used from another compiler invocation with
a different working directory then the first cache entry was erroneously
returned.
(cherry picked from commit 36b37c775c285bbff9b57630e7ea9d00b918cc91)
`Lexer::getLocForEndOfToken` is documented as returning an invalid
source location when the end of the token is inside a macro expansion.
We don't want that for this particular application, so just calculate
the end location directly instead.
Before this, format fix-its would omit the closing parenthesis (thus
producing invalid code) for macros, e.g.:
```
$ cat format.cpp
extern "C" int printf(const char *, ...);
enum class Foo { Bar };
#define LOG(...) printf(__VA_ARGS__)
void f(Foo foo) { LOG("%d\n", foo); }
$ clang -fsyntax-only format.cpp
format.cpp:4:29: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo f) { LOG("%d\n", f); }
| ~~ ^
| static_cast<int>(
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
We now emit a valid fix-it:
```
$ clang -fsyntax-only format.cpp
format.cpp:4:31: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo foo) { LOG("%d\n", foo); }
| ~~ ^~~
| static_cast<int>( )
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
Fixes https://github.com/llvm/llvm-project/issues/63462
(cherry picked from commit 61c5ad8857a71510e4393680a1e42740da4ba6fa)
In a809720102fae8d1b5a7073f99f9dae9395c5f41 I refactored some logic to
deal with the clang resource directory in standalone LLDB builds.
However, this logic escaped me because it only runs when you do not
build LLDB.framework.
Differential Revision: https://reviews.llvm.org/D156763
(cherry picked from commit 6888de118707e6392b46073fc35738804f9f1d80)
As of 0beffb854209a41f31beb18f9631258349a99299 there is a CMake
function to actually calculate the relative path to the clang resource
directory. Currently we have some bespoke logic that looks in a few
places, but with this new function we should be able to eliminate some
complexity here.
Also, I moved the functionality from LLDBConfig to LLDBStandalone since
it is only used in standalone builds.
Differential Revision: https://reviews.llvm.org/D156270
(cherry picked from commit a809720102fae8d1b5a7073f99f9dae9395c5f41)
lit tests require commands FileCheck and not. They must be available in
the PATH.
This also guarantees that python3-psutil is installed in order to enable
more tests.
Fixes#64892.
(cherry picked from commit b2247f85dc4b187dd0ebc93059a0aa42f35dd64a)
This is a followup to #66988. The implementation there did not
account for the possibility of the catch object frame index
referrring to a fixed object, which is the case on win64.
(cherry picked from commit aa70f4d8cf8f09a2997773156289b16d6a16ec01)
The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
be in a catchpad.
If we make use of first-use analysis, we may end up allocating
an alloca used inside the cleanuppad and the catch object at the
same stack offset, which would be incorrect.
https://reviews.llvm.org/D86673 was a previous attempt to fix it.
It used the heuristic "a slot loaded in a WinEH pad and never
written" to detect catch objects. However, because it checks
for more than one load (while probably more than zero was
intended), the fix does not actually work.
The general approach also seems dubious to me, so this patch
reverts that change entirely, and instead marks all catch object
slots as conservative (i.e. excluded from first-use analysis)
based on the WinEHFuncInfo. As far as I can tell we don't need
any heuristics here, we know exactly which slots are affected.
Fixes https://github.com/llvm/llvm-project/issues/66984.
(cherry picked from commit b3cb4f069c2cb99bdae68d6906156af20e76314f)
When unswitching via invariant condition injection, we currently
mark the condition in the old loop, so that it does not get
unswitched again. However, if there are multiple branches for
which conditions can be injected, then we can do that for both
the old and new loop. This means that the number of unswitches
increases exponentially.
Change the handling to be more similar to partial unswitching,
where we instead mark the whole loop, rather than a single
condition. This means that we will only generate a linear number
of loops.
TBH I think even that is still highly undesirable, and we should
probably be unswitching all candidates at the same time, so that
we end up with only two loops. But at least this mitigates the
worst case.
The test case is a reduced variant that generates 1700 lines of IR
without this patch and 290 with it.
Fixes https://github.com/llvm/llvm-project/issues/66868.
(cherry picked from commit 8362cae71b80bc43c8c680cdfb13c495705a622f)
The in-loop successor is only on the left after a potential condition
inversion. As we re-use the old condition as-is, we should also
reuse the old successors as-is.
Fixes https://github.com/llvm/llvm-project/issues/63962.
(cherry picked from commit afd7db48c55cb87566758e961f1ebac8af16b8bc)
An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.
Reported-By: ormris
Fixes: https://github.com/llvm/llvm-project/issues/65982
(cherry picked from commit 660876a4019b81b5a7427a3dcec5ce8c39cd1ee0)
When the caret location is lower than the lowest source range, clang is
printing wrong line numbers. The first line number should consider caret
location line even when there are source ranges provided.
Current wrong line example: https://godbolt.org/z/aj4qEjzs4
(cherry picked from commit ef5217b3c0dcbb58927fe43400b6d1faa677bf98)
Followup to D158849: We also need to remove the phi node from the
VN table, which is not handled by removeInstruction().
Fixes https://github.com/llvm/llvm-project/issues/65447.
(cherry picked from commit 18e77760ce5e42d9057f69c3e64a8300d01a48ac)
Duplicate phi nodes were being directly removed, without
invalidating MDA. This could result in a new phi node being
allocated at the same address, incorrectly reusing a cache entry.
Fix this by optionally allowing EliminateDuplicatePHINodes() to
collect phi nodes to remove into a vector, which allows GVN to
handle removal itself.
Fixes https://github.com/llvm/llvm-project/issues/64598.
Differential Revision: https://reviews.llvm.org/D158849
(cherry picked from commit 7c229f6e85478bb0626a5e598f47b7be94bb50b0)
