| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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: 246652
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12444
llvm-svn: 246618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 246526
|
| |
|
|
|
|
|
|
| |
predictable diagnostic experience. The hash-of-DeclID order we were using
before gave different results on Win32 due to a different predefined
declaration of __builtin_va_list.
llvm-svn: 246521
|
| |
|
|
| |
llvm-svn: 246520
|
| |
|
|
|
|
|
|
|
|
| |
GCC 4.8+ has a PowerPC-specific intrinsic, __builtin_ppc_get_timebase, to do
what Clang's __builtin_readcyclecounter does. For compatibility with code that
uses GCC's spelling (including glibc), support it as well.
Partially fixes PR23681.
llvm-svn: 246510
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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: 246497
|
| |
|
|
| |
llvm-svn: 246492
|
| |
|
|
| |
llvm-svn: 246479
|
| |
|
|
|
|
|
|
|
|
| |
This patch refactors the code to use the GCC installation detector
(modified so that it works in Solaris), and uses
ToolChain::GetFilePath everywhere once it works.
Patch by Xan López <xan@igalia.com>!
llvm-svn: 246473
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A class without a name for linkage purposes gets a name along the lines
of <unnamed-type-foo> where foo is either the name of a declarator which
defined it (like a variable or field) or a
typedef-name (like a typedef or alias-declaration).
We handled the declarator case correctly but it would fall down during
template instantiation if the declarator didn't share the tag's type.
We failed to handle the typedef-name case at all.
Instead, keep track of the association between the two and keep it up to
date in the face of template instantiation.
llvm-svn: 246469
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Clang should emit "atomicrmw umin/umax" instead of "atomicrmw min/max".
Reviewers: eliben, tra
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12487
llvm-svn: 246455
|
| |
|
|
|
|
|
|
|
|
| |
Proper diagnostic and resolution of mangled names conflicts between C++ methods
and C functions. This patch implements support for functions/methods only;
support for variables is coming separately.
Differential Revision: http://reviews.llvm.org/D11297
llvm-svn: 246438
|
| |
|
|
|
|
| |
Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type).
llvm-svn: 246422
|
| |
|
|
|
|
|
|
| |
Reviewers: pekka.jaaskelainen
Differential Revision: http://reviews.llvm.org/D12470
llvm-svn: 246393
|
| |
|
|
| |
llvm-svn: 246391
|
| |
|
|
|
|
|
|
|
|
|
| |
other numbers.
In release builds labels are numbers. Matching just the number may result
in false matches where the label is contained in other numbers, such as
14 inside [114 x i8]. A stricter match requiring start of line or > character
before the label avoids these false matches.
llvm-svn: 246385
|
| |
|
|
|
|
|
|
| |
(Re)added debug codegen test for F16C, FMA4, XOP + 3DNow! intrinsics
Part of PR24590
llvm-svn: 246363
|
| |
|
|
|
|
|
|
|
|
| |
We cannot tell if an object is past-the-end if its type is incomplete.
Zero sized objects satisfy past-the-end criteria and our object might
turn out to be such an object.
This fixes PR24622.
llvm-svn: 246359
|
| |
|
|
| |
llvm-svn: 246355
|
| |
|
|
|
|
|
| |
whether it can ever produce a constant expression in the case where it has a
void return type and no return statements.
llvm-svn: 246347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
region.
Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size
array fields. With this change, instead of invalidating the entire containing region the
analyzer now invalidates only offsets for the array itself when it can show that the
memcpy stays within the bounds of the array.
This addresses false positive memory leak warnings of the kind reported by
krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954
A patch by Pierre Gousseau!
Differential Revision: http://reviews.llvm.org/D11832
llvm-svn: 246345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions when safe (PR24593)
This patch does two things:
1) Don't error about dllimport/export on thread-local static local variables.
We put those attributes on static locals in dllimport/export functions
implicitly in case the function gets inlined. Now, for TLS variables this
is a problem because we can't import such variables, but it's a benign
problem becase:
2) Make sure we never inline a dllimport function TLS static locals. In fact,
never inline a dllimport function that references a non-imported function
or variable (because these are not defined in the importing library). This
seems to match MSVC's behaviour.
Differential Revision: http://reviews.llvm.org/D12422
llvm-svn: 246338
|
| |
|
|
|
|
| |
This reverts commit r246223, as it broke all ARM/AArch64 bots.
llvm-svn: 246323
|
| |
|
|
|
|
| |
This reverts commit r246211, as it broke all ARM/AArch64 bots.
llvm-svn: 246321
|
| |
|
|
|
|
| |
This reverts commit r246206, as it broke all ARM/AArch64 bots.
llvm-svn: 246320
|
| |
|
|
|
|
| |
This reverts commit r246204, as it was breaking all ARM/AArch64 bots.
llvm-svn: 246319
|
| |
|
|
|
|
|
| |
The test is currently failing on bots:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12747/
llvm-svn: 246288
|
| |
|
|
|
|
| |
These two commits causes llvm LTO bootstrap to hang in ScalarEvolution.
llvm-svn: 246282
|
| |
|
|
|
|
| |
Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type).
llvm-svn: 246278
|
| |
|
|
|
|
| |
pointer to an RVO construction of a returned object.
llvm-svn: 246263
|
| |
|
|
|
|
|
|
| |
Sometimes, a macro that expands to another macro name will not be printed in
the macro backtrace. This patch finds the missed macro expansions and prints
them. Fixes PR16799
llvm-svn: 246237
|
| |
|
|
|
|
|
|
|
|
|
| |
Without this, 64-byte vector types (__m512), specified to be 64-byte
aligned in the AVX512 draft SysV ABI, will only be 32-byte aligned.
This is analoguous to AVX, for which we accept 32-byte max alignment.
Differential Revision: http://reviews.llvm.org/D10724
llvm-svn: 246230
|
| |
|
|
|
|
|
|
|
| |
There's no point in using a larger alignment if we have no instructions
that would benefit from it.
Differential Revision: http://reviews.llvm.org/D12389
llvm-svn: 246229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ABI string only exists to communicate with TargetCodeGenInfo.
Concretely, since we only used "avx*" ABI strings on x86_64 (as AVX
doesn't affect the i386 ABIs), this meant that, when initializing
SimdDefaultAlign, we would ignore AVX/AVX512 on i386, for no good
reason.
Instead, directly check the features. A similar change for
MaxVectorAlign will follow.
Differential Revision: http://reviews.llvm.org/D12390
llvm-svn: 246228
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246223
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There was linker problem, and it turns out that it is not always safe
to refer to vtable. If the vtable is used, then we can refer to it
without any problem, but because we don't know when it will be used or
not, we can only check if vtable is external or it is safe to to emit it
speculativly (when class it doesn't have any inline virtual functions).
It should be fixed in the future.
http://reviews.llvm.org/D12385
llvm-svn: 246214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
http://reviews.llvm.org/D11859
llvm-svn: 246213
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246211
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246206
|
| |
|
|
|
|
| |
Part of PR24590
llvm-svn: 246204
|
| |
|
|
|
|
| |
Minor tweak to rL246083
llvm-svn: 246200
|