Allow the usage of minor version 0, for hip versions
such as 4.0. Change the default values when performing
version checks.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D104062
This adds implementation information for N2607,
clarifies that C17 only resolved defect reports,
and adds -std= information for the different versions.
Check applied to unbounded (incomplete) arrays and pointers to spot
cases where the computed address is beyond the largest possible
addressable extent of the array, based on the address space in which the
array is delcared, or which the pointer refers to.
Check helps to avoid cases of nonsense pointer math and array indexing
which could lead to linker failures or runtime exceptions. Of
particular interest when building for embedded systems with small
address spaces.
This is version 2 of this patch -- version 1 had some testing issues
due to a sign error in existing code. That error is corrected and
lit test for this chagne is extended to verify the fix.
Originally reviewed/accepted by: aaron.ballman
Original revision: https://reviews.llvm.org/D86796
Reviewed By: aaron.ballman, ebevhan
Differential Revision: https://reviews.llvm.org/D88174
Adds the basic instrumentation needed for stack tagging.
Currently does not support stack short granules or TLS stack histories,
since a different code path is followed for the callback instrumentation
we use.
We may simply wait to support these two features until we switch to
a custom calling convention.
Patch By: xiangzhangllvm, morehouse
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D102901
Given `int foo, bar;`, TraverseAST reveals this tree:
TranslationUnitDecl
- foo
- bar
Before this patch, with the TraversalScope set to {foo}, TraverseAST yields:
foo
After this patch it yields:
TranslationUnitDecl
- foo
Also, TraverseDecl(TranslationUnitDecl) now respects the traversal scope.
---
The main effect of this today is that clang-tidy checks that match the
translationUnitDecl(), either in order to traverse it or check
parentage, should work.
Differential Revision: https://reviews.llvm.org/D104071
<string> is currently the highest impact header in a clang+llvm build:
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html
One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.
This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.
Differential Revision: https://reviews.llvm.org/D103888
Refactor to avoid assignment inside condition by using 'if
(init-decl)'. Also remove some unnecessary braces on a separate
if-nest.
Differential Revision: https://reviews.llvm.org/D104039
This fixes the prioritization of address spaces when choosing a
constructor, stopping them from being considered equally good,
which made the construction of types that could be constructed
by more than one of the constructors.
It does this by preferring the most specific address space,
which is decided by seeing if one of the address spaces is
a superset of the other, and preferring the other.
Fixes: PR50329
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D102850
The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
block.
Differential Revision: https://reviews.llvm.org/D104101
Whenever Tracker spawns a visitor that needs to call tracker
back, we have to use TrackingBugReporterVisitor in order to maintain
all the hooks that the checker might've used.
Differential Revision: https://reviews.llvm.org/D103628
This component should not be used directly at this point and it is
simply an implementation detail, that's why StoreSiteFinder is
out of the header file.
Differential Revision: https://reviews.llvm.org/D103624
Additionally, this commit completely removes any uses of
FindLastStoreBRVisitor from the analyzer except for the
one in Tracker.
The next step is actually removing this class altogether
from the header file.
Differential Revision: https://reviews.llvm.org/D103618
This commit moves trackExpressionValue into the Tracker interface
as DefaultExpressionHandler. It still can be split into smaller
handlers, but that can be a future change.
Additionally, this commit doesn't remove the original trackExpressionValue
interface, so it's not too big. One of the next commits will address it.
Differential Revision: https://reviews.llvm.org/D103616
Tracking values through expressions and the stores is fundamental
for producing clear diagnostics. However, the main components
participating in this process, namely `trackExpressionValue` and
`FindLastStoreBRVisitor`, became pretty bloated. They have an
interesting dynamic between them (and some other visitors) that
one might call a "chain reaction". `trackExpressionValue` adds
`FindLastStoreBRVisitor`, and the latter calls `trackExpressionValue`.
Because of this design, individual checkers couldn't affect what's
going to happen somewhere in the middle of that chain. Whether they
want to produce a more informative note or keep the overall tracking
going by utilizing some of the domain expertise. This all lead to two
biggest problems that I see:
* Some checkers don't use it
This should probably never be the case for path-sensitive checks.
* Some checkers incorporated their logic directly into those
components
This doesn't make the maintenance easier, breaks multiple
architecture principles, and makes the code harder to read adn
understand, thus, increasing the probability of the first case.
This commit introduces a prototype for a new interface that will be
responsible for tracking. My main idea here was to make operations
that I want have as a checker developer easy to implement and hook
directly into the tracking process.
Differential Revision: https://reviews.llvm.org/D103605
Since 8866793b4e ("[OpenCL] Add OpenCL builtin test generator",
2021-06-09) there are two emitters in this file, so move the
file-level comment to the appropriate class.
-Wframe-larger-than= is an interesting warning; we can't know the frame
size until PrologueEpilogueInsertion (PEI); very late in the compilation
pipeline.
-Wframe-larger-than= was propagated through CC1 as an -mllvm flag, then
was a cl::opt in LLVM's PEI pass; this meant it was dropped during LTO
and needed to be re-specified via -plugin-opt.
Instead, make it part of the IR proper as a module level attribute,
similar to D103048. Introduce -fwarn-stack-size CC1 option.
Reviewed By: rsmith, qcolombet
Differential Revision: https://reviews.llvm.org/D103928
This expands NRVO propagation for more cases:
Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
marked as NRVO Candidates.
Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
variables' NRVO status propagated. For Blocks with non-auto return type,
as a limitation, this propagation does not consider the actual return
type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D99696
Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations).
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D99459
This patch adds the command line options /permissive and /permissive- to clang-cl. These flags are used in MSVC to enable various /Zc language conformance options at once. In particular, /permissive is used to enable the various non standard behaviour of MSVC, while /permissive- is the opposite.
When either of two command lines are specified they are simply expanded to the various underlying /Zc options. In particular when /permissive is passed it currently expands to:
/Zc:twoPhase- (disable two phase lookup)
-fno-operator-names (disable C++ operator keywords)
/permissive- expands to the opposites of these flags + /Zc:strictStrings (/Zc:strictStrings- does not currently exist). In the future, if any more MSVC workarounds are ever added they can easily be added to the expansion. One is also able to override settings done by permissive. Specifying /permissive- /Zc:twoPhase- will apply the settings from permissive minus, but disables two phase lookup.
Motivation for this patch was mainly parity with MSVC as well as compatibility with Windows SDK headers. The /permissive page from MSVC documents various workarounds that have to be done for the Windows SDK headers [1], when MSVC is used with /permissive-. In these, Microsoft often recommends simply compiling with /permissive for the specified source files. Since some of these also apply to clang-cl (which acts like /permissive- by default mostly), and some are currently implemented as "hacks" within clang that I'd like to remove, adding /permissive and /permissive- to be in full parity with MSVC and Microsofts documentation made sense to me.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-160#windows-header-issues
Differential Revision: https://reviews.llvm.org/D103773
When using the -fno-rtti option of the GCC style clang++, using typeid results in an error. The MSVC STL however kindly provides a define flag called _HAS_STATIC_RTTI, which either enables or disables uses of typeid throughout the STL. By default, if undefined, it is set to 1, enabling the use of typeid.
With this patch, _HAS_STATIC_RTTI is set to 0 when -fno-rtti is specified. This way various headers of the MSVC STL like functional can be consumed without compilation failures.
Differential Revision: https://reviews.llvm.org/D103771
This patch adds the command line option -foperator-names which acts as the opposite of -fno-operator-names. With this command line option it is possible to reenable C++ operator keywords on the command line if -fno-operator-names had previously been passed.
Differential Revision: https://reviews.llvm.org/D103749
This patch changes the ffp-model=precise to enables -ffp-contract=on
(previously -ffp-model=precise enabled -ffp-contract=fast). This is a
follow-up to Andy Kaylor's comments in the llvm-dev discussion
"Floating Point semantic modes". From the same email thread, I put
Andy's distillation of floating point options and floating point modes
into UsersManual.rst
Differential Revision: https://reviews.llvm.org/D74436
Clang will create a global value put in constant memory if an aggregate value
is declared firstprivate in the target device. The symbol name only uses the
name of the firstprivate variable, so symbol name conflicts will occur if the
variable is allowed to have different types through templates. An example of
this behvaiour is shown in https://godbolt.org/z/EsMjYh47n. This patch adds the
mangled type name to the symbol to avoid such naming conflicts. This fixes
https://bugs.llvm.org/show_bug.cgi?id=50642.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103995
Before this change, CXXDefaultArgExpr would always have
ExprDependence::None. This can lead to issues when, for example, the
inner expression is RecoveryExpr and yet containsErrors() on the default
expression is false.
Differential Revision: https://reviews.llvm.org/D103982
Post-commit feedback for d69c4372bf says the output
may vary between pass managers. This is hopefully a
quick fix, but we might want to investigate how to
better solve this type of problem.
Add a test to verify OpenCL builtin declarations using
OpenCLBuiltins.td.
This test consists of parsing a 60k line generated input file. The
entire test takes about 60s with a debug build on a decent machine.
Admittedly this is not the fastest test, but doesn't seem excessive
compared to other tests in clang/test/Headers (with one of the tests
taking 85s for example).
RFC: https://lists.llvm.org/pipermail/cfe-dev/2021-April/067973.html
Differential Revision: https://reviews.llvm.org/D97869
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and
lowering methods for load and stores of reference types from IR
globals. Once the lowering creates the new nodes, tablegen pattern
matches those and converts them to Wasm global.get/set.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D95425
Added --gpu-bundle-output to control bundling/unbundling output of HIP device compilation.
By default preprocessor expansion, llvm bitcode and assembly are unbundled, code objects are
bundled.
Reviewed by: Artem Belevich, Jan Svoboda
Differential Revision: https://reviews.llvm.org/D101630
1. There is no tests for mabi=ilp32e, and my patch covers that.
2. The tests in riscv-abi.c will show default ABI changes for special archs
in the future, especially the arch with the F but without the D extension.
3. The tests in riscv-arch.c will show default arch changes for abi=ilp32,
which is rv32imacfd currently, but it is better to be rv32imac.
And it is also better for abi=ilp32f defaults to arch=imacf.
Reviewed By: MaskRay, luismarques
Differential Revision: https://reviews.llvm.org/D103878
Aaron En Ye Shi