Clang static analyzer uses bitwidth to infer the integer value type, that is, any 32-bit integer is considered of type `int`, and any 64-bit integer is considered of type `long`. This isn't always true, for instance, in ILP32 (e.g., 32-bit AIX), 32-bit could be `long`, and in LP64 (e.g., 64-bit wasm64), 64-bit could be `long long`.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D114454
Currently the last value of linear is calculated as var = init + num_iters * step.
Replaced it with var = var_priv, i.e. original variable gets the value
of the last private copy.
Differential Revision: https://reviews.llvm.org/D105151
Need to postpone anlysis of the ranged for loops till the actual
instantiation to avoid erroneous emission of error messages.
Differential Revision: https://reviews.llvm.org/D114560
This change extends the current logic for inferring readonly and readnone argument attributes to also infer writeonly.
This change is deliberately minimal; there's a couple of areas for follow up.
* I left out all call handling and thus any benefit from the SCC walk. When examining the test changes, I realized the existing code is imprecise, and am going to fix that in it's own revision before adding in the writeonly handling. (Mostly because updating the tests is hard when I, the human, can't figure out whether the result is correct.)
* I left out handling for storing a value (as opposed to storing to a pointer). This should benefit readonly/readnone as well, and applies to a bunch of other instructions. Seemed worth having as a separate review.
Differential Revision: https://reviews.llvm.org/D114963
Need to postpone analysis for addressable lvalue in a depend clause with
iterators, otherwise the incorrect error message is emitted.
Differential Revision: https://reviews.llvm.org/D114653
The new runtime is currently broken for AMD offloading. This patch makes
the default the old runtime only for the AMD target.
Reviewed By: ronlieb
Differential Revision: https://reviews.llvm.org/D114965
If clang's output is set to bitcode and LTO is enabled, clang would
unconditionally add the flag to the module. Unfortunately, if the input were a
bitcode or IR file and had the flag set, this would result in two copies of the
flag, which is illegal IR. Guard the setting of the flag by checking whether it
already exists. This follows existing practice for the related "ThinLTO" module
flag.
Differential Revision: https://reviews.llvm.org/D112177
This patch changes the `-fopenmp-target-new-runtime` option which controls if
the new or old device runtime is used to be true by default. Disabling this to
use the old runtime now requires using `-fno-openmp-target-new-runtime`.
Reviewed By: JonChesterfield, tianshilei1992, gregrodgers, ronlieb
Differential Revision: https://reviews.llvm.org/D114890
Add mapping for CUDA address spaces for HIP to SPIR-V
translation. This change allows HIP device code to be
emitted as valid SPIR-V by mapping unqualified pointers
to generic address space and by mapping __device__ and
__shared__ AS to their equivalent AS in SPIR-V
(CrossWorkgroup and Workgroup, respectively).
Cuda's __constant__ AS is handled specially. In HIP
unqualified pointers (aka "flat" pointers) can point to
__constant__ objects. Mapping this AS to ConstantMemory
would produce to illegal address space casts to
generic AS. Therefore, __constant__ AS is mapped to
CrossWorkgroup.
Patch by linjamaki (Henry Linjamäki)!
Differential Revision: https://reviews.llvm.org/D108621
Updates the return types of these matchers' definitions to use
`internal::Matcher<LambdaCapture>` instead of `LambdaCaptureMatcher`. This
ensures that they are categorized as traversal matchers, instead of narrowing
matchers.
Reviewed By: ymandel, tdl-g, aaron.ballman
Differential Revision: https://reviews.llvm.org/D114809
Responding to a Discord call to help {D113977} and heavily inspired by the unlanded {D34225} add some support to help coroutinues from not being formatted from
```for co_await(auto elt : seq)```
to
```
for
co_await(auto elt : seq)
```
Because of the dominance of clang-format in the C++ community, I don't think we should make it the blocker that prevents users from embracing the newer parts of the standard because we butcher the layout of some of the new constucts.
Reviewed By: HazardyKnusperkeks, Quuxplusone, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114859
This reverts commit f02c5f3478 and
addresses the issue mentioned in D114619 differently.
Repeating the issue here:
Currently, during symbol simplification we remove the original member
symbol from the equivalence class (`ClassMembers` trait). However, we
keep the reverse link (`ClassMap` trait), in order to be able the query
the related constraints even for the old member. This asymmetry can lead
to a problem when we merge equivalence classes:
```
ClassA: [a, b] // ClassMembers trait,
a->a, b->a // ClassMap trait, a is the representative symbol
```
Now let,s delete `a`:
```
ClassA: [b]
a->a, b->a
```
Let's merge ClassA into the trivial class `c`:
```
ClassA: [c, b]
c->c, b->c, a->a
```
Now, after the merge operation, `c` and `a` are actually in different
equivalence classes, which is inconsistent.
This issue manifests in a test case (added in D103317):
```
void recurring_symbol(int b) {
if (b * b != b)
if ((b * b) * b * b != (b * b) * b)
if (b * b == 1)
}
```
Before the simplification we have these equivalence classes:
```
trivial EQ1: [b * b != b]
trivial EQ2: [(b * b) * b * b != (b * b) * b]
```
During the simplification with `b * b == 1`, EQ1 is merged with `1 != b`
`EQ1: [b * b != b, 1 != b]` and we remove the complex symbol, so
`EQ1: [1 != b]`
Then we start to simplify the only symbol in EQ2:
`(b * b) * b * b != (b * b) * b --> 1 * b * b != 1 * b --> b * b != b`
But `b * b != b` is such a symbol that had been removed previously from
EQ1, thus we reach the above mentioned inconsistency.
This patch addresses the issue by making it impossible to synthesise a
symbol that had been simplified before. We achieve this by simplifying
the given symbol to the absolute simplest form.
Differential Revision: https://reviews.llvm.org/D114887
Many of the SVE ACLE tests have gained entries as follows:
REQUIRES: aarch64-registered-target || arm-registered-target
which can cause test failures when only arm-registered-target is
available because only aarch64-registered-target supports SVE.
In C++23, discarded statements and if consteval statements can nest
arbitrarily. To support that, we keep track of whether the parent of
the current evaluation context is discarded or immediate.
This is done at the construction of an evaluation context
to improve performance.
Fixes https://bugs.llvm.org/show_bug.cgi?id=52231
The CLANG_DEFAULT_LINKER flag overrides the default toolchain linker.
VE strictly requires 'nld' to be the default linker. This causes a test
failure in test/Driver/ve-toolchain.cpp when configured with
CLANG_DEFAULT_LINKER!=ld
Failure in clang-ppc64le-rhel
(https://lab.llvm.org/buildbot/#/builders/57/builds/12628)
Until default linker selection with CLANG_DEFAULT_LINKER!=ld is fixed
proper, we manually specify '-fuse-ld=ld' (ie the toolchain default
linker) in the ve-toolchain tests.
MSVC says this should be 202002L for /std:c++20, and of VS16.11
that's indeed the case (older versions warn that they don't
understand /std:c++20, and then cl.exe defaults to C++14 and
sets _MSVC_LANG to 201402 accordingly).
Differential Revision: https://reviews.llvm.org/D114867
Make sure we do not try to change line comments that are non-regular, i.e. do
not start with "//" or "#". This can for example happen when "//" is
broken into two lines with an escaped newline.
This test which was just introduced in the PACBTI-M frontend
patch (https://reviews.llvm.org/D112421) is currently failing on some
platforms. Removing temporarily.
Handle branch protection option on the commandline as well as a function
attribute. One patch for both mechanisms, as they use the same underlying
parsing mechanism.
These are recorded in a set of LLVM IR module-level attributes like we do for
AArch64 PAC/BTI (see https://reviews.llvm.org/D85649):
- command-line options are "translated" to module-level LLVM IR
attributes (metadata).
- functions have PAC/BTI specific attributes iff the
__attribute__((target("branch-protection=...))) was used in the function
declaration.
- command-line option -mbranch-protection to armclang targeting Arm,
following this grammar:
branch-protection ::= "-mbranch-protection=" <protection>
protection ::= "none" | "standard" | "bti" [ "+" <pac-ret-clause> ]
| <pac-ret-clause> [ "+" "bti"]
pac-ret-clause ::= "pac-ret" [ "+" <pac-ret-option> ]
pac-ret-option ::= "leaf" ["+" "b-key"] | "b-key" ["+" "leaf"]
b-key is simply a placeholder to make it consistent with AArch64's
version. In Arm, however, it triggers a warning informing that b-key is
unsupported and a-key will be selected instead.
- Handle _attribute_((target(("branch-protection=..."))) for AArch32 with the
same grammer as the commandline options.
This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:
https://developer.arm.com/documentation/ddi0553/latest
The following people contributed to this patch:
- Momchil Velikov
- Victor Campos
- Ties Stuij
Reviewed By: vhscampos
Differential Revision: https://reviews.llvm.org/D112421
Previously, clang-format would not correctly identify preprocessor
directives directly following a conflict marker, which would result in
violating the formatter's invariants.
The provided test fails in assert mode before this change.
The invocation of a unary or binary operator for type-dependent expressions is represented as a CXXOperatorCallExpr. Upon template instantiation, TreeTransform::RebuildCXXOperatorCallExpr checks for the case of an overloaded operator, but not for a (non-ObjC) PseudoObject, and will directly create a UnaryOperator or BinaryOperator.
Generalizing commit 0f99537eca from @akyrtzi to handle non-ObjC pseudo objects (and also handle the case of unary pseudo object inc/dec).
This fixes https://bugs.llvm.org/show_bug.cgi?id=51855
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D111639
Fix for the case when there are no instructions in the entry basic block before the call
to `createSections`
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D114143
This patch changes clang-offload-bundler to use the original file extension for
the device archive member when unbundling archives instead of printing a warning
and defaulting to ".o".
Differential Revision: https://reviews.llvm.org/D114776
Allow toggling of -fnew-infallible so last instance takes precedence
Testing:
ninja check-all
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D113523
We've found that when profiling, counts are only generated for the real definition of constructor aliases (C2 in mangled name). However, when compiling the C1 version is present at the callsite and leads to a lack of counts due to this aliasing. This causes us to miss out on inlining an otherwise hot constructor.
-mconstructor-aliases is AFAICT an optimization, so having a disabling flag if wanted seems valuable.
Testing:
ninja check-all
Reviewed By: wenlei
Differential Revision: https://reviews.llvm.org/D114130
A big-endian version of vpermxor, named vpermxor_be, is added to LLVM
and Clang. vpermxor_be can be called directly on both the little-endian
and the big-endian platforms.
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D114540
Test failed on x86 platforms due to a calling convention mismatch
when member function was called like a free function. In this patch,
member function is marked static to address this.
This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.
Reviewed By: ymandel, xazax.hun, gribozavr2
Differential Revision: https://reviews.llvm.org/D114234
Over in D114631 and [0] there's a plan for turning instruction referencing
on by default for x86. This patch adds / removes all the relevant bits of
code, with the aim that the final patch is extremely small, for an easy
revert. It should just be a condition in CommandFlags.cpp and removing the
XFail on instr-ref-flag.ll.
[0] https://lists.llvm.org/pipermail/llvm-dev/2021-November/153653.html
Add the capability to simplify more complex constraints where there are 3
symbols in the tree. In this change I extend simplifySVal to query constraints
of children sub-symbols in a symbol tree. (The constraint for the parent is
asked in getKnownValue.)
Differential Revision: https://reviews.llvm.org/D103317
Currently, during symbol simplification we remove the original member symbol
from the equivalence class (`ClassMembers` trait). However, we keep the
reverse link (`ClassMap` trait), in order to be able the query the
related constraints even for the old member. This asymmetry can lead to
a problem when we merge equivalence classes:
```
ClassA: [a, b] // ClassMembers trait,
a->a, b->a // ClassMap trait, a is the representative symbol
```
Now lets delete `a`:
```
ClassA: [b]
a->a, b->a
```
Let's merge the trivial class `c` into ClassA:
```
ClassA: [c, b]
c->c, b->c, a->a
```
Now after the merge operation, `c` and `a` are actually in different
equivalence classes, which is inconsistent.
One solution to this problem is to simply avoid removing the original
member and this is what this patch does.
Other options I have considered:
1) Always merge the trivial class into the non-trivial class. This might
work most of the time, however, will fail if we have to merge two
non-trivial classes (in that case we no longer can track equivalences
precisely).
2) In `removeMember`, update the reverse link as well. This would cease
the inconsistency, but we'd loose precision since we could not query
the constraints for the removed member.
Differential Revision: https://reviews.llvm.org/D114619
We should match GCC's behavior which allows floating-point type for -mno-x87 option on 32-bits. https://godbolt.org/z/KrbhfWc9o
The previous block issues have partially been fixed by D112143.
Reviewed By: asavonic, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D114162
We're close to hitting the limited number of driver diagnostics, increase `DIAG_SIZE_DRIVER` to accommodate more.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D114615
See discussion in D51650, this change was a little aggressive in an
error while doing a 'while we were here', so this removes that error
condition, as it is apparently useful.
This reverts commit bb4934601d.
{D110833} regressed behavior of spaces before parentheses for operators, this revision reverts that so that operators are handled as they were before.
I think in hindsight it was a mistake to try and consume operator behaviour in with the function behaviour, I think Operators can be considered a special style. Its seems the code is getting confused as to if this is a function declaration or definition.
I think latterly we can consider adding an operator parentheses specific custom option but this should have been explicitly called out as it can impact projects.
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D114696
We don't properly handle lookup through using directives when there is
a linkage spec in the common chain. This is because `CppLookupName` and
`CppNamespaceLookup` end up skipping `LinkageSpec`'s (correctly, as they
are not lookup scopes), but the `UnqualUsingDirectiveSet` does not.
I discovered that when we are calculating the `CommonAncestor` for a
using-directive, we were coming up with the `LinkageSpec`, instead of
the `LinkageSpec`'s parent. Then, when we use
`UnqualUsingDirectiveSet::getNamespacesFor` a scope, we don't end up
finding any that were in the `LinkageSpec` (again, since `CppLookupName`
skips linkage specs), so those don't end up participating in the lookup.
The function `UnqualUsingDirectiveSet::addUsingDirective` calculates
this common ancestor via a loop through the the `DeclSpec::Encloses`
function.
Changing this Encloses function to believe that a `LinkageSpec`
`Encloses` nothing ends up fixing the problem without breaking any other tests,
so I opted to do that. A less aggressive patch could perhaps change only
the `addUsingDirective`, but my examination of all uses of `Encloses`
showed that it seems to be used exclusively in lookup, which makes me think
this is correct everywhere.
Differential Revision: https://reviews.llvm.org/D113709
I just read this part of the code, and I found the nested ifs less
readable.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D114441
Checker alpha.security.taint.TaintPropagation now has user documentation for
taint analysis with an example showing external YAML configuration format.
The format of the taint configuration file is now documented under the user
documentation of Clang SA.
Differential Revision: https://reviews.llvm.org/D113251
This doc lists ways of getting compilation databases out of some popular build systems for use with clangd and other tooling.
We built such a way for Bazel and just released it after a bunch of requests on GitHub. Thought I should propose that we add a link to help people find it and use clang tooling.
(This is my first revision submitted via LLVM Phabricator, so if I've messed something up, I'd really appreciate your help and patience. Asking for a review from Sam McCall, because I've had a great time working with him elsewhere on GitHub before and because I saw him in the Git history for this file.)
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D114213
Musl treats PowerPC SPE as a soft-float target (as the PowerPC SPE ABI
is soft-float compatible).
Reviewed By: jhibbits, MaskRay
Differential Revision: https://reviews.llvm.org/D105869
As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.
Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D114677
After 04f30795f1, -Wreturn-type has an effect on functions that
contain @try/@catch statements. CheckFallThrough() was missing
a case for ObjCAtTryStmts, leading to a false positive.
(What about the other two places in CheckFallThrough() that handle
CXXTryStmt but not ObjCAtTryStmts?
- I think the last use of CXXTryStmt is dead in practice: 04c6851cd made it so
that calls never add edges to try bodies, and the CFG block for a try
statement is always an empty block containing just the try element itself as
terminator (the try body itself is part of the normal flow of the function
and not connected to the block for the try statement itself. The try statment
cfg block is only connected to the catch bodies, and only reachable from
throw expressions within the try body.)
- The first use of CXXTryStmt might be important. It looks similar to
the code that adds all cfg blocks for try statements as roots of
the reachability graph for the reachability warnings, but I can't
find a way to trigger it. So I'm omitting it for now. The CXXTryStmt
code path seems to only be hit by try statements that are function
bodies without a surrounding compound statements
(`f() try { ... } catch ...`), and those don't exist for ObjC
@try statements.
)
Fixes PR52473.
Differential Revfision: https://reviews.llvm.org/D114660
The filesystem used during dependency scanning does two things: it caches file entries and minimizes source file contents. We use the term "ignored file" in a couple of places, but it's not clear what exactly that means. This commit clears up the semantics, explicitly spelling out this relates to minimization.
Currently, BeforeExecute is called before BeginSourceFile which does not allow
using PP in the callbacks. Change the ordering to ensure it is possible.
This is a prerequisite for D114370.
Originated from a discussion with @kadircet.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D114525
The AST structural equivalence check did not differentiate between
a struct and a struct with same name in different namespace. When
type of a member is checked it is possible to encounter such a case
and wrongly decide that the types are similar. This problem is fixed
by check for the namespaces of a record declaration.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D113118
[NFC] As part of using inclusive language within the llvm project, this patch
renames master flag to main flag in these comments.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D114090
GPUs are not supported on AIX, so this patch sets these tests as unsupported.
Reviewed By: stevewan
Differential Revision: https://reviews.llvm.org/D114381
Whilst the % clang-formatted remains the same, the number
of files added to the LLVM project has risen by almost by 259.
- 190 of them have been added clang-format clean.
- 69 files have been added unformatted. (lit tests should be excluded from this number)
- 291 files have been added to the list of files that are clang-format clean
- 101 files have either become unclean or have been removed
As this updates the clang-formatted-files there are now
8139 files that are clean which we can be used as a regression test when making changes to clang-format.
```
clang-format -verbose -n -files ./clang/docs/tools/clang-formatted-files.txt
```
Currently variables appearing inside private/firstprivate/lastprivate
clause of openmp task construct are not visible inside lldb debugger.
This is because compiler does not generate debug info for it.
Please consider the testcase debug_private.c attached with patch.
```
28 #pragma omp task shared(res) private(priv1, priv2) firstprivate(fpriv)
29 {
30 priv1 = n;
31 priv2 = n + 2;
32 printf("Task n=%d,priv1=%d,priv2=%d,fpriv=%d\n",n,priv1,priv2,fpriv);
33
-> 34 res = priv1 + priv2 + fpriv + foo(n - 1);
35 }
36 #pragma omp taskwait
37 return res;
(lldb) p priv1
error: <user expression 0>:1:1: use of undeclared identifier 'priv1'
priv1
^
(lldb) p priv2
error: <user expression 1>:1:1: use of undeclared identifier 'priv2'
priv2
^
(lldb) p fpriv
error: <user expression 2>:1:1: use of undeclared identifier 'fpriv'
fpriv
^
```
After the current patch, lldb is able to show the variables
```
(lldb) p priv1
(int) $0 = 10
(lldb) p priv2
(int) $1 = 12
(lldb) p fpriv
(int) $2 = 14
```
Reviewed By: djtodoro
Differential Revision: https://reviews.llvm.org/D114504
https://bugs.llvm.org/show_bug.cgi?id=52517
clang-format is butchering modules, this could easily become a barrier to entry for modules given clang-formats wide spread use.
Prevent the following from adding spaces around the `:` (cf was considering the ':' as an InheritanceColon)
Reviewed By: HazardyKnusperkeks, owenpan, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114151
https://bugs.llvm.org/show_bug.cgi?id=52595
missing space between `T(&&)` but not between `T (&` due to && being incorrectly thought of as `UnaryOperator` rather than `PointerOrReference`
```
int operator()(T (&)[N]) { return 0; }
int operator()(T(&&)[N]) { return 1; }
```
Existing Unit tests are changed because actually I think they are originally incorrect, and are inconsistent with the (&) cases that are 4 or 5 lines above them.
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D114519
From GCC's manpage:
-fplugin-arg-name-key=value
Define an argument called key with a value of value for the
plugin called name.
Since we don't have a key-value pair similar to gcc's plugin_argument
struct, simply accept key=value here anyway and pass it along as-is to
plugins.
This translates to the already existing '-plugin-arg-pluginname arg'
that clang cc1 accepts.
There is an ambiguity here because in clang, both the plugin name
as well as the option name can contain dashes, so when e.g. passing
-fplugin-arg-foo-bar-foo
it is not clear whether the plugin is foo-bar and the option is foo,
or the plugin is foo and the option is bar-foo. GCC solves this by
interpreting all dashes as part of the option name. So dashes can't be
part of the plugin name in this case.
Differential Revision: https://reviews.llvm.org/D113250
https://bugs.llvm.org/show_bug.cgi?id=47936
Using the MultiLine setting for BraceWrapping.AfterControlStatement appears to disable AllowShortFunctionsOnASingleLine, even in cases without any control statements
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D114521
The 14.31.30818 toolset has the following in the `stdatomic.h`:
~~~
#ifndef __cplusplus
#error <stdatomic.h> is not yet supported when compiling as C, but this is planned for a future release.
#endif
~~~
This results in clang failing to build existing code which relied on
`stdatomic.h` in C mode on Windows. Simply fallback to the clang header
until that header is available as a complete implementation.
The clang portion of c933c2eb33 was missed as I made
some kind of mistake squashing the commits with git.
This patch just adds those.
The original review: https://reviews.llvm.org/D114088
The PCH reader looks for `__clangast` section in the precompiled module file, which is not present in the file on AIX, and we don't support writing this custom section in XCOFF yet.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D114481
The AST structural equivalence check did not differentiate between
a struct and a struct with same name in different namespace. When
type of a member is checked it is possible to encounter such a case
and wrongly decide that the types are similar. This problem is fixed
by check for the namespaces of a record declaration.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D113118
The XL implementation of vec_round for vector double uses
"round-to-nearest, ties to even" just as the vector float
`version does. However clang and gcc use "round-to-nearest-away"
for vector double and "round-to-nearest, ties to even"
for vector float.
The XL behaviour is implemented under the __XL_COMPAT_ALTIVEC__
macro similarly to other instances of incompatibility.
Differential revision: https://reviews.llvm.org/D113642
Make all code go through FormatTokenSource instead of going around it, which
makes changes to TokenSource brittle.
Add LLVM_DEBUG in FormatTokenSource to be able to follow the token stream.
Make the SValBuilder capable to simplify existing
SVals based on a newly added constraints when evaluating a BinOp.
Before this patch, we called `simplify` only in some edge cases.
However, we can and should investigate the constraints in all cases.
Differential Revision: https://reviews.llvm.org/D113753
Add an AtomicScopeModel for HIP and support for OpenCL builtins
that are missing in HIP.
Patch by: Michael Liao
Revised by: Anshil Ghandi
Reviewed by: Yaxun Liu
Differential Revision: https://reviews.llvm.org/D113925
When building clang-format with -Wall on Visual Studio 20119 we see the following, prevent this the only -Wall error
```
..FormatTokenLexer.cpp(45) : warning C4868: compiler may not enforce left-to-right evaluation order in braced initializer list
```
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D113844
All supported FreeBSD releases use libc++, so default to it if the
target's major version is not specified.
Reviewed by: dim, emaste
Differential Revision: https://reviews.llvm.org/D77776
This enables Intel intrinsics support on FreeBSD.
Thanks to @pkubaj who noticed this feature was missing
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D113451
[NFC] As part of using inclusive language within the llvm project, this patch
replaces master with controller in these tests.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D114108
The test specified amd64-unknown-freebsd40.0 rather than 14.0. Since
40 is greater than 14 the test (for behaviour new in FreeBSD 14) worked
despite the typo.
Fixes: 699d47472c
Reviewed by: dim (in D77776)
This legacy option (available in other Fortran compilers with various
spellings) implies the SAVE attribute for local variables on subprograms
that are not explicitly RECURSIVE. The SAVE attribute essentially implies
static rather than stack storage. This was the default setting in Fortran
until surprisingly recently, so explicit SAVE statements & attributes
could be and often were omitted from older codes. Note that initialized
objects already have an implied SAVE attribute, and objects in COMMON
effectively do too, as data overlays are extinct; and since objects that are
expected to survive from one invocation of a procedure to the next in static
storage should probably be explicit initialized in the first place, so the
use cases for this option are somewhat rare, and all of them could be
handled with explicit SAVE statements or attributes.
This implicit SAVE attribute must not apply to automatic (in the Fortran sense)
local objects, whose sizes cannot be known at compilation time. To get the
semantics of IsSaved() right, the IsAutomatic() predicate was moved into
Evaluate/tools.cpp to allow for dynamic linking of the compiler. The
redundant predicate IsAutomatic() was noticed, removed, and its uses replaced.
GNU Fortran's spelling of the option (-fno-automatic) was added to
the clang-based driver and used for basic sanity testing.
Differential Revision: https://reviews.llvm.org/D114209
Make the SimpleSValBuilder capable to simplify existing IntSym
expressions based on a newly added constraint on the sub-expression.
Differential Revision: https://reviews.llvm.org/D113754
1. IndexTokenSource::getNextToken cannot return nullptr; some code was
still written assuming it can; make getNextToken more resilient against
incorrect input and fix its call-sites.
2. Change various asserts that can happen due to user provided input to
conditionals in the code.
The form 'for co_await' is part of CoroutineTS instead of C++20.
So if we detected the use of 'for co_await' in C++20, we should emit
a warning at least.
This is just a few trivial changes -- change the interpreter and fix a
few byte-vs-string issues.
Differential Revision: https://reviews.llvm.org/D107944
The `llvm.instrprof.increment` intrinsic uses `i32` for the index. We should use this same type for the index into the GEP instructions.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D114268
`DeducedTemplateSpecializationTypes` is a `llvm::FoldingSet<DeducedTemplateSpecializationType>` [1],
where `FoldingSetNodeID` is based on the values: {`TemplateName`, `QualType`, `IsDeducedAsDependent`},
those values are also used as `DeducedTemplateSpecializationType` constructor arguments.
A `FoldingSetNodeID` created by the static `DeducedTemplateSpecializationType::Profile` may not be equal
to`FoldingSetNodeID` created by a member `DeducedTemplateSpecializationType::Profile` of an instance
created with the same {`TemplateName`, `QualType`, `IsDeducedAsDependent`}, which makes
`DeducedTemplateSpecializationTypes` lookups nondeterministic.
Specifically, while `IsDeducedAsDependent` value is passes to the constructor, `IsDependent()` method on
the created instance may return a different value, because `IsDependent` is not saved as is:
```name=clang/include/clang/AST/Type.h
DeducedTemplateSpecializationType(TemplateName Template, QualType DeducedAsType, bool IsDeducedAsDependent)
: DeducedType(DeducedTemplateSpecialization, DeducedAsType,
toTypeDependence(Template.getDependence()) | // <~ also considers `TemplateName` parameter
(IsDeducedAsDependent ? TypeDependence::DependentInstantiation : TypeDependence::None)),
```
For example, if an instance A with key `FoldingSetNodeID {A, B, false}` is inserted. Then a key
`FoldingSetNodeID {A, B, true}` is probed:
If it happens to correspond to the same bucket in `FoldingSet` as the first key, and `A.Profile()` returns
`FoldingSetNodeID {A, B, true}`, then it's a hit.
If the bucket for the second key is different from the first key, instance A is not considered at all, and it's
a no hit, even if `A.Profile()` returns `FoldingSetNodeID {A, B, true}`.
Since `TemplateName`, `QualType` parameter values involve memory pointers, the lookup result depend on allocator,
and may differ from run to run. When this is used as part of modules compilation, it may result in "module out of date"
errors, if imported modules are built on different machines.
This makes `ASTContext::getDeducedTemplateSpecializationType` consider `Template.isDependent()` similar
`DeducedTemplateSpecializationType` constructor.
Tested on a very big codebase, by running modules compilations from directories with varied path length
(seem to affect allocator seed).
1. https://llvm.org/docs/ProgrammersManual.html#llvm-adt-foldingset-h
Patch by Wei Wang and Igor Sugak!
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D112481
This change allows SwiftAttr to be used with #pragma clang attribute push
to add Swift attributes to large regions of header files.
We plan to use this to annotate headers with concurrency information.
Patch by: Becca Royal-Gordon
Differential Revision: https://reviews.llvm.org/D112773
`CallDescriptions` have a `RequiredArgs` and `RequiredParams` members,
but they are of different types, `unsigned` and `size_t` respectively.
In the patch I use only `unsigned` for both, that should be large enough
anyway.
I also introduce the `MaybeUInt` type alias for `Optional<unsigned>`.
Additionally, I also avoid the use of the //smart// less-than operator.
template <typename T>
constexpr bool operator<=(const Optional<T> &X, const T &Y);
Which would check if the optional **has** a value and compare the data
only after. I found it surprising, thus I think we are better off
without it.
Reviewed By: martong, xazax.hun
Differential Revision: https://reviews.llvm.org/D113594
Previously, CallDescription simply referred to the qualified name parts
by `const char*` pointers.
In the future we might want to dynamically load and populate
`CallDescriptionMaps`, hence we will need the `CallDescriptions` to
actually **own** their qualified name parts.
Reviewed By: martong, xazax.hun
Differential Revision: https://reviews.llvm.org/D113593
This patch replaces each use of the previous API with the new one.
In variadic cases, it will use the ADL `matchesAny(Call, CDs...)`
variadic function.
Also simplifies some code involving such operations.
Reviewed By: martong, xazax.hun
Differential Revision: https://reviews.llvm.org/D113591
This patch introduces `CallDescription::matches()` member function,
accepting a `CallEvent`.
Semantically, `Call.isCalled(CD)` is the same as `CD.matches(Call)`.
The patch also introduces the `matchesAny()` variadic free function template.
It accepts a `CallEvent` and at least one `CallDescription` to match
against.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D113590
Sometimes we only want to decide if some function is called, and we
don't care which of the set.
This `CallDescriptionSet` will have the same behavior, except
instead of `lookup()` returning a pointer to the mapped value,
the `contains()` returns `bool`.
Internally, it uses the `CallDescriptionMap<bool>` for implementing the
behavior. It is preferred, to reuse the generic
`CallDescriptionMap::lookup()` logic, instead of duplicating it.
The generic version might be improved by implementing a hash lookup or
something along those lines.
Reviewed By: martong, Szelethus
Differential Revision: https://reviews.llvm.org/D113589
Eachempati.
This patch adds clang (parsing, sema, serialization, codegen) support for the 'depend' clause on the 'taskwait' directive.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D113540
Operations are emulated by software emulation and “float” instructions.
This patch is allowing the support of _Float16 type without the use of
-max512fp16 flag. The final goal being, perform _Float16 emulation for
all arithmetic expressions.
Makes clang-format bail out if an in-memory source file with an
unsupported BOM is handed in instead of creating source locations that
are violating clang's assumptions.
In the future, we should add support to better transport error messages
like this through clang-format instead of printing to stderr and not
creating any changes.
Let's describe accurately what the users can expect from the checker in
a direct way.
Also, add an example warning message.
Reviewed By: martong, Szelethus
Differential Revision: https://reviews.llvm.org/D113401
Sometimes it would be useful to see which Decl kind caused some issue,
along with the name of the concrete instance of the Decl in the source
code.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D113668
This test case had been missing when the original code
was introduced by 2fcb863b2b.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D114207
[NFC] This patch replaces `masterPort` with `mainPort` in these
testcases.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D113505
This covers both C-style variadic functions and template variadic w/
parameter packs.
Previously we would return no signatures when working with template
variadic functions once activeParameter reached the position of the
parameter pack (except when it was the only param, then we'd still
show it when no arguments were given). With this commit, we now show
signathure help correctly.
Additionally, this commit fixes the activeParameter value in LSP output
of clangd in the presence of variadic functions (both kinds). LSP does
not allow the activeParamter to be higher than the number of parameters
in the active signature. With "..." or parameter pack being just one
argument, for all but first argument passed to "..." we'd report
incorrect activeParameter value. Clients such as VSCode would then treat
it as 0, as suggested in the spec) and highlight the wrong parameter.
In the future, we should add support for per-signature activeParamter
value, which exists in LSP since 3.16.0. This is not part of this
commit.
Differential Revision: https://reviews.llvm.org/D111318
This removes the ability to disable roundtripping in assert builds.
(Roundtripping happens by default in assert builds both before and after
this patch.)
The CLANG_ROUND_TRIP_CC1_ARGS was added as an escape hatch 9 months ago
in https://reviews.llvm.org/D97462, with a FIXME to remove it eventually.
It's probably time to remove it.
Differential Revision: https://reviews.llvm.org/D114120
This patch refactors the code that checks whether a file has just been included for the first time.
The `HeaderSearch::FirstTimeLexingFile` function is removed and the information is threaded to the original call site from `HeaderSearch::ShouldEnterIncludeFile`. This will make it possible to avoid tracking the number of includes in a follow up patch.
Depends on D114092.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D114093
This patch removes `HeaderFileInfo::isNonDefault`, which is not being used anywhere.
Reviewed By: dexonsmith, vsapsai
Differential Revision: https://reviews.llvm.org/D114092
During explicit modules build, when all modules are provided via `-fmodule-file=<path>` and implicit modules and implicit module maps are disabled (`-fno-implicit-modules`, `-fno-implicit-module-maps`), we don't need to load the original module map files at all. This patch stops emitting the `-fmodule-map-file=` arguments we don't need, saving some compilation time due to avoiding parsing such module maps and making the command line shorter.
Reviewed By: bnbarham
Differential Revision: https://reviews.llvm.org/D113473
Problem:
PCM file includes references to all module maps used in compilation which created PCM. This problem leads to PCM-rebuilds in distributed compilations as some module maps could be missing in isolated compilation. (For example in our distributed build system we create a temp folder for every compilation with only modules and headers that are needed for that particular command).
Solution:
Add only affecting module map files to a PCM-file.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D106876
This is aligned with GCC's behavior.
Also, alias `-mno-fp-ret-in-387` to `-mno-x87`, by which we can fix pr51498.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112143
Add a tool for constructing commands for translating LLVM IR to
SPIR-V.
Used by HIPSPV tool chain (D110618).
Reviewed By: bader
Differential Revision: https://reviews.llvm.org/D112404
AMD64 ABI mandates caller to specify the number of used SSE registers
when passing variable arguments.
GCC also provides option -mskip-rax-setup to skip the setup of rax when
SSE is disabled. This helps to reduce the code size, see pr23258.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112413
Steven Wan