| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In the context of determining whether a class counts as an "aggregate",
a constructor template counts as a user-provided constructor.
Fixes #86384
(cherry picked from commit 3ab4ae9e58c09dfd8203547ba8916f3458a0a481)
|
|
have valid source locations (#89564)
Fixes #86998
(cherry picked from commit c1b6cca1214e7a9c14a30b81585dd8b81baeaa77)
|
|
A struct that declares an inner struct, but no fields, won't have a
field count. So getting the offset of the inner struct fails. This
happens in both C and C++:
struct foo {
struct bar {
int Quantizermatrix[];
};
};
Here 'struct foo' has no fields.
Closes: https://github.com/llvm/llvm-project/issues/88931
|
|
Linked to https://github.com/gnustep/libobjc2/pull/289.
More information can be found in issue: #88273.
My solution involves creating a new message-send function for this
calling convention when targeting MSVC. Additional information is
available in the libobjc2 pull request.
I am unsure whether we should check for a runtime version where
objc_msgSend_stret2_np is guaranteed to be present or leave it as is,
considering it remains a critical bug. What are your thoughts about this
@davidchisnall?
(cherry picked from commit 3dcd2cca7777b338d87deb1ca506df1376123667)
|
|
Fixes #88181
(cherry picked from commit e096c144921daba59963f15e89d2ca6fb32d3a78)
|
|
Previously, the `override` keyword in C++ was being print in the left
side of a method decl, which is unsupported by C++ standard. This commit
fixes that by setting the `CanPrintOnLeft` field to 0, forcing it to be
print on the right side of the decl.
Signed-off-by: Giuliano Belinassi <gbelinassi@suse.de>
|
|
(#74512)
Shadowing warning doesn't make much sense since field is not available
in lambda's body without capturing this.
Fixes https://github.com/llvm/llvm-project/issues/71976
|
|
The most recent declaration of a template as a friend can introduce a
different template parameter depth compared to what we anticipate from a
CTAD guide.
Fixes https://github.com/llvm/llvm-project/issues/86769
|
|
When emitting the storage (or memory copy operations) for constant
initializers, the decision whether to split a constant structure or
array store into a sequence of field stores or to use `memcpy` is
based upon the optimization level and the size of the initializer.
In afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d, we extended this by
allowing constants to be split when the array (or struct) type does
not match the type of data the address to the object (constant) is
expected to contain. This may happen when `emitStoresForConstant` is
called by `EmitAutoVarInit`, as the element type of the address gets
shrunk. When this occurs, let the initializer be split into a bunch
of stores only under `-ftrivial-auto-var-init=pattern`.
Fixes: https://github.com/llvm/llvm-project/issues/84178.
|
|
constraint expression
Previously we disabled to compute ODR hash for declarations from the
global module fragment. However, we missed the case that the functions
lives in the concept requiments (see the attached the test files for
example). And the mismatch causes the potential crashment.
Due to we will set the function body as lazy after we deserialize it and
we will only take its body when needed. However, we don't allow to take
the body during deserializing. So it is actually potentially problematic
if we set the body as lazy first and computing the hash value of the
function, which requires to deserialize its body. So we will meet a
crash here.
This patch tries to solve the issue by not taking the body of the
function from GMF. Note that we can't skip comparing the constraint
expression from the GMF directly since it is an key part of the
function selecting and it may be the reason why we can't return 0
directly for `FunctionDecl::getODRHash()` from the GMF.
|
|
This commit changes the default linker in the WebAssembly toolchain for
the `wasm32-wasip2` target. This target is being added to the
WebAssembly/wasi-sdk and WebAssembly/wasi-libc projects to target the
Component Model by default, in contrast with the preexisting
`wasm32-wasi` target (in the process of being renamed to
`wasm32-wasip1`) which outputs a core WebAssembly module by default.
The `wasm-component-ld` project currently lives in my GitHub account at
https://github.com/alexcrichton/wasm-component-ld and isn't necessarily
"official" yet, but it's expected to continue to evolve as the
`wasm32-wasip2` target continues to shape up and evolve.
(cherry picked from commit d66121d74a458e098511b9de920d815440acaa1b)
|
|
redeclaration errors with -fbuiltin-headers-in-system-modules (#84127)
On Apple platforms, some of the stddef.h types are also declared in
system headers. In particular NULL has a conflicting declaration in
<sys/_types/_null.h>. When that's in a different module from
<__stddef_null.h>, redeclaration errors can occur.
Make the \_\_stddef_ headers be non-modular in
-fbuiltin-headers-in-system-modules and restore them back to not
respecting their header guards. Still define the header guards though.
__stddef_max_align_t.h was in _Builtin_stddef_max_align_t prior to the
addition of _Builtin_stddef, and it needs to stay in a module because
struct's can't be type merged. __stddef_wint_t.h didn't used to have a
module, but leave it in it current module since it doesn't really belong
to stddef.h.
(cherry picked from commit f50d3582b4844b86ad86372028e44b52c560ec7d)
|
|
relate:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645016.html
(cherry picked from commit 2f479b811274fede36535e34ecb545ac22e399c3)
|
|
__iocsrrd_h. NFC
(cherry picked from commit aeda1a6e800e0dd6c91c0332b4db95094ad5b301)
|
|
getAdjustedParameterIndex() (#83585)
Fixes #78810
Thanks for Snape3058 's comment
---------
Co-authored-by: miaozhiyuan <miaozhiyuan@feysh.com>
(cherry picked from commit d4687fe7d1639ea5d16190c89a54de1f2c6e2a9a)
|
|
When analysing whether we should handle a binary expression as an
overloaded operator call or a builtin operator, we were calling
`checkPlaceholderForOverload()`, which takes care of any placeholders
that are not overload sets—which would usually make sense since those
need to be handled as part of overload resolution.
Unfortunately, we were also doing that for `.*`, which is not
overloadable, and then proceeding to create a builtin operator anyway,
which would crash if the RHS happened to be an unresolved overload set
(due hitting an assertion in `CreateBuiltinBinOp()`—specifically, in one
of its callees—in the `.*` case that makes sure its arguments aren’t
placeholders).
This pr instead makes it so we check for *all* placeholders early if the
operator is `.*`.
It’s worth noting that,
1. In the `.*` case, we now additionally also check for *any*
placeholders (not just non-overload-sets) in the LHS; this shouldn’t
make a difference, however—at least I couldn’t think of a way to trigger
the assertion with an overload set as the LHS of `.*`; it is worth
noting that the assertion in question would also complain if the LHS
happened to be of placeholder type, though.
2. There is another case in which we also don’t perform overload
resolution—namely `=` if the LHS is not of class or enumeration type
after handling non-overload-set placeholders—as in the `.*` case, but
similarly to 1., I first couldn’t think of a way of getting this case to
crash, and secondly, `CreateBuiltinBinOp()` doesn’t seem to care about
placeholders in the LHS or RHS in the `=` case (from what I can tell,
it, or rather one of its callees, only checks that the LHS is not a
pseudo-object type, but those will have already been handled by the call
to `checkPlaceholderForOverload()` by the time we get to this function),
so I don’t think this case suffers from the same problem.
This fixes #53815.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
|
|
In addition to being rather hard to follow, there isn't a good reason
why FatLTO shouldn't just share the same code for setting module flags
for (Thin)LTO. This patch simplifies the logic and makes sure we use set
these flags in a consistent way, independent of FatLTO.
Additionally, we now test that output in the .llvm.lto section actually
matches the output from Full and Thin LTO compilation.
(cherry picked from commit 7d8b50aaab8e0f935e3cb1f3f397e98b9e3ee241)
|
|
This include 2 fixes:
1. Disallow 'f' for softfloat.
2. Allow 'r' for softfloat.
Currently, 'f' is accpeted by clang, then LLVM meets an internal error.
'r' is rejected by LLVM by: couldn't allocate input reg for constraint
'r'.
Fixes: #64241, #63632
---------
Co-authored-by: Fangrui Song <i@maskray.me>
(cherry picked from commit c88beb4112d5bbf07d76a615ab7f13ba2ba023e6)
|
|
The Ampere1B is Ampere's third-generation core implementing a
superscalar, out-of-order microarchitecture with nested virtualization,
speculative side-channel mitigation and architectural support for
defense against ROP/JOP style software attacks.
Ampere1B is an ARMv8.7+ implementation, adding support for the FEAT
WFxT, FEAT CSSC, FEAT PAN3 and FEAT AFP extensions. It also includes all
features of the second-generation Ampere1A, such as the Memory Tagging
Extension and SM3/SM4 cryptography instructions.
(cherry picked from commit fbba818a78f591d89f25768ba31783714d526532)
|
|
Add AEK_PAUTH to ARMV8_3A in TargetParser and let it propagate to
ARMV8R, as it aligns with GCC defaults.
After adding AEK_PAUTH, several tests from TargetParserTest.cpp crashed
when trying to format an error message, thus update a format string in
AssertSameExtensionFlags to account for bitmask being pre-formatted as
std::string.
The CHECK-PAUTH* lines in aarch64-target-features.c are updated to
account for the fact that FEAT_PAUTH support and pac-ret can be enabled
independently and all four combinations are possible.
(cherry picked from commit a52eea66795018550e95c4b060165a7250899298)
|
|
* Consider that immediate escalating function can appear at global
scope, fixing a crash
* Lambda conversion to function pointer was sometimes not performed in
an immediate function context when it should be.
Fixes #82258
(cherry picked from commit baf6bd303bd58a521809d456dd9b179636982fc5)
|
|
This enables specifing "za" or "zt0" to the clobber list for inline asm.
This complies with the acle SME addition to the asm extension here:
https://github.com/ARM-software/acle/pull/276
(cherry picked from commit d9c20e437fe110fb79b5ca73a52762e5b930b361)
|
|
This adds support for marking arbitrary general purpose registers -
except for those with special purpose (G0, I6-I7, O6-O7) - as reserved,
as needed by some software like the Linux kernel.
(cherry picked from commit c2f9885a8aa3a820eefdacccf3fcc6b9d87e3284)
|
|
This reverts commit dc61ebb44c11d2f5d03b7dd9cb80a0644a30775e.
See https://github.com/llvm/llvm-project/pull/76733#issuecomment-1890311152.
(cherry picked from commit a628f68a9c4ce6f3dcd0c8bb3650db45671ed15a)
|
|
Commit d813af73f70f addressed a regression introduced by commit
3791b3fca6ea
but caused `clang-format -dump-config` to "hang".
This patch reverts changes to ClangFormat.cpp by both commits and
reworks the cleanup.
Fixes #80621.
(cherry picked from commit 8f6e13e6da84510c8321717860fd506e12118514)
|
|
C23 has `bool`, but logical operators still return int. Check that
we're not in C to avoid false-positive -Wconstant-logical-operand.
Fixes https://github.com/llvm/llvm-project/issues/64356
(cherry picked from commit a18e92d020b895b712175a3b13a3d021608115a7)
|
|
The TargetGuard fields for 'svldr[_vnum]_za' and 'svstr[_vnum]_za' were
incorrectly set to `+sve` instead of `+sme`. This means that compiling
code that uses these intrinsics requires compiling for both `+sve` as
well as `+sme`.
This PR also fixes the target guards for the `svadd` and `svsub`
builtins that are enabled under `+sme2,+sme-i16i64` and
`+sme2,+sme-f64f64`, as it initially did the following:
```
let TargetGuard = "+sme2" in {
let TargetGuard = "+sme-i16i64" in {
// Builtins defined here will be predicated only by
// '+sme-i16i64', and not '+sme2,+sme-i16i64'.
}
}
```
This PR also removes `-target-feature +sve` from all the SME tests, to
ensure that the SME features are sufficient to build the tests.
(cherry picked from commit 3d186a77cf1aa979014a6443cb423a633c167d9f)
|
|
This crash is basically caused by calling
`ASTContext::getRawCommentForDeclNoCacheImp` with its input arguments
`RepresentativeLocForDecl` and `CommentsInTheFile` refering to different
files. A reduced reproducer is provided in this patch.
After the source locations for instantiations of funtion template are
corrected in the commit 256a0b298c68b89688b80350b034daf2f7785b67, the
variable `CommitsInThisFile` in the function
`ASTContext::attachCommentsToJustParsedDecls` would refer to the source
file rather than the header file for implicit function template
instantiation. Therefore, in the first loop in
`ASTContext::attachCommentsToJustParsedDecls`, `D` should also be
adjusted for relevant scenarios like the second loop.
Fixes #67979
Fixes #68524
Fixes #70550
(cherry picked from commit 5f4ee5a2dfa97fe32ee62d1d67aa1413d5a059e6)
|
|
Close https://github.com/llvm/llvm-project/issues/79240
Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:
> There are two kinds of bugs / issues relevant here:
>
> Clang bugs that this change hides
> Here we can add a Frontend flag that disables the GMF ODR check, just
> so
> we can keep tracking, testing and fixing these issues.
> The Driver would just always pass that flag.
> We could add that flag in this current issue.
> Bugs in user code:
> I don't think it's worth adding a corresponding Driver flag for
> controlling the above Frontend flag, since we intend it's behavior to
> become default as we fix the problems, and users interested in testing
> the more strict behavior can just use the Frontend flag directly.
This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default
off, so that the every existing test will still be tested with checking
ODR violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior
we intended.
- Edit the document to tell the users who are still interested in more
strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the
existing behavior.
|
|
Previosly we land
https://github.com/llvm/llvm-project/commit/085eae6b863881fb9fda323e5b672b04a00ed19e
to workaround the false positive ODR violations in
https://github.com/llvm/llvm-project/issues/76638.
However, we decided to not perform ODR checks for decls from GMF in
https://github.com/llvm/llvm-project/issues/79240 and we land the
corresponding change. So we should be able to remove the workaround now.
The original tests get remained.
|
|
Close https://github.com/llvm/llvm-project/issues/79240.
See the linked issue for details. Given the frequency of issue reporting
about false positive ODR checks (I received private issue reports too),
I'd like to backport this to 18.x too.
|
|
attempting access check. (#80730)
Previously when fixing ambiguous lookup diagnostics in
cc1b6668c57170cd440d321037ced89d6a61a9cb The change refactored
`LookupResult` to split out diagnosing access and ambiguous lookups. The
call to `getSema().CheckLookupAccess(...)` should have guarded by a
check for isAmbiguous(). This change adds that guard.
Fixes: https://github.com/llvm/llvm-project/issues/80435
(cherry picked from commit a7bc9cb6ffa91ff0ebabc45c0c7263c7c2c3a4de)
|
|
Backporting https://github.com/llvm/llvm-project/pull/79568 to clang 18.
|
|
With a690e86 we added -mcpu/mtune=native support to handle the Microsoft
Azure Cobalt 100 CPU as a Neoverse N2. This patch adds a CPU alias in
TargetParser to maintain compatibility with GCC.
(cherry picked from commit ae8005ffb6cd18900de8ed5a86f60a4a16975471)
|
|
In https://github.com/llvm/llvm-project/pull/76873 a warning was added
when the macros INFINITY and NAN are used in binary expressions when
-menable-no-nans or -menable-no-infs are used. If the user uses an
option that nullifies these two options, the warning will still be
generated. This patch adds an additional information to the warning
comment to let the user know about this. It also suppresses the warning
when #ifdef INFINITY, #ifdef NAN, #ifdef NAN or #ifndef NAN are used in
the code.
(cherry picked from commit 62c352e13c145b5606ace88ecbe9164ff011b5cf)
|
|
This adds GCC-compatible names for code model selection on 64-bit SPARC
with absolute code.
Testing with a 2-stage build then running codegen tests works okay under
all of the supported code models.
(32-bit target does not have selectable code models)
Reviewed By: @brad0, @MaskRay
(cherry picked from commit b0f0babff22e9c0af74535b05e2c6424392bb24a)
|
|
When a function F has ZA and ZT0 state, calls another function G that
only shares ZT0 state with its caller, F will have to save ZA before
the call to G, and restore it afterwards (rather than setting up a
lazy-sve).
This is not yet implemented in LLVM and does not result in a
compile-time error either. So instead of silently generating incorrect
code, it's better to emit an error saying this is not yet implemented.
(cherry picked from commit 319f4c03ba2909c7240ac157cc46216bf1518c10)
|
|
This returns (probably temporarily) array-referring NTTP behavior to
which was prior to #78041 because ~~I'm fed up~~ have no time to fix
regressions.
(cherry picked from commit 9bf4e54ef42d907ae7550f36fa518f14fa97af6f)
|
|
to release/18.x (#80109)
Cherry picked from commit ee01a2c3996f9647f3158f5acdb921a6ede94dc1.
Closes #80041, backport #80108.
Co-authored-by: Shafik Yaghmour <shafik@users.noreply.github.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
|
|
__ARM_STATE_ZA and __ARM_STATE_ZT0 are set when the compiler can parse
the "za" and "zt0" strings in the SME attributes.
__ARM_FEATURE_SME and __ARM_FEATURE_SME2 are set when the compiler can
generate code for attributes with "za" and "zt0" state, respectively.
__ARM_FEATURE_LOCALLY_STREAMING is set when the compiler supports the
__arm_locally_streaming attribute.
(cherry picked from commit 9e649518e6038a5b9ea38cfa424468657d3be59e)
|
|
`ExprWithCleanups` (#80292)
Fixes https://github.com/llvm/llvm-project/issues/80285
(cherry picked from commit bfc6eaa26326e4d0d20d1f4a1f0064c6df0135bd)
|
|
`OpaqueValueExpr` doesn't necessarily contain a source expression.
Particularly, after #78041, it is used to carry the type and the value
kind of a non-type template argument of floating-point type or referring
to a subobject (those are so called `StructuralValue` arguments).
This fixes #79575.
(cherry picked from commit ef67f63fa5f950f4056b5783e92e137342805d74)
|
|
This adopts a similar behavior to AArch64 SVE, where bool vectors are
represented as a vector of chars with 1/8 the number of elements. This
ensures the vector always occupies a power of 2 number of bytes.
A consequence of this is that vbool64_t, vbool32_t, and vool16_t can
only be used with a vector length that guarantees at least 8 bits.
|
|
The Zicond extension was ratified in the last few months, with no
changes that affect the LLVM implementation. Although there's surely
more tuning that could be done about when to select Zicond or not, there
are no known correctness issues. Therefore, we should mark support as
non-experimental.
(cherry-picked from commit d833b9d677c9dd0a35a211e2fdfada21ea9a464b)
|
|
same type) (#77768)"
This reverts commit 924701311aa79180e86ad8ce43d253f27d25ec7d. Causes compilation
errors on valid code, see
https://github.com/llvm/llvm-project/pull/77768#issuecomment-1908062472.
(cherry picked from commit 6e4930c67508a90bdfd756f6e45417b5253cd741)
|
|
Flags `-fveclib=name` were not passed to LTO flags.
This pass fixes that by converting the `-fveclib` flags to their
relevant names for opt's `-vector-lib=name` flags.
For example:
`-fveclib=SLEEF` would become `-vector-library=sleefgnuabi` and passed
through the `-plugin-opt` flag.
(cherry picked from commit 03cf0e9354e7e56ff794e9efb682ed2971bc91ec)
|
|
Fixes a regression from #78041 as reported in the review. The original
patch failed to compare the canonical type, which this adds. A slightly
modified test of the original report is added.
(cherry picked from commit e3ee3762304aa81e4a240500844bfdd003401b36)
|
|
Fix and add a test case for combining '-ffat-lto-objects -c -emit-llvm'
options and fix a spelling mistake in same test.
(cherry picked from commit f1b1611148fa533fe198fec3fa4ef8139224dc80)
|
|
(#78414)
…bf8 instructions
Add VOP1, VOP1_DPP8, VOP1_DPP16, VOP3, VOP3_DPP8, VOP3_DPP16
instructions that were supported on GFX940 (MI300):
- V_CVT_F32_FP8
- V_CVT_F32_BF8
- V_CVT_PK_F32_FP8
- V_CVT_PK_F32_BF8
- V_CVT_PK_FP8_F32
- V_CVT_PK_BF8_F32
- V_CVT_SR_FP8_F32
- V_CVT_SR_BF8_F32
---------
Co-authored-by: Mateja Marjanovic <mateja.marjanovic@amd.com>
Co-authored-by: Mirko Brkušanin <Mirko.Brkusanin@amd.com>
(cherry picked from commit cfddb59be2124f7ec615f48a2d0395c6fdb1bb56)
|
|
Co-authored-by: Petar Avramovic <Petar.Avramovic@amd.com>
Co-authored-by: Piotr Sobczak <piotr.sobczak@amd.com>
|
