The trick we use (since cbc2a0623a39461b56bd9eeb308ca535f03793f8)
for exporting the __chkstk function (with various per-arch names)
that is defined in a different object file, relies on the function
already being linked in (by some function referencing it).
This function does end up referenced if there's a function that
allocates more than 4 KB on the stack. In most cases, it's referenced
somewhere, but in the case of builds with LLVM_LINK_LLVM_DYLIB
enabled (so most of the code resides in a separate libLLVM-<ver>.dll)
the only code in lli.exe is the lli tool specific code and the
mingw-w64 crt startup code. In the case of GCC based MinGW i386
builds with LLVM_LINK_LLVM_DYLIB, nothing else references it though.
Manually add a reference to the function to make sure it is linked
in (from libgcc or compiler-rt builtins) so that it can be exported.
This fixes one build issue encountered in
https://github.com/msys2/MINGW-packages/pull/18002.
Differential Revision: https://reviews.llvm.org/D159085
(cherry picked from commit 4bba12f7226228221d1fa4bad7732e25647ecb87)
This removes the backend requirement for crc instructions on HasV8, relying on
just HasCRC instead. This should allow them to be selected with ArmV7 + crc,
making them more usable whilst hopefully not making them incorrectly generated
(they only come from intrinsics, and HasCRC usually requires HasV8). This is
how most other instructions are specified.
(cherry picked from commit a82c106e571c6991a95c38a936a466895122d713)
This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.
Experimental: do not merge yet.
Differential Revision: https://reviews.llvm.org/D154660
(cherry picked from commit 1c35c1a73907a95ce54b5a0edca513591e2bc069)
As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the
unsigned long long cast fails on 32-bit systems at least with GCC.
It looks like a pointer provenance/aliasing issue rather than a bug in GCC.
Acked by Vassil Vassilev on the original revision.
(cherry picked from commit 3403686b72507e3fdbcd69f21fb9235ffa0ca169)
Whilst Clang does not use these, recent GCC does, and so on systems such
as FreeBSD that wish to use compiler-rt as the system runtime library
but also wish to support building programs with GCC these interfaces are
needed.
This is a light adaptation of the code committed to GCC by Sebastian Pop
<spop@amazon.com>, relicensed with permission for use in compiler-rt.
Fixes https://github.com/llvm/llvm-project/issues/63483
Reviewed By: sebpop, MaskRay
Differential Revision: https://reviews.llvm.org/D158536
(cherry picked from commit 4bb2416d42eb593c44bbeb765e1b8641a58f853c)
The following commit enabled the analysis of ranges for heap allocations:
22ca38da25e19a7c5fcfeb3f22159aba92ec381e
The range turns out to be empty in cases such as the one in test (which
is [1,1)), leading to an assertion failure. This patch fixes for the
same case.
Fixes https://github.com/llvm/llvm-project/issues/63856
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D159160
(cherry picked from commit 0609b65aaf03b083d282a4ffe8bf660351dac461)
When replacing ComplexDeinterleavingPass::ReductionOperation, we can do it
either from the Real or Imaginary part. The correct way is to take whichever
is later in the BasicBlock, but before the patch, we just always took the
Real part.
Fixes https://github.com/llvm/llvm-project/issues/65044
Differential Revision: https://reviews.llvm.org/D159209
(cherry picked from commit e2cb07c322e85604dc48f9caec52b3570db0e1d8)
This patch effectively maintains the status quo, making sure that the
safe mode keeps working the same way as before. Hardening will target
the next major release, allowing it to go through RFC and for the
implementation to stabilize and mature.
Differential Revision: https://reviews.llvm.org/D159171
When a loop has multiple reductions, each with an intermediate invariant
store, the order in which those reductions are processed is not considered.
This can result in the invariant stores outside the loop not preserving the
original order.
This patch sorts VPReductionPHIRecipes by the order in which they have
stores in the original loop before running
`InnerLoopVectorizer::fixReduction` function, and it helps to maintain
the correct order of stores.
Fixes https://github.com/llvm/llvm-project/issues/64047
Differential Revision: https://reviews.llvm.org/D157631
(cherry picked from commit ac65fb869977185b44757b94dc5130bd08c6f7e2)
This is probably a bad idea, but it's only become a problem with properties and is easy to fix.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D159185
The associated commit was reverted and backported in a93ca35, so this
release note line should also be removed.
This reverts commit 061e855767dbe0821d81a8d47158f468dd00ae5f.
`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.
In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.
Fixes https://github.com/clangd/clangd/issues/1745.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D158967
(cherry picked from commit e257c0a9190637e44e292271103a13d70bec4b03)
When the optional assignment-allocation character 'm' (Extension to the
ISO C standard) is present, we currently use internal_strlen(buf)+1 for
all of cCsS[ (D85350). Fix cCS to use the correct size.
Fix https://github.com/llvm/llvm-project/issues/61768
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D158485
(cherry picked from commit beeb37a8f3275281be305d2d1afe35ca053e21c0)
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
6b117d3b1f.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
(cherry picked from commit 2bcc0fdc58a220cb9921b47ec8a32c85f2511a47)
clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.
The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.
Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.
An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.
To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.
Fixes: https://github.com/llvm/llvm-project/issues/64931.
Reviewed By: MaskRay, probinson, simon_tatham
Differential Revision: https://reviews.llvm.org/D158614
This disables the transform if the branch does not have the kill
flag set for the AND we want to delete.
Ideally we'd be able to share the AND with the AND we create in
the expansion, but that's a more complex transform. So this starts
with the simple approach to fix miscompile.
This should be backported to LLVM 17.
Fixes PR65025.ll
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D158962
(cherry picked from commit ff6d33382faf3709fa270ae0abb8d165142df9ae)
D153645 added additional X-Form load/stores that can be generated for TLS accesses.
However, these added instructions have not been accounted for in lld. As a result,
lld does not know how to handle them and cannot relax initial-exec to local-exec
when the initial-exec sequence contains these additional load/stores.
This patch aims to resolve https://github.com/llvm/llvm-project/issues/64424.
Differential Revision: https://reviews.llvm.org/D158197
(cherry picked from commit 698b45aa902de4d30c798e8d6bd080c8e31bade8)
The `STGloop` family of pseudo-instructions all expand to a loop which
iterates over a region of memory setting all its MTE tags to a given
value. The loop writes to the flags in order to check termination. But
the unexpanded pseudo-instructions were not marked as modifying the
flags. Therefore it was possible for one to end up in a location where
the flags were live, and then the loop would corrupt them.
We spotted the effect of this in a libc++ test involving a lot of
complicated inlining, and haven't been able to construct a smaller
test case that demonstrates actual incorrect output code. So my test
here is just checking that `implicit-def $nzcv` shows up on the
pseudo-instructions as they're output from isel.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D158262
(cherry picked from commit b09c575975b691e988a0f2e31d632c5f1038ab1d)
When sending file from a Linux host to a Windows remote, Linux host will try to copy the source file's permission bits, which will contain `_S_I?GRP` and `_S_I?OTH` bits. Those bits are rejected by `_wsopen_s`, causing it to return EINVAL.
This patch masks out the rejected bits.
GitHub issue: #64313
Reviewed By: jasonmolenda, DavidSpickett
Differential Revision: https://reviews.llvm.org/D156817
(cherry picked from commit 9a4b3fdb82327e808213070fd157be3c557b8b9d)
Before accessing "getOpcode" thorugh machine instruction, check if the iterator
has reached the end of Machine basic block otherwise we will crash at the
assertion `!NodePtr->isKnownSentinel()`.
The above assertion is hit in "Prologue/Epilogue Insertion & Frame Finalization
pass".
Reviewed By: craig.topper, wangpc
Differential Revision: https://reviews.llvm.org/D158256
(cherry picked from commit fdef7952cbc26fd31d0d92a4f14dde58bc461fe9)
The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable.
This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle.
This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children.
This incidentally makes the non-deferrable marking also `O(n)` instead of `O(n^2)` (although not performance sensitive obviously).
Differential Revision: https://reviews.llvm.org/D158932
A dialect extension can add additional dialect extensions in its `apply` function. This used to crash when the vector of `extensions` was internally reallocated while it is being iterated over.
Differential Revision: https://reviews.llvm.org/D158838
Powf expansion currently returns NaN when the base is negative.
This is because taking natural log of a negative number gives
NaN. This patch will square the base and half the exponent, thereby
getting around the negative base problem.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D158797
`SubViewReturnTypeCanonicalizer` is used by `OpWithOffsetSizesAndStridesConstantArgumentFolder`, which folds constant SSA value (dynamic) sizes into static sizes. The previous implementation crashed when a dynamic size was folded into a static `1` dimension, which was then mistaken as a rank reduction.
Differential Revision: https://reviews.llvm.org/D158721
A check pattern in clang/test/SemaCXX/template-64605.cpp contains template
specialization kind (the text "implicit_instantiation"). It does not need to
be checked and can be safely removed.
Presence of this text in the check pattern prevents from backporting some
commits to the release branch: https://github.com/llvm/llvm-project/issues/64605.
It has only recently been printed and the relevant commit is not present in
the release/17.x branch.
(cherry picked from commit 8859c644ede4898f90f77dcad2286de08a9ba62e)
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.
(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)
5d8aaad445
removed the warning group as the functionality is no longer a GNU
extension. However, users have asked for the warning group to be
supported so that code transitioning from Clang 16 to Clang 17 has an
easier migration path when compiling with -Werror. This patch restores
the warning group, but as an ignored warning group because the
functionality is now always considered to be a C extension rather than
a GNU extension. This allows users to do:
-Werror -pedantic -Wno-gnu-empty-intializer -Wno-c2x-extensions
to silence the diagnostics in both Clang 16 and Clang 17.
Fixes https://github.com/llvm/llvm-project/issues/64357
Differential Revision: https://reviews.llvm.org/D157503
(cherry picked from commit 151214b40d869455666ca76548a9e3ad639f79de)
