This was intended to be fixed by D98856, but that only seemed to have
the desired behaviour when compiling to assembly using `-S`, not when
compiling into an object file or executable. Given that this was not
the intention of D98856, this patch fixes the behaviour.
According to v-spec v1.0, `zve-32x` is the new minimum extension to include
to have vector instructions.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D112613
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: xazax.hun
Differential Revision: https://reviews.llvm.org/D117754
Added warning for potential cases of
unaligned access when option
-mno-unaligned-access has been specified
Differential Revision: https://reviews.llvm.org/D116221
When adding new attributes, existing attributes are dropped. While
this appears to be a longstanding issue, this was highlighted by D105169
which dropped a lot of attributes due to adding the new noundef
attribute.
Ahmed Bougacha (@ab) tracked down the issue and provided the fix in
CGCall.cpp. I bundled it up and updated the tests.
Similar to the migration of or-folding to FoldOr, there are a few cases
where the fold in IRBuilder::CreateAnd triggered directly. Those have
been updated.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117431
Under ASTContext, clang only copies the features from the options with
Target->initFeatureMap, and no implications is done there. This makes
clang_cc1 fail to imply into `zve32x` for the vector extension, and test
cases will have to add ` -target-feature +experimental-zve32x` in order
to work.
This patch fixes it.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D113336
Fixes https://github.com/llvm/llvm-project/issues/44601.
This patch handles a bug when parsing a below example code :
```
template <class> class S;
template <class T> bool operator<(S<T> const &x, S<T> const &y) {
return x.i < y.i;
}
template <class T> class S {
int i = 42;
friend bool operator< <>(S const &, S const &);
};
int main() { return S<int>{} < S<int>{}; }
```
which parse `< <>` as `<< >`, not `< <>` in terms of tokens as discussed in discord.
1. Add a condition in `tryMergeLessLess()` considering `operator` keyword and `>`
2. Force to leave a whitespace between `tok::less` and a template opener
3. Add unit test
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D117398
`zve` is the new standard vector extension to specify varying degrees of
vector support for embedding processors. The `zve` extension is related
to the `zvl` extension and other updates that are added in v1.0.
According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21,
Clang defines macro `__riscv_v_max_elen`, `__riscv_v_max_elen_fp` for
`zve` and it can be used by applications that uses the vector extension.
Authored by: Zakk Chen <zakk.chen@sifive.com> @khchen
Co-Authored by: Eop Chen <eop.chen@sifive.com> @eopXD
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112408
Once we linked in math files, potentially even if we link in only other
"system libraries", we want to optimize the code again. This is not only
reasonable but also helps to hide various problems with the missing
attribute annotations in the math libraries.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D116906
The OpenMP offloading libraries are built with fixed triples and linked
in during compile time. This would cause un-helpful errors if the user
passed in the wrong expansion of the triple used for the bitcode
library. because we only support these triples for OpenMP offloading we
can normalize them to the full verion used in the bitcode library.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D117634
This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a source file without any external dependency but the .OBJ itself (other than the compiler) and without knowledge of the build system.
The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the source, and the full CC1 command line. The stored command line is self-standing (does not depend on the environment). In the same way, MSVC doesn't exactly store the provided command-line, but an expanded version (a somehow equivalent of CC1) which is also self-standing.
For more information see PR36198 and D43002.
Differential Revision: https://reviews.llvm.org/D80833
Extracted from D117246. This reflects the march value used by the
compile back into the toolchain arguments, letting downstream processes
such as LTO rely on it being present. Subsequent patches should also be able
to remove the two other calls to checkSystemForAMDGPU.
Reviewed By: jonchesterfield
Differential Revision: https://reviews.llvm.org/D117706
This diff adds support for relative roots to VFS overlays. The directory root
will be made absolute from the current working directory and will be used to
determine the path style to use. This supports the use of VFS overlays with
remote build systems that might use a different working directory for each
compilation.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D116174
HIP program with printf call fails to compile with -fsanitize=address
option, because of appending module flag - amdgpu_hostcall twice, one
for printf and one for sanitize option. This patch fixes that issue.
Patch by: Praveen Velliengiri
Reviewed by: Yaxun Liu, Roman Lebedev
Differential Revision: https://reviews.llvm.org/D116216
This patch adds OMPIRBuilder support for the simd directive (without any clause). This will be a first step towards lowering simd directive in LLVM_Flang. The patch uses existing CanonicalLoop infrastructure of IRBuilder to add the support. Also adds necessary code to add llvm.access.group and llvm.loop metadata wherever needed.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D114379
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: xazax.hun
Differential Revision: https://reviews.llvm.org/D117667
Some tests were skipped in D114454 to resolve test failures on some
platforms, where the pointers have different bitwidth than expected.
This patch re-enables these tests, by relaxing the requirements on the
types of the SVal.
The issue:
There is no way to reconstruct the type of the `SVal` perfectly
accurately, since there could be multiple types having the required
bitwidth and signedness.
Consider platforms where `int` and `long` have the same bitwidth.
Additionally, we need to be careful about casting a pointer to an
integral representation, because we don't know what smallest integral
type can represent that.
To workaround these issues, I propose enforcing a type that has the
same signedness and bitwidth as the expected type, instead of perfect
equality.
In the `GetLocAsIntType` test, in case of pointer-to-integral casts
I'm using the widest standard integral type (long long) to make sure
that the pointer can be represented by the type without losing
precision. This won't affect the test in any meaningful way, since the
type of the `lvalue` remained the same.
In one case, I had to replace `getUIntPtrType()` with `UnsignedLongTy`
because on some platforms `getUIntPtrType()` is different then `long
int`.
In this patch, I also enforce that the tests must compile without
errors, to prevent narrowing conversions in the future.
Reviewed By: stevewan
Differential Revision: https://reviews.llvm.org/D115349
E.g. `Concept auto Func();`
The nameLoc for the constained auto type loc pointed to the concept name
loc, it should be the auto token loc. This patch fixes it, and remove
a relevant hack in clang-tidy check.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D117009
This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target
directive need to be externally visible to the plugin for initialization
or reading. Previously this would cause runtime errors where the named
global could not be found because it was not included in the symbol
table.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D117362
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: xazax.hun
Differential Revision: https://reviews.llvm.org/D117567
Knowing the type of more dependent expressions means we can diagnose
more errors at template parsing rather than instantiation time.
Such templates are IFNDR, so this is a QoI improvement.
I hadn't anticipated this in the original patch, so had no test.
C17 deprecated ATOMIC_VAR_INIT with the resolution of DR 485. C++
followed suit when adopting P0883R2 for C++20, but additionally chose
to deprecate ATOMIC_FLAG_INIT at the same time despite the macro still
being required in C. This patch marks both macros as deprecated when
appropriate to do so.
This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target
directive need to be externally visible to the plugin for initialization
or reading. Previously this would cause runtime errors where the named
global could not be found because it was not included in the symbol
table.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D117362
This patch changes the visibility of the `__omp_rtl_debug_kind` variable
to be hidden. These variables are only used by the plugin so they do not
need to be read externally. Previously the default visibility prevented
these variables from being completely eliminated in the module.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D117320
The parsing code for a typename requirement currently asserts when
given something which is not a valid type-requirement
(http://eel.is/c++draft/expr.prim.req.type#nt:type-requirement). This
removes the assertion to continue on to the proper diagnostic.
This resolves PR53057.
Note that in that PR, it is using _BitInt(N) as a dependent type name.
This patch does not attempt to support that as it is not clear that is
a valid type requirement (it does not match the grammar production for
one). The workaround in the PR, however, is definitely valid and works
as expected.
The FIXME is no longer relevant as ControlFlowContext centralizes the
construction of the CFG.
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: xazax.hun
Differential Revision: https://reviews.llvm.org/D117563
GenericTaintChecker now uses CallDescriptionMap to describe the possible
operation in code which trigger the introduction (sources), the removal
(filters), the passing along (propagations) and detection (sinks) of
tainted values.
Reviewed By: steakhal, NoQ
Differential Revision: https://reviews.llvm.org/D116025
The `{HeaderSearch,Preprocessor}::LookupFile()` functions take an out-parameter `const DirectoryLookup *&`. Most callers end up creating a `const DirectoryLookup *` variable that's otherwise unused.
This patch changes the out-parameter from reference to a pointer, making it possible to simply pass `nullptr` to the function without the ceremony.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D117312
This patch removes bitrotten/dead uses of `DirectoryLookup` in `InclusionRewriter.cpp`.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D117309
Summary: Produce SymbolCast for integral types in `evalCast` function. Apply several simplification techniques while producing the symbols. Added a boolean option `handle-integral-cast-for-ranges` under `-analyzer-config` flag. Disabled the feature by default.
Differential Revision: https://reviews.llvm.org/D105340
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: xazax.hun
Differential Revision: https://reviews.llvm.org/D117496
Since Environment's setValue method already does part of the work that
initValueInStorageLocation does, we can factor out a new createValue
method to reduce the duplication.
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
Differential Revision: https://reviews.llvm.org/D117493
Sander de Smalen