Reproducer:
```
//--- a.cppm
export module a;
int func();
static int a = func();
//--- a.cpp
import a;
```
The `func()` should only execute once. However, before this patch we
will somehow import `static int a` from a.cppm incorrectly and
initialize that again.
This is super bad and can introduce serious runtime behaviors.
And also surprisingly, it looks like the root cause of the problem is
simply some oversight choosing APIs.
(cherry picked from commit 259eaa6878ead1e2e7ef572a874dc3d885c1899b)
While building llvm (clang, lld) for wasm using emscripten (recipe
hosted on emscripten-forge
https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/llvm)
I ended up with this error
```
│ │ wasm-ld: error: ../../../../lib/libclangInterpreter.a(Wasm.cpp.o): undefined symbol: lld::wasm::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm:
│ │ :raw_ostream&, bool, bool)
```
This is due to the link function here
a4819bd46d/clang/lib/Interpreter/Wasm.cpp (L25-L30)
This was added through this PR (https://github.com/llvm/llvm-project/pull/86402) as an attempt to support running clang-repl and executing C++ code interactively inside a Javascript engine using WebAssembly when built with Emscripten.
The definition for link is present in lldwasm and when building for the emscripten platform we should be linking against it.
(cherry picked from commit 075581f34035c01659cc883d0d69336c279ef0d5)
The lsxintrin.h and and lasxintrin.h headers uses `unsigned char`
vectors instead of `signed char` vectors. GCC also uses `unsigned char`
for them, so align their definition with the headers and GCC.
Fixes#110834.
Depends on #114512.
(cherry picked from commit 4f740f9d77cd038c8e55195fa189748e58ea6476)
The lsxintrin.h and and lasxintrin.h headers uses `signed char` vectors
instead of `unsigned char` vectors. GCC also uses `signed char` for
them, so align their definition with the headers and GCC.
Depends on #114511. Part of #110834 fix.
(cherry picked from commit 4006b28d102b09f4c736ef0f2664873305fedcd3)
These builtins operate on int8 vectors, not int16 vectors. So the old
definition does not make any sense.
Depends on #114510. Part of #110834 fix.
(cherry picked from commit 92daad2eac587cb0592de019cd5f6cbb7c42bb78)
`-flax-vector-conversions=none` does not allow an implicit conversion
from `signed char` vector to `char` vector, and we cannot remove
`signed`
from `v16i8` or `v32i8` because doing so will break our expectation with
`-fno-signed-char`. So to make lsxintrin.h and lasxintrin.h work fine
with `-flax-vector-conversions=none`, we must use `signed char` instead
of `char`.
The change is just done via
sed 's/V16c/V16Sc/g' -i BuiltinsLoongArchLSX.def
sed 's/V32c/V32Sc/g' -i BuiltinsLoongArchLASX.def
Depends on #114509. Part of #110834 fix.
(cherry picked from commit b88505414d47ca267f4df8823309264f78935686)
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)
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 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)
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)
`__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
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)
On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.
(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)
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)
This allows clang-scan-deps to work correctly when using cross compilers
with names like <triple>-clang.
(cherry picked from commit 87e1104cf0e2de0d04bee2944893fa7897277b2f)
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
(cherry picked from commit 8927576b8f6442bb6129bda597efee46176f8aec)
We established an instantiation scope in order for constraint
equivalence checking to properly map the uninstantiated parameters.
That mechanism mapped even packs to themselves. Consequently, parameter
packs e.g. appearing in a function call, were not expanded. So they
would end up becoming `SubstTemplateTypeParmPackType`s that circularly
depend on the canonical declaration of the function template, which is
not yet determined, hence the spurious error.
No release note as I plan to backport it to 19.
Fixes https://github.com/llvm/llvm-project/issues/101735
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
(cherry picked from commit e6974daa7bc100c8b88057d50f3ec3eca7282243)
This fixes a regression from f58330cbe44598eb2de0cca3b812f67fea0a71ca.
That commit changed the clang-cl options /Zi and /Z7 to be implemented
as aliases of -g rather than having separate handling.
This had the unintended effect, that when assembling .s files with
clang-cl, the /Z7 option (which implies using CodeView debug info) was
treated as a -g option, which causes `ClangAs::ConstructJob` to pick up
the option as part of `Args.getLastArg(options::OPT_g_Group)`, which
sets the `WantDebug` variable.
Within `Clang::ConstructJob`, we check for whether explicit `-gdwarf` or
`-gcodeview` options have been set, and if not, we pick the default
debug format for the current toolchain. However, in `ClangAs`, if debug
info has been enabled, it always adds DWARF debug info.
Add similar logic in `ClangAs` - check if the user has explicitly
requested either DWARF or CodeView, otherwise look up the toolchain
default. If we (either implicitly or explicitly) should be producing
CodeView, don't enable the default `ClangAs` DWARF generation.
This fixes the issue, where assembling a single `.s` file with clang-cl,
with the /Z7 option, causes the file to contain some DWARF sections.
This causes the output executable to contain DWARF, in addition to the
separate intended main PDB file.
By having the output executable contain DWARF sections, LLDB only looks
at the (very little) DWARF info in the executable, rather than looking
for a separate standalone PDB file. This caused an issue with LLDB's
tests, https://github.com/llvm/llvm-project/issues/101710.
(cherry picked from commit fcb7b390ccd5b4cfc71f13b5e16a846f3f400c10)
We were incorrectly not deduplicating results when looking up `_` which,
for a lambda init capture, would result in an ambiguous lookup.
The same bug caused some diagnostic notes to be emitted twice.
Fixes#107024
In #78436 we made some SourceLocExpr dependent to
deal with the fact that their value should reflect the name of
specialized function - rather than the rtemplate in which they are first
used.
However SourceLocExpr are unusual in two ways
- They don't depend on template arguments
- They morally depend on the context in which they are used (rather than
called from).
It's fair to say that this is quite novels and confuses clang. In
particular, in some cases, we used to create dependent SourceLocExpr and
never subsequently transform them, leaving dependent objects in
instantiated functions types. To work around that we avoid replacing
SourceLocExpr when we think they could remain dependent.
It's certainly not perfect but it fixes a number of reported bugs, and
seem to only affect scenarios in which the value of the SourceLocExpr
does not matter (overload resolution).
Fixes#106428Fixes#81155Fixes#80210Fixes#85373
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Fix codegen of consteval functions returning an empty class, and related
issues
If a class is empty, don't store it to memory: the store might overwrite
useful data. Similarly, if a class has tail padding that might overlap
other fields, don't store the tail padding to memory.
The problem here turned out a bit more general than I initially thought:
basically all uses of EmitAggregateStore were broken. Call lowering had
a method that did mostly the right thing, though: CreateCoercedStore.
Adapt CreateCoercedStore so it always does the conservatively right
thing, and use it for both calls and ConstantExpr.
Also, along the way, fix the "overlap" bit in AggValueSlot: the bit was
set incorrectly for empty classes in some cases.
Fixes#93040.
(cherry picked from commit 1762e01cca0186f1862db561cfd9019164b8c654)
