is not used since it consumes all preprocessor directives until it returns
a real token. Using the specific Lexer (i.e. CurLexer->Lex) makes it
possible to stop skipping after an #include or #pragma hdrstop. Previously
the skipping code was only handling CurLexer, now all will be handled
correctly.
Fixes: llvm.org/PR41585
Differential Revision: https://reviews.llvm.org/D61217
llvm-svn: 359506
Summary:
We are currently implementing support in LLDB that reconstructs the STL templates from
the target program in the expression evaluator. This reconstruction happens during the
import process from our debug info AST into the expression evaluation AST, which means
we need a way to intercept the ASTImporter import process.
This patch adds an protected ImportImpl method that we can overwrite in LLDB to implement
our special importing logic (which is essentially just looking into a C++ module that is attached to
the target context). Because ImportImpl has to call MapImported/AddToLookup for the decls it
creates, this patch also exposes those via a new unified method and checks that we call it when
importing decls.
Reviewers: martong, balazske, a.sidorin, shafik, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: rnkovacs, cfe-commits, lldb-commits, aprantl
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59485
llvm-svn: 359502
Summary: This fixes a few places in the Stencil implementation where a unique_ptr is created at a callsite that expects shared_ptr. Since the former implicitly converts to the latter, the code compiles and runs correctly as is. But, there's no reason to involve unique_ptr -- the current code was leftover from a previous version in which unique_ptr was the expected type.
Reviewers: sbenza
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61005
llvm-svn: 359468
us emitting the operand of __builtin_constant_p if it has side-effects.
Original commit message:
Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.
GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type
llvm-svn: 359367
This introduces a support for multilibs to Fuchsia driver. Unlike the
existing multilibs that are used primarily for handling different
architecture variants, we use multilibs to handle different variants
of Clang runtime libraries: -fsanitize=address and -fno-exceptions
are the two we support initially. This replaces the existing support
for sanitized runtimes libraries that was only used by Fuchsia driver
and it also refactors some of the logic to allow sharing between GNU
and Fuchsia drivers.
Differential Revision: https://reviews.llvm.org/D61040
llvm-svn: 359360
When more than one multilib flag matches, try to select the best
possible match based on priority. When two different multilibs with
the same same priority match, we still throw an error matching the
existing behavior.
Differential Revision: https://reviews.llvm.org/D60990
llvm-svn: 359359
is running in a toolchain outside of xcode
'libarclite' usually lives in the same toolchain as 'clang'. However, the
Swift open source toolchains for macOS distribute Clang without 'libarclite'.
In that case, to allow the linker to find 'libarclite', we point to the
'libarclite' that should be in the XcodeDefault toolchain instead. The
path to the toolchain is inferred from the SDK path if it's specified.
https://bugs.swift.org/browse/SR-9972
rdar://49947573
llvm-svn: 359353
This provides intrinsics support for Memory Tagging Extension (MTE),
which was introduced with the Armv8.5-a architecture.
These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined.
Each intrinsic is described in detail in the ACLE Q1 2019 documentation:
https://developer.arm.com/docs/101028/latest
Reviewed By: Tim Nortover, David Spickett
Differential Revision: https://reviews.llvm.org/D60485
llvm-svn: 359348
This makes sure that code built with headers for a statically linked
libc++ also works when linking to the DLL version, when the DLL
hasn't been built with --export-all-symbols.
This matches what GCC for MinGW does for this test case.
Differential Revision: https://reviews.llvm.org/D61177
llvm-svn: 359345
Summary:
- `__constant__` variables should not be `hidden` as the linker may turn
them into `LOCAL` symbols.
Reviewers: yaxunl
Subscribers: jvesely, nhaehnle, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61194
llvm-svn: 359344
Normally, in MinGW mode, inline methods aren't dllexported.
However, in the case of a dllimported template instantiation,
the inline methods aren't instantiated locally, but referenced
from the instantiation. Therefore, those methods also need to
be dllexported, in the case of an instantiation.
GCC suffers from the same issue, reported at [1], but the issue
is still unresolved there.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088
Differential Revision: https://reviews.llvm.org/D61176
llvm-svn: 359343
An explicit template instantiation declaration used to let
callers assume both outer and nested classes instantiations were
defined in a different translation unit.
If the instantiation is marked dllexport, only the outer class
is exported, but the caller will try to reference the instantiation
of both outer and inner classes.
This makes MinGW mode match both MSVC and Windows Itanium, by
having instantations only cover the outer class, and locally emitting
definitions of the nested classes. Windows Itanium was changed to
use this behavious in SVN r300804.
This deviates from what GCC does, but should be safe (and only
inflate the object file size a bit, but MSVC and Windows Itanium
modes do the same), and fixes cases where inner classes aren't
dllexported.
This fixes missing references in combination with dllexported/imported
template intantiations.
GCC suffers from the same issue, reported at [1], but the issue
is still unresolved there. The issue can probably be solved either
by making dllexport cover all nested classes as well, or this
way (matching MSVC).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087
Differential Revision: https://reviews.llvm.org/D61175
llvm-svn: 359342
counters.
According to the OpenMP 5.0, For any associated loop where the b or lb
expression is not loop invariant with respect to the outermost loop, the
var-outer that appears in the expression may not have a random access
iterator type.
llvm-svn: 359340
Summary:
For a CXXRecordDecl the RecordDeclBits are stored in the DeclContext. Currently when we import the definition of a CXXRecordDecl via the ASTImporter we do not copy over this data.
This change will add support for copying the ArgPassingRestrictions from RecordDeclBits to fix an LLDB expression parsing bug where we would set it to not pass in registers.
Note, we did not copy over any other of the RecordDeclBits since we don't have tests for those. We know that copying over LoadedFieldsFromExternalStorage would be a error and that may be the case for others as well.
The companion LLDB review: https://reviews.llvm.org/D61146
Differential Review: https://reviews.llvm.org/D61140
llvm-svn: 359338
"DefineStd(Builder, "bpf", Opts)" generates the following three
macros:
bpf
__bpf
__bpf__
and the macro "bpf" is due to the fact that the target language
is C which allows GNU extensions.
The name "bpf" could be easily used as variable name or type
field name. For example, in current linux kernel, there are
four places where bpf is used as a field name. If the corresponding
types are included in bpf program, the compilation error will
occur.
This patch removed predefined macro "bpf" as well as "__bpf" which
is rarely used if used at all.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61173
llvm-svn: 359310
Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute
on the template instantiation declaration, not on the definition.
Previously clang never marked explicit template instantiations as
dllexport in MinGW mode, if the instantiation had a previous
declaration, regardless of where the attribute was placed. This
makes Clang behave like GCC in this regard, and allows using the
same attribute form for both MinGW compilers.
This fixes PR40256.
Differential Revision: https://reviews.llvm.org/D61118
llvm-svn: 359285
This patch is more of a fix than a real improvement: in checkPostCall()
we should return immediately after finding the right call and handling
it. This both saves unnecessary processing and double-handling calls by
mistake.
Differential Revision: https://reviews.llvm.org/D61134
llvm-svn: 359283
In the OSObject universe there appears to be another slightly popular contract,
apart from "create" and "get", which is "matching". It optionally consumes
a "table" parameter and if a table is passed, it fills in the table and
returns it at +0; otherwise, it creates a new table, fills it in and
returns it at +1.
For now suppress false positives by doing a conservative escape on all functions
that end with "Matching", which is the naming convention that seems to be
followed by all such methods.
Differential Revision: https://reviews.llvm.org/D61161
llvm-svn: 359264
Because RetainCountChecker has custom "local" reasoning about escapes,
it has a separate facility to deal with tracked symbols at end of analysis
and check them for leaks regardless of whether they're dead or not.
This facility iterates over the list of tracked symbols and reports
them as leaks, but it needs to treat the return value specially.
Some custom allocators tend to return the value with an offset, storing
extra metadata at the beginning of the buffer. In this case the return value
would be a non-base region. In order to avoid false positives, we still need to
find the original symbol within the return value, otherwise it'll be unable
to match it to the item in the list of tracked symbols.
Differential Revision: https://reviews.llvm.org/D60991
llvm-svn: 359263
the assertion is in fact incorrect: there is a cornercase in Objective-C++
in which a C++ object is not constructed with a constructor, but merely
zero-initialized. Namely, this happens when an Objective-C message is sent
to a nil and it is supposed to return a C++ object.
Differential Revision: https://reviews.llvm.org/D60988
llvm-svn: 359262
const-qualified type is not implicitly given internal linkage. But a
variable template declared 'static' is.
This reinstates part of r359048, reverted in r359076.
llvm-svn: 359260
internal linkage entities.
Such constructs are ill-formed by [temp.explicit]p13. We make a special
exception to permit an invalid construct used by libc++ in some build
modes: its <valarray> header declares some functions with the
internal_linkage attribute and then (meaninglessly) provides explicit
instantiation declarations for them. Luckily, Clang happens to
effectively ignore the explicit instantiation declaration when
generating code in this case, and this change codifies that behavior.
This reinstates part of r359048, reverted in r359076. (The libc++ issue
triggering the rollback has been addressed.)
llvm-svn: 359259
Summary:
This is a follow up to r355253, which inadvertently broke Visual
Studio builds by trying to copy files from CMAKE_CFG_INTDIR.
See https://reviews.llvm.org/D58537#inline-532492
Reviewers: smeenai, vzakhari, phosek
Reviewed By: smeenai
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61054
llvm-svn: 359257
This reverts r359250 (git commit 4730604bd3)
The newly added test should use -cc1 and -emit-llvm and there are other
test failures that need fixing.
llvm-svn: 359251
Statically link certain runtime library functions for MSVC/GNU Windows
environments. This is consistent with MSVC behavior.
Fixes LNK4286 and LNK4217 warnings from link.exe when linking the static
CRT:
LINK : warning LNK4286: symbol '__std_terminate' defined in 'libvcruntime.lib(ehhelpers.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.asan_noinst_test.cc.x86_64-calls.o'
LINK : warning LNK4286: symbol '__std_terminate' defined in 'libvcruntime.lib(ehhelpers.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.asan_test_main.cc.x86_64-calls.o'
LINK : warning LNK4217: symbol '_CxxThrowException' defined in 'libvcruntime.lib(throw.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.gtest-all.cc.x86_64-calls.o' in function '"int `public: static class UnitTest::GetInstance * __cdecl testing::UnitTest::GetInstance(void)'::`1'::dtor$5" (?dtor$5@?0??GetInstance@UnitTest@testing@@SAPEAV12@XZ@4HA)'
Reviewers: mstorsjo, efriedma, TomTan, compnerd, smeenai, mgrang
Subscribers: abdulras, theraven, smeenai, pcc, mehdi_amini, javed.absar, inglorion, kristof.beyls, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D55229
llvm-svn: 359250
These builtins provide access to the new integer and
sub-integer variants of MMA (matrix multiply-accumulate) instructions
provided by CUDA-10.x on sm_75 (AKA Turing) GPUs.
Also added a feature for PTX 6.4. While Clang/LLVM does not generate
any PTX instructions that need it, we still need to pass it through to
ptxas in order to be able to compile code that uses the new 'mma'
instruction as inline assembly (e.g used by NVIDIA's CUTLASS library
https://github.com/NVIDIA/cutlass/blob/master/cutlass/arch/mma.h#L101)
Differential Revision: https://reviews.llvm.org/D60279
llvm-svn: 359248
(this would regress size without a corresponding LLVM change that avoids
putting other user defined types inside type units when they aren't in
their own type units - instead emitting declarations inside the type
unit and a definition in the primary CU)
Reviewers: aprantl
Differential Revision: https://reviews.llvm.org/D61079
llvm-svn: 359235
Path lists on windows should always be separated by semicolons, not
colons. Reuse llvm::sys::EnvPathSeparator for this purpose (as that's
also a path list that is separated in the same way).
Alternatively, this could just be a local ifdef _WIN32 in this function,
or generalizing the existing EnvPathSeparator to e.g. a
llvm::sys::path::PathListSeparator?
Differential Revision: https://reviews.llvm.org/D61121
llvm-svn: 359233
https://bugs.llvm.org/show_bug.cgi?id=41590
For the following code snippet, UninitializedObjectChecker crashed:
struct MyAtomicInt {
_Atomic(int) x;
MyAtomicInt() {}
};
void entry() {
MyAtomicInt b;
}
The problem was that _Atomic types were not regular records, unions,
dereferencable or primitive, making the checker hit the llvm_unreachable at
lib/StaticAnalyzer/Checkers/UninitializedObject/UninitializedObjectChecker.cpp:347.
The solution is to regard these types as primitive as well. The test case shows
that with this addition, not only are we able to get rid of the crash, but we
can identify x as uninitialized.
Differential Revision: https://reviews.llvm.org/D61106
llvm-svn: 359230
Currently InstrProf lowering is not enabled for Clang PGO instrumentation in
the new pass manager. The following command
"-fprofile-instr-generate -fexperimental-new-pass-manager ..." is broken.
This CL enables InstrProf lowering pass for Clang PGO instrumentation in the
new pass manager.
Differential Revision: https://reviews.llvm.org/D61138
llvm-svn: 359215
loop nests.
Added a checks that the initializer/condition expressions depend only
only of the single previous loop iteration variable.
llvm-svn: 359200
Summary:
Add a new variant to GlobalDecl for these so that we can detect them
more easily during debug info emission and handle them appropriately.
Reviewers: rsmith, rjmccall, jyu2
Subscribers: aprantl, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60930
llvm-svn: 359148
Summary:
Include insertion in clangd was inserting absolute paths when the
include directory was an absolute path with a double dot. This patch makes sure
double dots are handled both with absolute and relative paths.
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60873
llvm-svn: 359078
The behaviour of not quoting spaces appears to have been introduced by
mistake in r190620.
Patch by Brad Moody!
Differential revision: https://reviews.llvm.org/D60997
llvm-svn: 359077
The change breaks libc++ with the follwing error:
In file included from valarray:4:
.../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t))
^
.../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray())
llvm-svn: 359076
Summary:
This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`.
More tests to come, but early feedback is appreciated.
I plan to implement warnings for common mis-usages like those belowe in a following patch:
```
void foo(int x) {
if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead.
foo_constexpr(x);
} else {
foo_runtime(x);
}
}
```
Reviewers: rsmith, MaskRay, bruno, void
Reviewed By: rsmith
Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits
Differential Revision: https://reviews.llvm.org/D55500
llvm-svn: 359067
of an auto"
This commit changed the initializer expression passed into
initialization (stripping off an enclosing pair of parentheses or
braces) and subtly changing the meaning of programs, typically by
inserting bogus calls to copy constructors.
See the added testcase in test/SemaCXX/cxx1y-init-captures.cpp for an
example of the breakage.
llvm-svn: 359066
current trunk GCC.
GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type
llvm-svn: 359059
recursively captured.
Under ARC, a block variable is zero-initialized when it is recursively
captured by the block literal initializer.
rdar://problem/11022762
llvm-svn: 359049
AMDGPU currently relies on global properties being set before
setTargetProperties is called. Existing targets like MIPS which rely on
setTargetProperties do not rely on the current behavior, so this patch
moves the call later in SetFunctionAttributes.
Differential Revision: https://reviews.llvm.org/D60967
llvm-svn: 359039
If macro "CHECK_X(x)" expands to something like "if (x != NULL) ...",
the "Assuming..." note no longer says "Assuming 'x' is equal to CHECK_X".
Differential Revision: https://reviews.llvm.org/D59121
llvm-svn: 359037
Summary:
The opt level was not being passed down to the ThinLTO backend when
invoked via clang (for distributed ThinLTO).
This exposed an issue where the new PM was asserting if the Thin or
regular LTO backend pipelines were invoked with -O0 (not a new issue,
could be provoked by invoking in-process *LTO backends via linker using
new PM and -O0). Fix this similar to the old PM where -O0 only does the
necessary lowering of type metadata (WPD and LowerTypeTest passes) and
then quits, rather than asserting.
Reviewers: xur
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits, pcc
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61022
llvm-svn: 359025
Summary:
The existing CTU mechanism imports `FunctionDecl`s where the definition is available in another TU. This patch extends that to VarDecls, to bind more constants.
- Add VarDecl importing functionality to CrossTranslationUnitContext
- Import Decls while traversing them in AnalysisConsumer
- Add VarDecls to CTU external mappings generator
- Name changes from "external function map" to "external definition map"
Reviewers: NoQ, dcoughlin, xazax.hun, george.karpenkov, martong
Reviewed By: xazax.hun
Subscribers: Charusso, baloghadamsoftware, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, george.karpenkov, mgorny, whisperity, szepet, rnkovacs, a.sidorin, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D46421
llvm-svn: 358968
A compilation warning was in my previous commit which broke the buildbot
because it is using `-Werror` for compilation. This patch fixes this
issue.
llvm-svn: 358955
Currently iterator checkers record comparison of iterator positions
and process them for keeping track the distance between them (e.g.
whether a position is the same as the end position). However this
makes some processing unnecessarily complex and it is not needed at
all: we only need to keep track between the abstract symbols stored
in these iterator positions. This patch changes this and opens the
path to comparisons to the begin() and end() symbols between the
container (e.g. size, emptiness) which are stored as symbols, not
iterator positions. The functionality of the checker is unchanged.
Differential Revision: https://reviews.llvm.org/D53701
llvm-svn: 358951
Port mmintrin.h which include x86 MMX intrinsics implementation to PowerPC platform (using Altivec).
To make the include process correct, PowerPC's toolchain class is overrided to insert new headers directory (named ppc_wrappers) into the path. Basic test cases for several intrinsic functions are added.
The header is mainly developed by Steven Munroe, with contributions from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu.
Reviewed By: Jinsong Ji
Differential Revision: https://reviews.llvm.org/D59924
llvm-svn: 358949
When growing a body on a body farm, it's essential to use the same redeclaration
of the function that's going to be used during analysis. Otherwise our
ParmVarDecls won't match the ones that are used to identify argument regions.
This boils down to trusting the reasoning in AnalysisDeclContext. We shouldn't
canonicalize the declaration before farming the body because it makes us not
obey the sophisticated decision-making process of AnalysisDeclContext.
Differential Revision: https://reviews.llvm.org/D60899
llvm-svn: 358946
Stuffing invalid source locations (such as those in functions produced by
body farms) into path diagnostics causes crashes.
Fix a typo in a nearby function name.
Differential Revision: https://reviews.llvm.org/D60808
llvm-svn: 358945
Implement cplusplus.SmartPtrModeling, a new checker that doesn't
emit any warnings but models methods of smart pointers more precisely.
For now the only thing it does is make `(bool) P` return false when `P`
is a freshly moved pointer. This addresses a false positive in the
use-after-move-checker.
Differential Revision: https://reviews.llvm.org/D60796
llvm-svn: 358944
Summary:
isClassMessage is an equivalent to isInstanceMessage for ObjCMessageExpr, but matches message expressions to classes.
isClassMethod and isInstanceMethod check whether a method declaration (or definition) is for a class method or instance method (respectively).
Contributed by @mywman!
Reviewers: benhamilton, klimek, mwyman
Reviewed By: benhamilton, mwyman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60920
llvm-svn: 358904
Summary:
* Removed a member that was only used during construction.
* Use range-based for iteration when accessing the result of the search.
* Require an `ObjCMethodDecl` reference upon construction of an
* Constify.
Reviewers: rjmccall
Reviewed By: rjmccall
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D60850
llvm-svn: 358898
CWG 1691 changed the definition of the namespaces associated with a class
type or enumeration type.
For a class type, the associated namespaces are the innermost enclosing
namespaces of the associated classes. For an enumeration type, the associated
namespace is the innermost enclosing namespace of its declaration.
This also fixes CWG 1690 and CWG 1692.
Differential Revision: https://reviews.llvm.org/D60573
Reviewed By: rjmccall, rsmith
llvm-svn: 358882
Clang emits a warning when using a pure specifier =0 in a function definition
at class scope (a MS-specific construct), when using -fms-extensions.
However, to detect this, it was using FD->isCanonicalDecl() on function
declaration, which was also detecting out-of-class definition of member
functions of class templates. Fix this by using !FD->isOutOfLine() instead.
Fixes PR21334.
Differential Revision: https://reviews.llvm.org/D29707
Reviewed By: riccibruno
Reviewers: rnk, riccibruno
Patch By: Rudy Pons
llvm-svn: 358849
Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.
Differential Revision: https://reviews.llvm.org/D58573
llvm-svn: 358797
Exposed by a related bug about visibility of default arguments of nested
templates - without the correct decl context, default template
parameters of variable templates nested in classes would have incorrect
visibility computed.
llvm-svn: 358796
The code is/was already correct for the case where a parameter is a
parameter of its enclosing lexical DeclContext (functions and classes).
But for other templates (alias and variable templates) they don't create
their own scope to be members of - in those cases, they parameter should
be considered visible if any definition of the lexical decl context is
visible.
[this should cleanup the failure on the libstdc++ modules buildbot]
[this doesn't actually fix the variable template case for a
secondary/compounding reason (its lexical decl context is incorrectly
considered to be the translation unit)]
Test covers all 4 kinds of templates with default args, including a
regression test for the still broken variable template case.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D60892
llvm-svn: 358795
Summary:
This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug
info in codeview. Currently only changes FastISel, so emitting labels still
needs to be implemented in SelectionDAG.
Reviewers: hans, rnk
Subscribers: aprantl, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60800
llvm-svn: 358783
Previously, if the MSVC installation isn't detected properly, clang
will later just fail to execute link.exe.
This improves using clang in msvc mode on linux, where one intentionally
might not want to point clang to the MSVC installation itself (which
isn't executable as such), but where a link.exe named wine wrapper is
available in the path next to a cl.exe named wine wrapper.
Differential Revision: https://reviews.llvm.org/D60094
llvm-svn: 358778
runtime.
target [teams distribute] simd costructs do not require full runtime for
the correct execution, we can run them without full runtime.
llvm-svn: 358766
Gold and ld on Linux already support saving stats, but the
infrastructure is missing on Darwin. Unfortunately it seems like the
configuration from lib/LTO/LTO.cpp is not used.
This patch adds a new LTOStatsFile option and adds plumbing in Clang to
use it on Darwin, similar to the way remarks are handled.
Currnetly the handling of LTO flags seems quite spread out, with a bunch
of duplication. But I am not sure if there is an easy way to improve
that?
Reviewers: anemet, tejohnson, thegameg, steven_wu
Reviewed By: steven_wu
Differential Revision: https://reviews.llvm.org/D60516
llvm-svn: 358753
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
Ideally, there is no reason behind not being able to depend on checkers that
come from a different plugin (or on builtin checkers) -- however, this is only
possible if all checkers are added to the registry before resolving checker
dependencies. Since I used a binary search in my addDependency method, this also
resulted in an assertion failure (due to CheckerRegistry::Checkers not being
sorted), since the function used by plugins to register their checkers
(clang_registerCheckers) calls addDependency.
This patch resolves this issue by only noting which dependencies have to
established when addDependency is called, and resolves them at a later stage
when no more checkers are added to the registry, by which point
CheckerRegistry::Checkers is already sorted.
Differential Revision: https://reviews.llvm.org/D59461
llvm-svn: 358750
Default RegionStore bindings represent values that can be obtained by loading
from anywhere within the region, not just the specific offset within the region
that they are said to be bound to. For example, default-binding a character \0
to an int (eg., via memset()) means that the whole int is 0, not just
that its lower byte is 0.
Even though memset and bzero were modeled this way, it didn't work correctly
when applied to simple variables. Eg., in
int x;
memset(x, 0, sizeof(x));
we did produce a default binding, but were unable to read it later, and 'x'
was perceived as an uninitialized variable even after memset.
At the same time, if we replace 'x' with a variable of a structure or array
type, accessing fields or elements of such variable was working correctly,
which was enough for most cases. So this was only a problem for variables of
simple integer/enumeration/floating-point/pointer types.
Fix loading default bindings from RegionStore for regions of simple variables.
Add a unit test to document the API contract as well.
Differential Revision: https://reviews.llvm.org/D60742
llvm-svn: 358722
Summary: The requires directive containing target related clauses must appear before any target region in the compilation unit.
Reviewers: ABataev, AlexEichenberger, caomhin
Reviewed By: ABataev
Subscribers: guansong, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60875
llvm-svn: 358709
On configurations with -Werror,-Wmissing-field-initializers, the commit does not compile. This commit fixes the offending line.
Original Differential Revision: https://reviews.llvm.org/D60408
llvm-svn: 358705
Summary: This revision allows users to specify independent changes to multiple (related) sections of the input. Previously, only a single section of input could be selected for replacement.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60408
llvm-svn: 358697
Summary:
It's never set to true. Its only effect would be to set stdout to binary mode.
Hopefully we have better ways of doing this by now :-)
Reviewers: hokein
Subscribers: jkorous, arphaman, kadircet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60871
llvm-svn: 358696
Summary:
This file defines the *Stencil* abstraction: a code-generating object, parameterized by named references to (bound) AST nodes. Given a match result, a stencil can be evaluated to a string of source code.
A stencil is similar in spirit to a format string: it is composed of a series of raw text strings, references to nodes (the parameters) and helper code-generation operations.
See thread on cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling" for background.
Reviewers: sbenza
Reviewed By: sbenza
Subscribers: ilya-biryukov, mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59371
llvm-svn: 358691
Summary:
Currently clang-format uses ContinuationIndent to indent the contents of a raw
string literal that is the last parameter of the function call. This is to
achieve formatting similar to trailing:
```
f(1, 2, R"pb(
x: y)pb");
```
However this had the unfortunate consequence of producing format like this:
```
fffffff(1, 2,
R"pb(
a: b
)pb");
```
This patch makes clang-format consider indenting a trailing raw string param
after a newline based off the start of the format delimiter, producing:
```
fffffff(1, 2,
R"pb(
a: b
)pb");
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60558
llvm-svn: 358689
There are barely any lines I haven't changed in these files, so I think I could
might as well leave it in an LLVM coding style conforming state. I also renamed
2 functions and moved addDependency out of line to ease on followup patches.
Differential Revision: https://reviews.llvm.org/D59457
llvm-svn: 358676
Sort the elements of Sema::OpenCLTypeExtMap and Sema::OpenCLDeclExtMap
by TypeIDs and DeclIDs to guarantee a stable serialization order.
Differential Revision: https://reviews.llvm.org/D60835
Reviewed By: Anastasia
Reviewers: Anastasia, lebedev.ri
llvm-svn: 358674
If accessing the MSVC installation root directly on a case sensitive
filesystem, these details matter.
Differential Revision: https://reviews.llvm.org/D60627
llvm-svn: 358662
global module fragment.
We know that the declaration in question should have been introduced by
a '#include', so try to figure out which one and suggest it. Don't
suggest importing the global module fragment itself!
llvm-svn: 358631
retaining block and all of the enclosing blocks are non-escaping.
If the block implicitly retaining self doesn't escape, there is no risk
of creating retain cycles, so clang shouldn't diagnose it and force
users to add self-> to silence the diagnostic.
Also, fix a bug where clang was failing to diagnose an implicitly
retained self inside a c++ lambda nested inside a block.
rdar://problem/25059955
Differential Revision: https://reviews.llvm.org/D60736
llvm-svn: 358624
For the following code snippet:
void builtin_function_call_crash_fixes(char *c) {
__builtin_strncpy(c, "", 6);
__builtin_memset(c, '\0', (0));
__builtin_memcpy(c, c, 0);
}
security.insecureAPI.DeprecatedOrUnsafeBufferHandling caused a regression, as it
didn't recognize functions starting with __builtin_. Fixed exactly that.
I wanted to modify an existing test file, but the two I found didn't seem like
perfect candidates. While I was there, I prettified their RUN: lines.
Differential Revision: https://reviews.llvm.org/D59812
llvm-svn: 358609
All target-parallel-based constructs can be run in SPMD mode from now
on. Even if num_threads clauses or if clauses are used, such constructs
can be executed in SPMD mode.
llvm-svn: 358595
Summary:
Motivation/Context: in the code review system integrating with clang-tidy,
clang-tidy doesn't provide a human-readable description of the fix. Usually
developers have to preview a code diff (before vs after apply the fix) to
understand what the fix does before applying a fix.
This patch proposes that each clang-tidy check provides a short and
actional fix description that can be shown in the UI, so that users can know
what the fix does without previewing diff.
This patch extends clang-tidy framework to support fix descriptions (will add implementations for
existing checks in the future). Fix descriptions and fixes are emitted via diagnostic::Note (rather than
attaching the main warning diagnostic).
Before this patch:
```
void MyCheck::check(...) {
...
diag(loc, "my check warning") << FixtItHint::CreateReplacement(...);
}
```
After:
```
void MyCheck::check(...) {
...
diag(loc, "my check warning"); // Emit a check warning
diag(loc, "fix description", DiagnosticIDs::Note) << FixtItHint::CreateReplacement(...); // Emit a diagnostic note and a fix
}
```
Reviewers: sammccall, alexfh
Reviewed By: alexfh
Subscribers: MyDeveloperDay, Eugene.Zelenko, aaron.ballman, JonasToth, xazax.hun, jdoerfert, cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D59932
llvm-svn: 358576
Summary:
When -gsplit-dwarf is used together with other -g options, in most cases
the computed debug info level is decided by the last -g option, with one
special case (see below). This patch drops that special case and thus
makes it easy to reason about:
// If a lower debug level -g comes after -gsplit-dwarf, in some cases
// -gsplit-dwarf is cancelled.
-gsplit-dwarf -g0 => 0
-gsplit-dwarf -gline-directives-only => DebugDirectivesOnly
-gsplit-dwarf -gmlt -fsplit-dwarf-inlining => 1
-gsplit-dwarf -gmlt -fno-split-dwarf-inlining => 1 + split
// If -gsplit-dwarf comes after -g options, with this patch, the net
// effect is 2 + split for all combinations
-g0 -gsplit-dwarf => 2 + split
-gline-directives-only -gsplit-dwarf => 2 + split
-gmlt -gsplit-dwarf -fsplit-dwarf-inlining => 2 + split
-gmlt -gsplit-dwarf -fno-split-dwarf-inlining => 1 + split (before) 2 + split (after)
The last case has been changed. In general, if the user intends to lower
debug info level, place that -g option after -gsplit-dwarf.
Some context:
In gcc, the last of -gsplit-dwarf -g0 -g1 -g2 -g3 -ggdb[0-3] -gdwarf-*
... decides the debug info level (-gsplit-dwarf -gdwarf-* have level 2).
It is a bit unfortunate that -gsplit-dwarf -gdwarf-* ... participate in
the level computation but that is the status quo.
Reviewers: dblaikie, echristo, probinson
Reviewed By: dblaikie, probinson
Subscribers: probinson, aprantl, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59923
llvm-svn: 358544
Summary:
Previously, we would return true/false signifying if the cache/lookup
succeeded or failed. Instead, provide clients with the underlying error
that was thrown while attempting to look up in the cache.
Since clang::FileManager doesn't make use of this information, it discards the
error that's received and casts away to bool.
This change is NFC.
Reviewers: benlangmuir, arphaman
Subscribers: dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60735
llvm-svn: 358509
Combined constructs with parallel and if clauses without modifiers may
be executed in SPMD mode since if the condition is true for the target
region, it is also true for parallel region and the threads must be run
in parallel.
llvm-svn: 358503
LLDB can't currently handle Clang's default (limit/no-standalone) DWARF,
so platforms that default to LLDB (Darwin) or anyone else manually
requesting LLDB tuning, should also get standalone DWARF.
That doesn't mean a user can't explicitly enable (because they have
other reasons to prefer standalone DWARF (such as that they're only
building half their application with debug info enabled, and half
without - or because they're tuning for GDB, but want to be able to use
it under LLDB too (this is the default on FreeBSD))) or disable (testing
LLDB fixes/improvements that handle no-standalone mode, building C code,
perhaps, which wouldn't have the LLDB<>no-standalone conflict, etc) the
feature regardless of the tuning.
llvm-svn: 358464
mode.
After the previous patch with the more correct handling of the number of
threads in parallel regions, the parallel regions with num_threads
clauses can be executed in SPMD mode.
llvm-svn: 358445
Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.
Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.
(relanding after revert, r358414)
Added DefaultOptions.clear() to reset().
Reviewers: alexfh, klimek
Reviewed By: klimek
Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59746
llvm-svn: 358428
The pattern we replaced these with may be too hard to match as demonstrated by
PR41496 and PR41316.
This patch restores the intrinsics and then we can start focusing
on the optimizing the intrinsics.
I've mostly reverted the original patch that removed them. Though I modified
the avx512 intrinsics to not have masking built in.
Differential Revision: https://reviews.llvm.org/D60674
llvm-svn: 358427
Summary:
For example, a renamed type in a header file can conflict with declaration in
a random file that includes the header, but we should not consider the decl ambiguous if
it's not visible at the rename location. This improves consistency of generated replacements
when header file is included in different TUs.
Reviewers: hokein
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60257
llvm-svn: 358378
Summary:
Addresses https://bugs.llvm.org/show_bug.cgi?id=41170
The AlwaysBreakAfterReturn type setting can go wrong if the line ends with a comment
```
void foo() /* comment */
```
or
```
void foo() // comment
```
It will incorrectly see such functions as Declarations and not Definitions
The following code addresses this by looking for function which end with `; <comment>` rather than just `;` or `<comment>`
Reviewers: klimek, djasper, reuk, russellmcc, owenpan, sammccall
Reviewed By: owenpan
Subscribers: lebedev.ri, cfe-commits, sammccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60363
llvm-svn: 358375
and the global and private module fragment.
For now, the private module fragment introducer is ignored, but use of
the global module fragment introducer should be properly enforced.
llvm-svn: 358353
Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.
Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.
Reviewers: alexfh, klimek
Reviewed By: klimek
Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59746
llvm-svn: 358337
A marker (matching /#[A-Za-z0-9_-]/) is specified by attaching a comment
containing the marker to the line at which the diagnostic is expected,
and then can be referenced from an expected-* directive after an @:
foo // #1
// expected-error@#1 {{undeclared identifier 'foo'}}
The intent is for markers to be used in situations where relative line
numbers are currently used, to avoid the need to renumber when the test
case is rearranged.
llvm-svn: 358326
Writing stuff into an argument variable is usually equivalent to writing stuff
to a local variable: it will have no effect outside of the function.
There's an important exception from this rule: if the argument variable has
a non-trivial destructor, the destructor would be invoked on
the parent stack frame, exposing contents of the otherwise dead
argument variable to the caller.
If such argument is the last place where a pointer is stored before the function
exits and the function is the one we've started our analysis from (i.e., we have
no caller context for it), we currently diagnose a leak. This is incorrect
because the destructor of the argument still has access to the pointer.
The destructor may deallocate the pointer or even pass it further.
Treat writes into such argument regions as "escapes" instead, suppressing
spurious memory leak reports but not messing with dead symbol removal.
Differential Revision: https://reviews.llvm.org/D60112
llvm-svn: 358321
[MS] Add metadata for __declspec(allocator)
Original summary:
Emit !heapallocsite in the metadata for calls to functions marked with
__declspec(allocator). Eventually this will be emitted as S_HEAPALLOCSITE debug
info in codeview.
Differential Revision: https://reviews.llvm.org/D60237
llvm-svn: 358307
Use -mlink-builtin-bitcode instead of llvm-link to link
device library so that device library bitcode and user
device code can be compiled in a consistent way.
This is the same approach used by CUDA and OpenMP.
Differential Revision: https://reviews.llvm.org/D60513
llvm-svn: 358290
Systematically add the const-qualified version of children()
to all statement/expression nodes. Previously the const-qualified
variant was only defined for some nodes. NFC.
Patch by: Nicolas Manichon
Differential Revision: https://reviews.llvm.org/D60029
Reviewed By: riccibruno
llvm-svn: 358288
Disabled by default as this is still an experimental feature.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D59221
llvm-svn: 358285
Summary:
AnnotatingParser::next() is needed to implicitly set TT_BlockComment
versus TT_LineComment. On most other paths through
AnnotatingParser::parseLine(), all tokens are consumed to achieve that.
This change updates one place where this wasn't done.
Contributed by @dchai!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60541
llvm-svn: 358275
Summary:
Prepares ground for printing template arguments as written in the
source code, part of re-landing rC356541 with D59599 applied.
Reviewers: ioeric, ilya-biryukov
Subscribers: mgorny, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59639
llvm-svn: 358272
Summary:
alloca isn’t auto-init’d right now because it’s a different path in clang that
all the other stuff we support (it’s a builtin, not an expression).
Interestingly, alloca doesn’t have a type (as opposed to even VLA) so we can
really only initialize it with memset.
<rdar://problem/49794007>
Subscribers: jkorous, dexonsmith, cfe-commits, rjmccall, glider, kees, kcc, pcc
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60548
llvm-svn: 358243
internal lexing steps in the preprocessor.
It is not safe to use the preprocessor's token lookahead except when
operating on the final sequence of tokens that would be produced by
phase 4 of translation. Doing so corrupts the token lookahead cache used
by the parser. (See added testcase for an example.) Lookahead should
instead be viewed as a layer on top of the normal lexer.
Added assertions to catch any further incorrect uses of lookahead within
lexing actions.
llvm-svn: 358230
Summary:
These flags are used when emitting debug info and needed to initialize subprogram and member function attributes (function options) for Codeview. These function options are used to create an accurate compiler type for UDT symbols (class/struct/union) from PDBs.
The Trivial flag was introduced in https://reviews.llvm.org/D45122
It's been pointed out that Trivial and NonTrivial may imply each other and that seems to be the case in the current tests. This change combines them into a single flag -- NonTrivial -- and updates the corresponding unit tests. There is an additional change to llvm to update the flags.
Reviewers: rnk, zturner, dblaikie, probinson, Hui
Reviewed By: dblaikie
Subscribers: aprantl, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59347
llvm-svn: 358219
We want to make objc_nonlazy_class apply to implementations, but ran into this.
There doesn't seem to be any reason that this isn't supported.
Differential revision: https://reviews.llvm.org/D60542
llvm-svn: 358200
At least clang 3.6 warns on the original code:
../tools/clang/lib/CodeGen/CGNonTrivialStruct.cpp:829:34: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
return std::array<Address, 1>({Address(nullptr, CharUnits::Zero())});
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{ }
../tools/clang/lib/CodeGen/CGNonTrivialStruct.cpp:833:34: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
return std::array<Address, 2>({Address(nullptr, CharUnits::Zero()),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
llvm-svn: 358152
Summary:
https://reviews.llvm.org/D53809 fixed wrong address space(assert in debug build)
generated for event_ret argument. But exactly the same problem exists for
event_wait_list argument. This patch should fix both.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia
Subscribers: kristina, ebevhan, cfe-commits
Differential Revision: https://reviews.llvm.org/D59985
llvm-svn: 358151
Summary:
As was already stated in a previous comment, the parameter isn't
necessarily referring to one of the DeclContext's parameter. We
should check the index is within the range to avoid out-of-boundary
access.
Reviewers: gribozavr, rsmith, lebedev.ri
Reviewed By: gribozavr, rsmith
Subscribers: lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60055
Patch by Violet.
llvm-svn: 358134
Loading external comments is expensive. This change probably doesn't apply to common cases but is almost for free and would save some work in case none of the declaration needs external comments to be loaded.
Differential Revision: https://reviews.llvm.org/D60493
llvm-svn: 358133
regions.
Added more complex analysis for number of teams and number of threads in
the target regions, also merged related common code between CGOpenMPRuntime
and CGOpenMPRuntimeNVPTX classes.
llvm-svn: 358126
named metadata.
This fixes a bug where ARC contract wasn't inserting the retainRV
marker when LTO was enabled, which caused objects returned from a
function to be auto-released.
rdar://problem/49464214
Differential Revision: https://reviews.llvm.org/D60302
llvm-svn: 358048
Summary:
The current llvm/clang et al. project can be built with the latest developer toolset (devtoolset-8) on RHEL, which provides GCC 8.2.1.
However, the result compiler will not identify this toolset itself when compiling programs, which is of course not desirable.
After the patch - which simply adds the name of the developer toolset to the existing list - it gets identified and selected, as shown below:
[bamboo@bamboo llvm-project]$ clang -v
clang version 9.0.0 (https://github.com/llvm/llvm-project.gite5ac385fb1)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/bamboo/llvm/bin
Found candidate GCC installation: /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1
Found candidate GCC installation: /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Patch By: Radu-Adrian Popescu
Reviewers: tstellar, fedor.sergeev
Reviewed By: tstellar
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59987
llvm-svn: 358002
Summary:
These all had somewhat custom file headers with different text from the
ones I searched for previously, and so I missed them. Thanks to Hal and
Kristina and others who prompted me to fix this, and sorry it took so
long.
Reviewers: hfinkel
Subscribers: mcrosier, javed.absar, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60406
llvm-svn: 357941
Summary:
https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitEnumDecl(...) for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via getTypedefNameForAnonDecl(...).
Differential Revision: https://reviews.llvm.org/D59665
llvm-svn: 357940
Summary:
Emit !heapallocsite in the metadata for calls to functions marked with
__declspec(allocator). Eventually this will be emitted as S_HEAPALLOCSITE debug
info in codeview.
Reviewers: rnk
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60237
llvm-svn: 357928
Added special processing of the memory management directives/clauses for
NVPTX target. For private locals, omp_default_mem_alloc and
omp_thread_mem_alloc result in allocation in local memory.
omp_const_mem_alloc allocates const memory, omp_teams_mem_alloc
allocates shared memory, and omp_cgroup_mem_alloc and
omp_large_cap_mem_alloc allocate global memory.
llvm-svn: 357923
Summary:
Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696
The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter
```
int foo(A<8> a) { return a; }
```
When run with the Mozilla style. would not break after the `int`
```
int TestFn(A<8> a)
{
return a;
}
```
This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>`
Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh
Reviewed By: klimek
Subscribers: cfe-commits, llvm-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59309
llvm-svn: 357837
The idea behind this heuristic is that normally the visitor is there to
inform the user that a certain function may fail to initialize a certain
out-parameter. For system header functions this is usually dictated by the
contract, and it's unlikely that the header function has accidentally
forgot to put the value into the out-parameter; it's more likely
that the user has intentionally skipped the error check.
Warnings on skipped error checks are more like security warnings;
they aren't necessarily useful for all users, and they should instead
be introduced on a per-API basis.
Differential Revision: https://reviews.llvm.org/D60107
llvm-svn: 357810
[IMPORTANT]
With that last fix, CUDA has just started being compiling by clang on Windows after nearly a year and two clang’s major releases (7 and 8).
As long as the last LLVM release, in which clang was compiling CUDA on Windows successfully, was 6.0.1, this fix and two previous have to be included into upcoming 7.1.0 and 8.0.1 releases.
[How to repro]
clang++.exe -x cuda "c:\ProgramData\NVIDIA Corporation\CUDA Samples\v9.0\0_Simple\simplePrintf\simplePrintf.cu" -I"c:\ProgramData\NVIDIA Corporation\CUDA Samples\v9.0\common\inc" --cuda-gpu-arch=sm_50 --cuda-path="C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0" -L"c:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64" -lcudart.lib -v
[Output]
In file included from C:\GIT\LLVM\trunk-for-submits\llvm-64-release-vs2017-15.9.9\dist\lib\clang\9.0.0\include\__clang_cuda_runtime_wrapper.h:327:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:390:11: error: no matching function for call to '__isinfl'
return (__isinfl(a) != 0);
^~~~~~~~
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:2662:14: note: candidate function not viable: call to __host__ function from __device__ function
__func__(int __isinfl(long double a))
^
In file included from <built-in>:1:
In file included from C:\GIT\LLVM\trunk-for-submits\llvm-64-release-vs2017-15.9.9\dist\lib\clang\9.0.0\include\__clang_cuda_runtime_wrapper.h:327:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:438:11: error: no matching function for call to '__isnanl'
return (__isnanl(a) != 0);
^~~~~~~~
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:2672:14: note: candidate function not viable: call to __host__ function from __device__ function
__func__(int __isnanl(long double a))
^
In file included from <built-in>:1:
In file included from C:\GIT\LLVM\trunk-for-submits\llvm-64-release-vs2017-15.9.9\dist\lib\clang\9.0.0\include\__clang_cuda_runtime_wrapper.h:327:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:486:11: error: no matching function for call to '__finitel'
return (__finitel(a) != 0);
^~~~~~~~~
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0/include\crt/math_functions.hpp:2652:14: note: candidate function not viable: call to __host__ function from __device__ function
__func__(int __finitel(long double a))
^
3 errors generated when compiling for sm_50.
[Solution]
Add missing long double device functions' declarations. Provide only declarations to prevent any use of long double on the device side, because CUDA does not support long double on the device side.
[Testing]
{Windows 10, Ubuntu 16.04.5}/{Visual C++ 2017 15.9.9, gcc+ 5.4.0}/CUDA {8.0, 9.0, 9.1, 9.2, 10.0, 10.1}
Reviewed by: Artem Belevich
Differential Revision: http://reviews.llvm.org/D60220
llvm-svn: 357779
Summary:
Use cases:
- a tool that dumps the heuristic used for each header in a project can
be used to evaluate changes to the heuristic
- we want to expose this information to users in clangd as it affects
accuracy/reliability of editor features
- express interpolation tests more directly
Reviewers: ilya-biryukov, klimek
Subscribers: ioeric, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60194
llvm-svn: 357770
Summary: Adds a basic version of Transformer, a library supporting the concise specification of clang-based source-to-source transformations. A full discussion of the end goal can be found on the cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling".
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ioeric, ABataev, mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59376
llvm-svn: 357768
Summary:
Introduces a utility library in Refactoring/ to collect routines related to
source-code manipulation. In this change, we move "extended-range" functions
from the FixIt library (in clangTooling) to this new library.
We need to use this functionality in Refactoring/ and cannot access it if it
resides in Tooling/, because that would cause clangToolingRefactor to depend on
clangTooling, which would be a circular dependency.
Reviewers: ilya-biryukov, ioeric
Reviewed By: ilya-biryukov
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60269
llvm-svn: 357764
Requires making the llvm::MemoryBuffer* stored by SourceManager const,
which in turn requires making the accessors for that return const
llvm::MemoryBuffer*s and updating all call sites.
The original motivation for this was to use it and fix the TODO in
CodeGenAction.cpp's ConvertBackendLocation() by using the UnownedTag
version of createFileID, and since llvm::SourceMgr* hands out a const
llvm::MemoryBuffer* this is required. I'm not sure if fixing the TODO
this way actually works, but this seems like a good change on its own
anyways.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D60247
llvm-svn: 357724
ObjCPropertyDecl should use the category interface as a context similar to what is done for methods.
Previously category methods would be printed as `::property`; now they are printed as `Class::property`.
llvm-svn: 357720
Adding in androidx as another import group.
Differential Revision: https://reviews.llvm.org/D60203
Patch from Sam Maier <smaier@chromium.org>!
llvm-svn: 357700
When setting up library and tools paths when detecting an accompanying GCC
installation only riscv32 was handled. As a consequence when targetting
riscv64 neither the linker nor libraries would be found. This adds handling
and tests for riscv64.
Differential Revision: https://reviews.llvm.org/D53392
Patch by Edward Jones.
llvm-svn: 357699
Summary:
r357567 started to regroup include block for Google style; it was meant to apply
only for C++. This patch reverts this for ObjC.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: thakis, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60263
llvm-svn: 357695
Summary:
The fix isn't great, but it's hard to fix properly because the completion
code sensibly uses ParmVarDecl to represent parameters, but the AST-building
code sensibly doesn't synthesize them if the type is broken.
Also this case is apparently really rare, so it's probably not worth bending
over backwards for.
Reviewers: ilya-biryukov
Subscribers: javed.absar, kristof.beyls, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60258
llvm-svn: 357686
Prevent adding initializers implicitly to variables declared in
local address space. This happens when they get converted into
global variables and therefore theoretically have to be default
initialized in C++.
Differential Revision: https://reviews.llvm.org/D59646
llvm-svn: 357684
Improved classification of address space cast when qualification
conversion is performed - prevent adding addr space cast for
non-pointer and non-reference types. Take address space correctly
from the pointee.
Also pass correct address space from 'this' object using
AggValueSlot when generating addrspacecast in the constructor
call.
Differential Revision: https://reviews.llvm.org/D59988
llvm-svn: 357682
Create method `optForNone()` testing for the function level equivalent of
`-O0` and refactor appropriately.
Differential revision: https://reviews.llvm.org/D59852
llvm-svn: 357638
Summary:
Currently clang-format would always emit a replacement for multi-block #include
sections if `IBS_Regroup`, even if the sections are correct:
```
% cat ~/test.h
#include <a.h>
#include "b.h"
% bin/clang-format --output-replacements-xml -style=google ~/test.h
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='30'>#include <a.h> #include "b.h"</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case.
The logic is similar to the one implemented for Java in r354452.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60199
llvm-svn: 357599
Summary: Adds a basic version of Transformer, a library supporting the concise specification of clang-based source-to-source transformations. A full discussion of the end goal can be found on the cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling".
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59376
llvm-svn: 357576
__builtin_constant_p(x) is a compiler builtin that evaluates to 1 when
its argument x is a compile-time constant and to 0 otherwise. In CodeGen
it is simply lowered to the respective LLVM intrinsic. In the Analyzer
we've been trying to delegate modeling to Expr::EvaluateAsInt, which is
allowed to sometimes fail for no apparent reason.
When it fails, let's conservatively return false. Modeling it as false
is pretty much never wrong, and it is only required to return true
on a best-effort basis, which every user should expect.
Fixes VLAChecker false positives on code that tries to emulate
static asserts in C by constructing a VLA of dynamic size -1 under the
assumption that this dynamic size is actually a constant
in the sense of __builtin_constant_p.
Differential Revision: https://reviews.llvm.org/D60110
llvm-svn: 357557
The Emscripten OS provides a definition of __EMSCRIPTEN__, and also that it
supports iprintf optimizations.
Also define small_printf optimizations, which is a printf with float support
but not long double (which in wasm can be useful since long doubles are 128
bit and force linking of float128 emulation code). This part is based on
sunfish's https://reviews.llvm.org/D57620 (which can't land yet since
the WASI integration isn't ready yet).
Differential Revision: https://reviews.llvm.org/D60167
llvm-svn: 357552
Also for CUDA, we need to disable producing these fat binary functions when there is no GPU code.
Reviewers: yaxunl, tra
Differential Revision: https://reviews.llvm.org/D60141
llvm-svn: 357526
Skip producing the fat binary functions for HIP when no device code is present.
Reviewers: yaxunl
Differential Review: https://reviews.llvm.org/D60141
llvm-svn: 357520
moveAttrFromListToList only makes sense when moving an attribute to a list with
a pool that's either equivalent, or has a shorter lifetime. Therefore, using it
to move a ParsedAttr from a declarator to a declaration specifier doesn't make
sense, since the declaration specifier's pool outlives the declarator's. The
patch adds a new function, ParsedAttributes::takeOneFrom, which transfers the
attribute from one pool to another, fixing the use-after-deallocate.
rdar://49175426
Differential revision: https://reviews.llvm.org/D60101
llvm-svn: 357516
This ability was removed in r351487, but it's needed when a lambda appears as an
OpaqueValueExpr subexpression of a PseudoObjectExpr.
rdar://49030379
Differential revision: https://reviews.llvm.org/D60099
llvm-svn: 357515
In case of N64 ABI toolchain paths migth have `mips-linux-gnuabi64`
or `mips-linux-gnu` directory regardless of selected environment.
Check both variants while detecting a multiarch triple.
Fix for the bug https://bugs.llvm.org/show_bug.cgi?id=41204
llvm-svn: 357506
Allow the optimizer to remove unnecessary EH cleanups surrounding calls
to os_log_helper, to save some code size.
As a follow-up, it might be worthwhile to add a BasicNoexcept exception
spec to os_log_helper, and to then teach CGCall to emit direct calls for
callees which can't throw. This could save some compile-time.
Differential Revision: https://reviews.llvm.org/D60108
llvm-svn: 357501
If the pointer is captured by reference, it must be mapped as
_PTR_AND_OBJ kind of mapping to correctly translate the pointer address
on the device.
llvm-svn: 357488
At least gcc 7.4 complained with
../tools/clang/lib/StaticAnalyzer/Checkers/Taint.cpp:26:53: warning: extra ';' [-Wpedantic]
TaintTagType);
^
llvm-svn: 357461
Before this patch, CGLoop would dump all transformations for a loop into
a single LoopID without encoding any order in which to apply them.
rL348944 added the possibility to encode a transformation order using
followup-attributes.
When a loop has more than one transformation, use the follow-up
attribute define the order in which they are applied. The emitted order
is the defacto order as defined by the current LLVM pass pipeline,
which is:
LoopFullUnrollPass
LoopDistributePass
LoopVectorizePass
LoopUnrollAndJamPass
LoopUnrollPass
MachinePipeliner
This patch should therefore not change the assembly output, assuming
that all explicit transformations can be applied, and no implicit
transformations in-between. In the former case,
WarnMissedTransformationsPass should emit a warning (except for
MachinePipeliner which is not implemented yet). The latter could be
avoided by adding 'llvm.loop.disable_nonforced' attributes.
Because LoopUnrollAndJamPass processes a loop nest, generation of the
MDNode is delayed to after the inner loop metadata have been processed.
A temporary LoopID is therefore used to annotate instructions and
RAUW'ed by the actual LoopID later.
Differential Revision: https://reviews.llvm.org/D57978
llvm-svn: 357415
According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, allocate
clauses that appear on a target construct or on constructs in a target
region must specify an allocator expression unless a requires directive
with the dynamic_allocators clause is present in the same compilation
unit. Patch adds a check for this restriction.
llvm-svn: 357412
Summary:
ASTStructuralEquivalence uses a flag to indicate whether ODR diagnostics
should be considered errors or warnings as module Sema is more strict than
ASTMerge. The implementation of ASTImporter should allso follow
along the same lines.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: shafik, a_sidorin
Subscribers: rnkovacs, martong, dkrupp, Szelethus, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59761
Patch by Endre Fulop!
llvm-svn: 357402
Summary:
ODR errors are not necessarily true errors during the import of ASTs.
ASTMerge and CrossTU should use the warning equivalent of every CTU error,
while Sema should emit errors as before.
Reviewers: martong, a_sidorin, shafik, a.sidorin
Reviewed By: a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58897
Patch by Endre Fulop!
llvm-svn: 357394
According to OpenMP 5.0 standard, 2.11.4 allocate Clause, Restrictions,
For any list item that is specified in the allocate clause on a
directive, a data-sharing attribute clause that may create a private
copy of that list item must be specified on the same directive. Patch
adds the checks for this restriction.
llvm-svn: 357390
Summary:
Based on a patch by Dustin Howett, modified to not change the ABI for
ELF platforms.
Use more Windows-like section names.
This also makes things more readable by PE/COFF debug tools that assume
sections fit in the first header.
With these changes in, it is now possible to build a working WinObjC
with clang and the WinObjC version of GNUstep libobjc (upstream GNUstep
libobjc + a work around for incremental linking, which can be removed
once LINK.EXE gains a feature to opt sections out of receiving extra
padding during an incremental link).
Patch by Dustin Howett!
Reviewers: DHowett-MSFT
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58724
llvm-svn: 357364
Without this change, linking multiple objects containing block
descriptors together on Windows will generate duplicate symbol errors.
Patch by Dustin Howett!
Differential Revision: https://reviews.llvm.org/D58807
llvm-svn: 357363
Summary:
Import sorting of java file, incorrectly move import statement to after a function beginning with the word import.
Make 1 character change to regular expression to ensure there is always at least one space/tab after the word import
Previously clang-format --style="LLVM" would format
```
import X;
class C {
void m() {
importFile();
}
}
```
as
```
class C {
void m() {
importFile();
import X;
}
}
```
Reviewers: djasper, klimek, reuk, JonasToth
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59684
llvm-svn: 357345
This patch aims to add support for the following rules from the JUCE coding standards:
- Always put a space before an open parenthesis that contains text - e.g. foo (123);
- Never put a space before an empty pair of open/close parenthesis - e.g. foo();
Patch by Reuben Thomas
Differential Revision: https://reviews.llvm.org/D55170
llvm-svn: 357344
This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc.
This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2
Patch by Aras Pranckevičius.
Differential Revision: https://reviews.llvm.org/D58675
llvm-svn: 357340
It turns out that SourceManager::isInSystemHeader() crashes when an invalid
source location is passed into it. Invalid source locations are relatively
common: not only they come from body farms, but also, say, any function in C
that didn't come with a forward declaration would have an implicit
forward declaration with invalid source locations.
There's a more comfy API for us to use in the Static Analyzer:
CallEvent::isInSystemHeader(), so just use that.
Differential Revision: https://reviews.llvm.org/D59901
llvm-svn: 357329
It is now an inter-checker communication API, similar to the one that
connects MallocChecker/CStringChecker/InnerPointerChecker: simply a set of
setters and getters for a state trait.
Differential Revision: https://reviews.llvm.org/D59861
llvm-svn: 357326
The transfer function for the CFG element that represents a logical operation
computes the value of the operation and does nothing else. The element
appears after all the short circuit decisions were made, so they don't need
to be made again at this point.
Because our expression evaluation is imprecise, it is often hard to
discriminate between:
(1) we don't know the value of the RHS because we failed to evaluate it
and
(2) we don't know the value of the RHS because it didn't need to be evaluated.
This is hard because it depends on our knowledge about the value of the LHS
(eg., if LHS is true, then RHS in (LHS || RHS) doesn't need to be computed)
but LHS itself may have been evaluated imprecisely and we don't know whether
it is true or not. Additionally, the Analyzer wouldn't necessarily even remember
what the value of the LHS was because theoretically it's not really necessary
to know it for any future evaluations.
In order to work around these issues, the transfer function for logical
operations consists in looking at the ExplodedGraph we've constructed so far
in order to figure out from which CFG direction did we arrive here.
Such post-factum backtracking that doesn't involve looking up LHS and RHS values
is usually possible. However sometimes it fails because when we deduplicate
exploded nodes with the same program point and the same program state we may end
up in a situation when we reached the same program point from two or more
different directions.
By removing the assertion, we admit that the procedure indeed sometimes fails to
work. When it fails, we also admit that we don't know the value of the logical
operator.
Differential Revision: https://reviews.llvm.org/D59857
llvm-svn: 357325
Almost all path-sensitive checkers need to tell the user when something specific
to that checker happens along the execution path but does not constitute a bug
on its own. For instance, a call to operator delete in C++ has consequences
that are specific to a use-after-free bug. Deleting an object is not a bug
on its own, but when the Analyzer finds an execution path on which a deleted
object is used, it'll have to explain to the user when exactly during that path
did the deallocation take place.
Historically such custom notes were added by implementing "bug report visitors".
These visitors were post-processing bug reports by visiting every ExplodedNode
along the path and emitting path notes whenever they noticed that a change that
is relevant to a bug report occurs within the program state. For example,
it emits a "memory is deallocated" note when it notices that a pointer changes
its state from "allocated" to "deleted".
The "visitor" approach is powerful and efficient but hard to use because
such preprocessing implies that the developer first models the effects
of the event (say, changes the pointer's state from "allocated" to "deleted"
as part of operator delete()'s transfer function) and then forgets what happened
and later tries to reverse-engineer itself and figure out what did it do
by looking at the report.
The proposed approach tries to avoid discarding the information that was
available when the transfer function was evaluated. Instead, it allows the
developer to capture all the necessary information into a closure that
will be automatically invoked later in order to produce the actual note.
This should reduce boilerplate and avoid very painful logic duplication.
On the technical side, the closure is a lambda that's put into a special kind of
a program point tag, and a special bug report visitor visits all nodes in the
report and invokes all note-producing closures it finds along the path.
For now it is up to the lambda to make sure that the note is actually relevant
to the report. For instance, a memory deallocation note would be irrelevant when
we're reporting a division by zero bug or if we're reporting a use-after-free
of a different, unrelated chunk of memory. The lambda can figure these thing out
by looking at the bug report object that's passed into it.
A single checker is refactored to make use of the new functionality: MIGChecker.
Its program state is trivial, making it an easy testing ground for the first
version of the API.
Differential Revision: https://reviews.llvm.org/D58367
llvm-svn: 357323
Summary:
This feature is not actually used for anything in the WebAssembly
backend, but adding it allows users to get it into the target features
sections of their objects, which makes these objects
future-compatible.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jdoerfert, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60013
llvm-svn: 357321
Fixes the assertion
> no Attr* for AttributedType*
> UNREACHABLE executed at llvm-project/clang/lib/Sema/SemaType.cpp:298!
In `TypeProcessingState::getAttributedType` we put into `AttrsForTypes`
types with `auto` but later in
`TypeProcessingState::takeAttrForAttributedType` we use transformed
types and that's why cannot find `Attr` corresponding to
`AttributedType`.
Fix by keeping `AttrsForTypes` up to date after replacing `AutoType`.
rdar://problem/47689465
Reviewers: rsmith, arphaman, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: jkorous, dexonsmith, jdoerfert, cfe-commits
Differential Revision: https://reviews.llvm.org/D58659
llvm-svn: 357298
Android does not allow shared text relocations. Enable the linker
warning to detect them by default.
Reviewers: srhines, pirama
Reviewed By: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53344
llvm-svn: 357296
Effectively reverts r337612. The issues that cropped up with the last
attempt appear to have gone away.
Differential Revision: https://reviews.llvm.org/D59008
llvm-svn: 357285
Add an -mtp=el[0-3] option to select which of the AArch64 thread ID registers
will be used for the TLS base pointer.
This is a followup to rL356657 which added subtarget features to enable
accesses to the privileged thread ID registers.
Patch by Philip Derrin!
Differential revision: https://reviews.llvm.org/D59631
llvm-svn: 357250
Summary:
- If a parameter is used, nonnull checking needs function prototype to
retrieve the corresponding parameter's attributes. However, at the
prototype substitution phase when a template is being instantiated,
expression may be created and checked without a fully specialized
prototype. Under such a scenario, skip nonnull checking on that
argument.
Reviewers: rjmccall, tra, yaxunl
Subscribers: javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59900
llvm-svn: 357236
copy/move constructor/assignment operator functions for non-trivial C
structs.
This commit fixes a bug where the offset of struct fields weren't being
taken into account when computing the addresses passed to calls to the
special functions.
For example, the copy constructor for S1 (__copy_constructor_8_8_s0_s8)
would pass the start addresses of the destination and source structs to
the call to S0's copy constructor (_copy_constructor_8_8_s0) without
adding the offset of field f1 to the addresses.
typedef struct {
id f0;
S0 f1;
} S1;
void test(S1 s1) {
S1 t = s1;
}
rdar://problem/49400610
llvm-svn: 357229
Future versions of MSVC make these intrinsics available on x86 & x64,
according to:
http://lists.llvm.org/pipermail/cfe-dev/2019-March/061711.html
The purpose of these builtins is to emit plain, non-atomic, volatile
stores when /volatile:ms (-cc1 -fms-volatile) is enabled.
llvm-svn: 357220
target and task-based directives.
According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, For task,
taskloop or target directives, allocation requests to memory allocators
with the trait access set to thread result in unspecified behavior.
Patch introduces a check for omp_thread_mem_alloc predefined allocator
on target- and trask-based directives.
llvm-svn: 357205
In https://bugs.llvm.org/show_bug.cgi?id=41206 we observe bad codegen
when embedding a non-trivial C struct within a C struct. This is due to
the fact that name mangling for non-trivial structs marks the two
structs as identical. This diff contains a fix for this issue.
Patch by Dan Zimmerman <daniel.zimmerman@me.com>.
Differential Revision: https://reviews.llvm.org/D59873
llvm-svn: 357184
Since rL335814, if the constraint manager cannot find a range set for `A - B`
(where `A` and `B` are symbols) it looks for a range for `B - A` and returns
it negated if it exists. However, if a range set for both `A - B` and `B - A`
is stored then it only returns the first one. If we both use `A - B` and
`B - A`, these expressions behave as two totally unrelated symbols. This way
we miss some useful deductions which may lead to false negatives or false
positives.
This tiny patch changes this behavior: if the symbolic expression the
constraint manager is looking for is a difference `A - B`, it tries to
retrieve the range for both `A - B` and `B - A` and if both exists it returns
the intersection of range `A - B` and the negated range of `B - A`. This way
every time a checker applies new constraints to the symbolic difference or to
its negated it always affects both the original difference and its negated.
Differential Revision: https://reviews.llvm.org/D55007
llvm-svn: 357167
Fixed bug in C++ to prevent parsing 'private' as a
valid address space qualifier.
Differential Revision: https://reviews.llvm.org/D59874
llvm-svn: 357162
In gcc, -gsplit-dwarf is handled in gcc/gcc.c as a spec
(ASM_FINAL_SPEC): objcopy --extract-dwo + objcopy --strip-dwo. In
gcc/opts.c, -gsplit_dwarf has the same semantic of a -g. Except for the
availability of the external command 'objcopy', nothing precludes the
feature working on other ELF OSes. llvm doesn't use objcopy, so it doesn't
have to exclude other OSes.
llvm-svn: 357150
Summary:
We may try and re-import an EnumDecl while trying to complete it in IsStructuralMatch(...) specialization for EnumDecl. This change mirrors a similar fix for the specialization for RecordDecl.
Differential Revision: https://reviews.llvm.org/D59845
llvm-svn: 357100
This fixes a false positive on the following, where st is configured to have
different sizes based on some preprocessor logic:
if (sizeof(buf) == sizeof(*st))
memcpy(&buf, st, sizeof(*st));
llvm-svn: 357041
MarkVarDeclODRUsed indirectly calls captureInBlock, which creates a copy
expression. The copy expression is insulated in it's own
ExpressionEvaluationContext, so it saves, mutates, and restores MaybeODRUseExprs
as CleanupVarDeclMarking is iterating through it, leading to a crash. Fix this
by iterating through a local copy of MaybeODRUseExprs.
rdar://47493525
https://reviews.llvm.org/D59670
llvm-svn: 357040
FileManager constructs a VFS in its constructor if it isn't passed one,
and there's no way to reset it. Make that contract clear by returning a
reference from its accessor.
https://reviews.llvm.org/D59388
llvm-svn: 357038
Remove CompilerInstance::VirtualFileSystem and
CompilerInstance::setVirtualFileSystem, instead relying on the VFS in
the FileManager. CompilerInstance and its clients already went to some
trouble to make these match. Now they are guaranteed to match.
As part of this, I added a VFS parameter (defaults to nullptr) to
CompilerInstance::createFileManager, to avoid repeating construction
logic in clients that just wanted to customize the VFS.
https://reviews.llvm.org/D59377
llvm-svn: 357037
Since AArch64 has default outlining behaviour, we need to make sure that
-mno-outline is actually passed along to the linker in this case. Otherwise,
it will run by default on minsize functions even when -mno-outline is specified.
Also fix the darwin-ld test for this, which wasn't actually doing anything.
llvm-svn: 357031
Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57687
llvm-svn: 357027
The RISC-V assembler needs the target ABI because it defines a flag of the ELF
file, as described in [1].
Make clang (the driver) to pass the target ABI to -cc1as in exactly the same
way it does for -cc1.
Currently -cc1as knows about -target-abi but is not handling it. Handle it and
pass it to the MC layer via MCTargetOptions.
[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#file-header
Differential Revision: https://reviews.llvm.org/D59298
llvm-svn: 356981
r356634 didn't fix all the problems caused by r356222 - even though simple
constructors involving transparent init-list expressions are now evaluated
precisely, many more complicated constructors aren't, for other reasons.
The attached test case is an example of a constructor that will never be
evaluated precisely - simply because there isn't a constructor there (instead,
the program invokes run-time undefined behavior by returning without a return
statement that should have constructed the return value).
Fix another part of the problem for such situations: evaluate transparent
init-list expressions transparently, so that to avoid creating ill-formed
"transparent" nonloc::CompoundVals.
Differential Revision: https://reviews.llvm.org/D59622
llvm-svn: 356969
The intention is to add metadata to direct call sites of functions
marked with __declspec(allocator), which will ultimately result in some
S_HEAPALLOCSITE debug info records when emitting codeview.
This is a piece of PR38491
llvm-svn: 356964
Bail-out of CheckArrayAccess when the types of the base expression before
and after eventual casts are dependent. We will get another chance to check
for array bounds during instantiation. Fixes PR41087.
Differential Revision: https://reviews.llvm.org/D59776
Reviewed By: efriedma
llvm-svn: 356957
We can't (don't want to) honor the same set of "-fuse-ld" flags with
WebAssembly since the ELF linkers (ld.lld, ld.gnu, etc) don't work with
wasm object files.
Instead we implement our own linker finding logic, similar or other
non-ELF platforms like MSVC.
We've had a few issues with CLANG_DEFAULT_LINKER overriding the
WebAssembly linker which doesn't make sense since there is no generic
linker that can handle WebAssembly today.
Differential Revision: https://reviews.llvm.org/D59743
llvm-svn: 356953
Summary:
SExprBuilder::translateDeclRefExpr was only looking at FunctionDecl and not also looking at ObjCMethodDecl. It should consider both because the attributes can be used on Objective-C as well.
<rdar://problem/48941331>
Reviewers: dexonsmith, erik.pilkington
Subscribers: jkorous, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59523
llvm-svn: 356940
Summary:
Revision r356575 had the unfortunate consequence that now clang-format never
detects an ObjC call expression after `&&`.
This patch tries harder to distinguish between C++17 structured bindings and
ObjC call expressions and adds a few regression tests.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59774
llvm-svn: 356928
The various CorrectionCandidateCallbacks are currently heap-allocated
unconditionally. This was needed because of delayed typo correction.
However these allocations represent currently 15.4% of all allocations
(number of allocations) when parsing all of Boost (!), mostly because
of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes
and isCXXDeclarationSpecifier. Note that all of these callback objects
are small. Let's not do this.
Instead initially allocate the callback on the stack, and only do a
heap allocation if we are going to do some typo correction. Do this by:
1. Adding a clone function to each callback, which will do a polymorphic
clone of the callback. This clone function is required to be implemented
by every callback (of which there is a fair amount). Make sure this is
the case by making it pure virtual.
2. Use this clone function when we are going to try to correct a typo.
This additionally cut the time of -fsyntax-only on all of Boost by 0.5%
(not that much, but still something). No functional changes intended.
Differential Revision: https://reviews.llvm.org/D58827
Reviewed By: rnk
llvm-svn: 356925
This reverts commit r356835. This patch causes a regression, see the
test below:
verifyFormat("// Detached comment\n\n"
"// Leading comment\n"
"syntax = \"proto2\"; // trailing comment\n\n"
"// in foo.bar package\n"
"package foo.bar; // foo.bar package\n");
llvm-svn: 356912
For backwards compatibility we allow alternative spelling of address
spaces - 'private', 'local', 'global', 'constant', 'generic'.
In order to accept 'private' correctly, parsing has been changed to
understand different use cases - access specifier vs address space.
Fixes PR40707 and PR41011!
Differential Revision: https://reviews.llvm.org/D59603
llvm-svn: 356888
Summary:
https://reviews.llvm.org/D59076 added a new coroutine error that
prevented users from using 'co_await' or 'co_yield' within a exception
handler. However, it was reverted in https://reviews.llvm.org/rC356774
because it caused a regression in nested scopes in C++ catch statements,
as documented by https://bugs.llvm.org/show_bug.cgi?id=41171.
The issue was due to an incorrect use of a `clang::ParseScope`. To fix:
1. Add a regression test for catch statement parsing that mimics the bug
report from https://bugs.llvm.org/show_bug.cgi?id=41171.
2. Re-apply the coroutines error patch from
https://reviews.llvm.org/D59076, but this time with the correct
ParseScope behavior.
Reviewers: GorNishanov, tks2103, rsmith, riccibruno, jbulow
Reviewed By: riccibruno
Subscribers: EricWF, jdoerfert, lewissbaker, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59752
llvm-svn: 356865
Summary:
These are all implemented by icc as well.
I made bit_scan_forward/reverse forward to the __bsfd/__bsrq since we also have
__bsfq/__bsrq.
Note, when lzcnt is enabled the bsr intrinsics generates lzcnt+xor instead of bsr.
Reviewers: RKSimon, spatel
Subscribers: cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59682
llvm-svn: 356848
Summary:
Top-level "package" and "import" statements should generally be kept on one
line, for all languages.
Reviewers: sammccall, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59627
Patch By: dchai (Donald Chai)
llvm-svn: 356835
Summary:
This eliminates a linker error the user might otherwise see about how
using the 'atomics' feature requires --shared-memory.
Reviewers: sbc100, aheejin
Subscribers: dschuff, jgravelle-google, sunfish, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59721
llvm-svn: 356817
dynamic_allocators.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit. Patch adds a check for a
presence of the requires directive with the dynamic_allocators clause.
llvm-svn: 356758
clause in target region.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit.
llvm-svn: 356752
This is the result of discussions on the list about how to deal with intrinsics
which require codegen to disambiguate them via only the integer/fp overloads.
It causes problems for GlobalISel as some of that information is lost during
translation, while with other operations like IR instructions the information is
encoded into the instruction opcode.
This patch changes clang to emit the new faddp intrinsic if the vector operands
to the builtin have FP element types. LLVM IR AutoUpgrade has been taught to
upgrade existing calls to aarch64.neon.addp with fp vector arguments, and
we remove the workarounds introduced for GlobalISel in r355865.
This is a more permanent solution to PR40968.
Differential Revision: https://reviews.llvm.org/D59655
llvm-svn: 356722
in the include path.
Instead of making the incorrect claim that the included file has an
absolute path, describe the actual problem: the including file was found
either by absolute path, or relative to such a file, or relative to the
primary source file.
llvm-svn: 356712
Use the new cx8 feature flag that was added to the backend to represent support for cmpxchg8b. Use this flag to set the MaxAtomicInlineWidth.
This also assumes all the cmpxchg instructions are enabled for CK_Generic which is what cc1 defaults to when nothing is specified.
Differential Revision: https://reviews.llvm.org/D59566
llvm-svn: 356709
-malign-double is currently only implemented in the -cc1 interface. But its declared in Options.td so it is a driver option too. But you try to use it with the driver you'll get a message about the option being unused.
This patch teaches the driver to pass the option through to cc1 so it won't be unused. The Options.td says the option is x86 only but I didn't see any x86 specific code in its impementation in cc1 so not sure if the documentation is wrong or if I should only pass this option through the driver on x86 targets.
Differential Revision: https://reviews.llvm.org/D59624
llvm-svn: 356706
with notail on x86-64.
On x86-64, the epilogue code inserted before the tail jump blocks the
autoreleased return optimization.
rdar://problem/38675807
Differential Revision: https://reviews.llvm.org/D59656
llvm-svn: 356705
For the global variables the allocate directive must specify only the
predefined allocator. This allocator must be translated into the correct
form of the address space for the targets that support different address
spaces.
llvm-svn: 356702
Previously implemented check required the reevaluation of the already
evaluated predefined allocator kind for the global variables. Patch
simplifies this evaluation and removes extra code.
llvm-svn: 356699
gcc and icc both implement popcntd and popcntq which we did not. gcc doesn't seem to require a feature flag for the _popcnt32/_popcnt64 spelling and will use a libcall if its not supported.
Differential Revision: https://reviews.llvm.org/D59567
llvm-svn: 356689
Summary:
`OMPClause` is the base class, it is not descendant from **any**
other class, therefore for it to work with e.g.
`VariadicDynCastAllOfMatcher<>`, it needs to be handled here.
Reviewers: sbenza, bkramer, pcc, klimek, hokein, gribozavr, aaron.ballman, george.karpenkov
Reviewed By: gribozavr, aaron.ballman
Subscribers: guansong, jdoerfert, alexfh, ABataev, cfe-commits
Tags: #openmp, #clang
Differential Revision: https://reviews.llvm.org/D57112
llvm-svn: 356675
After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.
When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly. This patch ALSO
unifies those under a 'select'. Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.
Differential Revision: https://reviews.llvm.org/D59560
Change-Id: I79f99fe7c2301640755ffdd774b46eb44526bb22
llvm-svn: 356663
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
When searching for construction contexts, i.e. figuring out which statements
define the object that is constructed by each construct-expression, ignore
transparent init-list expressions because they don't add anything to the
context. This allows the Static Analyzer to model construction, destruction,
materialization, lifetime extension correctly in more cases. Also fixes
a crash caused by incorrectly evaluating initial values of variables
initialized with such expressions.
Differential Revision: https://reviews.llvm.org/D59573
llvm-svn: 356634
gcc has these intrinsics in ia32intrin.h as well. And icc implements them
though they aren't documented in the Intel Intrinsics Guide.
Differential Revision: https://reviews.llvm.org/D59533
llvm-svn: 356609
allocators.
It is better to deduce omp_allocator_handle_t type from the predefined
allocators, because omp.h header might not define it explicitly. Plus,
it allows to identify the predefined allocators correctly when trying to
build the allcoator for the global variables.
llvm-svn: 356607
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
llvm.org/PR40991
rdar://48564179
Differential revision: https://reviews.llvm.org/D59394
llvm-svn: 356599
This diff previously exposed a bug in LLVM's IRLinker, breaking
buildbots that tried to self-host LLVM with monolithic LTO.
The bug is now in LLVM by D59552
Original commit message:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.
Test Plan: Added a testcase
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D56928
llvm-svn: 356598
Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.
Reviewers: balazske, martong, a.sidorin, shafik
Reviewed By: balazske, martong
Subscribers: rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59595
llvm-svn: 356592
Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++
Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160
$ clang-format.exe test.h
Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format
--- test.h --
```
std::vector<std::pair<std::string,std::string>> C;
void foo()
{
for (auto && [A,B] : C)
{
std::string D = A + B;
}
}
```
The following code fixes this issue of incorrect detection
Reviewers: djasper, klimek, JonasToth, reuk
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59546
llvm-svn: 356575
Summary:
[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))
For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller
will try to fully unroll a loop unless the trip count is not known at compile time.
In that case for '.full' metadata no unrolling will be processed, while for '.enable'
the loop will be partially unrolled with a heuristically chosen unroll factor.
See: docs/LanguageExtensions.rst
From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html
__attribute__((opencl_unroll_hint))
for (int i=0; i<2; i++)
{
...
}
In the example above, the compiler will determine how much to unroll the loop.
Before the patch for __attribute__((opencl_unroll_hint)) was generated metadata
!{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how
much to unroll the loop.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia
Subscribers: zzheng, dmgreen, jdoerfert, cfe-commits, asavonic, AlexeySotkin
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59493
llvm-svn: 356571
Summary:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3:
```
structured block
For C/C++, an executable statement, possibly compound, with a single entry at the
top and a single exit at the bottom, or an OpenMP construct.
COMMENT: See Section 2.1 on page 38 for restrictions on structured
blocks.
```
```
2.1 Directive Format
Some executable directives include a structured block. A structured block:
• may contain infinite loops where the point of exit is never reached;
• may halt due to an IEEE exception;
• may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
_Noreturn specifier (in C) or a noreturn attribute (in C/C++);
• may be an expression statement, iteration statement, selection statement, or try block, provided
that the corresponding compound statement obtained by enclosing it in { and } would be a
structured block; and
Restrictions
Restrictions to structured blocks are as follows:
• Entry to a structured block must not be the result of a branch.
• The point of exit cannot be a branch out of the structured block.
C / C++
• The point of entry to a structured block must not be a call to setjmp().
• longjmp() and throw() must not violate the entry/exit criteria.
```
Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`,
in the same sense as with the normal `noexcept` functions in C++.
I.e. if throw happens, and it attempts to travel out of the `noexcept` function
(here: out of the current structured-block), then the program terminates.
Now, one of course can say that since it is explicitly prohibited by the Specification,
then any and all programs that violate this Specification contain undefined behavior,
and are unspecified, and thus no one should care about them. Just don't write broken code /s
But i'm not sure this is a reasonable approach.
I have personally had oss-fuzz issues of this origin - exception thrown inside
of an OpenMP structured-block that is not caught, thus causing program termination.
This issue isn't all that hard to catch, it's not any particularly different from
diagnosing the same situation with the normal `noexcept` function.
Now, clang static analyzer does not presently model exceptions.
But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check,
and it is even refactored as a `ExceptionAnalyzer` class for reuse.
So it would be trivial to use that analyzer to check for
exceptions escaping out of OpenMP structured blocks. (D59466)
All that sounds too great to be true. Indeed, there is a caveat.
Presently, it's practically impossible to do. To check a OpenMP structured block
you need to somehow 'get' the OpenMP structured block, and you can't because
it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation.
Now, it is of course possible to write e.g. some AST matcher that would e.g.
match every OpenMP executable directive, and then return the whatever `Stmt` is
the structured block of said executable directive, if any.
But i said //practically//. This isn't practical for the following reasons:
1. This **will** bitrot. That matcher will need to be kept up-to-date,
and refreshed with every new OpenMP spec version.
2. Every single piece of code that would want that knowledge would need to
have such matcher. Well, okay, if it is an AST matcher, it could be shared.
But then you still have `RecursiveASTVisitor` and friends.
`2 > 1`, so now you have code duplication.
So it would be reasonable (and is fully within clang AST spirit) to not
force every single consumer to do that work, but instead store that knowledge
in the correct, and appropriate place - AST, class structure.
Now, there is another hoop we need to get through.
It isn't fully obvious //how// to model this.
The best solution would of course be to simply add a `OMPStructuredBlock` transparent
node. It would be optimal, it would give us two properties:
* Given this `OMPExecutableDirective`, what's it OpenMP structured block?
* It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`)
But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`.
(even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween).
So i'm not sure whether or not we could re-create AST statements after they were already created?
There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12
```
1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity.
2. You will need to support serialization/deserialization.
3. You will need to support template instantiation.
4. You will need to support codegen and take this new construct to account in each OpenMP directive.
```
Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts.
Part 1:
* Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class,
that will tell whether this directive is stand-alone or not, as per the spec.
We need it because we can't just check for the existance of associated statements,
see code comment.
* Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself,
that assert that this is not a stand-alone directive, and either return the correct loop body
if this is a loop-like directive, or the captured statement.
This way, given an `OMPExecutableDirective`, we can get it's structured block.
Also, since the knowledge is ingrained into the clang OpenMP implementation,
it will not cause any duplication, and //hopefully// won't bitrot.
Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach.
Thus, there is a second part needed:
* How can we check whether a given `Stmt*` is `OMPStructuredBlock`?
Well, we can't really, in general. I can see this workaround:
```
class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> {
using Base = RecursiveASTVisitor<FunctionASTVisitor>;
public:
bool VisitOMPExecDir(OMPExecDir *D) {
OmpStructuredStmts.emplace_back(D.getStructuredStmt());
}
bool VisitSOMETHINGELSE(???) {
if(InOmpStructuredStmt)
HI!
}
bool TraverseStmt(Stmt *Node) {
if (!Node)
return Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node)
++InOmpStructuredStmt;
Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node) {
OmpStructuredStmts.pop_back();
--InOmpStructuredStmt;
}
return true;
}
std::vector<Stmt*> OmpStructuredStmts;
int InOmpStructuredStmt = 0;
};
```
But i really don't see using it in practice.
It's just too intrusive; and again, requires knowledge duplication.
.. but no. The solution lies right on the ground.
Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself?
This does not appear to have any impact on the memory footprint of the clang AST,
since it's just a single extra bit in the bitfield. At least the static assertions don't fail.
Thus, indeed, we can achieve both of the properties without a new AST node.
We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`,
by just calling the `getStructuredBlock()` that we just added.
Test coverage that demonstrates all this has been added.
This isn't as great with serialization though. Most of it does not use abbrevs,
so we do end up paying the full price (4 bytes?) instead of a single bit.
That price, of course, can be reclaimed by using abbrevs.
In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly.
I'm not seeing a third solution. If there is one, it would be interesting to hear about it.
("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.)
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]].
Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr
Reviewed By: ABataev, gribozavr
Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits
Tags: #clang, #openmp
Differential Revision: https://reviews.llvm.org/D59214
llvm-svn: 356570
Summary:
The ASTNodeImporter::ImportTemplateParameterList is replaced by a
template specialization of 'import' that already exists and does
(almost) the same thing.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59134
llvm-svn: 356564
PentiumPro has HasNOPL set in the backend. i686 does not.
Despite having a function that looks like it canonicalizes alias names. It
doesn't seem to be called. So I don't think this is a functional change. But its
good to be consistent between the backend and frontend.
llvm-svn: 356537
Use the new kind for both angled header-name tokens and for
double-quoted header-name tokens.
This is in preparation for C++20's context-sensitive header-name token
formation rules.
llvm-svn: 356530
The attribute pass_dynamic_object_size(n) behaves exactly like
pass_object_size(n), but instead of evaluating __builtin_object_size on calls,
it evaluates __builtin_dynamic_object_size, which has the potential to produce
runtime code when the object size can't be determined statically.
Differential revision: https://reviews.llvm.org/D58757
llvm-svn: 356515
If the allocator was specified for the variable and next one is found
with the different allocator, the warning is emitted, and the allocator
is ignored.
llvm-svn: 356513
"clang++ hello.cc --rtlib=compiler-rt"
now can works without specifying additional unwind or exception
handling libraries.
This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.
This should address the issues from the previous version.
Update tests for new --unwindlib semantics.
Differential Revision: https://reviews.llvm.org/D59109
llvm-svn: 356508
According to OpenMP, 2.11.3 allocate Directive, Restrictions, C / C++,
if a list item has a static storage type, the allocator expression in
the allocator clause must be a constant expression that evaluates to
one of the predefined memory allocator values. Added check for this
restriction.
llvm-svn: 356496
When we create overloads for the builtin compound assignment operators
we need to preserve address space for the reference operand taking it
from the argument that is passed in.
Differential Revision: https://reviews.llvm.org/D59367
llvm-svn: 356475
Added initial codegen for the local variables with the #pragma omp
allocate directive. Instead of allocating the variables on the stack,
__kmpc_alloc|__kmpc_free functions are used for memory (de-)allocation.
llvm-svn: 356472
Summary:
Redecl chains of function template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58668
llvm-svn: 356455
Summary:
Redecl chains of class template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58673
llvm-svn: 356452
Addresses PR40999 https://bugs.llvm.org/show_bug.cgi?id=40999
Private fields and methods in JavaScript would get incorrectly indented
(it sees them as preprocessor directives and hence left aligns them)
In this revision `#identifier` tokens `tok::hash->tok::identifier` are
merged into a single new token `tok::identifier` with the `#` contained
inside the TokenText.
Before:
```
class Example {
pub = 1;
static pub2 = "foo";
static #priv2 = "bar";
method() { this.#priv = 5; }
static staticMethod() {
switch (this.#priv) {
case '1':
break;
}
}
this.#privateMethod(); // infinite loop
}
static #staticPrivateMethod() {}
}
```
After this fix the code will be correctly indented
```
class Example {
pub = 1;
#priv = 2;
static pub2 = "foo";
static #priv2 = "bar";
method() { this.#priv = 5; }
static staticMethod() {
switch (this.#priv) {
case '1':
#priv = 3;
break;
}
}
#privateMethod() {
this.#privateMethod(); // infinite loop
}
static #staticPrivateMethod() {}
}
```
NOTE: There might be some JavaScript code out there which uses the C
processor to preprocess .js files
http://www.nongnu.org/espresso/js-cpp.html. It's not clear how this
revision or even private fields and methods would interact.
Patch originally by MyDeveloperDays (thanks!).
llvm-svn: 356449
Before:
const x = veryLongIdentifier
`hello`;
After:
const x =
veryLongIdentifier`hello`;
While it's allowed to have the template string and tag identifier
separated by a line break, currently the clang-format output is not
stable when a break is forced. Additionally, disallowing a line break
makes it clear that the identifier is actually a tag for a template
string.
Patch originally by mitchellwills (thanks!).
llvm-svn: 356447
Summary:
Previously, when the renamed spelling is ambiguous, we simply use the
full-qualfied name (with leading "::"). This patch makes it try adding
additional specifiers one at a time until name is no longer ambiguous,
which allows us to find better disambuguated spelling.
Reviewers: kadircet, gribozavr
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59487
llvm-svn: 356446
Summary:
This patch refactors several instances of cast<> used in if
conditionals. Since cast<> asserts on failure, the else branch can
never be taken.
In some cases, the fix is to replace cast<> with dyn_cast<>. While
others required the removal of the conditional and some minor
refactoring.
A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html
Differential Revision: https://reviews.llvm.org/D59529
llvm-svn: 356441
tokens.
We now actually form an angled_string_literal token for a header name by
concatenation rather than just working out what its contents would be.
This substantially simplifies downstream processing and is necessary for
C++20 header unit imports.
llvm-svn: 356433
Summary:
Similar to D56967, we add the existing diag::note_locked_here to tell
the user where we saw the locking that isn't matched correctly.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59455
llvm-svn: 356427
As background, when constructing a complete object, virtual bases are
constructed first. If an exception is thrown later in the ctor, those
virtual bases are destroyed, so sema marks the relevant constructors and
destructors of virtual bases as referenced. If necessary, they are
emitted.
However, an abstract class can never be used to construct a complete
object. In the Itanium C++ ABI, this works out nicely, because we never
end up emitting the "complete" constructor variant, only the "base"
constructor variant, which can be called by constructors of derived
classes. Clang's Sema::MarkBaseAndMemberDestructorsReferenced is aware
of this optimization, and it does not mark ctors and dtors of virtual
bases referenced when the constructor of an abstract class is emitted.
In the Microsoft ABI, there are no complete/base variants, so before
this change, the constructor of an abstract class could reference ctors
and dtors of a virtual base without marking them referenced. This could
lead to unresolved symbol errors at link time, as reported in PR41065.
The fix is to implement the same optimization as Sema: If the class is
abstract, don't bother initializing its virtual bases. The "is this
class the most derived class" check in the constructor will never pass,
and the virtual base constructor calls are always dead. Skip them.
I think Richard noticed this missed optimization back in 2016 when he
was implementing inheriting constructors. I wasn't able to find any bugs
or email about it, though.
Fixes PR41065
llvm-svn: 356425
This is another attempt at what Erich Keane tried to do in r355322.
This adds rolb, rolw, rold, rolq and their ror equivalent as always_inline wrappers around __builtin_rotate* which will lower to funnel shift intrinsics in IR.
Additionally, when _MSC_VER is not defined we will define _rotl, _lrotl, _rotr, _lrotr as macros to one of the always_inline intrinsics mentioned above. Making sure that _lrotl/_lrotr use either 32 or 64 bit based on the size of long. These need to be macros because we have builtins with the same name for MS compatibility, but _MSC_VER isn't always defined when those builtins are enabled.
We also define _rotwl and _rotwr as macros aliasing to rolw/rorw just like gcc to complete the set. These don't need to be gated with _MSC_VER because these aren't MS builtins.
I've added tests both for non-MS and -ms-extensions with and without _MSC_VER being defined.
Differential Revision: https://reviews.llvm.org/D59346
llvm-svn: 356423
These diagnose overflowing calls to subset of fortifiable functions. Some
functions, like sprintf or strcpy aren't supported right not, but we should
probably support these in the future. We previously supported this kind of
functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work
with _FORTIFY implementations that use wrapper functions. Also unlike that
diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is
actually enabled, which is nice for programs that don't enable the runtime
checks.
Why not just use diagnose_if, like Bionic does? We can get better diagnostics in
the compiler (i.e. mention the sizes), and we have the potential to diagnose
sprintf and strcpy which is impossible with diagnose_if (at least, in languages
that don't support C++14 constexpr). This approach also saves standard libraries
from having to add diagnose_if.
rdar://48006655
Differential revision: https://reviews.llvm.org/D58797
llvm-svn: 356397
Summary:
If the constraint information is not changed between two program states the
analyzer has not learnt new information and made no report. But it is
possible to happen because we have no information at all. The new approach
evaluates the condition to determine if that is the case and let the user
know we just `Assuming...` some value.
Reviewers: NoQ, george.karpenkov
Reviewed By: NoQ
Subscribers: llvm-commits, xazax.hun, baloghadamsoftware, szepet, a.sidorin,
mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D57410
llvm-svn: 356323
Summary:
Removed the `GDM` checking what could prevent reports made by this visitor.
Now we rely on constraint changes instead.
(It reapplies 356318 with a feature from 356319 because build-bot failure.)
Reviewers: NoQ, george.karpenkov
Reviewed By: NoQ
Subscribers: cfe-commits, jdoerfert, gerazo, xazax.hun, baloghadamsoftware,
szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D54811
llvm-svn: 356322
Summary: If the constraint information is not changed between two program states the analyzer has not learnt new information and made no report. But it is possible to happen because we have no information at all. The new approach evaluates the condition to determine if that is the case and let the user know we just 'Assuming...' some value.
Reviewers: NoQ, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57410
llvm-svn: 356319
Summary: Removed the `GDM` checking what could prevent reports made by this visitor. Now we rely on constraint changes instead.
Reviewers: NoQ, george.karpenkov
Reviewed By: NoQ
Subscribers: jdoerfert, gerazo, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D54811
llvm-svn: 356318
Summary:
Because in wasm we merge all catch clauses into one big catchpad, in
case none of the types in catch handlers matches after we test against
each of them, we should unwind to the next EH enclosing scope. For this,
we should NOT use a call to `__cxa_rethrow` but rather a call to our own
rethrow intrinsic, because what we're trying to do here is just to
transfer the control flow into the next enclosing EH pad (or the
caller). Calls to `__cxa_rethrow` should only be used after a call to
`__cxa_begin_catch`.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59353
llvm-svn: 356317
Partial fix for the clang Bug 38811 "Clang fails to compile with CUDA-9.x on Windows".
[Synopsis]
__sptr is a new Microsoft specific modifier (https://docs.microsoft.com/en-us/cpp/cpp/sptr-uptr?view=vs-2017).
[Solution]
Replace all `__sptr` occurrences with `__s` (and all `__cptr` with `__c` as well) to eliminate the below clang compilation error on Windows.
In file included from C:\GIT\LLVM\trunk\llvm-64-release-vs2017-15.9.5\dist\lib\clang\9.0.0\include\__clang_cuda_runtime_wrapper.h:162:
C:\GIT\LLVM\trunk\llvm-64-release-vs2017-15.9.5\dist\lib\clang\9.0.0\include\__clang_cuda_device_functions.h:524:33: error: expected expression
return __nv_fast_sincosf(__a, __sptr, __cptr);
^
Reviewed by: Artem Belevich
Differential Revision: http://reviews.llvm.org/D59423
llvm-svn: 356291
Change the HIP Toolchain to pass the OPT_mllvm options into OPT and LLC stages. Added a lit test to verify the command args.
Reviewers: yaxunl
Differential Revision: https://reviews.llvm.org/D59316
llvm-svn: 356277
Partial fix for the clang Bug https://bugs.llvm.org/show_bug.cgi?id=38811 "Clang fails to compile with CUDA-9.x on Windows".
Adding defined(_WIN64) check along with existing #if defined(__LP64__) eliminates the below clang (64-bit) compilation error on Windows.
C:/GIT/LLVM/trunk/llvm-64-release-vs2017/dist/lib/clang/9.0.0\include\__clang_cuda_device_functions.h(1609,45): error GEF7559A7: no matching function for call to 'roundf'
__DEVICE__ long lroundf(float __a) { return roundf(__a); }
Reviewed by: Artem Belevich
Differential Revision: http://reviews.llvm.org/D59361
llvm-svn: 356255
We already handle pointers and references, member ptrs are just another
special case. Fixes PR40732.
Differential Revision: https://reviews.llvm.org/D59387
llvm-svn: 356250
Don't crash when a function has a name that starts with "CF" and ends with
"Retain" but takes 0 arguments. In particular, don't try to treat it as if
it returns its first argument.
These problems are inevitable because the checker is naming-convention-based,
but at least we shouldn't crash.
Differential Revision: https://reviews.llvm.org/D59123
llvm-svn: 356223
RegionStore now knows how to bind a nonloc::CompoundVal that represents the
value of an aggregate initializer when it has its initial segment of sub-values
correspond to base classes.
Additionally, fixes the crash from pr40022.
Differential Revision: https://reviews.llvm.org/D59054
llvm-svn: 356222
llvm-svn 356197 relanded previously failing test case max_align.c.
This commit will reland the rest of llvm-svn 356060 commit.
Differential Revision: https://reviews.llvm.org/D59048
llvm-svn: 356208
If the doacross lop construct is used and the loop counter is declare
outside of the loop, the compiler might crash trying to get the address
of the loop counter. Patch fixes this problem.
llvm-svn: 356198
The constraint "0" in the following asm did not consider the its
relationship with "=y" when try to replace the type of the operands.
asm ("nop" : "=y"(Mu8_1 ) : "0"(Mu8_0 ));
Patch by Xiang Zhang.
Differential Revision: https://reviews.llvm.org/D56990
llvm-svn: 356196
We were allocating the implicit attribute in the declarator's attribute pool,
but putting into the declaration specifier's ParsedAttributesView. If there are
multiple declarators, then we'll use the attribute from the declaration
specifier after clearing out the declarators attribute pool. Fix this by
allocating the attribute in the declaration specifier's pool.
rdar://48529718
Differential revision: https://reviews.llvm.org/D59327
llvm-svn: 356187
__pragma(execution_character_set(push, "UTF-8")) is used in
TraceLoggingProvider.h. This commit implements a no-op handler for
compatability, similar to how the flag -fexec_charset is handled.
Patch by Matt Gardner!
Differential Revision: https://reviews.llvm.org/D58530
llvm-svn: 356185
For a rather short code snippet, if debug.ReportStmts (added in this patch) was
enabled, a bug reporter visitor crashed:
struct h {
operator int();
};
int k() {
return h();
}
Ultimately, this originated from PathDiagnosticLocation::createMemberLoc, as it
didn't handle the case where it's MemberExpr typed parameter returned and
invalid SourceLocation for MemberExpr::getMemberLoc. The solution was to find
any related valid SourceLocaion, and Stmt::getBeginLoc happens to be just that.
Differential Revision: https://reviews.llvm.org/D58777
llvm-svn: 356161
metadata and protocol list
The leading 'l' tells ld64 to remove the symbol name, which can make
debugging difficult.
rdar://problem/47256637
Differential Revision: https://reviews.llvm.org/D59234
llvm-svn: 356156
Summary:
Import type location in case of TypeSpec and TypeSpecWithTemplate.
Without this fix the imported NespedNameSpecifierLoc will have an
invalid begin location.
Reviewers: a.sidorin, shafik, a_sidorin, martong
Reviewed By: a_sidorin
Subscribers: rnkovacs, jdoerfert, dkrupp, martong, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55358
llvm-svn: 356151
This adds support for static_assert() (and _Static_assert()) in
@interface/@implementation ivar lists and in @interface method declarations.
It was already supported in @implementation blocks outside of the ivar lists.
The assert AST nodes are added at file scope, matching where other
(non-Objective-C) declarations at @interface / @implementation level go (cf
`allTUVariables`).
Also add a `__has_feature(objc_c_static_assert)` that's true in C11 (and
`__has_extension(objc_c_static_assert)` that's always true) and
`__has_feature(objc_cxx_static_assert)` that's true in C++11 modea fter this
patch, so it's possible to check if this is supported.
Differential Revision: https://reviews.llvm.org/D59223
llvm-svn: 356148
Summary:
This define should correspond to CMPXCHG16B being available which requires 64-bit mode.
I checked and gcc also seems to only define this in 64-bit mode.
Reviewers: RKSimon, spatel, efriedma, jyknight, jfb
Reviewed By: jfb
Subscribers: jfb, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59287
llvm-svn: 356118
The above commit breaks the usage of PGO and LTO when -fprofile-use is
supplied without a path. This patch changes the usage of this argument
to be inline with its use in addPGOAndCoverageFlags().
Differential revision: https://reviews.llvm.org/D59304
llvm-svn: 356111
This reverts commit r353765. After talking with our c stdlib folks, we decided
to use the existing pass_object_size attribute to implement _FORTIFY_SOURCE
wrappers, like Bionic does (I didn't realize that pass_object_size could be used
for this purpose). Sorry for the flip/flop, and thanks to James Y. Knight for
pointing this out to me.
llvm-svn: 356103
rC355158 added an optional language parameter to getLLVMStyle(), but this parameter was not used in getPredefinedStyle(). Because unit tests directly specify the style, this codepath wasn't tested. Add an additional unit test for getStyle().
llvm-svn: 356099
array.
If the firstprivate variable is a reference, we may incorrectly classify
the kind of the private copy. Use the type of the private copy instead
of the original shared variable.
llvm-svn: 356098
Summary:
Introduces variants of `getText` and `getSourceRange` that extract the source text of an AST node potentially with a trailing token.
Some of the new functions manipulate `CharSourceRange`s, rather than `SourceRange`s, because they document and dynamically enforce their type. So, this revision also updates the corresponding existing FixIt functions to manipulate `CharSourceRange`s. This change is not strictly necessary, but seems like the correct choice, to keep the API self-consistent.
This revision is the first in a series intended to improve the abstractions available to users for writing source-to-source transformations. A full discussion of the end goal can be found on the cfe-dev list with subject "[RFC] Easier source-to-source transformations with clang tooling".
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: kimgr, riccibruno, JonasToth, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58556
llvm-svn: 356095
Previously, we parsed it only in the top level, which excludes namespaces and
extern "C" blocks.
rdar://problem/48818890
Differential revision: https://reviews.llvm.org/D59282
llvm-svn: 356075
'_openmp_teams_reductions_buffer_$_.
nvlink does not handle weak linkage correctly, same symbols with the
different sizes are reported as erroneous though the largest size must
be chosen instead. Patch fixes this problem by using Internal linkage
instead of the Common.
llvm-svn: 356072
Summary:
A first pass over platform-specific properties of the C API/ABI
on AIX for both 32-bit and 64-bit modes.
This is a continuation of D18360 by Andrew Paprocki and further work by Wu Zhao.
Patch by Andus Yu
Reviewers: apaprocki, chandlerc, hubert.reinterpretcast, jasonliu,
xingxue, sfertile
Reviewed by: hubert.reinterpretcast, apaprocki, sfertile
Differential Revision: https://reviews.llvm.org/D59048
llvm-svn: 356060
Checking whether two regions are the same is a partially decidable problem:
either we know for sure that they are the same or we cannot decide. A typical
case for this are the symbolic regions based on conjured symbols. Two
different conjured symbols are either the same or they are different. Since
we cannot decide this and want to reduce false positives as much as possible
we exclude these regions whenever checking whether two containers are the
same at iterator mismatch check.
Differential Revision: https://reviews.llvm.org/D53754
llvm-svn: 356049
Summary:
This patch fixes several small problems with external layouts support in
`MicrosoftRecordLayoutBuilder`:
- aligns properly the size of a struct that ends with a bit field. It was
aligned on byte before, not on the size of the field, so the struct size was
smaller than it should be;
- adjusts the struct size when injecting a vbptr in the case when there were no
bases or fields allocated after the vbptr. Similarly, without the adjustment
the struct was smaller than it should be;
- the same fix as above for the vfptr.
All these fixes affect the non-virtual size of a struct, so they are tested
through non-virtual inheritance.
Reviewers: rnk, zturner, rsmith
Reviewed By: rnk
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58544
llvm-svn: 356047
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356031
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356029
This patch adds an XCOFF triple object format type into LLVM.
This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.
Differential Revision: https://reviews.llvm.org/D58930
llvm-svn: 355989
Summary:
These ObjC AST classes inherit from Stmt, but don't call `VisitStmt(S);`.
Some were founded with help of existing tests (with `NumStmtFields` bumped to `1`),
but some of them don't even have PCH test coverage. :/
Reviewers: arphaman, sammccall, smeenai, aprantl, rsmith, jordan_rose
Reviewed By: jordan_rose
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59197
llvm-svn: 355987
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
Original llvm-svn: 355964
llvm-svn: 355984
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
llvm-svn: 355964
If the variable was declared and marked as declare target, a new offload
entry with size 0 is created. But if later a definition is created and
marked as declare target, this definition is not added to the entry set
and the definition remains not mapped to the target. Patch fixes this
problem allowing to redefine the size and linkage for
previously registered declaration.
llvm-svn: 355960
Add an option to cache the generated PCH in the ModuleCache when
emitting it. This protects clients that build PCHs and read them in the
same process, allowing them to avoid race conditions between parallel
jobs the same way that Clang's implicit module build system does.
rdar://problem/48740787
llvm-svn: 355950
As for OpenCL C, we need to allow using printf and toolchain variadic
functions (prefixed by "__") in C++ mode.
Differential Revision: https://reviews.llvm.org/D59219
llvm-svn: 355915
Buildbot breaks when LLVm is compiled with memory sanitizer.
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0xa3d16d8 in getMacroNameAndPrintExpansion(blahblah)
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:903:11
llvm-svn: 355911
When there is a functor-like macro which is passed as parameter to another
"function" macro then its parameters are not listed at the place of expansion:
#define foo(x) int bar() { return x; }
#define hello(fvar) fvar(0)
hello(foo)
int main() { 1 / bar(); }
Expansion of hello(foo) asserted Clang, because it expected an l_paren token in
the 3rd line after "foo", since it is a function-like token.
Patch by Tibor Brunner!
Differential Revision: https://reviews.llvm.org/D57893
llvm-svn: 355903
This change introduces support for object files in addition to static
and shared libraries which were already supported which requires
changing the type of the argument from boolean to an enum.
Differential Revision: https://reviews.llvm.org/D56044
llvm-svn: 355891
It hasn't seen active development in years, and it hasn't reached a
state where it was useful.
Remove the code until someone is interested in working on it again.
Differential Revision: https://reviews.llvm.org/D59133
llvm-svn: 355862
If the declare target link global is used in the target region
indirectly (used in the inner parallel, teams, etc. regions), we may
miss this variable and it leads to incorrect codegen.
llvm-svn: 355858
Summary:
The revision r355434 had the unfortunate side-effect that it started to
recognize certain ObjC expressions with a call subexpression followed by a
`a->b` subexpression as C++ lambda expressions.
This patch adds a bit of logic to handle these cases and documents them in
tests.
The commented-out test cases in the new test suite are ones that were
problematic before r355434.
Reviewers: MyDeveloperDay, gribozavr
Reviewed By: MyDeveloperDay, gribozavr
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59210
llvm-svn: 355831
Leverage the InMemoryModuleCache to invalidate a module the first time
it fails to import (and to lock a module as soon as it's built or
imported successfully). For implicit module builds, this optimizes
importing deep graphs where the leaf module is out-of-date; see example
near the end of the commit message.
Previously the cache finalized ("locked in") all modules imported so far
when starting a new module build. This was sufficient to prevent
loading two versions of the same module, but was somewhat arbitrary and
hard to reason about.
Now the cache explicitly tracks module state, where each module must be
one of:
- Unknown: module not in the cache (yet).
- Tentative: module in the cache, but not yet fully imported.
- ToBuild: module found on disk could not be imported; need to build.
- Final: module in the cache has been successfully built or imported.
Preventing repeated failed imports avoids variation in builds based on
shifting filesystem state. Now it's guaranteed that a module is loaded
from disk exactly once. It now seems safe to remove
FileManager::invalidateCache, but I'm leaving that for a later commit.
The new, precise logic uncovered a pre-existing problem in the cache:
the map key is the module filename, and different contexts use different
filenames for the same PCM file. (In particular, the test
Modules/relative-import-path.c does not build without this commit.
r223577 started using a relative path to describe a module's base
directory when importing it within another module. As a result, the
module cache sees an absolute path when (a) building the module or
importing it at the top-level, and a relative path when (b) importing
the module underneath another one.)
The "obvious" fix is to resolve paths using FileManager::getVirtualFile
and change the map key for the cache to a FileEntry, but some contexts
(particularly related to ASTUnit) have a shorter lifetime for their
FileManager than the InMemoryModuleCache. This is worth pursuing
further in a later commit; perhaps by tying together the FileManager and
InMemoryModuleCache lifetime, or moving the in-memory PCM storage into a
VFS layer.
For now, use the PCM's base directory as-written for constructing the
filename to check the ModuleCache.
Example
=======
To understand the build optimization, first consider the build of a
module graph TU -> A -> B -> C -> D with an empty cache:
TU builds A'
A' builds B'
B' builds C'
C' builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
If we build TU again, where A, B, C, and D are in the cache and D is
out-of-date, we would previously get this build:
TU imports A
imports B
imports C
imports D (out-of-date)
TU builds A'
A' imports B
imports C
imports D (out-of-date)
builds B'
B' imports C
imports D (out-of-date)
builds C'
C' imports D (out-of-date)
builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
After this commit, we'll immediateley invalidate A, B, C, and D when we
first observe that D is out-of-date, giving this build:
TU imports A
imports B
imports C
imports D (out-of-date)
TU builds A' // The same graph as an empty cache.
A' builds B'
B' builds C'
C' builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
The new build matches what we'd naively expect, pretty closely matching
the original build with the empty cache.
rdar://problem/48545366
llvm-svn: 355778
Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to
Serialization. Another patch will start using it to manage module build
more explicitly, but this is split out because it's mostly mechanical.
Because of the move to Serialization we can no longer abuse the
Preprocessor to forward it to the ASTReader. Besides the rename and
file move, that means Preprocessor::Preprocessor has one fewer parameter
and ASTReader::ASTReader has one more.
llvm-svn: 355777
Summary:
The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1]
```
// error {{never produces a constant expression}}
void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {}
void test() { foo("abc"); }
```
Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression.
The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions.
[1] https://godbolt.org/z/ksAjmq
Reviewers: rsmith, hans, sbenza
Reviewed By: rsmith
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59038
llvm-svn: 355743
There is nontrivial bug caused in lld that I need to further
investigate. Meanwhile, I'll revert this.
This reverts commit 8297e93480c636dc90fd14653c5a66406193363f.
llvm-svn: 355721
In the commited testfile, macro expansion (the one implemented for the plist
output) runs into an infinite recursion. The issue originates from the algorithm
being faulty, as in
#define value REC_MACRO_FUNC(value)
the "value" is being (or at least attempted) expanded from the same macro.
The solved this issue by gathering already visited macros in a set, which does
resolve the crash, but will result in an incorrect macro expansion, that would
preferably be fixed down the line.
Patch by Tibor Brunner!
Differential Revision: https://reviews.llvm.org/D57891
llvm-svn: 355705
Asserting on invalid input isn't very nice, hence the patch to emit an error
instead.
This is the first of many patches to overhaul the way we handle checker options.
Differential Revision: https://reviews.llvm.org/D57850
llvm-svn: 355704
In D55734, we implemented a far more general way of describing taint propagation
rules for functions, like being able to specify an unlimited amount of
source and destination parameters. Previously, we didn't have a particularly
elegant way of expressing the propagation rules for functions that always return
(either through an out-param or return value) a tainted value. In this patch,
we model these functions similarly to other ones, by assigning them a
TaintPropagationRule that describes that they "create a tainted value out of
nothing".
The socket C function is somewhat special, because for certain parameters (for
example, if we supply localhost as parameter), none of the out-params should
be tainted. For this, we added a general solution of being able to specify
custom taint propagation rules through function pointers.
Patch by Gábor Borsik!
Differential Revision: https://reviews.llvm.org/D59055
llvm-svn: 355703
Use this feature to fix a bug on ARM where 4 byte alignment is
incorrectly assumed.
Differential Revision: https://reviews.llvm.org/D57335
llvm-svn: 355685
Summary:
In current indexing logic we get references to class itself when we see
a constructor/destructor which is only syntactically true. Semantically
this information is not correct. This patch marks that reference as
NameReference to let clients deal with it.
Reviewers: akyrtzi, gribozavr, nathawes, benlangmuir
Reviewed By: gribozavr, nathawes
Subscribers: nathawes, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58814
llvm-svn: 355668
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
expression inside the parentheses is a valid UTF-8 string literal.
Previously clang emitted an expression like @("abc") as a message send
to stringWithUTF8String. This commit makes clang emit the boxed
expression as a compile-time constant instead.
This commit also has the effect of silencing the nullable-to-nonnull
conversion warning clang started emitting after r317727, which
originally motivated this commit (see https://oleb.net/2018/@keypath).
rdar://problem/42684601
Differential Revision: https://reviews.llvm.org/D58729
llvm-svn: 355662
The patch originally broke code that was incompatible with GCC, but
we want to follow GCC behavior here according to the discussion in
https://reviews.llvm.org/D58216
Original commit message:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.
Test Plan: Added a testcase
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D56928
llvm-svn: 355627
This change adds a new diagnostic for mismatching address spaces
to be used for C++ casts (only enabled in C style cast for now,
the rest will follow!).
The change extends C-style cast rules to account for address spaces.
It also adds a separate function for address space cast checking that
can be used to map from a separate address space cast operator
addrspace_cast (to be added as a follow up patch).
Note, that after this change clang will no longer allows arbitrary
address space conversions in reinterpret_casts because they can lead
to accidental errors. The implicit safe conversions would still be
allowed.
Differential Revision: https://reviews.llvm.org/D58346
llvm-svn: 355609
Adjust address space for references and pointer operands of builtin operators.
Currently this change only fixes addr space in assignment (= and |=) operator,
that is needed for the test case reported in the bug. Wider support for all
other operations will follow.
Differential Revision: https://reviews.llvm.org/D58719
llvm-svn: 355608
The address space for the Base class pointer when up-casting
from Derived should be taken from the Derived class pointer.
Differential Revision: https://reviews.llvm.org/D53818
llvm-svn: 355606
We should track mutation of a variable within a comma operator expression.
Current code in ExprMutationAnalyzer does not handle it.
This will handle cases like:
(a, b) ++ < == b is modified
(a, b) = c < == b is modifed
Patch by Djordje Todorovic.
Differential Revision: https://reviews.llvm.org/D58894
llvm-svn: 355605
Summary:
Member expressions with explicit template arguments were not imported
correctly: the DeclRefExpr was missing. This patch fixes.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58830
llvm-svn: 355596
Summary:
Redecl chains of function templates are not handled well currently. We
want to handle them similarly to functions, i.e. try to keep the
structure of the original AST as much as possible. The aim is to not
squash a prototype with a definition, rather we create both and put them
in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58494
llvm-svn: 355593
Summary:
When comparing a symbolic region and a constant, the constant would be
widened or truncated to the width of a void pointer, meaning that the
constant could be incorrectly truncated when handling symbols for
non-default address spaces. In the attached test case this resulted in a
false positive since the constant was truncated to zero. To fix this,
widen/truncate the constant to the width of the symbol expression's
type.
This commit does not consider non-symbolic regions as I'm not sure how
to generalize getting the type there.
This fixes PR40814.
Reviewers: NoQ, zaks.anna, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, jdoerfert, Charusso, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58665
llvm-svn: 355592
Since
commit 56f548bbbb7e4387a69708f70724d00e9e076153
[modules] Round-trip -Werror flag through explicit module build.
the behavior of CXTranslationUnit_KeepGoing changed:
Unresolved #includes are fatal errors again. As a consequence, some
templates are not instantiated and lead to confusing errors.
Revert to the old behavior: With CXTranslationUnit_KeepGoing fatal
errors are mapped to errors.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D58501
llvm-svn: 355586
Use this feature to fix a bug on ARM where 4 byte alignment is
incorrectly assumed.
Differential Revision: https://reviews.llvm.org/D57335
llvm-svn: 355585
Summary:
- A device functions could be used as a non-type template parameter in a
global/host function template. However, we should not try to retrieve that
device function and reference it in the host-side debug info as it's
only valid at device side.
Subscribers: aprantl, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58992
llvm-svn: 355551
Use this feature to fix a bug on ARM where 4 byte alignment is
incorrectly assumed.
Differential Revision: https://reviews.llvm.org/D57335
llvm-svn: 355522
This allows us to store more info about where we're emitting the remarks
without cluttering LLVMContext. This is needed for future support for
the remark section.
Differential Revision: https://reviews.llvm.org/D58996
Original llvm-svn: 355507
llvm-svn: 355514
This allows us to store more info about where we're emitting the remarks
without cluttering LLVMContext. This is needed for future support for
the remark section.
Differential Revision: https://reviews.llvm.org/D58996
llvm-svn: 355507
This change fixes temporary materialization to happen in the right
(default) address space when binding to it a reference of different type.
It adds address space conversion afterwards to match the addr space
of a reference.
Differential Revision: https://reviews.llvm.org/D58634
llvm-svn: 355499
Apparently GCC allows this, and there's code relying on it (see bug).
The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be done
(the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()).
Differential Revision: https://reviews.llvm.org/D58821
llvm-svn: 355491
Summary:
This reverts rL352390 / D57280.
As discussed in https://reviews.llvm.org/D57112#inline-506781,
'flush' clause does not exist in the OpenMP spec, it can not be
specified, and `OMPFlushClause` class is just a helper class.
Now, here's the caveat. I have read @ABataev's
> Well, I think it would be good to filter out OMPC_flush somehow
> because there is no such clause actually, it is a pseudo clause
> for better handling of the flush directive.
as if that clause is pseudo clause that only exists for the sole
purpose of simplifying the parser. As in, it never reaches AST.
I did not however try to verify that. Too bad, i was wrong.
It absolutely *does* reach AST. Therefore my understanding/justification
for the change was flawed, which makes the patch a regression which **must** be reverted.
@gribozavr has brought that up again in https://reviews.llvm.org/D57112#inline-521238
> > ...
> Sorry to be late for this discussion, but I don't think this conclusion
> follows. ASTMatchers are supposed to match the AST as it is.
> Even if OMPC_flush is synthetic, it exists in the AST, and users might
> want to match it. I think users would find anything else (trying to filter
> out AST nodes that are not in the source code) to be surprising. For example,
> there's a matcher materializeTemporaryExpr even though this AST node is a
> Clang invention and is not a part of the C++ spec.
>
> Matching only constructs that appear in the source code is not feasible with
> ASTMatchers, because they are based on Clang's AST that exposes tons of semantic
> information, and its design is dictated by the structure of the semantic information.
> See "RFC: Tree-based refactorings with Clang" in cfe-dev for a library that will
> focus on representing source code as faithfully as possible.
>
> Not to even mention that this code is in ASTTypeTraits, a general library for
> handling AST nodes, not specifically for AST Matchers...
Reviewers: gribozavr, ABataev, rjmccall, aaron.ballman
Reviewed By: gribozavr, ABataev
Subscribers: dylanmckay, guansong, arphaman, jdoerfert, cfe-commits, gribozavr, ABataev
Tags: #clang, #openmp
Differential Revision: https://reviews.llvm.org/D58979
llvm-svn: 355486
Add a remark for importing modules. Depending on whether this is a
direct import (into the TU being built by this compiler instance) or
transitive import (into an already-imported module), the diagnostic has
two forms:
importing module 'Foo' from 'path/to/Foo.pcm'
importing module 'Foo' into 'Bar' from 'path/to/Foo.pcm'
Also drop a redundant FileCheck invocation in Rmodule-build.m that was
using -Reverything, since the notes from -Rmodule-import were confusing
it.
https://reviews.llvm.org/D58891
llvm-svn: 355477
This patch includes the necessary code for converting between a fixed point type and integer.
This also includes constant expression evaluation for conversions with these types.
Differential Revision: https://reviews.llvm.org/D56900
llvm-svn: 355462
Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer literal
https://bugs.llvm.org/show_bug.cgi?id=40910
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, jkorous
Reviewed By: jkorous
Subscribers: jkorous, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58922
llvm-svn: 355450
A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g. foo< 1 ? !0 : (3+1)%4 >
Inspired by https://reviews.llvm.org/D58922
Differential Revision: https://reviews.llvm.org/D58934
llvm-svn: 355434
If a kernel template has a function as its template parameter, a device function should be
allowed as template argument since a kernel can call a device function. However,
currently if the kernel template is instantiated in a host function, clang will emit an error
message saying the device function is an invalid candidate for the template parameter.
This happens because clang checks the reference to the device function during parsing
the template arguments. At this point, the template is not instantiated yet. Clang incorrectly
assumes the device function is called by the host function and emits the error message.
This patch fixes the issue by disabling checking of device function during parsing template
arguments and deferring the check to the instantion of the template. At that point, the
template decl is already available, therefore the check can be done against the instantiated
function template decl.
Differential Revision: https://reviews.llvm.org/D56411
llvm-svn: 355421
memory.
If the variable with the constant non-scalar type is firstprivatized in
the target region, the local copy is created with the data copying.
Instead, we allocate the copy in the constant memory and avoid extra
copying in the outlined target regions. This global copy is used in the
target regions without loss of the performance.
llvm-svn: 355418
When -fno-gpu-rdc is set, device code is compiled, linked, and assembled into fat binary
and embedded as string in object files. The object files are normal object files which
can be linked by host linker. In the linking stage, the object files should not be unbundled
when -fno-gpu-rdc is set since they are normal object files, not bundles. The object files
only need to be unbundled when -fgpu-rdc is set.
Currently clang always unbundles object files, disregarding -fgpu-rdc option.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D58917
llvm-svn: 355410
The gets function has no SrcArgs. Because the default value for isTainted was
false, it didn't mark its DstArgs as tainted.
Patch by Gábor Borsik!
Differential Revision: https://reviews.llvm.org/D58828
llvm-svn: 355396
Summary:
Redecl chains of classes and class templates are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58502
llvm-svn: 355390
Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.
The `InPCH` member was also always set to false, and unused.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58924
llvm-svn: 355368
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
When -forder-file-instrumentation is on, we pass llvm flag to enable the order file instrumentation pass.
https://reviews.llvm.org/D58751
llvm-svn: 355333
Summary:
Currently when we see a built-in we try and import the include location. Instead what we do now is find the buffer like we do for the invalid case and copy that over to the to context.
Differential Revision: https://reviews.llvm.org/D58743
llvm-svn: 355332
Part 1 of CSPGO change in Clang. This includes changes in clang options
and calls to llvm PassManager. Tests will be committed in part2.
This change needs the PassManager change in llvm.
Differential Revision: https://reviews.llvm.org/D54176
llvm-svn: 355331
On SPIR targets, the default calling convention is SpirFunction.
However, operator new/delete and builtins were being created with CC_C.
The result is indirect references to new/delete (or builtins that are permitted
to be called indirectly have a mismatched type, as well as questionable codegen
in some cases.
This patch sets both to the default calling convention, so that it
properly matches the calling convention of the target.
Differential Revision: https://reviews.llvm.org/D58844
Change-Id: I52065bb00bc2655945caea8f29c409ba1e0ac24a
llvm-svn: 355317
Under the term "subchecker", I mean checkers that do not have a checker class on
their own, like unix.MallocChecker to unix.DynamicMemoryModeling.
Since a checker object was required in order to retrieve checker options,
subcheckers couldn't possess options on their own.
This patch is also an excuse to change the argument order of getChecker*Option,
it always bothered me, now it resembles the actual command line argument
(checkername:option=value).
Differential Revision: https://reviews.llvm.org/D57579
llvm-svn: 355297
Support locating the libc++ header files relatively to the clang
executable, in addition to the default system path. This is meant
to cover two use cases: running just-built clang from the install
directory, and running installed clang from non-standard location
(e.g. /usr/local).
This is the first step towards ensuring that tests of more LLVM projects
can work out-of-the-box within the build tree, and use the correct set
of headers (rather than e.g. mixing just-built clang+libcxx with system
install of libcxx). It avoids requiring the user to hack around missing
include paths, or LLVM build system to replicate system-specific C++
library defaults in order to append appropriate paths implicitly.
Differential Revision: https://reviews.llvm.org/D58592
llvm-svn: 355282
Then, as a consequence, remove the complex set of workarounds for
initialization order -- which are apparently not 100% reliable.
The only downside is that some of the member functions are now
specific to kNumElem == 2, and will need to be updated if that
constant is increased in the future.
Unfortunately, the current code caused an initialization-order runtime
failure for me in some compilation modes. It appears that in a
toolchain without init-array enabled, the order of initialization of
static data members of a template can be reversed w.r.t. the order
within a file.
This caused e.g. SanitizerKind::CFI to be initialized to 0.
I'm not quite sure if that is an allowable ordering variation, or
nonconforming behavior, but in any case, making everything constexpr
eliminates the possibility of such an issue.
llvm-svn: 355278
Summary:
If the clang-format on/off is in a /* comment */ then the sorting of headers is not ignored
PR40901 - https://bugs.llvm.org/show_bug.cgi?id=40901
Reviewers: djasper, klimek, JonasToth, krasimir, alexfh
Reviewed By: alexfh
Subscribers: alexfh, cfe-commits, llvm-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58819
llvm-svn: 355266
Summary:
Replace cut and pasted code with cmake macros and reduce the number of
install commands. This fixes an issue where the headers were being
installed twice.
This clean up should also make future modifications easier, like
adding a cmake option to install header files into a custom resource
directory.
Reviewers: chandlerc, smeenai, mgorny, beanz, phosek
Reviewed By: smeenai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58537
llvm-svn: 355253
Summary:
To prevent the instability of bulk-memory in the wasm backend from
blocking separate pthread testing, temporarily remove the logic that
adds -mbulk-memory in the presence of -pthread. Since browsers will
ship bulk memory before or alongside threads, this change will be
reverted as soon as bulk memory has stabilized in the backend.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58854
llvm-svn: 355248
enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks.
This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare".
This is a recommit of r354873 but with a fix for unqualified lookup error in lldb cmake build bot.
Fixes: https://llvm.org/PR39425
Differential Revision: https://reviews.llvm.org/D57914
llvm-svn: 355190
Previously revisions commited non-clang-formatted changes to the Format library, this means submitting any revision e.g. {D55170} can cause additional whitespace changes to potentially be included in a revision.
Commit a non functional change using latest build Windows clang-format r351376 with no other changes, to remove these differences
All FormatTests
pass [==========] 652 tests from 20 test cases ran.
llvm-svn: 355182
When emitting initializers for local structures for code built with
-ftrivial-auto-var-init, replace constant structures with sequences of
stores.
This appears to greatly help removing dead initialization stores to those
locals that are later overwritten by other data.
This also removes a lot of .rodata constants (see PR40605), replacing most
of them with immediate values (for Linux kernel the .rodata size is
reduced by ~1.9%)
llvm-svn: 355181
declaring an unavailable method in the subclass's extension that
overrides the designated initializer in the base class.
r243676 made changes to allow declaring the unavailable method in the
subclass interface to silence the warning. This commit additionally
allows declaring the unavailable method in the class extension.
rdar://problem/42731306
llvm-svn: 355175
When we have an annotated local variable after a function returns, we
generate IR that fails verification with the error
> Instruction referencing instruction not embedded in a basic block!
And it means that bitcast referencing alloca doesn't have a parent basic
block.
Fix by checking if we are at an unreachable point and skip emitting
annotations. This approach is similar to the way we emit variable
initializer and debug info.
rdar://problem/46200420
Reviewers: rjmccall
Reviewed By: rjmccall
Subscribers: aprantl, jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D58147
llvm-svn: 355166
Summary:
clang-formatting wants to add spaces around items in square braces, e.g. [1, 2] -> [ 1, 2 ]. Based on a quick check [1], it seems like most cases are using the [1, 2] format, so make that the consistent one.
[1] in llvm `.td` files, the regex `\[[^ ]` (bracket followed by not-a-space) shows up ~400 times, but `\[\s[^ ]` (bracket followed by one space and one not-a-space) shows up ~40 times => ~90% uses this format.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55964
llvm-svn: 355158
Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they differ from C++. This change adds LanguageKind as an input to getLLVMStyle so that we can start doing that.
See D55964 as a motivation for this, where we want Tablegen to be formatted differently than C++.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: jdoerfert, MyDeveloperDay, kristina, cfe-commits, arphaman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56943
llvm-svn: 355123
Summary:
In the clang UI, replaces -mthread-model posix with -matomics as the
source of truth on threading. In the backend, replaces
-thread-model=posix with the atomics target feature, which is now
collected on the WebAssemblyTargetMachine along with all other used
features. These collected features will also be used to emit the
target features section in the future.
The default configuration for the backend is thread-model=posix and no
atomics, which was previously an invalid configuration. This change
makes the default valid because the thread model is ignored.
A side effect of this change is that objects are never emitted with
passive segments. It will instead be up to the linker to decide
whether sections should be active or passive based on whether atomics
are used in the final link.
Reviewers: aheejin, sbc100, dschuff
Subscribers: mehdi_amini, jgravelle-google, hiraditya, sunfish, steven_wu, dexonsmith, rupprecht, jfb, jdoerfert, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D58742
llvm-svn: 355112
Remove comments and tests about passing -mcode-object-v3 to driver since it does
not work. Other -m options are OK.
Also put back -mattr=-code-object-v3 since HIP is still not ready for code object
v3.
Differential Revision: https://reviews.llvm.org/D57977
llvm-svn: 355106
Summary:
If CPP dialects are different then return with error.
Consider this STL code:
template<typename _Alloc>
struct __alloc_traits
#if __cplusplus >= 201103L
: std::allocator_traits<_Alloc>
#endif
{ // ...
};
This class template would create ODR errors during merging the two units,
since in one translation unit the class template has a base class, however
in the other unit it has none.
Reviewers: xazax.hun, a_sidorin, r.stahl
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57906
llvm-svn: 355096
I think the author of the function assumed that `GetInsertBlock()`
wouldn't change from where `atomicPHI` was created, but this isn't
true when `-fsanitize=unsigned-integer-overflow` is enabled (we
generate an overflow/continuation label). Fix by keeping track of the
block we want to return to to complete the cmpxchg loop.
rdar://48406558
Differential revision: https://reviews.llvm.org/D58744
llvm-svn: 355054
Basic data structures for index
Tests are missing from this patch - will be covered properly by tests for the whole feature.
I'm just trying to split into smaller patches to make it easier for reviewers.
Differential Revision: https://reviews.llvm.org/D58478
llvm-svn: 355035
initializes a local auto variable or is assigned to a local auto
variable that is declared in the scope that introduced the block
literal.
rdar://problem/13289333
https://reviews.llvm.org/D58514
llvm-svn: 355012
Frameworks filesystem representations:
UIKit.framework/Headers/%header%
Framework import format:
#import <UIKit/%header%>
Thus the completion code must map the input format of <UIKit/> to
the path of UIKit.framework/Headers as well as strip the
".framework" suffix when auto-completing the framework name.
llvm-svn: 355008
Summary:
Even if the content cache has a directory and filename, it may be a virtual file.
The old code returned with error in this case, but it is worth to try to handle
the file as it were a memory buffer.
Reviewers: a.sidorin, shafik, martong, a_sidorin
Reviewed By: shafik
Subscribers: efriedma, rnkovacs, cfe-commits, dkrupp, martong, Szelethus, gamesh411
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57590
llvm-svn: 355000
Add .stub to kernel stub function name so that it is different from kernel
name in device code. This is necessary to let debugger find correct symbol
for kernel.
Differential Revision: https://reviews.llvm.org/D58518
llvm-svn: 354948
Currently the symbol for MSPropertyDecl has kind `SymbolKind::Unknown`
which can trip up various indexing tools.
rdar://problem/46764224
Reviewers: akyrtzi, benlangmuir, jkorous
Reviewed By: jkorous
Subscribers: dexonsmith, cfe-commits, jkorous, jdoerfert, arphaman
Differential Revision: https://reviews.llvm.org/D57628
llvm-svn: 354942
MSVC header files using vectorcall to differentiate overloaded functions, which
causes failure for AMDGPU target. This is because clang does not check function
calling convention based on function target.
This patch checks calling convention using the proper target info.
Differential Revision: https://reviews.llvm.org/D57716
llvm-svn: 354929
statements.
If the assembler instruction is not generated and the delayed diagnostic
is emitted, we may end up with extra warning message for variables used
in the asm statement. Since the asm statement is not built, the
variables may be left non-referenced and it may produce a warning about
a use of the non-initialized variables.
llvm-svn: 354928
Summary:
The MS C++ ABI has no constructor variants, but it has destructor
variants, so we should move the deleting destructor variant check
outside the check for "does the ABI have constructor variants".
Fixes PR37561, so basic code coverage works on Windows with C++.
Reviewers: vsk
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58691
llvm-svn: 354924
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
This was originally reviewed and approved in
https://reviews.llvm.org/D58292 and submitted as r354832. It was
reverted in r354839 due to failures on the Windows CI builds.
This version fixes the test failures on Windows, which were caused by
differences in template expansion between versions of clang on different
OSes. The version of clang built with MSVC and running on Windows never
expands the template in the C++ test in ImportExpr.ImportChooseExpr in
clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for
the empty arguments and -fms-compatibility.
So, this version of the patch drops the C++ test for
__builtin_choose_expr, since that version was written to catch
regressions of the logic for isConditionTrue() in the AST import code
for ChooseExpr, and those regressions are also caught by
ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on
Windows.
Reviewers: shafik, a_sidorin, martong, aaron.ballman, rnk, a.sidorin
Subscribers: cfe-commits, jdoerfert, rnkovacs, aaron.ballman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58663
llvm-svn: 354916
This patch enables the following
1) AMD family 17h "znver2" tune flag (-march, -mcpu).
2) ISAs that are enabled for "znver2" architecture.
3) For the time being, it uses the znver1 scheduler model.
4) Tests are updated.
5) This patch is the clang counterpart to D58343
Reviewers: craig.topper
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58344
llvm-svn: 354899
A recent change caused assertion in CodeGenFunction::EmitBlockCallExpr when a block is called.
There is code
Func = CGM.getOpenCLRuntime().getInvokeFunction(E->getCallee());
getCalleeDecl calls Expr::getReferencedDeclOfCallee, which does not handle
BlockExpr and returns nullptr, which causes isa to assert.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D58658
llvm-svn: 354893
Summary:
Add indexing of UsingDecl itself.
Also enable generation of USRs for UsingDecls, using the qualified name of the
decl.
Reviewers: ilya-biryukov, akyrtzi
Subscribers: arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58340
llvm-svn: 354878
enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks.
This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare".
Fixes: https://llvm.org/PR39425
Differential Revision: https://reviews.llvm.org/D57914
llvm-svn: 354873
Summary:
See the added test for some new cases.
This change also removes special code completion calls inside the
ParseExpressionList function now that we properly propagate expected
type to the function responsible for parsing elements of the expression list
(ParseAssignmentExpression).
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: xbolva00, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58541
llvm-svn: 354864
When generating initializers for local structures in the
-ftrivial-auto-var-init mode, explicitly wipe the padding bytes with
either 0x00 or 0xAA.
This will allow us to automatically handle the padding when splitting
the initialization stores (see https://reviews.llvm.org/D57898).
Reviewed at https://reviews.llvm.org/D58188
llvm-svn: 354861
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
Reviewers: shafik, a_sidorin, martong, aaron.ballman
Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58292
llvm-svn: 354832
ObjCMessageExpr::getInstanceReceiver returns nullptr if the receiver
is 'super'. Make this check more strict, since we don't care about
messages to super here.
rdar://48247290
llvm-svn: 354826
This patch implements the parsing and sema support for the OpenMP
'from'-clause with potential user-defined mappers attached.
User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause
can have an explicit or implicit associated mapper, which instructs the
compiler to generate and use customized mapping functions. An example is
shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device
Contributed-by: Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D58638
llvm-svn: 354817
#define f(y) x
#define x f(x)
int main() { x; }
This example results a compilation error since "x" in the first line was not
defined earlier. However, the macro expression printer goes to an infinite
recursion on this example.
Patch by Tibor Brunner!
Differential Revision: https://reviews.llvm.org/D57892
llvm-svn: 354806
Summary:
Fixes a data race and makes it possible to run clang-based tools in
multithreaded environment with TSan.
Reviewers: ilya-biryukov, riccibruno
Reviewed By: riccibruno
Subscribers: riccibruno, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58612
llvm-svn: 354795
This patch implements the parsing and sema support for OpenMP to clause
with potential user-defined mappers attached. User defined mapper is a
new feature in OpenMP 5.0. A to/from clause can have an explicit or
implicit associated mapper, which instructs the compiler to generate and
use customized mapping functions. An example is shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device
Contributed-by: <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D58523
llvm-svn: 354698
Summary:
In r353970, I enabled those features in C++11 and above. To be strictly
conforming, those features should only be enabled in C++17 and above.
Reviewers: jfb, eli.friedman
Subscribers: jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58289
llvm-svn: 354691
SVN r339438 added support to deduplicate the helpers by using a consistent
naming scheme and using LinkOnceODR semantics. This works on ELF by means of
weak linking semantics, and entirely does not work on PE/COFF where you end up
with multiply defined strong symbols, which is a strong error on PE/COFF.
Assign the functions a COMDAT group so that they can be uniqued by the linker.
This fixes the use of blocks in CoreFoundation on Windows.
llvm-svn: 354678
Adapted targetDiag for the CUDA and used for the delayed diagnostics in
asm constructs. Works for both host and device compilation sides.
Differential Revision: https://reviews.llvm.org/D58463
llvm-svn: 354671
Add more "consuming" functions. For now only vm_deallocate() was supported.
Add a non-zero value that isn't an error; this value is -305 ("MIG_NO_REPLY")
and it's fine to deallocate data when you are returning this error.
Make sure that the mig_server_routine annotation is inherited.
rdar://problem/35380337
Differential Revision: https://reviews.llvm.org/D58397
llvm-svn: 354643
When a MIG server routine argument is released in an automatic destructor,
the Static Analyzer thinks that this happens after the return statement, and so
the violation of the MIG convention doesn't happen.
Of course, it doesn't quite work that way, so this is a false negative.
Add a hack that makes the checker double-check at the end of function
that no argument was released when the routine fails with an error.
rdar://problem/35380337
Differential Revision: https://reviews.llvm.org/D58392
llvm-svn: 354642
Add a BugReporterVisitor for highlighting the events of deallocating a
parameter. All such events are relevant to the emitted report (as long as the
report is indeed emitted), so all of them will get highlighted.
Add a trackExpressionValue visitor for highlighting where does the error return
code come from.
Do not add a trackExpressionValue visitor for highlighting how the deallocated
argument(s) was(were) copied around. This still remains to be implemented.
rdar://problem/35380337
Differential Revision: https://reviews.llvm.org/D58368
llvm-svn: 354641
r354530 has added a new function/block/message attribute "mig_server_routine"
that attracts compiler's attention to functions that need to follow the MIG
server routine convention with respect to deallocating out-of-line data that
was passed to them as an argument.
Teach the checker to identify MIG routines by looking at this attribute,
rather than by making heuristic-based guesses.
rdar://problem/35380337
Differential Revision: https://reviews.llvm.org/58366
llvm-svn: 354638
This checker detects use-after-free bugs in (various forks of) the Mach kernel
that are caused by errors in MIG server routines - functions called remotely by
MIG clients. The MIG convention forces the server to only deallocate objects
it receives from the client when the routine is executed successfully.
Otherwise, if the server routine exits with an error, the client assumes that
it needs to deallocate the out-of-line data it passed to the server manually.
This means that deallocating such data within the MIG routine and then returning
a non-zero error code is always a dangerous use-after-free bug.
rdar://problem/35380337
Differential Revision: https://reviews.llvm.org/D57558
llvm-svn: 354635
This patch implements fixed point comparisons with other fixed point types and
integers. This also provides constant expression evaluation for them.
Differential Revision: https://reviews.llvm.org/D57219
llvm-svn: 354621
Add .stub to kernel stub function name so that it is different from kernel
name in device code. This is necessary to let debugger find correct symbol
for kernel
Differential Revision: https://reviews.llvm.org/D58518
llvm-svn: 354615
Summary:
- If a string literal is reused directly, need to add necessary address
space casting if the target requires that.
Reviewers: yaxunl
Subscribers: jvesely, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58509
llvm-svn: 354610
Summary:
Adapted targetDiag for the CUDA and used for the delayed diagnostics in
asm constructs. Works for both host and device compilation sides.
Reviewers: tra, jlebar
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58463
llvm-svn: 354593
Summary:
This will allow completion consumers to guess the specified scope by
putting together scopes in the context with the specified scope (e.g. when the
specified namespace is not imported yet).
Reviewers: ilya-biryukov
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58446
llvm-svn: 354570
Summary:
Emit direct call of block invoke functions when possible, i.e. in case the
block is not passed as a function argument.
Also doing some refactoring of `CodeGenFunction::EmitBlockCallExpr()`
Reviewers: Anastasia, yaxunl, svenvh
Reviewed By: Anastasia
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58388
llvm-svn: 354568
Summary:
clangd uses indexing api to provide references and it was not possible
to perform symbol information for template parameters. This patch enables
visiting of TemplateTypeParmTypeLocs.
Reviewers: ilya-biryukov, akyrtzi
Subscribers: javed.absar, kristof.beyls, ioeric, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58293
llvm-svn: 354560
The new __attribute__ ((mig_server_routine)) is going to be used for annotating
Mach Interface Generator (MIG) callback functions as such, so that additional
static analysis could be applied to their implementations. It can also be
applied to regular functions behavior of which is supposed to be identical to
that of a MIG server routine.
Differential Revision: https://reviews.llvm.org/D58365
llvm-svn: 354530
r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE
instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more
directly and can be overridden by a user. Make the corresponding change
in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should
be available for both standalone and integrated builds.
Differential Revision: https://reviews.llvm.org/D58284
llvm-svn: 354525
We unconditionally predefine these macros. However, they may be used to
determine if the type is supported. In that case, there are unnecessary
failures to compile the code.
This is the proposed fix for https://bugs.llvm.org/show_bug.cgi?id=40559
Differential revision: https://reviews.llvm.org/D57577
llvm-svn: 354512
Summary: This change mimics GCC's support for the "-static-pie" argument.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58307
llvm-svn: 354502
Summary:
Added the ability to emit target-specific builtin assembler error
messages only in case if the function is really is going to be emitted
for the device.
Reviewers: rjmccall
Subscribers: guansong, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58243
llvm-svn: 354486
A faster way to reduce the values in teams reductions was found, the
codegen is updated to use this faster algorithm and new runtime functions.
llvm-svn: 354479
Summary:
Currently clang-format would always emit a replacement for a block of Java imports even if it is correctly formatted:
```
% cat /tmp/Aggregator.java
import X;
% clang-format /tmp/Aggregator.java
import X;
% clang-format -output-replacements-xml /tmp/Aggregator.java
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='9'>import X;</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case. Note that
there is logic to not emit replacements in this case for C++.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58436
llvm-svn: 354452
This patch implements the parsing and sema support for OpenMP map
clauses with potential user-defined mapper attached. User defined mapper
is a new feature in OpenMP 5.0. A map clause can have an explicit or
implicit associated mapper, which instructs the compiler to generate
extra data mapping. An example is shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss
Contributed-by: Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D58074
llvm-svn: 354347
Summary:
For some reason OpenCL blocks in LLVM IR are represented as function pointers.
These pointers do not point to any real function and never get called. Actually
they point to some structure, which in turn contains pointer to the real block
invoke function.
This patch changes represntation of OpenCL blocks in LLVM IR from function
pointers to pointers to `%struct.__block_literal_generic`.
Such representation allows to avoid unnecessary bitcasts and simplifies
further processing (e.g. translation to SPIR-V ) of the module for targets
which do not support function pointers.
Patch by: Alexey Sotkin.
Reviewers: Anastasia, yaxunl, svenvh
Reviewed By: Anastasia
Subscribers: alexbatashev, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58277
llvm-svn: 354337
This adds ACLE-defined macros to test for code being compiled in the ROPI and
RWPI position-independence modes.
Differential revision: https://reviews.llvm.org/D23610
llvm-svn: 354265
Summary:
Indexing context was skipping explicit template instantiations as well.
This patch makes sure it only skips implicit ones.
Subscribers: arphaman, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58189
llvm-svn: 354262
(Originally commited in r354215 and reverted in r354216 because of a
missed failing clang-tidy test (fix in r354228))
Now that the implementation of all of the Expr::Ignore* is in Expr.cpp
we can try to remove some duplication. Do this by separating the logic
of the Expr::Ignore* from the iterative loop.
This is NFC, except for one change: IgnoreParenImpCasts now skips,
among other things, everything that IgnoreImpCasts skips. This means
FullExpr are now skipped by IgnoreParenImpCasts. This was likely an
oversight when FullExpr was added to the nodes skipped by IgnoreImpCasts.
Differential Revision: https://reviews.llvm.org/D57267
Reviewed By: aaron.ballman (with comments from void and rnk)
llvm-svn: 354232
Now that the implementation of all of the Expr::Ignore* is in Expr.cpp
we can try to remove some duplication. Do this by separating the logic of
the Expr::Ignore* from the iterative loop.
This is NFC, except for one change: IgnoreParenImpCasts now skips, among
other things, everything that IgnoreImpCasts skips. This means FullExpr
are now skipped by IgnoreParenImpCasts. This was likely an oversight when
FullExpr was added to the nodes skipped by IgnoreImpCasts.
Differential Revision: https://reviews.llvm.org/D57267
Reviewed By: aaron.ballman (with comments from void and rnk)
llvm-svn: 354215
This can be used to disable libc linking. This flag is supported by
GCC since version 9 as well as some Clang target toolchains.
Differential Revision: https://reviews.llvm.org/D58326
llvm-svn: 354210
This can be used to disable libc linking. This flag is supported by
GCC since version 9 as well as some Clang target toolchains. This
change also includes tests for all -no* flags which previously weren't
covered.
Differential Revision: https://reviews.llvm.org/D58325
llvm-svn: 354208
...instead of just comparing rank. Also, fix a bad warning about
_Float16, since its declared out of order in BuiltinTypes.def,
meaning comparing rank using BuiltinType::getKind() is incorrect.
Differential revision: https://reviews.llvm.org/D58254
llvm-svn: 354190
Fixes the warning about incompatible pointer types on assigning to a
subclass of type argument an expression of type `__kindof TypeParam`.
We already have a mechanism in `ASTContext::canAssignObjCInterfaces`
that handles `ObjCObjectType` with `__kindof`. But it wasn't triggered
because during type substitution `__kindof TypeParam` was represented as
`AttributedType` with attribute `ObjCKindOf` and equivalent type
`TypeArg`. For assignment type checking we use canonical types so
attributed type was desugared and the attribute was ignored.
The fix is in checking transformed `AttributedType` and pushing
`__kindof` down into `ObjCObjectType` when necessary.
rdar://problem/38514910
Reviewers: ahatanak, erik.pilkington, doug.gregor
Reviewed By: doug.gregor
Subscribers: jkorous, dexonsmith, manmanren, jordan_rose, doug.gregor, cfe-commits
Differential Revision: https://reviews.llvm.org/D57076
llvm-svn: 354189
Trailing comments are not always aligned properly when UseTab is set to Always.
Consider:
int a; // x
int bbbbbbbb; // x
With .clang-format:
---
Language: Cpp
BasedOnStyle: LLVM
UseTab: Always
...
The trailing comments of this code block should be aligned, but aren't
To align the first trailing comment it needs to insert 8 spaces. This should be
one tab plus six spaces. It skips the logic of the first partial tab in
FirstTabWidth (=2) + Style.TabWidth (=8) <= Spaces (=8) and only inserts one
tab. Proposed fix and test is attached.
Patch by Hylke Kleve.
Differential revision: https://reviews.llvm.org/D57655
llvm-svn: 354183
Switch to the inheritance-based visitor from the lambda-based visitor to
allow both preorder and postorder customizations during type
transformation. NFC intended.
Reviewers: ahatanak, erik.pilkington
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D57075
llvm-svn: 354180
When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
This reinstates r354091, which was previously reverted in r354097
because it exposed bugs in lldb and compiler-rt. Those bugs were fixed
in r354173 and r354174 respectively.
llvm-svn: 354176
Summary:
There are an insignificant number of ARM Android devices that don't
support NEON. Default to using NEON since that will improve
performance on the majority of devices. Users that need to target
non-NEON devices can still explicitly disable NEON.
Reviewers: srhines, pirama, kristof.beyls
Reviewed By: pirama
Subscribers: efriedma, javed.absar, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58153
llvm-svn: 354166
`QualType::substObjCTypeArgs` doesn't go past non-canonical types and as
the result misses some of the substitutions like `ObjCTypeParamType`.
Update `SimpleTransformVisitor` to traverse past the type sugar.
Reviewers: ahatanak, erik.pilkington
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D57270
llvm-svn: 354164
Summary:
The main effect is that clang now accepts the following conforming C11
code with MSVC headers:
#include <assert.h>
static_assert(1, "true");
This is a non-conforming extension (the keyword is outside the
implementer's namespace), so it is placed under -fms-compatibility
instead of -fms-extensions like most MSVC-specific keyword extensions.
Normally, in C11, the compiler is supposed to provide the _Static_assert
keyword, and assert.h should define static_assert to _Static_assert.
However, that is not what MSVC does, and MSVC doesn't even provide
_Static_assert.
This also has the less important side effect of enabling static_assert
in C++98 mode with -fms-compatibility. It's exceptionally difficult to
use modern MSVC headers without C++14 even, so this is relatively
unimportant.
Fixes PR26672
Patch by Andrey Bokhanko!
Reviewers: rsmith, thakis
Subscribers: cfe-commits, STL_MSFT
Differential Revision: https://reviews.llvm.org/D17444
llvm-svn: 354162
Summary:
Blocks that capture themselves (and escape) after initialization currently codegen wrong because this:
bool capturedByInit =
Init && emission.IsEscapingByRef && isCapturedBy(D, Init);
Address Loc =
capturedByInit ? emission.Addr : emission.getObjectAddress(*this);
Already adjusts Loc from thr alloca to a GEP. This code:
if (emission.IsEscapingByRef)
Loc = emitBlockByrefAddress(Loc, &D, /*follow=*/false);
Was trying to do the same adjustment, and a GEP on a GEP (returning an int) triggers an assertion.
<rdar://problem/47943027>
Reviewers: ahatanak
Subscribers: jkorous, dexonsmith, cfe-commits, rjmccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58218
llvm-svn: 354147
Summary:
Previously only the fields were imported. Now every Decl is imported.
This way the destructor decl is not missing after import.
Patch by balazske (Balázs Kéri)
Reviewers: a.sidorin, shafik
Reviewed By: shafik
Subscribers: balazske, cfe-commits, Szelethus, martong, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57740
llvm-svn: 354120
Summary:
The idea is that the code here isn't written, so doesn't indicate a bug.
Similar to code expanded from macros.
This means the warning no longer fires on this code:
for (auto C : collection) {
process(C);
return;
}
handleEmptyCollection();
Unclear whether this is more often a bug or not in practice, I think it's a
reasonable idiom in some cases.
Either way, if we want to warn on "loop that doesn't loop", I think it should be
a separate warning, and catch `while(1) break;`
Reviewers: ilya-biryukov, ioeric
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58134
llvm-svn: 354102
When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
llvm-svn: 354091
expression is a discarded-value expression.
Summary:
We used to get this wrong in three ways:
1) During parsing, an expression-statement followed by the }) ending a
statement expression was always treated as producing the value of the
statement expression. That's wrong for ({ if (1) expr; })
2) During template instantiation, various kinds of statement (most
statements not appearing directly in a compound-statement) were not
treated as discarded-value expressions, resulting in missing volatile
loads (etc).
3) In all contexts, an expression-statement with attributes was not
treated as producing the value of the statement expression, eg
({ [[attr]] expr; }).
Also fix incorrect enforcement of OpenMP rule that directives can "only
be placed in the program at a position where ignoring or deleting the
directive would result in a program with correct syntax". In particular,
a label (be it goto, case, or default) should not affect whether
directives are permitted.
Reviewers: aaron.ballman, rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57984
llvm-svn: 354090
Summary:
instrprof-darwin-exports.c test fails on Darwin due to r354064.
Updated clang list of exported symbols to fix the issue.
Reviewers: vsk
Reviewed By: vsk
Subscribers: davidxl, efriedma
Differential Revision: https://reviews.llvm.org/D58259
llvm-svn: 354089
Instead of letting a program fail at runtime, emit an error during
compilation.
rdar://problem/12206955
Reviewers: dexonsmith, bob.wilson, steven_wu
Reviewed By: steven_wu
Subscribers: jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D57991
llvm-svn: 354084
The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s in ParsedAST::Includes in clangd and this caused the problem.
This fixes an internal test failure in clangd - ClangdTests.GoToInclude.All
rdar://47536127
Differential Revision: https://reviews.llvm.org/D58213
llvm-svn: 354075
We were warning on valid ObjC property reference exprs, and passing
in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
worded diagnostic).
rdar://47644670
Differential revision: https://reviews.llvm.org/D58145
llvm-svn: 354074
This provides a code size win on the caller side, since the init
message send is done in the runtime function.
rdar://44987038
Differential revision: https://reviews.llvm.org/D57936
llvm-svn: 354056
D54902 removed CallExpr::setNumArgs in preparation of tail-allocating the
arguments of CallExpr. It did this by allocating storage for
max(number of arguments, number of parameters in the prototype). The
temporarily nulled arguments however causes issues in BuildResolvedCallExpr
when typo correction is done just after the creation of the call expression.
This was unfortunately missed by the tests /:
To fix this, delay setting the number of arguments to
max(number of arguments, number of parameters in the prototype) until we are
ready for it. It would be nice to have this encapsulated in CallExpr but this
is the best I can come up with under the constraint that we cannot add
anything the CallExpr.
Fixes PR40286.
Differential Revision: https://reviews.llvm.org/D57948
Reviewed By: aaron.ballman
llvm-svn: 354035
Summary:
During import of a global variable with external visibility the lookup
will find variables (with the same name) but with static visibility.
Clearly, we cannot put them into the same redecl chain. The same is
true in case of functions. In this fix we filter the lookup results and
consider only those which have the same visibility as the decl we
currently import.
We consider two decls in two anonymous namsepaces to have the same
visibility only if they are imported from the very same translation
unit.
Reviewers: a_sidorin, shafik, a.sidorin
Reviewed By: shafik
Subscribers: jdoerfert, balazske, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57232
llvm-svn: 354027
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.
Also see the discussion in https://reviews.llvm.org/D56593.
Reviewers: jyknight
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58120
llvm-svn: 354023
__hipRegisterFunction and __hipRegisterVar need to accept device side kernel and variable names
so that HIP runtime can associate kernel stub functions in host code with kernel symbols in fat binaries,
and associate shadow variables in host code with device variables in fat binaries.
Currently, clang assumes kernel functions and device variables have the same name as the kernel
stub functions and shadow variables. However, when host is compiled in windows with MSVC C++
ABI and device is compiled with Itanium C++ ABI (e.g. AMDGPU), kernels and device symbols in fat
binary are mangled differently than host.
This patch gets the device side kernel and variable name by mangling them in the mangle context
of aux target.
Differential Revision: https://reviews.llvm.org/D58163
llvm-svn: 354004
This is the second attempt to port ASan to new PM after D52739. This takes the
initialization requried by ASan from the Module by moving it into a separate
class with it's own analysis that the new PM ASan can use.
Changes:
- Split AddressSanitizer into 2 passes: 1 for the instrumentation on the
function, and 1 for the pass itself which creates an instance of the first
during it's run. The same is done for AddressSanitizerModule.
- Add new PM AddressSanitizer and AddressSanitizerModule.
- Add legacy and new PM analyses for reading data needed to initialize ASan with.
- Removed DominatorTree dependency from ASan since it was unused.
- Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the
new PM analysis holds these 2 classes and will need to expose them.
Differential Revision: https://reviews.llvm.org/D56470
llvm-svn: 353985
Summary:
When this was rewritten in D43737, the logic changed to better explore infinite loops. The check for a reachable exit block was deleted which accidentally introduced false positives in case the exit node was unreachable.
We were testing for cases like this, but @steven_wu provided an additional test case that I've included in the regression tests for this patch.
Reviewers: steven_wu, rtrieu
Reviewed By: steven_wu, rtrieu
Subscribers: cfe-commits, steven_wu
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58122
llvm-svn: 353984
This fixes a regression that was caused by r335084, which reversed
the order that attributes are applied. objc_method_family can change
whether a method is an init method, so the order that these
attributes are applied matters. The commit fixes this by delaying the
init check until after all attributes have been applied.
rdar://47829358
Differential revision: https://reviews.llvm.org/D58152
llvm-svn: 353976
Summary:
The predefined macro `_ARCH_PWR6X` is associated with GCC's
`-mcpu=power6x` option, which enables generation of P6 "raw mode"
instructions such as `mftgpr`.
Later POWER processors build upon the "architected mode", not the raw
one. `_ARCH_PWR6X` should not be defined for these later processors.
Fixes PR#40236.
Reviewers: echristo, hfinkel, kbarton, nemanjai, wschmidt
Reviewed By: hfinkel
Subscribers: jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58128
llvm-svn: 353975
Summary:
Previously, those #defines were only provided in C or when GNU extensions were
enabled. We need those #defines in C++11 and above, too.
Reviewers: jfb, eli.friedman
Subscribers: jkorous, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58149
llvm-svn: 353970
Argument evaluation order is different between gcc and clang, so pull out
the Builder calls to make the generated IR independent of the host compiler's
argument evaluation order. Thanks to rnk for reminding me of this clang/gcc
difference.
llvm-svn: 353969
The rationale of this change is to fix _Unwind_Word / _Unwind_SWord
definitions for MIPS N32 ABI. This ABI uses 32-bit pointers,
but _Unwind_Word and _Unwind_SWord types are eight bytes long.
# The __attribute__((__mode__(__unwind_word__))) is added to the type
definitions. It makes them equal to the corresponding definitions used
by GCC and allows to override types using `getUnwindWordWidth` function.
# The `getUnwindWordWidth` virtual function override in the `MipsTargetInfo`
class and provides correct type size values.
Differential revision: https://reviews.llvm.org/D58165
llvm-svn: 353965
This is a follow up to D48580 and D48581 which allows reserving
arbitrary general purpose registers with the exception of registers
with special purpose (X8, X16-X18, X29, X30) and registers used by LLVM
(X0, X19). This change also generalizes some of the existing logic to
rely entirely on values generated from tablegen.
Differential Revision: https://reviews.llvm.org/D56305
llvm-svn: 353957
Allow the compile options for -m such as -mxnack/-mno-xnack, -msram-ecc/-mno-sram-ecc, -mcode-object-v3/-mno-code-object-v3 to propagate into LLC args. Fix an issue where -mattr was pushed even when it was empty.
Also add lit tests to verify features are properly passed.
Differential Revision: https://reviews.llvm.org/D57977
Reviewers: yaxunl, kzhuravl
llvm-svn: 353952
FindLastStoreBRVisitor tries to find the first node in the exploded graph where
the current value was assigned to a region. This node is called the "store
site". It is identified by a pair of Pred and Succ nodes where Succ already has
the binding for the value while Pred does not have it. However the visitor
mistakenly identifies a node pair as the store site where the value is a
`LazyCompoundVal` and `Pred` does not have a store yet but `Succ` has it. In
this case the `LazyCompoundVal` is different in the `Pred` node because it also
contains the store which is different in the two nodes. This error may lead to
crashes (a declaration is cast to a parameter declaration without check) or
misleading bug path notes.
In this patch we fix this problem by checking for unequal `LazyCompoundVals`: if
their region is equal, and their store is the same as the store of their nodes
we consider them as equal when looking for the "store site". This is an
approximation because we do not check for differences of the subvalues
(structure members or array elements) in the stores.
Differential Revision: https://reviews.llvm.org/D58067
llvm-svn: 353943
Profiling still doesn't seem to work properly, but this at least
hooks up the library and eases completing whatever is missing.
Differential Revision: https://reviews.llvm.org/D58107
llvm-svn: 353917
Allow the compile options for -m such as -mxnack/-mno-xnack, -msram-ecc/-mno-sram-ecc, -mcode-object-v3/-mno-code-object-v3 to propagate into LLC args.
Also add lit tests to verify features are properly passed.
Differential Revision: https://reviews.llvm.org/D57977
Reviewers: yaxunl, kzhuravl
llvm-svn: 353880
Add secondary triple to existing SSE test for it. I audited other uses
of __attribute__((__packed__)) in the intrinsic headers, and this seemed
to be the only missing one.
llvm-svn: 353878
Relocatable code generation is meaningless on MSP430, as the platform is too small to use shared libraries.
Patch by Dmitry Mikushev!
Differential Revision: https://reviews.llvm.org/D56927
llvm-svn: 353877
This allows the global visibility controls to be restrictive while still
populating the dynamic symbol table where required.
Differential Revision: https://reviews.llvm.org/D56871
llvm-svn: 353870
Summary: See the added test for a repro.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58111
llvm-svn: 353840
This attribute applies to declarations of C stdlib functions
(sprintf, memcpy...) that have known fortified variants
(__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit
calls to the fortified variant functions instead of calls to the
defaults.
In GCC, this is done by adding gnu_inline-style wrapper functions,
but that doesn't work for us for variadic functions because we don't
support __builtin_va_arg_pack (and have no intention to).
This attribute takes two arguments, the first is 'type' argument
passed through to __builtin_object_size, and the second is a flag
argument that gets passed through to the variadic checking variants.
rdar://47905754
Differential revision: https://reviews.llvm.org/D57918
llvm-svn: 353765
Basically the same issue as string init, except it didn't really have
any visible consequences before I removed the implicit lvalue-to-rvalue
conversion from CodeGen.
While I'm here, a couple minor drive-by cleanups: IgnoreParens never
returns a ConstantExpr, and there was a potential crash with string init
involving a ChooseExpr.
The analyzer test change maybe indicates we could simplify the analyzer
code a little with this fix? Apparently a hack was added to support
lvalues in initializers in r315750, but I'm not really familiar with the
relevant code.
Fixes regression reported in the kernel build at
https://bugs.llvm.org/show_bug.cgi?id=40430#c6 .
Differential Revision: https://reviews.llvm.org/D58069
llvm-svn: 353762
Summary:
There have been three options related to threads and users had to set
all three of them separately to get the correct compilation results.
This makes sure the relationship between the options makes sense and
sets necessary options for users if only part of the necessary options
are specified. This does:
- Remove `-matomics`; this option alone does not enable anything, so
removed it to not confuse users.
- `-mthread-model posix` sets `-target-feature +atomics`
- `-pthread` sets both `-target-feature +atomics` and
`-mthread-model posix`
Also errors out when explicitly given options don't match, such as
`-pthread` is given with `-mthread-model single`.
Reviewers: dschuff, sbc100, tlively, sunfish
Subscribers: jgravelle-google, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57874
llvm-svn: 353761
We must only set the construction vtable visibility after we create the
vtable initializer, otherwise the global value will be treated as
declaration rather than definition and the visibility won't be set.
Differential Revision: https://reviews.llvm.org/D58010
llvm-svn: 353742
_byteswap_* functions are are implemented in below file as normal function
from libucrt.lib and declared in stdlib.h. Define them in intrin.h triggers
lld error "conflicting comdat type" and "duplicate symbols" which was just
added to LLD (https://reviews.llvm.org/D57324).
C:\Program Files (x86)\Windows Kits\10\Source\10.0.17763.0\ucrt\stdlib\byteswap.cpp
Differential Revision: https://reviews.llvm.org/D57915
llvm-svn: 353740
There are certain unsafe or deprecated (since C11) buffer handling
functions which should be avoided in safety critical code. They
could cause buffer overflows. A new checker,
'security.insecureAPI.DeprecatedOrUnsafeBufferHandling' warns for
every occurrence of such functions (unsafe or deprecated printf,
scanf family, and other buffer handling functions, which now have
a secure variant).
Patch by Dániel Kolozsvári!
Differential Revision: https://reviews.llvm.org/D35068
llvm-svn: 353698
Summary:
Parameters in declarations are useful for clangd, so that we can
provide symbol information for them as well. It also helps clangd to be
consistent whether a function's definition is accessible or not.
Reviewers: hokein, akyrtzi
Subscribers: ilya-biryukov, ioeric, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57949
llvm-svn: 353695
The various EltSize, Offset, DataLayout, and StructLayout arguments
are all computable from the Address's element type and the DataLayout
which the CGBuilder already has access to.
After having previously asserted that the computed values are the same
as those passed in, now remove the redundant arguments from
CGBuilder's Create*GEP functions.
Differential Revision: https://reviews.llvm.org/D57767
llvm-svn: 353629
oth strlcat and strlcpy cut off their safe bound for the argument value
at sizeof(destination). There's no need to subtract 1 in only one
of these cases.
Differential Revision: https://reviews.llvm.org/D57981
rdar://problem/47873212
llvm-svn: 353583
When a module name is specified as -fmodule-name, that module gets a
clang::Module object, but it won't actually be built or imported; it
will be textual. CGDebugInfo wouldn't detect this and them emit a
DICompileUnit that had a hash but no name and that confused both
dsymutil, LLDB, and myself.
rdar://problem/47926508
Differential Revision: https://reviews.llvm.org/D57976
llvm-svn: 353578
When we are calling `__builtin_constant_p` with ObjC objects of
different classes, we hit the assertion
> Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file include/llvm/Support/Casting.h, line 254.
It happens because LLVM types for `ObjCInterfaceType` are opaque and
have no name (see `CodeGenTypes::ConvertType`). As the result, for
different ObjC classes we have different `is_constant` intrinsics with
the same name `llvm.is.constant.p0s_s`. When we try to reuse an
intrinsic with the same name, we fail because of type mismatch.
Fix by bitcasting `ObjCObjectPointerType` to `id` prior to passing as an
argument to `__builtin_constant_p`. This results in using intrinsic
`llvm.is.constant.p0i8` and correct types.
rdar://problem/47499250
Reviewers: rjmccall, ahatanak, void
Reviewed By: void, ahatanak
Subscribers: ddunbar, jkorous, hans, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D57427
llvm-svn: 353577
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.
This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization. If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray. This shouldn't
affect the memory usage for other string literals. (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)
The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check. I this this is fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .
llvm-svn: 353569
of the array type itself.
This fixes a bug found by inspection that was introduced in r353459. I
don't have a test case for this since we don't yet have types that would
make the containing C struct non-trivial to copy/move but wouldn't make
it non-trivial to default-initialize or destruct.
llvm-svn: 353556
Summary:
With MSVC, #pragma pack is ignored when there is explicit alignment. This differs from gcc. Clang emulates this difference when compiling for Windows.
It appears that MSVC and its headers consider the __m128/__m128i/__m128d/etc. types to be explicitly aligned and ignores #pragma pack for them. Since we don't have explicit alignment on them in our headers, we don't match the MSVC behavior here.
This patch adds explicit alignment to match this behavior. I'm hoping this won't cause any problems when we're not emulating MSVC. But if someone knows of something that would be different we can swith to conditionally adding the alignment based on _MSC_VER.
I had to add explicitly unaligned types as well so we could use them in the loadu/storeu intrinsics which use __attribute__(__packed__). Using the now explicitly aligned types wouldn't produce align 1 accesses when targeting Windows.
Reviewers: rnk, erichkeane, spatel, RKSimon
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57961
llvm-svn: 353555
Fixed diagnostic emission for the exceptions support in case of the
compilation of OpenMP code for the devices. From now on, it uses delayed
diagnostics mechanism, previously used for CUDA only. It allow to
diagnose not allowed used of exceptions only in functions that are going
to be codegen'ed.
llvm-svn: 353542
It is important to delay the emission of the diagnostic messages for the
functions unless it is proved that the function is going to be used on
the device side. It is required to support compilation with some of the
target-specific system headers.
llvm-svn: 353540
Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:
```
[foo bar]->baz
```
as:
```
[foo bar] -> baz
```
Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't
know if the arrow token is after an ObjC method expression or not.
This diff makes `TokenAnnotator` remove the TT_LambdaArrow on
the arrow token if it follows an ObjC method expression.
Test Plan: New test added. Ran test with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Confirmed test failed before diff and passed after diff.
Reviewers: krasimir, djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57923
llvm-svn: 353531
Some of these functions take some extraneous arguments, e.g. EltSize,
Offset, which are computable from the Type and DataLayout.
Add some asserts to ensure that the computed values are consistent
with the passed-in values, in preparation for eliminating the
extraneous arguments. This also asserts that the Type is an Array for
the calls named "Array" and a Struct for the calls named "Struct".
Then, correct a couple of errors:
1. Using CreateStructGEP on an array type. (this causes the majority
of the test differences, as struct GEPs are created with i32
indices, while array GEPs are created with i64 indices)
2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on
x86-64 NACL (which uses 32-bit pointers).
Differential Revision: https://reviews.llvm.org/D57766
llvm-svn: 353529
Summary: Operators kind was not checked, so we reported e.g. op- to be equal with op+
Reviewers: shafik, a_sidorin, aaron.ballman
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57902
llvm-svn: 353504
Summary:
Automatic initialization [1] of __block variables was trampling over the block's
headers after they'd been initialized, which caused self-init usage to crash,
such as here:
typedef struct XYZ { void (^block)(); } *xyz_t;
__attribute__((noinline))
xyz_t create(void (^block)()) {
xyz_t myself = malloc(sizeof(struct XYZ));
myself->block = block;
return myself;
}
int main() {
__block xyz_t captured = create(^(){ (void)captured; });
}
This type of code shouldn't be broken by variable auto-init, even if it's
sketchy.
[1] With -ftrivial-auto-var-init=pattern
<rdar://problem/47798396>
Reviewers: rjmccall, pcc, kcc
Subscribers: jkorous, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57797
llvm-svn: 353495
This patch simply teach BPF driver about the new CPU "v3" introduced in
LLVM backend.
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
llvm-svn: 353479
This patch fixes a bug where clang doesn’t reject union fields of
non-trivial C struct types. For example:
```
// This struct is non-trivial under ARC.
struct S0 {
id x;
};
union U0 {
struct S0 s0; // clang should reject this.
struct S0 s1; // clang should reject this.
};
void test(union U0 a) {
// Previously, both 'a.s0.x' and 'a.s1.x' were released in this
// function.
}
```
rdar://problem/46677858
Differential Revision: https://reviews.llvm.org/D55659
llvm-svn: 353459
Summary:
Deferred diagnostic interface is going to be used for OpenMP device
compilation. Generalized previously existed deferred diagnostic
interface for CUDA to be used with OpenMP and, possibly, other models.
Reviewers: rjmccall, tra
Subscribers: caomhin, cfe-commits, kkwli0
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57908
llvm-svn: 353456
Valid OpenCL C code should still compile in C++ mode.
This change enables extensions and OpenCL types.
Differential Revision: https://reviews.llvm.org/D57824
llvm-svn: 353431
The patch in r350643 incorrectly sets the COFF emission based on bits
instead of bytes. This patch converts the 32 via CharUnits to bits to
compare the correct values.
Change-Id: Icf38a16470ad5ae3531374969c033557ddb0d323
llvm-svn: 353411
Now, instead of passing the reference to a shared_ptr, we pass the shared_ptr instead.
I've also removed the check if Z3 is present in CreateZ3ConstraintManager as this function already calls CreateZ3Solver that performs the exactly same check.
Differential Revision: https://reviews.llvm.org/D54976
llvm-svn: 353371
This patch moves the ConstraintSMT definition to the SMTConstraintManager header to make it easier to move the Z3 backend around.
We achieve this by not using shared_ptr anymore, as llvm::ImmutableSet doesn't seem to like it.
The solver specific exprs and sorts are cached in the Z3Solver object now and we move pointers to those objects around.
As a nice side-effect, SMTConstraintManager doesn't have to be a template anymore. Yay!
Differential Revision: https://reviews.llvm.org/D54975
llvm-svn: 353370
CreateCall/Invoke.
Also, remove the getFunctionType() function from CGCallee, since it
accesses the pointee type of the value. The only use was in EmitCall,
so just inline it into the debug assertion.
This is the last of the changes for Call and Invoke in clang.
Differential Revision: https://reviews.llvm.org/D57804
llvm-svn: 353356
Memory region that correspond to a variable is identified by the variable's
declaration and, in case of local variables, the stack frame it belongs to.
The declaration needs to be canonical, otherwise we'd have two different
memory regions that correspond to the same variable.
Fix such bug for global variables with forward declarations and assert
that no other problems of this kind happen.
Differential Revision: https://reviews.llvm.org/D57619
llvm-svn: 353353
This reverts commit r341722.
The "postponed" mechanism turns out to be necessary in order to handle
situations when a symbolic region is only kept alive by implicit bindings
in the Store. Otherwise the region is never scanned by the Store's worklist
and the binding gets dropped despite being live, as demonstrated
by the newly added tests.
Differential Revision: https://reviews.llvm.org/D57554
llvm-svn: 353350
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 353268
The assert added to EmitCall there was triggering in Windows Chromium
builds, due to a mismatch of the return type.
The MSVC constructor call extension (`this->Foo::Foo()`) was emitting
the constructor call from 'EmitCXXMemberOrOperatorMemberCallExpr' via
calling 'EmitCXXMemberOrOperatorCall', instead of
'EmitCXXConstructorCall'. On targets where HasThisReturn is true, that
was failing to set the proper return type in the call info.
Switching to calling EmitCXXConstructorCall also allowed removing some
code e.g. the trivial copy/move support, which is already handled in
EmitCXXConstructorCall.
Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=928861
Differential Revision: https://reviews.llvm.org/D57794
llvm-svn: 353246
For global variables with unordered initialization that are instantiated
within a module, we previously did not emit the global (or its
initializer) at all unless it was used in the importing translation unit
(and sometimes not even then!), leading to misbehavior and link errors.
We now emit the initializer for an instantiated global variable with
unordered initialization with side-effects in a module into every
translation unit that imports the module. This is unfortunate, but
mostly matches the behavior of a non-modular compilation and seems to be
the best that we can reasonably do.
llvm-svn: 353240
When a framework with the same name is available at multiple framework
search paths, we use the first matching location. If a framework at this
location doesn't have all the headers, it can be confusing for
developers because they see only an error `'Foo/Foo.h' file not found`,
can find the complete framework with required header, and don't know the
incomplete framework was used instead.
Add a note explaining a framework without required header was found.
Also mention framework directory path to make it easier to find the
incomplete framework.
rdar://problem/39246514
Reviewers: arphaman, erik.pilkington, jkorous
Reviewed By: jkorous
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D56561
llvm-svn: 353231
This is suggested by 3.3.9 of MSP430 EABI document.
We do allow user to manually enable frame pointer. GCC toolchain uses the same behavior.
Patch by Dmitry Mikushev!
Differential Revision: https://reviews.llvm.org/D56925
llvm-svn: 353212
Summary:
Added ability to generate correct debug info data about the variable
address class. Currently, for all the locals and globals the default
values are used, ADDR_local_space(6) for locals and ADDR_global_space(5)
for globals. The values are taken from the table in
https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf.
We need to emit correct data for address classes of, at least, shared
and constant globals. Currently, all these variables are treated by
the cuda-gdb debugger as the variables in the global address space
and, thus, it require manual data type casting.
Reviewers: echristo, probinson
Subscribers: jholewinski, aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D57162
llvm-svn: 353204
The fix is to issue error messages if there are more than one
teams construct inside a target constructs.
#pragma omp target
{
#pragma omp teams
{ ... }
#pragma omp teams
{ ... }
}
llvm-svn: 353186
Emit{Nounwind,}RuntimeCall{,OrInvoke} have been modified to take a
FunctionCallee as an argument, and CreateRuntimeFunction has been
modified to return a FunctionCallee. All callers have been updated.
Additionally, CreateBuiltinFunction is removed, as it was redundant
with CreateRuntimeFunction after some previous changes.
Differential Revision: https://reviews.llvm.org/D57668
llvm-svn: 353184
edge cases.
Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.
All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.
As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.
List of fixes:
* arrangeCXXConstructorCall was passing an incorrect value for the
number of Required args, when calling an inheriting constructor
where the inherited constructor is variadic. (The inheriting
constructor doesn't actually get passed any of the user's args, but
the code was calculating it as if it did).
* arrangeFreeFunctionLikeCall was not including the count of the
pass_object_size arguments in the count of required args.
* OpenCL uses other address spaces for the "this" pointer. However,
commonEmitCXXMemberOrOperatorCall was not annotating the address
space on the "this" argument of the call.
* Destructor calls were being created with EmitCXXMemberOrOperatorCall
instead of EmitCXXDestructorCall in a few places. This was a problem
because the calling convention sometimes has destructors returning
"this" rather than void, and the latter function knows about that,
and sets up the types properly (through calling
arrangeCXXStructorDeclaration), while the former does not.
* generateObjCGetterBody: the 'objc_getProperty' function returns type
'id', but was being called as if it returned the particular
property's type. (That is of course the *dynamic* return type, and
there's a downcast immediately after.)
* OpenMP user-defined reduction functions (#pragma omp declare
reduction) can be called with a subclass of the declared type. In
such case, the call was being setup as if the function had been
actually declared to take the subtype, rather than the base type.
Differential Revision: https://reviews.llvm.org/D57664
llvm-svn: 353181
When we attempt to add an addr space qual to a type already
qualified by an addr space ICE is triggered. Before creating
a type with new address space, remove the old addr space.
Fixing PR38614!
Differential Revision: https://reviews.llvm.org/D57524
llvm-svn: 353160
Summary: The backend used to print the x87 FPSW register as 'fpsw', but gcc inline asm uses 'fpsr'. After D57641, the backend now uses 'fpsr' to match.
Reviewers: rnk
Reviewed By: rnk
Subscribers: eraman, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57642
llvm-svn: 353142
Mike Rice