When defined in NSObject, +new will call -init. If -init has been marked
unavailable, diagnose uses of +new.
rdar://18335828
Differential revision: https://reviews.llvm.org/D51189
llvm-svn: 341874
Problem was that we were appending to the source location info buffer in the
copy assignment operator (instead of overwriting).
rdar://42746401
llvm-svn: 341869
The instruction set first appeared with Westmere, but not all processors
in that and the next few generations have the instructions. According to
Wikipedia[1], the first generation in which all SKUs have AES
instructions are Skylake and Goldmont. I can't find any Skylake,
Kabylake, Kabylake-R or Cannon Lake currently listed at
https://ark.intel.com that says "Intel® AES New Instructions" "No".
This matches GCC commit
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01940.html
[1] https://en.wikipedia.org/wiki/AES_instruction_set
Patch By: thiagomacieira
Differential Revision: https://reviews.llvm.org/D51510
llvm-svn: 341862
Summary:
_Atomic and __sync_* operations are implicitly sequentially-consistent. Some
codebases want to force explicit usage of memory order instead. This warning
allows them to know where implicit sequentially-consistent memory order is used.
The warning isn't on by default because _Atomic was purposefully designed to
have seq_cst as the default: the idea was that it's the right thing to use most
of the time. This warning allows developers who disagree to enforce explicit
usage instead.
A follow-up patch will take care of C++'s std::atomic. It'll be different enough
from this patch that I think it should be separate: for C++ the atomic
operations all have a memory order parameter (or two), but it's defaulted. I
believe this warning should trigger when the default is used, but not when
seq_cst is used explicitly (or implicitly as the failure order for cmpxchg).
<rdar://problem/28172966>
Reviewers: rjmccall
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51084
llvm-svn: 341860
This patch removes the last reason why DIFlagBlockByrefStruct from
Clang by directly implementing the drilling into the member type done
in DwarfDebug::DbgVariable::getType() into the frontend.
rdar://problem/31629055
Differential Revision: https://reviews.llvm.org/D51807
llvm-svn: 341842
Summary:
Currently CodeCompleteCall only gets called after a comma or parantheses. This
patch makes sure it is called even at the cases like:
```foo(1^);```
Reviewers: ilya-biryukov, ioeric, hokein
Reviewed By: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D51038
llvm-svn: 341824
This patch adds support for the following operations in the iterator checkers: assign, clear, insert, insert_after, emplace, emplace_after, erase and erase_after. This affects mismatched iterator checks ("this" and parameter must match) and invalidation checks (according to the standard).
Differential Revision: https://reviews.llvm.org/D32904
llvm-svn: 341794
This patch adds support for the following operations in the iterator checkers: push_back, push_front, emplace_back, emplace_front, pop_back and pop_front. This affects iterator range checks (range is extended after push and emplace and reduced after pop operations) and invalidation checks (according to the standard).
Differential Revision: https://reviews.llvm.org/D32902
llvm-svn: 341793
Extension of the mismatched iterator checker for constructors taking range of first..last (first and last must be iterators of the same container) and also for comparisons of iterators of different containers (one does not compare iterators of different containers, since the set of iterators is partially ordered, there are no relations between iterators of different containers, except that they are always non-equal).
Differential Revision: https://reviews.llvm.org/D32860
llvm-svn: 341792
If a container is moved by its move assignment operator, according to the standard all their iterators except the past-end iterators remain valid but refer to the new container. This patch introduces support for this case in the iterator checkers.
Differential Revision: https://reviews.llvm.org/D32859
llvm-svn: 341791
New check added to the checker which checks whether iterator parameters of template functions typed by the same template parameter refer to the same container.
Differential Revision: https://reviews.llvm.org/D32845
llvm-svn: 341790
match when checking for redeclaration of a function template.
This properly handles differences in deduced return types, particularly
when performing redeclaration checks for a friend function template.
llvm-svn: 341778
Add the capability to nest multiple declare target directives
- including header files within a declare target region.
Differential Revision: https://reviews.llvm.org/D51378
Patch by Patrick Lyster
llvm-svn: 341766
edit_distance returns UpperBound+1 if the distance will exceed UpperBound. We can subtract 1 from UpperBound and change >= to > in the if condition. The threshold does not change but edit_distance will have more opportunity to bail out earlier.
llvm-svn: 341763
This patch fixes the handling of clang-cl options in InterpolatingCompilationDatabase.
They were previously ignored completely, which led to a lot of bugs:
Additional options were being added with the wrong syntax. E.g. a file was
specified as C++ by adding -x c++, which causes an error in CL mode.
The args were parsed and then rendered, which means that the aliasing information
was lost. E.g. /W4 was rendered to -Wall, which in CL mode means -Weverything.
CL options were ignored when checking things like -std=, so a lot of logic was
being bypassed.
Differential Revision: https://reviews.llvm.org/D51321
llvm-svn: 341760
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 341754
Summary:
The optimized (__atomic_foo_<n>) libcalls assume that the atomic object
is properly aligned, so should never be called on an underaligned
object.
This addresses one of several problems identified in PR38846.
Reviewers: jyknight, t.p.northover
Subscribers: jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51817
llvm-svn: 341734
The "derived" symbols indicate children fields of a larger symbol.
As parents do not have pointers to their children, the garbage
collection algorithm the analyzer currently uses adds such symbols into
a "postponed" category, and then keeps running through the worklist
until the fixed point is reached.
The current patch rectifies that by instead using a helper map which
stores pointers from parents to children, so that no fixed point
calculation is necessary.
The current patch yields ~5% improvement in running time on sqlite.
Differential Revision: https://reviews.llvm.org/D51397
llvm-svn: 341722
This is the clang side of D51803. The llvm intrinsic now returns two results. So we need to emit an explicit store in IR for the out parameter. This is similar to addcarry/subborrow/rdrand/rdseed.
Differential Revision: https://reviews.llvm.org/D51805
llvm-svn: 341699
This is the clang side of D51769. The llvm intrinsics now return two results instead of using an out parameter.
Differential Revision: https://reviews.llvm.org/D51771
llvm-svn: 341678
Summary:
Code completion in clang is actually a mix of two features:
- Code completion is a familiar feature. Results are exposed via the
CodeCompleteConsumer::ProcessCodeCompleteResults callback.
- Signature help figures out if the current expression is an argument of
some function call and shows corresponding signatures if so.
Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates.
This patch refactors the implementation to untangle those two from each
other and makes some naming tweaks to avoid confusion when reading the
code.
The refactoring is required for signature help fixes, see D51038.
The only intended behavior change is the order of callbacks.
ProcessOverloadCandidates is now called before ProcessCodeCompleteResults.
Reviewers: sammccall, kadircet
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51782
llvm-svn: 341660
[RISCV] Add support for computing sysroot for riscv32-unknown-elf
Extends r338385 to allow the driver to compute the sysroot when an explicit path is not provided. This allows the linker to find C runtime files and the correct include directory for header files.
Patch by lewis-revill (Lewis Revill)
llvm-svn: 341655
The test was missing '--' on mac as pointed out by -Wslash-u-filename:
<stdin>:5:69: note: possible intended match here
clang: warning: '/Users/thakis/src/llvm-mono/clang/test/Driver/msvc-link.c' treated as the '/U' option [-Wslash-u-filename]
Differential Revision: https://reviews.llvm.org/D51635
llvm-svn: 341654
Boilerplate code for using KMSAN instrumentation in Clang.
We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::KernelMemory, which, along with
SanitizerKind::Memory, maps to the memory_sanitizer feature.
KMSAN is only supported on x86_64 Linux.
It's incompatible with other sanitizers, but supports code coverage
instrumentation.
llvm-svn: 341641
accessible from the context where aggregate initialization occurs.
rdar://problem/38168772
Differential Revision: https://reviews.llvm.org/D45898
llvm-svn: 341629
A node is considered to be trivial if it only has one successor, one
predecessor, and a state equal to the predecessor.
Can drastically (> 2x) reduce the size of the generated exploded
graph.
Differential Revision: https://reviews.llvm.org/D51665
llvm-svn: 341616
Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the existing binary at all.
Differential Revision: https://reviews.llvm.org/D51655
llvm-svn: 341601
context.
If the explicit template instantiation definition defined outside of the
target context, its vtable should not be marked as used. This is true
for other situations where the compiler want to emit vtables
unconditionally.
llvm-svn: 341570
Namely, print the likely macro name when it's used, and include the actual
computed sizes in the diagnostic message, which are sometimes not obvious.
rdar://43909200
Differential revision: https://reviews.llvm.org/D51697
llvm-svn: 341566
This recommits r341472, which was reverted due to test failures on macos bots.
The issue was that a macos target implies -glldb which, together with
this patch added a -gpubnames switch where there previously wasn't one.
The intentions of those checks was to check that -gpubnames is not
emitted by default so I add an explicit -ggdb arg to those command lines
to get same behavior on all platforms (the fact that -glldb *does* set
-gpubnames is tested by a separate test).
Differential Revision: https://reviews.llvm.org/D51576
llvm-svn: 341564
This reverts commit r341519, which generates debug info that causes
backend crashes. (with -split-dwarf-file)
Details in https://reviews.llvm.org/D50495
llvm-svn: 341549
Summary:
Negative arguments in kernel attributes are silently bitcast'ed to
unsigned, for example:
__attribute__((reqd_work_group_size(1, -1, 1)))
__kernel void k() {}
is a complete equivalent of:
__attribute__((reqd_work_group_size(1, 4294967294, 1)))
__kernel void k() {}
This is likely an error, so the patch forbids negative arguments in
several OpenCL attributes. Users who really want 4294967294 can still
use it as an unsigned representation.
Reviewers: Anastasia, yaxunl, bader
Reviewed By: Anastasia, yaxunl, bader
Subscribers: bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D50259
llvm-svn: 341539
Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.
After fixing PR37395.
After fixing problems in LiveDebugVariables.
Differential Revision: https://reviews.llvm.org/D45045
llvm-svn: 341519
destructors.
We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.
This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.
This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.
This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.
llvm-svn: 341499
This is a warning about using 'assign' instead of 'unsafe_unretained'
in Objective-C property declarations. It's off by default because there
isn't consensus in the Objective-C steering group that this is the right
thing to do, but we're nonetheless okay with adding it because there's a
substantial pool of Objective-C programmers who will appreciate the warning.
Patch by Alfred Zien!
llvm-svn: 341489
Summary:
This provides information about the macro definition. For example, it
can be used to compute macro USRs.
Reviewers: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51675
llvm-svn: 341476
Summary:
DWARF v5 accelerator tables provide a considerable performance
improvement for lldb and will make the default -glldb behavior same on
all targets (right now we emit apple tables on apple targets, but these
are not controlled by -gpubnames, only by -glldb).
Reviewers: dblaikie
Subscribers: probinson, clayborg, JDevlieghere, aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D51576
llvm-svn: 341472
This fixes formatting namespaces with preceding 'inline' and 'export' (Modules TS) specifiers.
This change fixes namespaces not being identified as such with preceding 'inline' or 'export' specifiers.
Motivation: I was experimenting with the Modules TS (-fmodules-ts) and found it would be useful if clang-format would correctly format 'export namespace'. While making the changes, I noticed that similar issues still exist with 'inline namespace', and addressed them as well.
Patch by Marco Elver!
Reviewers: klimek, djasper, owenpan, sammccall
Reviewed By: owenpan, sammccall
Subscribers: owenpan, cfe-commits
Differential Revision: https://reviews.llvm.org/D51036
llvm-svn: 341450
Summary:
Added support of creating a hardlink from one file to another file.
After a hardlink is added between two files, both file will have the same:
1. UniqueID (inode)
2. Size
3. Buffer
This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs.
Patch by Utkarsh Saxena!
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51359
llvm-svn: 341366
Load Hardening.
Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.
Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.
While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.
This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.
Differential Revision: https://reviews.llvm.org/D51157
llvm-svn: 341363
This reverts commit b4547c9cadd2f8adfe3f3182e4c56e466c5256cb.
Apparently git llvm push from the monorepo does not respect branches and
pushes the current branch to master.
llvm-svn: 341352
The code remains so that we can potentially reenable it in a point
release, but the driver will reject it. Several issues were raised
during testing that made it clear that this was not quite ready for
general consumption.
Approved by: Hans Wennborg
llvm-svn: 341350
Summary:
Some `Expr` classes set up default values for the `ExprBits` of `Stmt`. These
default values are then overwritten by the parser sometimes. One example is
`InitListExpr` which sets the value kind to be an rvalue in the ctor. However,
this bit may change after the `InitListExpr` is created. There may be other
expressions similar to `InitListExpr` in this sense, thus the safest solution
is to copy the expression bits.
The lack of copying `ExprBits` causes an assertion in the analyzer engine in a
specific case: Since the value kind is not imported, the analyzer engine
believes that the given InitListExpr is an rvalue, thus it creates a
nonloc::CompoundVal instead of creating memory region (as in case of an lvalue
reference).
Reviewers: a_sidorin, r.stahl, xazax.hun, a.sidorin
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D51533
llvm-svn: 341316
This patch fixes target linker emulation for aarch64 big endian.
aarch64_be_linux is not recognized by gnu ld. The equivalent emulation
mode supported by gnu ld is aarch64linuxb.
Patch by: Bharathi Seshadri
Reviewed by: Peter Smith
Differential Revision: https://reviews.llvm.org/D42930
llvm-svn: 341312
Summary:
Given the following kernel:
__kernel void foo() {
double d;
double4 dd;
}
and cl_khr_fp64 is disabled, the compilation would fail due to
the presence of 'double d', but when removed, it passes.
The expectation is that extended vector types of unsupported types
will also be unsupported.
The patch adds the check for this scenario.
Patch by: Ofir Cohen
Reviewers: bader, Anastasia, AlexeySotkin, yaxunl
Reviewed By: Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51296
llvm-svn: 341309
These aren't documented in the Intel Intrinsics Guide, but are supported by gcc and icc.
Includes these intrinsics:
_ktestc_mask8_u8, _ktestz_mask8_u8, _ktest_mask8_u8
_ktestc_mask16_u8, _ktestz_mask16_u8, _ktest_mask16_u8
_ktestc_mask32_u8, _ktestz_mask32_u8, _ktest_mask32_u8
_ktestc_mask64_u8, _ktestz_mask64_u8, _ktest_mask64_u8
llvm-svn: 341265
This adds:
_cvtmask8_u32, _cvtmask16_u32, _cvtmask32_u32, _cvtmask64_u64
_cvtu32_mask8, _cvtu32_mask16, _cvtu32_mask32, _cvtu64_mask64
_load_mask8, _load_mask16, _load_mask32, _load_mask64
_store_mask8, _store_mask16, _store_mask32, _store_mask64
These are currently missing from the Intel Intrinsics Guide webpage.
llvm-svn: 341251
This adds the following intrinsics:
_kshiftli_mask8
_kshiftli_mask16
_kshiftli_mask32
_kshiftli_mask64
_kshiftri_mask8
_kshiftri_mask16
_kshiftri_mask32
_kshiftri_mask64
llvm-svn: 341234
Summary:
Added option -gline-directives-only to support emission of the debug directives
only. It behaves very similar to -gline-tables-only, except that it sets
llvm debug info emission kind to
llvm::DICompileUnit::DebugDirectivesOnly.
Reviewers: echristo
Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D51177
llvm-svn: 341212
There are two types of dynamic initializer stubs. There's
`dynamic initializer for 'x''(void)
and
`dynamic initializer for `static Foo::Bar StaticDataMember''(void)
The second case is disambiguated from the first by the presence of
a ? after the operator code. So the first will appear something like
?__E<name> while the second will appear something like ?__E?<name>.
clang-cl was mangling these both the same though. This patch
matches behavior with cl.
Differential Revision: https://reviews.llvm.org/D51500
llvm-svn: 341117
The changes were breaking CUDA compilation.
Reverted revisions:
r340681 D50845
[CUDA/OpenMP] Define only some host macros during device compilation
r340772 D51312
[OpenMP][NVPTX] Use appropriate _CALL_ELF macro when offloading
r340967 D51441
Add predefined macro __gnu_linux__ for proper aux-triple
llvm-svn: 341115
Erik Pilkington