The ASTWriter currently assumes template type constraints to be
initialized ((bool)getTypeConstraint() == hasTypeConstraint()). Issues
#99036 and #109354 identified a scenario where this assertion is
violated.
This patch removes the assumption and adds another boolean to the
serialization, to explicitly encode whether the type constraint has been
initialized.
The same issue was incidentally fixed on the main branch by #111179.
This solution avoids backporting #111179 and its dependencies.
LazyOffsetPtr currently relies on uint64_t being able to store a pointer
and, unless sizeof(uint64_t) == sizeof(void *), little endianness, since
getAddressOfPointer reinterprets the memory as a pointer. This also
doesn't properly respect the C++ object model.
As removing getAddressOfPointer would have wide-reaching implications,
improve the implementation to account for these problems by using
placement new and a suitably sized-and-aligned buffer, "right"-aligning
the objects on big-endian platforms so the LSBs are in the same place
for use as the discriminator.
Fixes: bc73ef0031b50f7443615fef614fb4ecaaa4bd11
Fixes: https://github.com/llvm/llvm-project/issues/111993
(cherry picked from commit 76196998e25b98d81abc437708622261810782ca)
'rjmp .+4094' is legal but rejected by llvm-mc since
86a60e7f1e8f361f84ccb6e656e848dd4fbaa713, and this patch fixed that
range issue.
(cherry picked from commit 8c3b94f420a20a45dd07f3e12d6a6d649858f452)
With -fsanitize-cfi-icall-experimental-normalize-integers, Clang
appends ".normalized" to KCFI types in CodeGenModule::CreateKCFITypeId,
which changes type hashes also for functions that don't have integer
types in their signatures. However, llvm::setKCFIType does not take
integer normalization into account, which means LLVM generated
functions with KCFI types, e.g. sanitizer constructors, will fail KCFI
checks when integer normalization is enabled in Clang.
Add a cfi-normalize-integers module flag to indicate integer
normalization is used, and append ".normalized" to KCFI types also in
llvm::setKCFIType to fix the type mismatch.
(cherry picked from commit e1c36bde0551977d4b2efae032af6dfc4b2b3936)
The whole struct is specificed in the __bdos. The calculation of the
whole size of the structure can be done in two ways:
1) sizeof(struct S) + count * sizeof(typeof(fam))
2) offsetof(struct S, fam) + count * sizeof(typeof(fam))
The first will add any remaining whitespace that might exist after
allocation while the second method is more precise, but not quite
expected from programmers. See [1] for a discussion of the topic.
GCC isn't (currently) able to calculate __bdos on a pointer to the whole
structure. Therefore, because of the above issue, we'll choose to match
what GCC does for consistency's sake.
[1] https://lore.kernel.org/lkml/ZvV6X5FPBBW7CO1f@archlinux/
Co-authored-by: Eli Friedman <efriedma@quicinc.com>
This fixes a problem introduced in #80094. That PR copied negative
features from the TargetMachine to the end of the feature string. This
is not correct, because even if we have a baseline TM of say `-simd128`,
but a function with `+simd128`, the coalesced feature string should have
`+simd128`, not `-simd128`.
To address the original motivation of that PR, we should instead
explicitly materialize the negative features in the target feature
string, so that explicitly disabled default features are honored.
Unfortunately, there doesn't seem to be any way to actually test this
using llc, because `-mattr` appends the specified features to the end of
the `"target-features"` attribute. I've tested this locally by making it
prepend the features instead.
(cherry picked from commit 5a7b79c93e2e0c71aec016973f5f13d3bb2e7a62)
This is a backport of 387b37af1aabf325e9be844361564dfad8d45c75 for 19.x,
adjusted to add new Triple::EnvironmentType members at the end to avoid
breaking backwards ABI compatibility.
Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
TypedefNameDecl referenced by a synthesized CTAD guide for type aliases
was not transformed previously, resulting in a substitution failure in
BuildDeductionGuideForTypeAlias() when substituting into the
right-hand-side deduction guide.
This patch fixes it in the way we have been doing since
https://reviews.llvm.org/D80743. We transform all the function
parameters, parenting referenced TypedefNameDecls with the
CXXDeductionGuideDecl. Then we instantiate these declarations in
FindInstantiatedDecl() as we build up the eventual deduction guide,
using the mechanism introduced in D80743
Fixes#111508
(cherry picked from commit 0bc02b999a9686ba240b7a68d3f1cbbf037d2170)
- **[Inliner] Add tests for bad propagationg of access attr for `byval`
param; NFC**
- **[Inliner] Don't propagate access attr to `byval` params**
We previously only handled the case where the `byval` attr was in the
callbase's param attr list. This PR also handles the case if the
`ByVal` was a param attr on the function's param attr list.
(cherry picked from commit 3c777f04f065dda5f0c80eaaef2a7f623ccc20ed)
This change is identical to
26800a2c7e7996dc773b4e990dd5cca41c45e1a9 ("[sanitizer] Undef
_TIME_BITS along with _FILE_OFFSET_BITS on Linux"), but for
sanitizer_procmaps_solaris.cpp.
Indeed, even though sanitizer_procmaps_solaris.cpp is Solaris
specific, it also gets built on Linux platforms. It also includes
sanitizer_platform.h, which also ends up including features-time64.h,
causing a build failure on 32-bit Linux platforms on which 64-bit
time_t is enabled by setting _TIME_BITS=64.
To fix this, we do the same change: undefine _TIME_BITS, which anyway
will cause no harm as the rest of this file is inside a
SANITIZER_SOLARIS compile-time conditional.
Fixes:
In file included from /home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features.h:394,
from ../../../../libsanitizer/sanitizer_common/sanitizer_platform.h:25,
from ../../../../libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp:14:
/home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is al
lowed only with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^~~~~
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Closes: https://github.com/llvm/llvm-project/pull/99699
(cherry picked from commit a1217020da219386b29c1a5a4a217904ecf07d7d)
In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.
Fixes: llvm/llvm-project#95581.
cc: @jeaye
(cherry picked from commit 6c62ad446b2441b78ae524d9e700e351d5a76394)
When encountering an instruction like `if (p0) r0 = add(r0,##bar@GOT)`,
lld would fail with:
```
ld.lld: error: unrecognized instruction for 16_X type: 0x7400C000
```
This issue was encountered while building libreadline with clang 19.1.0.
Fixes: #111876
(cherry picked from commit 77aa8257acbd773c0c430cd962da1bcfbd5ee94b)
To Fix#110215
Interceptors introduced with 18a7ebda99044473fdbce6376993714ff54e6690
(cherry picked from commit d0b9c2c5647656738cda3fb670aa5d3b3a69d784)
This bails out if we see an intrinsic with an operand bundle on it, to
make sure we don't process the bundles incorrectly.
Fixes#110382.
(cherry picked from commit c136d3237a3c6230cfe1ab3f0f6790f903c54a27)
`__has_builtin` was relying on reversible identifiers and string
matching to recognize builtin-type traits, leading to some newer type
traits not being recognized.
Fixes#111477
This was using the default address space instead of the
correct one.
Fixes#56055
Keep old method around for ABI compatibility on the release branch.
(cherry picked from commit 81ba95cefe1b5a12f0a7d8e6a383bcce9e95b785)
In 6a884a9aef39, I synchronized the export list of libc++abi to the
export list of libc++. From the linker's perspective, this caused these
symbols to be taken from libc++.dylib instead of libc++abi.dylib.
However, that can be problematic when back-deploying. Indeed, this means
that the linker will encode an undefined reference to be fullfilled by
libc++.dylib, but when backdeploying against an older system, that
symbol might only be available in libc++abi.dylib.
Most of the symbols that started being re-exported after 6a884a9aef39
turn out to be implementation details of libc++abi, so nobody really
depends on them and this back-deployment issue is inconsequential.
However, we ran into issues with a few of these symbols while testing
LLVM 19, which led to this patch. This slipped between the cracks and
that is why the patch is coming so long after the original patch landed.
In the future, a follow-up cleanup would be to stop exporting most of
the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
since they are implementation details that nobody should be relying on.
rdar://131984512
(cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c)
Fix counted_by attribute for cases where the flexible array member is
accessed through struct pointer inside another struct:
```
struct variable {
int a;
int b;
int length;
short array[] __attribute__((counted_by(length)));
};
struct bucket {
int a;
struct variable *growable;
int b;
};
```
__builtin_dynamic_object_size(p->growable->array, 0);
This commit makes sure that if the StructBase is both a MemberExpr and a
pointer, it is treated as a pointer. Otherwise clang will generate to
code to access the address of p->growable intead of loading the value of
p->growable->length.
Fixes#110385
PR #74625 introduced a regression in the code generated for the
following set of intrinsic:
vec_add_u128, vec_addc_u128, vec_adde_u128, vec_addec_u128
vec_sub_u128, vec_subc_u128, vec_sube_u128, vec_subec_u128
vec_sum_u128, vec_msum_u128
vec_gfmsum_128, vec_gfmsum_accum_128
This is because the new code incorrectly assumed that a cast
from "unsigned __int128" to "vector unsigned char" would simply
be a bitcast re-interpretation; instead, this cast actually
truncates the __int128 to char and splats the result.
Fixed by adding an intermediate cast via a single-element
128-bit integer vector.
Fixes: https://github.com/llvm/llvm-project/issues/109113
(cherry picked from commit baf9b7da81025c1e3b0704d7ecf667e06f95642b)
The special-casing for RequiresExprBodyDecl caused a regression, as
reported in #110785.
The original fix for #84020 has been superseded by fd87d765c0, which
establishes a `DependentScopeDeclRefExpr` instead of a
`CXXDependentScopeMemberExpr` for the case in issue. So the spurious
diagnostic in #84020 would no longer occur.
This also merges the test for #84020 together with that for #110785 into
clang/test/SemaTemplate/instantiate-requires-expr.cpp.
No release note because I think this merits a backport.
Fixes#110785
(cherry picked from commit 8c1547055eaf65003f3e6fd024195f4926ff2356)
Windows does not support float C89 math functions like:
- acosf
- asinf
- atanf
- coshf
- sinhf
- tanhf
These 6 libfuncs need to be type promoted.
This PR fixes the bug introduced by https://github.com/llvm/llvm-project/pull/98949
On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.
(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)
This is instead of pushing directly. Creating a pull request is slightly
more work for the release manager, but it is more secure as we no longer
need a secret with write access to the www-releases repo.
(cherry picked from commit 9cd289fa4a7355e1bfd3129ba9c755f979fd0a72)
The actions/checkout step will clear the current directory, so we need
to checkout the sources first so that the downloaded artifacts won't be
deleted.
(cherry picked from commit 8f2aa9dbad7c1400f66e1ee1c43b071a1905f3e6)
This was mistakely changed by #109579, which doesn't match with other
EVEX decoding.
(cherry picked from commit 70529b24a30943d46e361d2990268499921e28a2)
Promoted KMOV* was encoded with CD8 incorrectly, see
https://godbolt.org/z/cax513hG1
(cherry picked from commit 0d334d83a4c7ce16fa1bc0e5e56bbdeaf01c2b2d)
Multiple invocations of the pass could interfere with eachother,
preventing some undefs being initialised.
I found it very difficult to create a unit test for this due to it being
dependent on particular allocations of a previous function. However, the
bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the
creation of the illegal instruction `vnsrl.wi v9, v8, 0`
Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.
This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.
Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.
(cherry picked from commit 6f6422f4a2b8647a59936c131e50a79906d89510)
