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)
Use i32 for offset instead of i16, this way it does not get interpreted
as negative 16 bit offset.
(cherry picked from commit 83fe85115da9dc25fa270d2ea8140113c8d49670)
Large scratch offset with one on highest bit selected as negative,
negative offset has same binary representation in 16 bits as large
unsigned offset.
(cherry picked from commit e9d12a6b451bd403d95105aa976a011dc821f126)
In ExpandFPLibCall, an assumption is made that all floating point
libcalls that take integer arguments use unsigned integers. In the case
of ldexp and frexp, this assumption is incorrect, leading to
miscompilation and subsequent target-dependent incorrect operation.
Indicate that ldexp and frexp utilize signed arguments in
ExpandFPLibCall.
Fixes#108904
Signed-off-by: Timothy Pearson <tpearson@solidsilicon.com>
(cherry picked from commit 90c14748638f1e10e31173b145fdbb5c4529c922)
Since a26ec542371652e1d774696e90016fd5b0b1c191, we expand the executable
name to an absolute path, if it isn't already one, if found in path.
This broke a couple tests in some environments; when the clang workdir
resides in a path under e.g. /opt. Tests that only use a tool name like
"clang-cl" would get expanded to the absolute path in the build tree.
The loop for finding the last "-o" like option for clang-cl command
lines would inspect all arguments, including Args[0] which is the
executable name itself. As an /opt path matches Arg.starts_with("/o"),
this would get detected as an object file output name in cases where
there was no other explicit output argument.
Thus, this fixes those tests in workdirs under e.g. /opt.
(cherry picked from commit cead9044a995910306e2e64b426fcc8042d7e0ef)
This allows the clang driver to know which tool is meant to be executed,
which allows the clang driver to load the right clang config files, and
allows clang to find colocated sysroots.
This makes sure that doing `clang-scan-deps -- <tool> ...` looks up
things in the same way as if one just would execute `<tool> ...`, when
`<tool>` isn't an absolute or relative path.
(cherry picked from commit a26ec542371652e1d774696e90016fd5b0b1c191)
This fixes building in this configuration after
87e1104cf0e2de0d04bee2944893fa7897277b2f.
(cherry picked from commit aa3465793a250faa5426ac626989375465256658)
