| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Patch allows to recognize additional registers x8d, x8b, x8w - x15d, x15b, x15w in inline assembler, already recognized by backend
Differential Revision: http://reviews.llvm.org/D12594
llvm-svn: 246835
|
| |
|
|
|
|
| |
simplify the implementation a bit.
llvm-svn: 246830
|
| |
|
|
| |
llvm-svn: 246826
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12445
llvm-svn: 246818
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Dtor sanitization handled amidst other dtor cleanups,
between cleaning bases and fields. Sanitizer call pushed onto
stack of cleanup operations.
Reviewers: eugenis, kcc
Differential Revision: http://reviews.llvm.org/D12022
Refactoring dtor sanitizing emission order.
- Support multiple inheritance by poisoning after
member destructors are invoked, and before base
class destructors are invoked.
- Poison for virtual destructor and virtual bases.
- Repress dtor aliasing when sanitizing in dtor.
- CFE test for dtor aliasing, and repression of aliasing in dtor
code generation.
- Poison members on field-by-field basis, with collective poisoning
of trivial members when possible.
- Check msan flags and existence of fields, before dtor sanitizing,
and when determining if aliasing is allowed.
- Testing sanitizing bit fields.
llvm-svn: 246815
|
| |
|
|
|
|
|
|
|
|
| |
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
|
| |
|
|
|
|
|
| |
disable checking of arguments to the function, which is done by
-Wthread-safety-reference.
llvm-svn: 246806
|
| |
|
|
| |
llvm-svn: 246804
|
| |
|
|
|
|
|
|
|
|
| |
COMDAT only for ELF objects.
http://llvm.org/pr23472
Reviewed by Reid Kleckner.
llvm-svn: 246803
|
| |
|
|
|
|
| |
ASan may not be supported for the default target triple.
llvm-svn: 246795
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It used to work, but was accidentally broken by r179769.
The issue with decayed types was fixed by r190796.
So this patch partially reverts r179769, and adds more tests.
This also fixes PR 18669.
Patch by Sergey Kalinichev.
llvm-svn: 246778
|
| |
|
|
|
|
|
|
|
| |
targets.
Differential Revision: http://reviews.llvm.org/D12244
Change-Id: Iffd4e822c15e18668fe8868278230ff232ef50aa
llvm-svn: 246768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assembler macros.
Summary: The command line options for these are -Wa,--trap and -Wa,--break.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11676
llvm-svn: 246765
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
|
| |
|
|
|
|
| |
Fixed capturing of VLAs in 'private' clause of the OpenMP directives.
llvm-svn: 246757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
|
| |
|
|
|
|
| |
Fixed codegen for extended format of 'if' clauses with special 'directive-name-modifier' + ast-print tests for extended format of 'if' clause.
llvm-svn: 246748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause.
Format of 'if' clause is as follows:
```
if([ directive-name-modifier :] scalar-logical-expression)
```
The restriction rules are also changed.
1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'.
2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive.
3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive.
'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied.
llvm-svn: 246747
|
| |
|
|
| |
llvm-svn: 246715
|
| |
|
|
| |
llvm-svn: 246714
|
| |
|
|
|
|
|
|
|
|
|
| |
variables.
Full list of changes:
- all scan-build command-line arguments are now kept in %Options hash.
- most of environment variables scan-build operates with are stored in %EnvVars hash.
- moved processing of command-line arguments to the ProcessArgs subroutine.
llvm-svn: 246710
|
| |
|
|
|
|
|
|
| |
every time it's called rather than attempting to cache the result.
It's unlikely to be called frequently and the overhead of using
it in the first place is already factored out.
llvm-svn: 246706
|
| |
|
|
| |
llvm-svn: 246702
|
| |
|
|
|
|
|
| |
additional data members in attributes as they'll leak and provide
some guidance as to where they should be allocated if necessary.
llvm-svn: 246701
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
Introduce a frontend option -fdepfile-entry, and only insert them
for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps
from -fdepfile-entry, instead of -fsanitize-blacklist.
Reviewers: rsmith, pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12544
llvm-svn: 246700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch depends on r246688 (D12341).
The goal is to make LLVM generate different code for these functions for a target that
has cheap branches (see PR23827 for more details):
int foo();
int normal(int x, int y, int z) {
if (x != 0 && y != 0) return foo();
return 1;
}
int crazy(int x, int y) {
if (__builtin_unpredictable(x != 0 && y != 0)) return foo();
return 1;
}
Differential Revision: http://reviews.llvm.org/D12458
llvm-svn: 246699
|
| |
|
|
|
|
| |
to blocks. We don't need these names, and decoding the corresponding bitcode has a significant cost.
llvm-svn: 246680
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TagDecls (structs, enums, etc.) may have the same name for linkage
purposes of one another; to disambiguate, we add a number to the mangled
named. However, we didn't do this if the TagDecl has a pseudo-name for
linkage purposes (it was defined alongside a DeclaratorDecl or a
TypeNameDecl).
This fixes PR24651.
llvm-svn: 246659
|
| |
|
|
| |
llvm-svn: 246657
|
| |
|
|
| |
llvm-svn: 246652
|
| |
|
|
| |
llvm-svn: 246650
|
| |
|
|
| |
llvm-svn: 246646
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12444
llvm-svn: 246618
|
| |
|
|
|
|
|
|
|
|
| |
the main attribute and cache the results so we don't have to parse
a single attribute more than once.
This reapplies r246596 with a fix for an uninitialized class member,
and a couple of cleanups and formatting changes.
llvm-svn: 246610
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`OpaqueValueExpr`s may not have a source expression (as in the case when
they are created due to a default argument error).
This can cause an assertion failure in `TransformOpaqueValueExpr` during
template instantiation.
This patch fixes the assertion failure.
Reviewers: hfinkel, rsmith
Subscribers: fraggamuffin, cfe-commits
Differential Revision: http://reviews.llvm.org/D11582
Patch by Rachel Craik!
llvm-svn: 246600
|
| |
|
|
|
|
|
|
| |
This is failing in release mode. Revert while I figure out what's happening.
This reverts commit r246596.
llvm-svn: 246598
|
| |
|
|
|
|
|
| |
the main attribute and cache the results so we don't have to parse
a single attribute more than once.
llvm-svn: 246596
|
| |
|
|
| |
llvm-svn: 246595
|
| |
|
|
|
|
|
| |
We now have an implementation of the CRC in LLVM's libSupport. Let's
consolidate around that one.
llvm-svn: 246591
|
| |
|
|
| |
llvm-svn: 246589
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015
rejects-valid.
Original commit message:
[modules] Rework serialized DeclContext lookup table management. Instead of
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.
This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).
llvm-svn: 246582
|
| |
|
|
| |
llvm-svn: 246573
|
| |
|
|
| |
llvm-svn: 246565
|
| |
|
|
|
|
|
|
| |
constructor or destructor function-try-block, which is UB in C++.
This corresponds to the CERT secure coding rule ERR53-CPP.
llvm-svn: 246548
|
| |
|
|
|
|
|
|
|
|
|
| |
avoid merge conflicts). It broke the build on MSVC 2015. It also broke an MSVC 2013 bot with testing issues.
llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):
error C2065: 'Files': undeclared identifier
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/2917
llvm-svn: 246546
|
| |
|
|
|
|
| |
referenced by the entries that we emit.
llvm-svn: 246534
|
| |
|
|
| |
llvm-svn: 246526
|
| |
|
|
| |
llvm-svn: 246524
|
| |
|
|
|
|
|
| |
Use "lookup" instead of operator[], it will not perform unnecessary
insertions. No functionality change is intended.
llvm-svn: 246523
|