Also stop buiding the bolt project on other platforms since bolt only
supports ELF.
(cherry picked from commit 148111fdcf0e807fe74274b18fcf65c4cff45d63)
This PR adds LLVM 20.1.0 release notes that are related to the PowerPC
target.
---------
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
addInstantiatedCapturesToScope() might be called when transforming a
lambda body. In this situation, it would look into all the lambda's
parents and figure out all the instantiated captures. However, the
instantiated captures are not visible from lambda's class decl until the
lambda is rebuilt (i.e. after the lambda body transform). So this patch
corrects that by also examining the LambdaScopeInfo, serving as a
workaround for not having deferred lambda body instantiation in Clang
20, to avoid regressing some real-world use cases.
Fixes#128175
(cherry picked from commit ecc7e6ce4cd57a614985e95daf7027918cb8723e)
Close https://github.com/llvm/llvm-project/issues/127963
The root cause of the problem seems to be that we didn't realize it
simply.
(cherry picked from commit 24c06a19be7bcf28b37e5eabbe65df95a2c0265a)
Summary:
The scan operation implemented here only works if there are contiguous
ones in the executation mask that can be used to propagate the result.
There are two solutions to this, one is to enter 'whole-wave-mode' and
forcibly turn them back on, or to do this serially. This implementation
does the latter because it's more portable, but checks to see if the
parallel fast-path is applicable.
Needs to be backported for correct behavior and because it fixes a
failing libc test.
(cherry picked from commit 6cc7ca084a5bbb7ccf606cab12065604453dde59)
Add support for sm101 and sm120 target architectures. It requires CUDA
12.8.
---------
Co-authored-by: Sebastian Jodlowski <sjodlowski@nuro.ai>
(cherry picked from commit 0127f169dc8e0b5b6c2a24f74cd42d9d277916f6)
This fixes instantiation of definition for friend function templates,
when the declaration found and the one containing the definition have
different template contexts.
In these cases, the the function declaration corresponding to the
definition is not available; it may not even be instantiated at all.
So this patch adds a bit which tracks which function template
declaration was instantiated from the member template. It's used to find
which primary template serves as a context for the purpose of
obtainining the template arguments needed to instantiate the definition.
Fixes#55509
When bytes with negative signed char values appear in the data, make
sure to use raw bytes from the data string when preprocessing, not char
values.
Fixes https://github.com/llvm/llvm-project/issues/102798
This change will cause clang and the other tools to statically link
against the runtimes built in stage1. This will make the built binaries
more portable by eliminating dependencies on system libraries like
libgcc and libstdc++.
(cherry picked from commit f5b311e47de044160aeb25221095898c35c4847f)
Class templates might be only instantiated when they are required to be
complete, but checking the template args against the primary template is
immediate.
This result is cached so that later when the class is instantiated,
checking against the primary template is not repeated.
The 'MatchedPackOnParmToNonPackOnArg' flag is also produced upon
checking against the primary template, so it needs to be cached in the
specialziation as well.
This fixes a bug which has not been in any release, so there are no
release notes.
Fixes#125290
…ete decl chains until the end of `finishPendingActions`. (#121245)"
This reverts commit a9e249f64e800fbb20a3b26c0cfb68c1a1aee5e1.
Reverting this change because of issue #126973.
(cherry picked from commit 912b154f3a3f8c3cebf5cc5731fd8b0749762da5)
This fixes a false positive caused by #114044.
For `GSLPointer*` types, it's less clear whether the lifetime issue is
about the GSLPointer object itself or the owner it points to. To avoid
false positives, we take a conservative approach in our heuristic.
Fixes#127195
(This will be backported to release 20).
(cherry picked from commit 9c49b188b8e1434eb774ee8422124ad3e8870dce)
A DeclRefExpr could never refer to a Decomposition in valid C++ code,
but somehow the Analyzer creates these entities and then it tries to
print them.
There is no sensible answer here, so we print 'decomposition' followed
by the names of all of its bindings, separated by dashes.
(cherry picked from commit 00c096e604ad3a5244af06602556f8de867e36c4)
This patch fixes a regression caused by
https://github.com/llvm/llvm-project/pull/114684 where clang accepts
trailing commas for function calls.
Fixes#125225
(cherry picked from commit 922f339c4ef3631f66dc4b8caa4c356103dbf69d)
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an
InsertPosition instead, so that they can be called with an iterator
(preferred), or with a deprecation warning an Instruction *, or a
BasicBlock *. This commit also updates the existing calls to the
DIBuilder methods to pass in iterators.
As a special exception, DIBuilder::insertDeclare() keeps a separate
overload accepting a BasicBlock *InsertAtEnd. This is because despite
the name, this method does not insert at the end of the block, therefore
this cannot be handled implicitly by using InsertPosition.
(cherry picked from commit 1083ec647f16314bcc9af8c4d6b11f50d288bca6)
This fixes a crash where CallExpr::getBeginLoc() tries to access the
first argument of a CallExpr representing a call to a function with
an explicit object parameter, assuming that a first argument exists
because it's the object argument.
This is the case for non-dependent calls, but for dependent calls
the object argument is part of the callee (the semantic analysis
that separates it out has not been performed yet) and so there may
not be a first argument.
Fixes https://github.com/llvm/llvm-project/issues/126720
(cherry picked from commit 32c8754fbcb936ba6b5bc6cb6817cf3b6a4602f4)
In my previous PR (#123656) to update the names of AVX10.2 intrinsics
and mnemonics, I have erroneously deleted `_ph` from few intrinsics.
This PR corrects this.
(cherry picked from commit 161cfc6f39bef8994eb944687033ebd3570196e8)
Found during work on #120927. This caused the compiler to silently drop
ignore half of the mask in the specific intrinsics.
(cherry picked from commit af522c5dd3a38cc5e11e8e62009d7dbe2cde2d86)
Close https://github.com/llvm/llvm-project/issues/126373
Although the root problems should be we shouldn't place the friend
declaration to the incorrect module, let's avoid bleeding the edge by
stoping diagnosing declarations not in file scope.
(cherry picked from commit 569e94f8f1c3e6998860e2b2ff577870433bdac9)
Summary:
The CUDA impelementation has long supported the `width` argument on its
shuffle instrucitons, which makes it more difficult to replace those
uses with this helper. This patch just correctly implements that for
AMDGPU and NVPTX so it's equivalent to `__shfl_sync` in CUDA. This will
ease porting.
Fortunately these get optimized out correctly when passing in known
widths.
(cherry picked from commit 2d8106cb5a505326d1da0f4461708ed44a0ac761)
This patch does two things.
1. Previously, when checking driver arguments, we emitted an error for
unsupported values of `-mbranch-protection` when using pauthtest ABI.
The reason for that was ptrauth-returns being enabled as part of
pauthtest. This patch changes the check against pauthtest to a check
against ptrauth-returns.
2. Similarly, check against values of the following function attribute
which are unsupported with ptrauth-returns:
`__attribute__((target("branch-protection=XXX`. Note that existing
`validateBranchProtection` function is used, and current behavior is to
ignore the unsupported attribute value, so no error is emitted.
(cherry picked from commit 84b0c128a751acfbf5b439edc724ba27d1da653e)
We now process all 6 options left-to-right and pick whatever is active
at the end.
Fixes#124868.
(cherry picked from commit 783275eb7b3ecde63bdb6ac1316c090bfc568bdd)
Also move the -fno-strict-overflow option definition next to the
-fstrict-overflow one while here.
Also add test coverage for f(no-)wrapv-pointer being a clang-cl option.
(cherry picked from commit 71adb054024a1e9bd5ed4566beda74dea65362cd)
For C++ (but not C), empty structs should be passed to functions as if
they are a 1 byte object with 1 byte alignment.
This is defined in Arm's CPPABI32:
https://github.com/ARM-software/abi-aa/blob/main/cppabi32/cppabi32.rst
For the purposes of parameter passing in AAPCS32, a parameter whose
type is an empty class shall be treated as if its type were an
aggregate with a single member of type unsigned byte.
The AArch64 equivalent of this has an exception for structs containing
an array of size zero, I've kept that logic for ARM. I've not found a
reason for this exception, but I've checked that GCC does have the same
behaviour for ARM as it does for AArch64.
The AArch64 version has an Apple ABI with different rules, which ignores
empty structs in both C and C++. This is documented at
https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms.
The ARM equivalent of that appears to be AAPCS16_VFP, used for WatchOS,
but I can't find any documentation for that ABI, so I'm not sure what
rules it should follow. For now I've left it following the AArch64 Apple
rules.
Close https://github.com/llvm/llvm-project/issues/125521
We shouldn't use the ownership information for friend declarations to do
anything.
(cherry picked from commit c5a9a72b3cd118a23193d01bf9393fbf1d4b90ae)
Re-enables compact-unwind support in JITLink, which was reverted in b04847b427d
due to buildbot failures.
The underlying cause for the failures on the buildbots was the lack of
compact-unwind registration support on older Darwin OSes. Since the
CompactUnwindManager pass now removes eh-frames by default we were left with
unwind-info that could not be registered. On x86-64, where eh-frame info is
produced by default the solution is to fall back to using eh-frames. On arm64
we simply can't support exceptions on older OSes.
This patch updates the EHFrameRegistrationPlugin to remove the compact-unwind
section (__LD,__compact_unwind) when installed, forcing use of eh-frames when
the EHFrameRegistrationPlugin is used. In LLJIT, the EHFrameRegistrationPlugin
continues to be used for all non-Darwin platform, and will be added on Darwin
platforms when the a CompactUnwindRegistrationPlugin instance can't be created
(e.g. due to missing support for compact-unwind info registration).
The lit.cfg.py script is updated to check whether the host OSes default unwind
info supports JIT registration, allowing tests to be disabled for older Darwin
OSes on arm64.
(cherry picked from commit eae6d6d18bd4d9e7dfe5fc1206d23d8ef663c8c7)
The call to `hasBody` inside `finishPendingActions` that bumps the `PendingIncompleteDeclChains`
size from `0` to `1`, and also sets the `LazyVal->LastGeneration` to `6` which matches
the `LazyVal->ExternalSource->getGeneration()` value of `6`. Later, the iterations over `redecls()`
(which calls `getNextRedeclaration`) is expected to trigger the reload, but it **does not** since
the generation numbers match.
The proposed solution is to perform the marking of incomplete decl chains at the end of `finishPendingActions`.
This way, **all** of the incomplete decls are marked incomplete as a post-condition of `finishPendingActions`.
It's also safe to delay this operation since any operation being done within `finishPendingActions` has
`NumCurrentElementsDeserializing == 1`, which means that any calls to `CompleteDeclChain` would simply
add to the `PendingIncompleteDeclChains` without doing anything anyway.
(cherry picked from commit a9e249f64e800fbb20a3b26c0cfb68c1a1aee5e1)
We can emit diagnostics while parsing warning-suppression-mapping, make
sure command line flags take affect when emitting those.
(cherry picked from commit ecb016a87d89aed36b8f5d8102e15d8eb0e57108)
Also link with libexecinfo on FreeBSD, NetBSD, OpenBSD and DragonFly
for the backtrace functions.
(cherry picked from commit d1de75acea0da55316cd7827563e064105868f0f)
This gets rid of some extra IO from driver startup, and possiblity of
emitting warnings twice.
(cherry picked from commit df22bbe2beb57687c76402bc0cfdf7901a31cf29)
Per the feedback we got, we’d like to switch m[no-]avx10.2 to alias of
512 bit options and disable m[no-]avx10.1 due to they were alias of 256
bit options.
We also change -mno-avx10.[1,2]-512 to alias of 256 bit options to
disable both 256 and 512 instructions.
Cherry-pick from
9ebfee9d68
This seems consistent with the documentation, which claims it:
```
/// Looks through the Decl's underlying type to extract a FunctionType
/// when possible. Will return null if the type underlying the Decl does not
/// have a FunctionType.
const FunctionType *getFunctionType(bool BlocksToo = true) const;
```
Note: This patch rewords this doc comment to clarify it includes various
function pointer types.
Without this, attaching attributes (which use `HasFunctionProto`) to
member function pointers errors with:
```
error: '<attr>' only applies to non-K&R-style functions
```
...which does not really make sense, since member functions are not K&C
functions.
With this change the Arm SME TypeAttrs work correctly on member function
pointers.
Note, however, that not all attributes work correctly when applied to
function pointers or member function pointers. For example,
`alloc_align` crashes when applied to a function pointer (on truck):
https://godbolt.org/z/YvMhnhKfx (as it only expects a `FunctionDecl` not
a `ParmVarDecl`). The same crash applies to member function pointers
(for the same reason).
(cherry picked from commit 692c9b210728323ac499a402ee6eb901f35856f2)
If we have +sme but not +sve, we would not set vscale_range on
functions. It should be valid to apply it with the same range with just
+sme, which can help mitigate some performance regressions in cases such
as scalable vector bitcasts (https://godbolt.org/z/exhe4jd8d).
(cherry picked from commit 9f1c825fb62319b94ac9604f733afd59e9eb461b)
