Add HLSLExternalSemaSource as ExternalSemaSource instead of ASTContext::ExternalSource when PCH is included.
This allows a different external source to be set for the AST context.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132421
This flag enables the .debug_aranges section by passing a flag to LLD
and our internal linker. This also adds a new routine that will generate
the correct flag for our internal linker or set of flags for LLD when
given a list of LLVM options. That ensures multiple LLVM codegen options
can be passed to either linker consistently.
Differential Revision: https://reviews.llvm.org/D134296
This change exposes the sqrt library function for HLSL scalar types,
excluding long and long long doubles. Sqrt is supported for all scalar, vector,
and matrix types. This patch only adds a subset of scalar type support.
Long and long long double support is missing in this patch because that type
doesn't exist in HLSL.
The full documentation of the HLSL asin function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-sqrt
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132711
This can be used to disable vectorization and memcpy/memset
expansion for things like OS kernels. It also disables implicit
uses of scalar FP, but I don't know if we have any of those for
RISC-V.
NOTE: Without this patch you can still do -Xclang -no-implicit-float
Reviewed By: rui.zhang
Differential Revision: https://reviews.llvm.org/D134077
Clang already generates code that doesn't use writeable data in executable
sections so the linker flag is all that is necessary.
-Wl,--no-execute-only can be used to turn this default off.
Differential Revision: https://reviews.llvm.org/D134289
This implements experimental support for the Zawrs extension as specified here: https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf. Despite the 1.0 version name, this has not been ratified and there was a major change to proposed specification between rc2 and rc3. Once this is ratified, it'll move out of experimental status.
This change adds assembly support, but does not include C language or IR intrinsics. We can decide if we want them, and handle that in a separate patch.
Differential Revision: https://reviews.llvm.org/D133443
Fix __builtin_assume_aligned incorrect type descriptor
example from @rsmith
struct A { int n; };
struct B { int n; };
struct C : A, B {};
void *f(C *c) {
// Incorrectly returns `c` rather than the address of the B base class.
return __builtin_assume_aligned((B*)c, 8);
}
Differential Revision: https://reviews.llvm.org/D133583
Having the flags only pass through if you're using the dxc-driver means
that the clang driver doesn't work for HLSL, which is undesirable. This
change switches to instead passing flags based on the language mode
similar to how OpenCL does it. This allows the clang driver to be used
for HLSL source files as well.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D133958
AArch64 MachO has a compact unwind format where most functions' unwind info can
be represented in just 4 bytes. But this cannot represent any asynchronous CFI
function, so it's essentially disabled when that's used. This is a large
code-size hit that we'd rather not take unless explicitly requested.
Disable transformations (e.g. attempting to replace target architecture)
in the config filename that is passed explicitly via `--config`. This
behavior is surprising and confusing -- if user passes an explicit
config filename, Clang should use it as is. The transformations are
still applied when the name is deduced from filename.
Update the tests accordingly. This primarily ensures that full filename
with .cfg suffix is passed to --config (appending `.cfg` implicitly is
not documented, and would collide with use of filenames with other
suffixes). The config-file2.c suite is removed entirely as it tested
the transformations on the argument to --config. However, the aspects
of that that were not tested as part of config-file3.c are now added
there (based on config filename deduced from executable).
This change streamlines the code in Driver::loadConfigFile(), opening
the possibility of further changes, including support for handling
multiple --config options and refactoring of filename deduction.
Differential Revision: https://reviews.llvm.org/D134208
When passing arguments with `__fastcall` or `__vectorcall` in 32-bit MSVC, the following arguments have chance to be passed by register if the current one failed. `__regcall` from ICC is on the contrary: https://godbolt.org/z/4MPbzhaMG
All the three calling conversions are not supported in GCC.
Fixes: #57737
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D133920
Summary: This patch add codegen support for the has_device_addr clause. It
use the same logic of is_device_ptr.
Differential Revision: https://reviews.llvm.org/D134186
Implement suggested fix for [[ https://cplusplus.github.io/CWG/issues/2628.html | DR2628. ]] Couldn't update the DR docs because there hasn't been a DR index since it was filed, but the tests still run in CI.
Note: I only transfer the constructor constraints, not the struct constraints. I think that's OK because the struct constraints are the same
for all constructors so they don't affect the overload resolution, and if they deduce to something that doesn't pass the constraints
we catch it anyway. So (hopefully) that should be more efficient without sacrificing correctness.
Closes:
https://github.com/llvm/llvm-project/issues/57646https://github.com/llvm/llvm-project/issues/43829
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D134145
Previously when using the `clang-offload-packager` we did not pass the
active offloading kinds. Then in Clang when we attempted to detect when
there was host-offloading action that needed to be embedded in the host
we did not find it. This patch adds the active offloading kinds so we
know when there is input to be embedded.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D134189
- Remove use of `runDataflowAnalysis` to keep test isolated.
- Add test for `ASTMatchSwitch<CXXCtorInitializer, ...>`.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D133935
To keep API of transfer functions consistent.
The single use of this transfer function in `ChromiumCheckModel` is also updated.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D133933
- Update `transfer` and `diagnose` to take `const CFGElement *` as input in `Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel`.
- Update `clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp` accordingly.
- Rename `runDataflowAnalysisOnCFG` to `runDataflowAnalysis` and remove the deprecated `runDataflowAnalysis` (this was only used by the now updated optional check).
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D133930
It is possible that we can pass a null ParamType to
CheckNonTypeTemplateParameter -- the ParamType var can be reset to a null
type on Line 6940, and the followed bailout if is not entered.
Differential Revision: https://reviews.llvm.org/D134180
Make `--config`, `--no-default-config` and `--config-*-dir` CoreOptions
to enable their availability to all clang driver modes. This improves
consistency given that the default set of configuration files is
processed independently of mode anyway.
Differential Revision: https://reviews.llvm.org/D134191
Working in a mixed environment of both vscode/vim with a team configured prettier configuration, this can leave clang-format and prettier fighting each other over the formatting of arrays, both simple arrays of elements.
This review aims to add some "control knobs" to the Json formatting in clang-format to help align the two tools so they can be used interchangeably.
This will allow simply arrays `[1, 2, 3]` to remain on a single line but will break those arrays based on context within that array.
Happy to change the name of the option (this is the third name I tried)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133589
Reuse most of RISCV's implementation with several exceptions:
1. Assign signext/zeroext attribute to args passed in stack.
On RISCV, integer scalars passed in registers have signext/zeroext
when promoted, but are anyext if passed on the stack. This is defined
in early RISCV ABI specification. But after this change [1], integers
should also be signext/zeroext if passed on the stack. So I think
RISCV's ABI lowering should be updated [2].
While in LoongArch ABI spec, we can see that integer scalars narrower
than GRLEN bits are zero/sign-extended no matter passed in registers
or on the stack.
2. Zero-width bit fields are ignored.
This matches GCC's behavior but it hasn't been documented in ABI sepc.
See https://gcc.gnu.org/r12-8294.
3. `char` is signed by default.
There is another difference worth mentioning is that `char` is signed
by default on LoongArch while it is unsigned on RISCV.
This patch also adds `_BitInt` type support to LoongArch and handle it
in LoongArchABIInfo::classifyArgumentType.
[1] cec39a064e
[2] https://github.com/llvm/llvm-project/issues/57261
Differential Revision: https://reviews.llvm.org/D132285
module unit directly
Previously we lack a test which ensures that the module unit will
generate initializer if it is compiled directly (instead of from a pcm
file). Now we add the test back.
Previsouly the module-initializer*.cpp lives in the CodeGen dir instead
of CodeGenCXX dir, which is not consistency with other tests since
modules are features for C++.
There already exists logic to disallow requires *expressions* to be
treated as function declarations, but this expands it to include
requires *clauses*, when they happen to also be parenthesized.
Previously, in the following case:
```
template <typename T>
requires(Foo<T>)
T foo();
```
The line with the requires clause was actually being considered as the
line with the function declaration due to the parentheses, and the
*real* function declaration on the next line became a trailing
annotation
(Together with https://reviews.llvm.org/D134049) Fixes https://github.com/llvm/llvm-project/issues/56213
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D134052
In the following construction:
`template <typename T> requires Foo<T> || Bar<T> auto func() -> int;`
The `->` of the trailing return type was actually considered as an
operator as part of the binary operation in the requires clause, with
the precedence level of `PrecedenceArrowAndPeriod`, leading to fake
parens being inserted in strange locations, that would never be closed.
Fixes one part of https://github.com/llvm/llvm-project/issues/56213
(the rest will probably be in a separate patch)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D134049
Add vector version of abs as
```
__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
int2 abs (int2 );
__attribute__((clang_builtin_alias(__builtin_elementwise_abs)))
int3 abs (int3 );
```
To make this work.
Allowed custom type checking builtins to be recelareable.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D133737
I'm planning to deprecate and eventually remove llvm::empty.
Note that no use of llvm::empty requires the ability of llvm::empty to
determine the emptiness from begin/end only.
Currently there're two pages that both talk about "Modules" in clang, but
they're different. The one that describes C++ standard modules explicitly
spells out the difference but the other one which targeting Clang modules
doesn't.
This patch adds a link that refers to the C++ standard modules
one in Clang modules doc, as you usually got the later page when
googling. I believe this will make newcomers less confused.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D134105
Closing https://github.com/llvm/llvm-project/issues/57778.
Previously it judge if we're compiling a module unit by
LangOpts::CurrentModule.empty(). But it is not true since we can specify
the module name by `-fmodule-name` option for arbitrary module unit.
Then this patch adjuest the judgement properly.
Most of the state traits used for non-POD array evaluation were
only cleaned up if the ctors/dtors were inlined, since the cleanup
happened in ExprEngine::processCallExit(). This patch makes sure
they are removed even if said functions are not inlined.
Differential Revision: https://reviews.llvm.org/D133643
This improves consistency with other places (e.g. llvm::compression::decompress,
llvm::object::Decompressor::decompress, llvm-objcopy).
Note: when zstd::uncompress was added, we noticed that the API `ZSTD_decompress`
is fine while the zlib API `uncompress` is a misnomer.
After compilation errors, expression a transformation result may not be usable.
It triggers an assert in RemoveNestedImmediateInvocation and SIGSEGV in case of
builds without asserts. This issue significantly affects clangd because source
may not be valid during typing. Tests cases that I attached was reduce from huge
C++ translation unit.
Test Plan: check-clang
Differential Revision: https://reviews.llvm.org/D133948
We would diagnose use of `long long` as an extension in C89 and C++98
modes when the user spelled the type `long long` or used the `LL`
literal suffix, but failed to diagnose when the literal had no suffix
but required a `long long` to represent the value.
Some HLSL functionality is gated on the target shader model version.
Enabling the use of availability markup allows us to diagnose
availability issues easily in the frontend.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D134067
Before this patch, when compiling an IR file (eg the .llvmbc section
from an object file compiled with -Xclang -fembed-bitcode=all) and
profile data was passed in using the -fprofile-instrument-use-path
flag, there would be no error printed (as the previous implementation
relied on the error getting caught again in the constructor of
CodeGenModule which isn't called when -x ir is set). This patch
moves the error checking directly to where the error is caught
originally rather than failing silently in setPGOUseInstrumentor and
waiting to catch it in CodeGenModule to print diagnostic information to
the user.
Regression test added.
Reviewed By: xur, mtrofin
Differential Revision: https://reviews.llvm.org/D132991
This patch modifies the testcase to use error substitution so it will pass on all platforms.
Reviewed By: fanbo-meng, zibi
Differential Revision: https://reviews.llvm.org/D134034
The `ScanInstance` is a local variable in `DependencyScanningAction::runInvocation()` that is referenced by `ModuleDepCollector`. Since D132405, `ModuleDepCollector` can escape the function and can outlive its `ScanInstance`. This patch fixes that.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D133988
The uncached lookup is mainly used in the ASTImporter/LLDB code-path
where we're not allowed to load from external storage. When importing
a FieldDecl with a DeclContext that had no external visible storage
(but came from a Clang module or PCH) the above call to `lookup(Name)`
the regular `DeclContext::lookup` fails because:
1. `DeclContext::buildLookup` doesn't set `LookupPtr` for decls
that came from a module
2. LLDB doesn't use the `SharedImporterState`
In such a case we would never continue with the "slow" path of iterating
through the decl chain on the DeclContext. In some cases this means that
ASTNodeImporter::VisitFieldDecl ends up importing a decl into the
DeclContext a second time.
The patch removes the short-circuit in the case where we don't find
any decls via the regular lookup.
**Tests**
* Un-skip the failing LLDB API tests
Differential Revision: https://reviews.llvm.org/D133945
We change the template specialization of builtin templates to
behave like aliases.
Though unlike real alias templates, these might still produce a canonical
TemplateSpecializationType when some important argument is dependent.
For example, we can't do anything about make_integer_seq when the
count is dependent, or a type_pack_element when the index is dependent.
We change type deduction to not try to deduce canonical TSTs of
builtin templates.
We also change those buitin templates to produce substitution sugar,
just like a real instantiation would, making the resulting type correctly
represent the template arguments used to specialize the underlying template.
And make_integer_seq will now produce a TST for the specialization
of it's first argument, which we use as the underlying type of
the builtin alias.
When performing member access on the resulting type, it's now
possible to map from a Subst* node to the template argument
as-written used in a regular fashion, without special casing.
And this fixes a bunch of bugs with relation to these builtin
templates factoring into deduction.
Fixes GH42102 and GH51928.
Depends on D133261
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133262
When ‘ffast-math’ is set, ffp-contract is altered this way:
-ffast-math/ Ofast -> ffp-contract=fast
-fno-fast-math -> if ffp-contract= fast then ffp-contract=on else
ffp-contract unchanged
This differs from gcc which doesn’t connect the two options.
Connecting these two options in clang, resulted in spurious warnings
when the user combines these two options -ffast-math -fno-fast-math; see
issue https://github.com/llvm/llvm-project/issues/54625.
The issue is that the ‘ffast-math’ option is an on/off flag, but the
‘ffp-contract’ is an on/off/fast flag. So when ‘fno-fast-math’ is used
there is no obvious value for ‘ffp-contract’. What should the value of
ffp-contract be for -ffp-contract=fast -fno-fast-math and -ffast-math
-ffp-contract=fast -fno-fast-math? The current logic sets ffp-contract
back to on in these cases. This doesn’t take into account that the value
of ffp-contract is modified by an explicit ffp-contract` option.
This patch is proposing a set of rules to apply when ffp-contract',
ffast-math and fno-fast-math are combined. These rules would give the
user the expected behavior and no diagnostic would be needed.
See RFC
https://discourse.llvm.org/t/rfc-making-ffast-math-option-unrelated-to-ffp-contract-option/61912
This continues D111283 by extending the getCommonSugaredType
implementation to also merge non-canonical type nodes.
We merge these nodes by going up starting from the canonical
node, calculating their merged properties on the way.
If we reach a pair that is too different, or which we could not
otherwise unify, we bail out and don't try to keep going on to
the next pair, in effect striping out all the remaining top-level
sugar nodes. This avoids mismatching 'companion' nodes, such as
ElaboratedType, so that they don't end up elaborating some other
unrelated thing.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D130308
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
Fixes https://github.com/llvm/llvm-project/issues/57738
old
```
#define FOO(typeName, realClass) \
{ \
#typeName, foo < FooType>(new foo <realClass>(#typeName)) \
}
```
new
```
#define FOO(typeName, realClass) \
{ #typeName, foo<FooType>(new foo<realClass>(#typeName)) }
```
Previously, when an UnwrappedLine began with a hash in a macro
definition, the program incorrectly assumed the line was a preprocessor
directive. It should be stringification.
The rule in spaceRequiredBefore was added in 8b5297117b. Its purpose is
to add a space in an include directive. It also added a space to a
template opener when the line began with a stringification hash. So we
changed it.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133954
Fixes https://github.com/llvm/llvm-project/issues/57539
Previously things outside of `#if` blocks were parsed as if only the
first branch of the conditional compilation branch existed, unless the
first condition is 0. In that case the outer parts would be parsed as
if nothing inside the conditional parts existed. Now we use the second
conditional branch if the first condition is 0.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D133647
For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).
We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111509
After upgrading the type deduction machinery to retain type sugar in
D110216, we were left with a situation where there is no general
well behaved mechanism in Clang to unify the type sugar of multiple
deductions of the same type parameter.
So we ended up making an arbitrary choice: keep the sugar of the first
deduction, ignore subsequent ones.
In general, we already had this problem, but in a smaller scale.
The result of the conditional operator and many other binary ops
could benefit from such a mechanism.
This patch implements such a type sugar unification mechanism.
The basics:
This patch introduces a `getCommonSugaredType(QualType X, QualType Y)`
method to ASTContext which implements this functionality, and uses it
for unifying the results of type deduction and return type deduction.
This will return the most derived type sugar which occurs in both X and
Y.
Example:
Suppose we have these types:
```
using Animal = int;
using Cat = Animal;
using Dog = Animal;
using Tom = Cat;
using Spike = Dog;
using Tyke = Dog;
```
For `X = Tom, Y = Spike`, this will result in `Animal`.
For `X = Spike, Y = Tyke`, this will result in `Dog`.
How it works:
We take two types, X and Y, which we wish to unify as input.
These types must have the same (qualified or unqualified) canonical
type.
We dive down fast through top-level type sugar nodes, to the
underlying canonical node. If these canonical nodes differ, we
build a common one out of the two, unifying any sugar they had.
Note that this might involve a recursive call to unify any children
of those. We then return that canonical node, handling any qualifiers.
If they don't differ, we walk up the list of sugar type nodes we dived
through, finding the last identical pair, and returning that as the
result, again handling qualifiers.
Note that this patch will not unify sugar nodes if they are not
identical already. We will simply strip off top-level sugar nodes that
differ between X and Y. This sugar node unification will instead be
implemented in a subsequent patch.
This patch also implements a few users of this mechanism:
* Template argument deduction.
* Auto deduction, for functions returning auto / decltype(auto), with
special handling for initializer_list as well.
Further users will be implemented in a subsequent patch.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111283
%T is a deprecated lit feature. It refers to the parent directory.
When two tests in test/Driver refer to the same `%T/foo`, they are racy with each other.
%t includes the test name and is safe for use.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D133998
This is a reland of https://reviews.llvm.org/D122336.
Original patch caused a problem in collecting coverage in
Fuchsia because it was returning early without putting unused
function names into __llvm_prf_names section. This patch
fixes that issue.
The original commit message is as the following:
CoverageMappingModuleGen generates a coverage mapping record
even for unused functions with internal linkage, e.g.
static int foo() { return 100; }
Clang frontend eliminates such functions, but InstrProfiling pass
still emits runtime hook since there is a coverage record.
Fuchsia uses runtime counter relocation, and pulling in profile
runtime for unused functions causes a linker error:
undefined hidden symbol: __llvm_profile_counter_bias.
Since https://reviews.llvm.org/D98061, we do not hook profile
runtime for the binaries that none of its translation units
have been instrumented in Fuchsia. This patch extends that for
the instrumented binaries that consist of only unused functions.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D122336
Getting the default module cache path calls llvm::sys::path::cache_directory,
which calls home_directory, which checks the HOME environment variable
before falling back to getpwuid. When compiling against musl libc,
which does not support NSS, and running on a machine that doesn't have
the current user in /etc/passwd due to NSS, no home directory can
be found. Set the HOME environment variable in the tests to avoid
depending on getpwuid.
Reviewed By: pirama, srhines
Differential Revision: https://reviews.llvm.org/D132984
While investigating something else, I discovered that a prototypeless
function with 'overloadable' was having the attribute left on the
declaration, which caused 'ambiguous' call errors later on. This lead to
some confusion. This patch removes the 'overloadable' attribute from
the declaration and leaves it as prototypeless, instead of trying to
make it variadic.
This patch fixes a crash which appears because of getTypeAlignInChars() call with depentent type.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D133886
Sometimes we make changes to the compiler that we expect may cause
disruption for users. For example, we may strengthen a warning to
default to be an error, or fix an accepts-invalid bug that's been
around for a long time, etc which may cause previously accepted code to
now be rejected. Rather than hope users discover that information by
reading all of the release notes, it's better that we call these out in
one location at the top of the release notes.
Based on feedback collected in the discussion at:
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/
Differential Revision: https://reviews.llvm.org/D133771
Parallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function's argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3) forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call.
Reviewed By: jdoerfert, jhuber6, ABataev
Differential Revision: https://reviews.llvm.org/D102107
I used RV32 so I didn't have to write RV32I and RV32E. Ideally
these builtins will be wrapped in a header someday so long term I don't
expect users to see these errors.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D133444
Restore GlobalsAA if sanitizers inserted at early optimize callback.
The analysis can be useful for the following FunctionPassManager.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D133537
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is.
This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
When running in MSVC compatibility mode, previously no deprecated copy
operation warnings (enabled by -Wdeprecated-copy) were raised. This
restriction was already in place when the deprecated copy warning was
first introduced.
This patch removes said restriction so that deprecated copy warnings, if
enabled, are also raised in MSVC compatibility mode. The reasoning here
being that these warnings are still useful when running in MSVC
compatibility mode and also have to be semi-explicitly enabled in the
first place (using -Wdeprecated-copy, -Wdeprecated or -Wextra).
Differential Revision: https://reviews.llvm.org/D133354
A previous patch (https://reviews.llvm.org/D132810) introduced a test
that fails on systems where the linker executable (`ld`) has a `.exe`
extension. This patch updates the regex in the test so that lit can
look for both `ld` as well as `ld.exe`.
Reviewed By: stella.stamenova
Differential Revision: https://reviews.llvm.org/D133773
Downstream users who doesn't make use of the clang cc1 frontend for
commandline argument parsing, won't benefit from the Marshalling
provided default initialization of the AnalyzerOptions entries. More
about this later.
Those analyzer option fields, as they are bitfields, cannot be default
initialized at the declaration (prior c++20), hence they are initialized
at the constructor.
The only problem is that `ShouldEmitErrorsOnInvalidConfigValue` was
forgotten.
In this patch I'm proposing to initialize that field with the rest.
Note that this value is read by
`CheckerRegistry.cpp:insertAndValidate()`.
The analyzer options are initialized by the marshalling at
`CompilerInvocation.cpp:GenerateAnalyzerArgs()` by the expansion of the
`ANALYZER_OPTION_WITH_MARSHALLING` xmacro to the appropriate default
value regardless of the constructor initialized list which I'm touching.
Due to that this only affects users using CSA as a library, without
serious effort, I believe we cannot test this.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D133851
Previously, we linked in the ROCm device libraries which provide math
and other utility functions late. This is not stricly correct as this
library contains several flags that are only set per-TU, such as fast
math or denormalization. This patch changes this to pass the bitcode
libraries per-TU using the same method we use for the CUDA libraries.
This has the advantage that we correctly propagate attributes making
this implementation more correct. Additionally, many annoying unused
functions were not being fully removed during LTO. This lead to
erroneous warning messages and remarks on unused functions.
I am not sure if not finding these libraries should be a hard error. let
me know if it should be demoted to a warning saying that some device
utilities will not work without them.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D133726
The old device runtime had a "simplified" version that prevented many of
the runtime features from being initialized. The old device runtime was
deleted in LLVM 14 and is no longer in use. Selectively deactivating
features is now done using specific flags rather than the old technique.
This patch simply removes the extra logic required for handling the old
simple runtime scheme.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D133802
Now when the compiler can't find the sized deallocation function
correctly in promise_type if there are multiple deallocation function
overloads there.
According to [dcl.fct.def.coroutine]p12:
> If both a usual deallocation function with only a pointer parameter
> and a usual deallocation function with both a pointer parameter and a
> size parameter are found, then the selected deallocation function
> shall be the one with two parameters.
So when there are multiple deallocation functions, the compiler should
choose the sized one instead of the unsized one. The patch fixes this.
Two new dxc mode options -O and -Od are added for dxc mode.
-O is just alias of existing cc1 -O option.
-Od will be lowered into -O0 and -dxc-opt-disable.
-dxc-opt-disable is cc1 option added to for build ShaderFlags.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D128845
Right now in case of LTO the section is not emited:
$ cat test.c
void __attribute__((optnone)) bar()
{
}
void __attribute__((optnone)) foo()
{
bar();
}
int main()
{
foo();
}
$ clang -flto=thin -gdwarf-aranges -g -O3 test.c
$ eu-readelf -waranges a.out | fgrep -c -e foo -e bar
0
$ clang -gdwarf-aranges -g -O3 test.c
$ eu-readelf -waranges a.out | fgrep -c -e foo -e bar
2
Fix this by passing explicitly -mllvm -generate-arange-section.
P.S. although this looks like a hack, since none of -mllvm was passed to
the lld before.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
Suggested-by: OCHyams <orlando.hyams@sony.com>
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D133092
HLSL doesn't have a C++ runtime that supports `atexit` registration. To
enable global destructors we instead rely on the `llvm.global_dtor`
mechanism.
This change disables `atexit` generation for HLSL and updates the HLSL
code generation to call global destructors on the exit from entry
functions.
Depends on D132977.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D133518
The original proposal was seen in Apr 2019 and we accidentally used
that date (201904L) as the feature testing value. However, WG14 N2408
was adopted at the Oct 2019 meeting and so that's the correct date for
the feature testing macro. The committee draft for C2x shows 201910L
for this value, so this changes brings us in line with the standard.
The original proposal was adopted in Apr 2019, but was subsequently
updated by WG14 N2662 in June 2021. We already supported the attribute
on a label and it behaved as expected, but we had not bumped the
feature test value.
The original proposal was adopted in Apr 2019 and so the previous value
was 201904L. However, a subsequent proposal (N2448) was adopted to add
an optional message argument to the attribute. We already support that
functionality, but had not bumped the feature test value.
This reverts commit d200db3863, which causes a
clang crash. See https://reviews.llvm.org/D111283#3785755
Test case for convenience:
```
template <typename T>
using P = int T::*;
template <typename T, typename... A>
void j(P<T>, T, A...);
template <typename T>
void j(P<T>, T);
struct S {
int b;
};
void g(P<S> k, S s) { j(k, s); }
```
Ensure any uses of `image2d_depth_t` and `image2d_array_depth_t` are
guarded behind the `cl_khr_depth_images` extension in
`OpenCLBuiltins.td`.
Fix a few missing guards in `opencl-c.h`.
References are implemented through pointers, so we need a second deref
when encountering a DeclRefExpr of a reference type.
Differential Revision: https://reviews.llvm.org/D132997
Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()`
if the user didn't specify it; set `ExplicitEmulatedTLS` to true
in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's
opinion of what the default or preference is.
This avoids any risk of deviance between the two.
This affects one check of `getCodeGenOpts().EmulatedTLS` in
`shouldAssumeDSOLocal` in CodeGenModule, but as that check only
is done for `TT.isWindowsGNUEnvironment()`, and
`hasDefaultEmulatedTLS()` returns false for such environments
it doesn't make any current testable difference - thus NFC.
Some mingw distributions carry a downstream patch, that enables
emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()`
- and for such cases, this patch does make a difference and fixes the
detection of emulated TLS, if it is implicitly enabled.
Differential Revision: https://reviews.llvm.org/D132916
By this change the `exploded-graph-rewriter` will display the class kind
of the expression of the environment entry. It makes easier to decide if
the given entry corresponds to the lvalue or to the rvalue of some
expression.
It turns out the rewriter already had support for visualizing it, but
probably was never actually used?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D132109
`LazyCompoundVals` should only appear as `default` bindings in the
store. This fixes the second case in this patch-stack.
Depends on: D132142
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D132143
It turns out that in certain cases `SymbolRegions` are wrapped by
`ElementRegions`; in others, it's not. This discrepancy can cause the
analyzer not to recognize if the two regions are actually referring to
the same entity, which then can lead to unreachable paths discovered.
Consider this example:
```lang=C++
struct Node { int* ptr; };
void with_structs(Node* n1) {
Node c = *n1; // copy
Node* n2 = &c;
clang_analyzer_dump(*n1); // lazy...
clang_analyzer_dump(*n2); // lazy...
clang_analyzer_dump(n1->ptr); // rval(n1->ptr): reg_$2<int * SymRegion{reg_$0<struct Node * n1>}.ptr>
clang_analyzer_dump(n2->ptr); // rval(n2->ptr): reg_$1<int * Element{SymRegion{reg_$0<struct Node * n1>},0 S64b,struct Node}.ptr>
clang_analyzer_eval(n1->ptr != n2->ptr); // UNKNOWN, bad!
(void)(*n1);
(void)(*n2);
}
```
The copy of `n1` will insert a new binding to the store; but for doing
that it actually must create a `TypedValueRegion` which it could pass to
the `LazyCompoundVal`. Since the memregion in question is a
`SymbolicRegion` - which is untyped, it needs to first wrap it into an
`ElementRegion` basically implementing this untyped -> typed conversion
for the sake of passing it to the `LazyCompoundVal`.
So, this is why we have `Element{SymRegion{.}, 0,struct Node}` for `n1`.
The problem appears if the analyzer evaluates a read from the expression
`n1->ptr`. The same logic won't apply for `SymbolRegionValues`, since
they accept raw `SubRegions`, hence the `SymbolicRegion` won't be
wrapped into an `ElementRegion` in that case.
Later when we arrive at the equality comparison, we cannot prove that
they are equal.
For more details check the corresponding thread on discourse:
https://discourse.llvm.org/t/are-symbolicregions-really-untyped/64406
---
In this patch, I'm eagerly wrapping each `SymbolicRegion` by an
`ElementRegion`; basically canonicalizing to this form.
It seems reasonable to do so since any object can be thought of as a single
array of that object; so this should not make much of a difference.
The tests also underpin this assumption, as only a few were broken by
this change; and actually fixed a FIXME along the way.
About the second example, which does the same copy operation - but on
the heap - it will be fixed by the next patch.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D132142
According to [dcl.inline]p7/note4,
> In the global module, a function defined within a class definition is
> implicitly inline.
And the declarations in the header unit are attached to the global
module fragment. So the function defined within a class definition in
header units should be implicitly inline too.
This fixes https://github.com/llvm/llvm-project/issues/57571.
Hidden visibility is incompatible with dllexport.
Hidden and protected visibilities are incompatible with dllimport.
(PlayStation uses dllexport protected.)
When an explicit visibility attribute applies on a dllexport/dllimport
declaration, report a Frontend error (Sema does not compute visibility).
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D133266
__declspec(safebuffers) is equivalent to
__attribute__((no_stack_protector)). This information is recorded in
CodeView.
While we are here, add support for strict_gs_check.
Sort additional module maps when serializing pcm files. This ensures
the `MODULE_MAP_FILE` record is deterministic across repeated builds.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D133611
Make the default module cache path invalid when running lit tests so
that tests are forced to provide a cache path. This avoids accidentally
escaping to the system default location, and would have caught the
failure recently found in ClangScanDeps/multiple-commands.c.
Differential Revision: https://reviews.llvm.org/D133622
If the declaration of an identifier has block scope, and the identifier has
external or internal linkage, the declaration shall have no initializer for
the identifier.
Clang now gives a more suitable diagnosis for this case.
Fixes https://github.com/llvm/llvm-project/issues/57478
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D133088
If CLANG_LINK_CLANG_DYLIB, clang_target_link_libraries ignores all
indivial libraries and only links clang-cpp. As LLVMTestingSupport
is separate, pass it via target_link_libraries directly.
Matheus Izvekov