RVV intrinsics has new overloading rule, please see
82aac7dad4
Changed:
1. Rename `generic` to `overloaded` because the new rule is not using C11 generic.
2. Change HasGeneric to HasNoMaskedOverloaded because all masked operations
support overloading api.
3. Add more overloaded tests due to overloading rule changed.
Differential Revision: https://reviews.llvm.org/D99189
I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inalloca, so catch this up to the others so that can
happen.
Breaking a string literal or a function calls arguments with
AlignConsecutiveDeclarations or AlignConsecutiveAssignments did misalign
the continued line. E.g.:
void foo() {
int myVar = 5;
double x = 3.14;
auto str = "Hello"
"World";
}
or
void foo() {
int myVar = 5;
double x = 3.14;
auto str = "Hello"
"World";
}
Differential Revision: https://reviews.llvm.org/D98214
Currently we want to allow calling non-const methods even when only a
shared lock is held, because -Wthread-safety-reference is already quite
sensitive and not all code is const-correct. Even if it is, this might
require users to add std::as_const around the implicit object argument.
See D52395 for a discussion.
Fixes PR46963.
The contents of the string returned by getenv() is not guaranteed across calls to getenv(). The code to handle the CC_PRINT etc env vars calls getenv() and saves the results in just a char *. The string returned by getenv() needs to be copied and saved. Switching the type of the strings from char * to std::string will do this and manage the alloated memory.
Differential Revision: https://reviews.llvm.org/D98554
Zero length bitfield alignment is not respected if they are leading members on z/OS target.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D98890
This patch should fix the errors shown on the Windows bots by turning off text mode. I plan to investigate a better fix but this should unblock the buildbots for now.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D99363
When emitting a function body there needs to be a instr profiling counter emitted. Otherwise instr profiling won't work for this function.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D98135
tl;dr Correct implementation of Corouintes requires having lifetime intrinsics available.
Coroutine functions are functions that can be suspended and resumed latter. To do so, data that need to stay alive after suspension must be put on the heap (i.e. the coroutine frame).
The optimizer is responsible for analyzing each AllocaInst and figure out whether it should be put on the stack or the frame.
In most cases, for data that we are unable to accurately analyze lifetime, we can just conservatively put them on the heap.
Unfortunately, there exists a few cases where certain data MUST be put on the stack, not on the heap. Without lifetime intrinsics, we are unable to correctly analyze those data's lifetime.
To dig into more details, there exists cases where at certain code points, the current coroutine frame may have already been destroyed. Hence no frame access would be allowed beyond that point.
The following is a common code pattern called "Symmetric Transfer" in coroutine:
```
auto tmp = await_suspend();
__builtin_coro_resume(tmp.address());
return;
```
In the above code example, `await_suspend()` returns a new coroutine handle, which we will obtain the address and then resume that coroutine. This essentially "transfered" from the current coroutine to a different coroutine.
During the call to `await_suspend()`, the current coroutine may be destroyed, which should be fine because we are not accessing any data afterwards.
However when LLVM is emitting IR for the above code, it needs to emit an AllocaInst for `tmp`. It will then call the `address` function on tmp. `address` function is a member function of coroutine, and there is no way for the LLVM optimizer to know that it does not capture the `tmp` pointer. So when the optimizer looks at it, it has to conservatively assume that `tmp` may escape and hence put it on the heap. Furthermore, in some cases `address` call would be inlined, which will generate a bunch of store/load instructions that move the `tmp` pointer around. Those stores will also make the compiler to think that `tmp` might escape.
To summarize, it's really difficult for the mid-end to figure out that the `tmp` data is short-lived.
I made some attempt in D98638, but it appears to be way too complex and is basically doing the same thing as inserting lifetime intrinsics in coroutines.
Also, for reference, we already force emitting lifetime intrinsics in O0 for AlwaysInliner: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Passes/PassBuilder.cpp#L1893
Differential Revision: https://reviews.llvm.org/D99227
These contain clang driver changes for supporting HWASan on Fuchsia.
This includes hwasan multilibs and the dylib path change.
Differential Revision: https://reviews.llvm.org/D99361
Add builtin function __builtin_get_device_side_mangled_name
to get device side manged name for functions and global
variables, which can be used to get symbol address of kernels
or variables by mangled name in dynamically loaded
bundled code objects at run time.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D99301
`expandedTokens(SourceRange)` used to do a binary search to get the
expanded tokens belonging to a source range. Each binary search uses
`isBeforeInTranslationUnit` to order two source locations. This is
inherently very slow.
By profiling clangd we found out that users like clangd::SelectionTree
spend 95% of time in `isBeforeInTranslationUnit`. Also it is worth
noting that users of `expandedTokens(SourceRange)` majorly use ranges
provided by AST to query this funciton. The ranges provided by AST are
token ranges (starting at the beginning of a token and ending at the
beginning of another token).
Therefore we can avoid the binary search in majority of the cases by
maintaining an index of ExpandedToken by their SourceLocations. We still
do binary search for ranges which are not token ranges but such
instances are quite low.
Performance:
`~/build/bin/clangd --check=clang/lib/Serialization/ASTReader.cpp`
Before: Took 2:10s to complete.
Now: Took 1:13s to complete.
Differential Revision: https://reviews.llvm.org/D99086
Currently, we infer 0 if the divisible of the modulo op is 0:
int a = x < 0; // a can be 0
int b = a % y; // b is either 1 % sym or 0
However, we don't when the op is / :
int a = x < 0; // a can be 0
int b = a / y; // b is either 1 / sym or 0 / sym
This commit fixes the discrepancy.
Differential Revision: https://reviews.llvm.org/D99343
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used.
```
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFile(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true, bool IsVolatile = false);
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFileOrSTDIN(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true);
static ErrorOr<std::unique_ptr<MB>>
getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset,
bool IsText, bool RequiresNullTerminator, bool IsVolatile);
static ErrorOr<std::unique_ptr<WritableMemoryBuffer>>
getFile(const Twine &Filename, bool IsVolatile = false);
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D99182
In order to test the preservation of the original Debug Info metadata
in your projects, a front end option could be very useful, since users
usually report that a concrete entity (e.g. variable x, or function fn2())
is missing debug info. The [0] is an example of running the utility
on GDB Project.
This depends on: D82546 and D82545.
Differential Revision: https://reviews.llvm.org/D82547
Before we unified the names of the builtins across all the
compilers, there were a number of synonyms between them. There
is code out there that uses XL naming for some of these loads and
stores. This just adds those names.
Commit
f7f9f94b2e
changed the indent of ObjC method arguments from +4 to +2, if the method
occurs after a block statement. I believe this was unintentional and there
was insufficient ObjC test coverage to catch this.
Example: `clang-format -style=google test.mm`
before:
```
void aaaaaaaaaaaaaaaaaaaaa(int c) {
if (c) {
f();
}
[dddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeee:^(fffffffffffffff gggggggg) {
f(SSSSS, c);
}];
}
```
after:
```
void aaaaaaaaaaaaaaaaaaaaa(int c) {
if (c) {
f();
}
[dddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeee:^(fffffffffffffff gggggggg) {
f(SSSSS, c);
}];
}
```
Differential Revision: https://reviews.llvm.org/D99063
Summary: Add -fno-split-stack and rename CC1 option from `-split-stacks`
to `-fsplit-stack`.
Test Plan: check-all
Differential Revision: https://reviews.llvm.org/D99245
```
Warn when a function pointer is cast to an incompatible function
pointer. In a cast involving function types with a variable argument
list only the types of initial arguments that are provided are
considered. Any parameter of pointer-type matches any other
pointer-type. Any benign differences in integral types are ignored, like
int vs. long on ILP32 targets. Likewise type qualifiers are ignored. The
function type void (*) (void) is special and matches everything, which
can be used to suppress this warning. In a cast involving pointer to
member types this warning warns whenever the type cast is changing the
pointer to member type. This warning is enabled by -Wextra.
```
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D97831
This reverts commit aae84b8e39.
The chromium goma folks want to use a Debian sysroot without
lib/x86_64-linux-gnu to perform `clang -c` but no link action. The previous
commit has removed D.getVFS().exists check to make such usage work.
Not only can this save unneeded filesystem stats, it can make `clang
--sysroot=/path/to/debian-sysroot -c a.cc` work (get `-internal-isystem
$sysroot/usr/include/x86_64-linux-gnu`) even without `lib/x86_64-linux-gnu/`.
This should make thakis happy.
As of CMake commit https://gitlab.kitware.com/cmake/cmake/-/commit/d993ebd4,
which first appeared in CMake 3.19.x series, in the compile commands for
clang-cl, CMake puts `--` before the input file. When operating on such a
database, the `InterpolatingCompilationDatabase` - specifically, the
`TransferableCommand` constructor - does not recognize that pattern and so, does
not strip the input, or the double dash when 'transferring' the compile command.
This results in a incorrect compile command - with the double dash and old input
file left in, and the language options and new input file appended after them,
where they're all treated as inputs, including the language version option.
Test files for some tests have names similar enough to be matched to commands
from the database, e.g.:
`.../path-mappings.test.tmp/server/bar.cpp`
can be matched to:
`.../Driver/ToolChains/BareMetal.cpp`
etc. When that happens, the tool being tested tries to use the matched, and
incorrectly 'transferred' compile command, and fails, reporting errors similar
to:
`error: no such file or directory: '/std:c++14'; did you mean '/std:c++14'? [clang-diagnostic-error]`
This happens in at least 4 tests:
Clang Tools :: clang-tidy/checkers/performance-trivially-destructible.cpp
Clangd :: check-fail.test
Clangd :: check.test
Clangd :: path-mappings.test
The fix for `TransferableCommand` removes the `--` and everything after it when
determining the arguments that apply to the new file. `--` is inserted in the
'transferred' command if the new file name starts with `-` and when operating in
clang-cl mode, also `/`. Additionally, other places in the code known to do
argument adjustment without accounting for the `--` and causing the tests to
fail are fixed as well.
Differential Revision: https://reviews.llvm.org/D98824
Functions specified in `-emscripten-cxx-exceptions-allowed`, which is
set by Emscripten's `EXCEPTION_CATCHING_ALLOWED` setting, can be inlined
in LLVM middle ends before we reach WebAssemblyLowerEmscriptenEHSjLj
pass in the wasm backend and thus don't get transformed for exception
catching.
This fixes the issue by adding `--force-attribute=FUNC_NAME:noinline`
for each function name in `-emscripten-cxx-exceptions-allowed`, which
adds `noinline` attribute to the specified function and thus excludes
the function from inlining candidates in optimization passes.
Fixes the remaining half of
https://github.com/emscripten-core/emscripten/issues/10721.
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D99259
Create fix-it hints to fix the order of constructors.
To make this a lot simpler, I've grouped all the warnings for each out of order initializer into 1.
This is necessary as fixing one initializer would often interfere with other initializers.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98745
This patch sets the OF_Text flag correctly for the json file created in Clang::DumpCompilationDatabaseFragmentToDir.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D99200
If emit inlined region for master/critical directives, no need to clear
lambda/block context data, otherwise the variables cannot be found and
it causes a crash at compile time.
Differential Revision: https://reviews.llvm.org/D99280
The original implementation didn't fire on non-template classes when a
base class was an instantiation of a template with a dependent base.
In that case the base of the base is dependent as seen from the base,
but not from the class we're interested in, which isn't a template.
Also it simplifies the code a lot.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98724
Add an option to tell the compiler that it can use privileged instructions.
This patch only adds the option. Backend implementation will be added in a
future patch.
Reviewed By: lei, amyk
Differential Revision: https://reviews.llvm.org/D99193
Files compiled with C++ for OpenCL mode can now have a distinct
file extension - clcpp, then clang driver picks the compilation
mode automatically (-x clcpp) without the use of -cl-std=clc++.
Differential Revision: https://reviews.llvm.org/D96771
This patch documents how `ModuleDepCollector{,PP}` work and what their members store. Also renames somewhat vague `MainDeps` to `FileDeps` and `Deps` to `ModularDeps`.
Depends on D98943.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D98950
This patch extracts the `ModuleName` and `ContextHash` members of `ClangModuleDep`, `FullDependencies` and `ModuleDeps` into a single struct `ModuleID`. This makes it easier to understand how the full dependency graph works.
Reviewed By: Bigcheese, dexonsmith
Differential Revision: https://reviews.llvm.org/D98943
In order to have the same option on power PC LLVM and power PC gcc
the option will be changed from -mrop-protection to -mrop-protect.
The feature will be off by default and turned on when the option is used.
Reviewed By: lei, amyk
Differential Revision: https://reviews.llvm.org/D99185
There are a number of functions in altivec.h that use
vector __int128 which isn't supported on AIX. Those functions
need to be guarded for targets that don't support the type.
Furthermore, the functions that produce quadword instructions
without using the type need a builtin. This patch adds the
macro guards to altivec.h using the __SIZEOF_INT128__ which
is only defined on targets that support the __int128 type.
Review D88220 turns out to have some pretty severe bugs, but I *think*
this patch fixes them.
Paper P1825 is supposed to enable implicit move from "non-volatile objects
and rvalue references to non-volatile object types." Instead, what was committed
seems to have enabled implicit move from "non-volatile things of all kinds,
except that if they're rvalue references then they must also refer to non-volatile
things." In other words, D88220 accidentally enabled implicit move from
lvalue object references (super yikes!) and also from non-object references
(such as references to functions).
These two cases are now fixed and regression-tested.
Differential Revision: https://reviews.llvm.org/D98971
Saves having to manually deallocate storage and keeps InnerArgs will have good cache locality.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D99106
This line has a TODO comment, but the answer to it seems to be "no"
given that clang itself uses attributes on @try statements in its tests.
This ProhibitAttributes() statement is also dead code since
ProhibitAttributs() does not handle GNU attributes at the moment but
those are the only attributes valid in objc.
Differential Revision: https://reviews.llvm.org/D97371
We currently use signed long long instead of ptrdiff_t for offsets
in altivec.h. This has never really presented a problem because
all platforms where we use these are 64-bit. However, now that
we have 32-bit targets, we need to use a meaningful type.
Add overloads that perform subtraction on v1i128 that take and
produce vector unsigned char to avoid needing to use __int128.
The overloads are suffixed with _u128 and are needed for targets
where __int128 isn't supported (AIX).
The OpenCL C specification v3.0.6 s6.15.12.7.5 mentions:
For atomic_fetch and modify functions with key = or, xor, and, min
and max on atomic type atomic_intptr_t, M is intptr_t, and on
atomic type atomic_uintptr_t, M is uintptr_t.
Remove the atomic_fetch_* overloads from opencl-c.h that mix intptr_t
and uintptr_t in the same declaration.
Differential Revision: https://reviews.llvm.org/D98418
Add overloads that perform addition on v1i128 that take and produce
vector unsigned char to avoid needing to use __int128. The overloads
are suffixed with _u128 and are needed for targets where __int128
isn't supported (AIX).
Update ASTImporter to import value of FieldDecl::getCapturedVLAType.
Reviewed By: shafik, martong
Differential Revision: https://reviews.llvm.org/D99062
* List inferred lists of imports in `#pragma clang __debug module_map`.
* Add `#pragma clang __debug modules {all,visible,building}` to dump
lists of known / visible module names or the building modules stack.
GlobalISel is currently not enabled when using -flto since the front-end
-mvllm flags don't get passed through. This change fixes this for Darwin
platforms. We have to do this in the driver because the code generator choice
isn't embedded into the bitcode file.
Differential Revision: https://reviews.llvm.org/D99126
There is no functional change here (hence no new tests). The only change
is to replace a couple uintptr_t members with llvm::PointerIntPair<> to
clean up the code, making it more readable and less error prone.
This cleanup highlighted that the old code was effectively casting away
const. This is fixed by changing some function signatures.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D98889
This reverts commit 933d146f38 and 21b211a8f2
(which mis-identified the issue) but restores i586-linux-gnu which was
removed by `Gnu.cpp: remove obsoleted i386 triple detection from end-of-life distribution versions`.
Looks like i586-linux-gnu was not dead enough (used in a sysroot by Fuchsia build bot based on Debian jessie:)
but i486-linux-gnu should be very dead by now.
ROCm has changed installation path to /opt/rocm-{release}. Add detection
for that. Also support ROCM_PATH environment variable.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D98867
Objective-C apparently allows name conflicts between instance and class
properties, so this is valid code:
```
@protocol DupProp
@property (class, readonly) int prop;
@property (readonly) int prop;
@end
```
The ASTImporter however isn't aware of this and will consider the two properties
as if they are the same property because it just compares their name and types.
This causes that when importing both properties we only end up with one property
(whatever is imported first from what I can see).
Beside generating a different AST this also leads to a bunch of asserts and
crashes as we still correctly import the two different getters for both
properties (the import code for methods does the correct check where it
differentiated between instance and class methods). As one of the setters will
not have its associated ObjCPropertyDecl imported, any call to
`ObjCMethodDecl::findPropertyDecl` will just lead to an assert or crash.
Fixes rdar://74322659
Reviewed By: shafik, kastiglione
Differential Revision: https://reviews.llvm.org/D99077
There was only an `Import` function for `QualType` but not for `Type`.
For correct import of some AST nodes where not `QualType` is used
an import of `Type *` is needed. (It is the case with
`FieldDecl::getCapturedVLAType`.)
Reviewed By: shafik, teemperor, martong
Differential Revision: https://reviews.llvm.org/D98951
This attribute represents the minimum and maximum values vscale can
take. For now this attribute is not hooked up to anything during
codegen, this will be added in the future when such codegen is
considered stable.
Additionally hook up the -msve-vector-bits=<x> clang option to emit this
attribute.
Differential Revision: https://reviews.llvm.org/D98030
Implement the TreeTransform for AsTypeExpr. Split `BuildAsTypeExpr`
out of `ActOnAsTypeExpr`, such that we can call the Build method from
the TreeTransform.
Fixes PR47979.
Differential Revision: https://reviews.llvm.org/D98855
ImmutableSet doesn't seem like the perfect fit for the RangeSet
data structure. It is good for saving memory in a persistent
setting, but not for the case when the population of the container
is tiny. This commit replaces RangeSet implementation and
redesigns the most common operations to be more efficient.
Differential Revision: https://reviews.llvm.org/D86465
Additionally, this patch puts an assertion checking for feasible
constraints in every place where constraints are assigned to states.
Differential Revision: https://reviews.llvm.org/D98948
Debian multiarch additionally adds /usr/include/<triplet> and somehow
Android borrowed the idea. (Note /usr/<triplet>/include is already an
include dir...). On Debian, we should just assume a GCC installation is
available and use its triple.
Summary: Try to enable the support for C++20 coroutine keywords for AST
Matchers.
Reviewers: sammccall, njames93, aaron.ballman
Differential Revision: https://reviews.llvm.org/D96316
08196e0b2e exposed LowerExpectIntrinsic's
internal implementation detail in the form of
LikelyBranchWeight/UnlikelyBranchWeight options to the outside.
While this isn't incorrect from the results viewpoint,
this is suboptimal from the layering viewpoint,
and causes confusion - should transforms also use those weights,
or should they use something else, D98898?
So go back to status quo by making LikelyBranchWeight/UnlikelyBranchWeight
internal again, and fixing all the code that used it directly,
which currently is only clang codegen, thankfully,
to emit proper @llvm.expect intrinsics instead.
Upon reviewing D98898 i've come to realization that these are
implementation detail of LowerExpectIntrinsicPass,
and they should not be exposed to outside of it.
This reverts commit ee8b53815d.
With this change, on Debian x86-64 (with a MULTILIB_OSDIRNAMES local patch
../lib64 -> ../lib; this does not matter because /usr/lib64/crt{1,i,n}.o do not exist),
`clang++ --target=aarch64-linux-gnu a.cc -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath,/usr/aarch64-linux-gnu/lib`
built executable can run under qemu-user. Previously this failed with
`/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../include/c++/10/iostream:38:10: fatal error: 'bits/c++config.h' file not found`
On Arch Linux, due to the MULTILIB_OSDIRNAMES patch and the existence of
/usr/lib64/crt{1,i,n}.o, clang driver may pick
/usr/lib64/crt{1,i,n}.o and cause a linker error. -B can work around the problem.
`clang++ --target=aarch64-linux-gnu -B /usr/aarch64-linux-gnu/lib a.cc -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath,/usr/aarch64-linux-gnu/lib64:/usr/aarch64-linux-gnu/lib`
With this change, for `#include <ar.h>`, `clang --target=aarch64-linux-gnu`
will read `/usr/lib/gcc/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/include/ar.h`
(on Debian gcc->gcc-cross)
instead of `/usr/include/ar.h`. Some glibc headers (e.g. gnu/stubs.h) are different across architectures.
Seem unnecessary to diverge from GCC here.
Beside, lib/../$OSLibDir can be considered closer to the GCC
installation then the system root. The comment should not apply.
After path resolution, it duplicates a subsequent -L entry. The entry below
(lib/gcc/$triple/$version/../../../../$OSLibDir) usually does not exist (e.g.
Arch Linux; Debian cross gcc). When it exists, it typically just has ld.so (e.g.
Debian native gcc) which cannot cause collision. Removing the -L (similar to
reordering it) is therefore justified.
This makes the settings available for use in other passes by housing
them within the Support lib, but NFC otherwise.
See D98898 for the proposed usage in SimplifyCFG
(where this change was originally included).
Differential Revision: https://reviews.llvm.org/D98945
so that when --sysroot is specified, the detected GCC installation will not be
overridden by another from /usr which happens to have a larger version.
This behavior is particularly inconvenient when the system has a larger version
GCC while the user wants to try out an older sysroot.
Delete some tests from linux-ld.c which overlap with cross-linux.c
In GCC, if `-B $prefix` is specified, `$prefix` is used to find executable files and startup files.
`$prefix/include` is added as an include search directory.
Clang overloads -B with GCC installation detection semantics which make the
behavior less predictable (due to the "largest GCC version wins" rule) and
interact poorly with --gcc-toolchain (--gcc-toolchain can be overridden by -B).
* `clang++ foo.cpp` detects GCC installation under `/usr`.
* `clang++ --gcc-toolchain=Inputs foo.cpp` detects GCC installation under `Inputs`.
* `clang++ -BA --gcc-toolchain=B foo.cpp` detects GCC installation under A and B and the larger version wins. With this patch, only B is used for detection.
* `clang++ -BA foo.cpp` detects GCC installation under `A` and `/usr`, and the larger GCC version wins. With this patch `A` is not used for detection.
This patch changes -B to drop the GCC detection semantics. Its executable
searching semantics are preserved. --gcc-toolchain is the recommended option to
specify the GCC installation detection directory.
(
Note: Clang detects GCC installation in various target dependent directories.
`$sysroot/usr` (sysroot defaults to "") is a common directory used by most targets.
Such a directory is expected to contain something like `lib{,32,64}/gcc{,-cross}/$triple`.
Clang will then construct library/include paths from the directory.
)
Differential Revision: https://reviews.llvm.org/D97993
This patch adds a new command line option to clang which outputs the directory containing clangs runtime libraries to stdout.
The primary use case for this command line flag is for build systems using clang-cl. Build systems when using clang-cl invoke the linker, that is either link or lld-link in this case, directly instead of invoking the compiler for the linking process as is common with the other drivers. This leads to issues when runtime libraries of clang, such as sanitizers or profiling, have to be linked in as the compiler cannot communicate the link directory to the linker.
Using this flag, build systems would be capable of getting the directory containing all of clang's runtime libraries and add it to the linker path.
Differential Revision: https://reviews.llvm.org/D98868
It is possible that imported `SourceLocExpr` can cause not expected behavior (if `__builtin_LINE()` is used together with `__LINE__` for example) but still it may be worth to import these because some projects use it.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D98876
At the moment "link.exe" is hard-coded as default linker in MSVC.cpp,
so there's no way to use LLD as default linker for MSVC driver.
This patch adds checking of CLANG_DEFAULT_LINKER to MSVC.cpp and
updates unit-tests that expect link.exe linker to explicitly select it
via -fuse-ld=link, so that buildbots and other builds that set
-DCLANG_DEFAULT_LINKER=foobar don't fail these tests.
This is a squash of
- https://reviews.llvm.org/D98493 (MSVC.cpp change) and
- https://reviews.llvm.org/D98862 (unit-tests change)
Reviewed By: maxim-kuvyrkov
Differential Revision: https://reviews.llvm.org/D98935
Clang currently automates a fair amount of diagnostic checking for
declaration attributes based on the declarations in Attr.td. It checks
for things like subject appertainment, number of arguments, language
options, etc. This patch uses the same machinery to perform diagnostic
checking on statement attributes.
This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to get feedback from Windows users on setting OF_None for all ToolOutputFiles. This seems to have been done as an optimization to prevent CRLF translation on Windows in the past.
Reviewed By: zibi
Differential Revision: https://reviews.llvm.org/D97785
C functions may be declared and defined in different prototypes like below. This patch unifies the checks for mangling names in symbol linkage name emission and debug linkage name emission so that the two names are consistent.
static int go(int);
static int go(a) int a;
{
return a;
}
Test Plan:
Differential Revision: https://reviews.llvm.org/D98799
These experimental builtin functions and the feature macro they were gated
behind have been removed.
Reviewed By: aheejin
Differential Revision: https://reviews.llvm.org/D98907
Updates the names (e.g. widen => extend, saturate => sat) and opcodes of all
SIMD instructions to match the finalized SIMD spec. Deliberately does not change
the public interface in wasm_simd128.h yet; that will require more care.
Depends on D98466.
Differential Revision: https://reviews.llvm.org/D98676
Removes the instruction definitions, intrinsics, and builtins for qfma/qfms,
signselect, and prefetch instructions, which were not included in the final
WebAssembly SIMD spec.
Depends on D98457.
Differential Revision: https://reviews.llvm.org/D98466
Now that the WebAssembly SIMD specification is finalized and engines are
generally up-to-date, there is no need for a separate target feature for gating
SIMD instructions that engines have not implemented. With this change,
v128.const is now enabled by default with the simd128 target feature.
Differential Revision: https://reviews.llvm.org/D98457
Added basic parsing/sema/serialization support to extend the
existing 'destroy' clause for use with the 'interop' directive.
Differential Revision: https://reviews.llvm.org/D98834
The `int` and `long` versions of these builtins already provide the
necessary overloads for `intptr_t` and `uintptr_t` arguments, as
`ASTContext` defines `atomic_(u)intptr_t` in terms of the `int` or
`long` types.
Prior to this patch, calls to those builtins with particular argument
types resulted in call-is-ambiguous errors.
Differential Revision: https://reviews.llvm.org/D98520
After the import, we did not copy the `TSCSpec`.
This commit resolves that.
Reviewed By: balazske
Differential Revision: https://reviews.llvm.org/D98707
This patch is a second attempt at fixing a link error for MSVC
entry points when calling conventions are specified using a flag.
Calling conventions specified using flags should not be applied to MSVC
entry points. The default calling convention is set in this case. The
default calling convention for MSVC entry points main and wmain is cdecl.
For WinMain, wWinMain and DllMain, the default calling convention is
stdcall on 32 bit Windows.
Explicitly specified calling conventions are applied to MSVC entry points.
For MinGW, the default calling convention for all MSVC entry points is
cdecl.
First attempt: 4cff1b40da
Revert of first attempt: bebfc3b92d
Differential Revision: https://reviews.llvm.org/D97941
Cleanup attribute allows users to attach a destructor-like functions
to variable declarations to be called whenever they leave the scope.
The logic of such functions is not supported by the Clang's CFG and
is too hard to be reasoned about. In order to avoid false positives
in this situation, we assume that we didn't see ALL of the executtion
paths of the function and, thus, can warn only about multiple call
violation.
rdar://74441906
Differential Revision: https://reviews.llvm.org/D98694
This patch introduces a very simple inter-procedural analysis
between blocks and enclosing functions.
We always analyze blocks first (analysis is done as part of semantic
analysis that goes side-by-side with the parsing process), and at the
moment of reporting we don't know how that block will be actually
used.
This patch introduces new logic delaying reports of the "never called"
warnings on blocks. If we are not sure that the block will be called
exactly once, we shouldn't warn our users about that. Double calls,
however, don't require such delays. While analyzing the enclosing
function, we can actually decide what we should do with those
warnings.
Additionally, as a side effect, we can be more confident about blocks
in such context and can treat them not as escapes, but as direct
calls.
rdar://74090107
Differential Revision: https://reviews.llvm.org/D98688
At the moment "link.exe" is hard-coded as default linker in MSVC.cpp,
so there's no way to use LLD as default linker for MSVC driver.
This patch adds checking of CLANG_DEFAULT_LINKER to MSVC.cpp.
Reviewed By: asl
Differential Revision: https://reviews.llvm.org/D98493
This category is generic enough to hold a variety of checkers.
Currently it contains the Dead Stores checker and an alpha unreachable
code checker.
Differential Revision: https://reviews.llvm.org/D98741
This reverts commit 809a1e0ffd.
Mach-O doesn't support dso_local and this change broke XNU because of the use of dso_local.
Differential Revision: https://reviews.llvm.org/D98458
This would assert if we hit the evaluation step limit between starting
to delay the call and finishing. In any case, delaying the call was
largely pointless as it doesn't really matter when we mark the
evaluation as having had side effects.
The condition variable is in scope in the loop increment, so we need to
emit the jump destination from wthin the scope of the condition
variable.
For GCC compatibility (and compatibility with real-world 'FOR_EACH'
macros), 'continue' is permitted in a statement expression within the
condition of a for loop, though, so there are two cases here:
* If the for loop has no condition variable, we can emit the jump
destination before emitting the condition.
* If the for loop has a condition variable, we must defer emitting the
jump destination until after emitting the variable. We diagnose a
'continue' appearing in the initializer of the condition variable,
because it would jump past the initializer into the scope of that
variable.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D98816
Added basic parsing/sema/serialization support for interop directive.
Support for the 'init' clause.
Differential Revision: https://reviews.llvm.org/D98558
SYCL compilations initiated by the driver will spawn off one or more
frontend compilation jobs (one for device and one for host). This patch
reworks the driver options to make upstreaming this from the downstream
SYCL fork easier.
This patch introduces a language option to identify host executions
(SYCLIsHost) and a -cc1 frontend option to enable this mode. -fsycl and
-fno-sycl become driver-only options that are rejected when passed to
-cc1. This is because the frontend and beyond should be looking at
whether the user is doing a device or host compilation specifically.
Because the frontend should only ever be in one mode or the other,
-fsycl-is-device and -fsycl-is-host are mutually exclusive options.
Previously NEON used a target specific intrinsic for frintn, given that
the FROUNDEVEN ISD node now exists, move over to that instead and add
codegen support for that node for both NEON and fixed length SVE.
Differential Revision: https://reviews.llvm.org/D98487
Split out some of the instructions predicated on the dot2-insts target
feature into a new dot7-insts, in preparation for subtargets that have
some but not all of these instructions. NFCI.
Differential Revision: https://reviews.llvm.org/D98717
The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```
is not safe when in the loop body we trigger deserialization from an AST file.
The deserialization can insert new declarations in the StoredDeclsList whose
underlying type is a vector. When the vector decides to reallocate its storage
the pointer we hold becomes invalid.
This patch replaces a SmallVector with an singly-linked list. The current
approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers.
The linked list is 3, 5, or 7. We do better in terms of memory usage for small
cases (and worse in terms of locality -- the linked list entries won't be near
each other, but will be near their corresponding declarations, and we were going
to fetch those memory pages anyway). For larger cases: the vector uses a
doubling strategy for reallocation, so will generally be between half-full and
full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth
of space allocated currently and will be 2N pointers with the linked list. So we
break even when there are N=6 entries and slightly lose in terms of memory usage
after that. We suspect that's still a win on average.
Thanks to @rsmith!
Differential revision: https://reviews.llvm.org/D91524
This commit makes escapes symmetrical, meaning that having escape
before and after the branching, where parameter is not called on
one of the paths, will have the same effect.
Differential Revision: https://reviews.llvm.org/D98622
`CodeGenFunction::EmitRuntimeCall` automatically sets the right calling
convention for the callee so we can avoid setting it ourselves.
As requested in https://reviews.llvm.org/D98411
Reviewed by: anastasia
Differential Revision: https://reviews.llvm.org/D98705
There is no syntax like {@code ...} in Doxygen, @code is a block command
that ends with @endcode, and generally these are not enclosed in braces.
The correct syntax for inline code snippets is @c <code>.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98665
Somewhat surprisingly, signature help is emitted as a side-effect of
computing the expected type of a function argument.
The reason is that both actions require enumerating the possible
function signatures and running partial overload resolution, and doing
this twice would be wasteful and complicated.
Change #1: document this, it's subtle :-)
However, sometimes we need to compute the expected type without having
reached the code completion cursor yet - in particular to allow
completion of designators.
eb4ab3358c did this but introduced a
regression - it emits signature help in the wrong location as a side-effect.
Change #2: only emit signature help if the code completion cursor was reached.
Currently there is PP.isCodeCompletionReached(), but we can't use it
because it's set *after* running code completion.
It'd be nice to set this implicitly when the completion token is lexed,
but ConsumeCodeCompletionToken() makes this complicated.
Change #3: call cutOffParsing() *first* when seeing a completion token.
After this, the fact that the Sema::Produce*SignatureHelp() functions
are even more confusing, as they only sometimes do that.
I don't want to rename them in this patch as it's another large
mechanical change, but we should soon.
Change #4: prepare to rename ProduceSignatureHelp() to GuessArgumentType() etc.
Differential Revision: https://reviews.llvm.org/D98488
Nico Weber