| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
library. That results in the linker resolving all references to weak symbols in
the DSO to the definition from within that DSO. Ironically, this rarely causes
observable problems, except that it causes ubsan's own dynamic type check to
spuriously fail (because we fail to properly merge type_info object names).
llvm-svn: 210220
|
| |
|
|
|
|
|
|
| |
They should be initialized when they're exported.
Differential Revision: http://reviews.llvm.org/D4020
llvm-svn: 210217
|
| |
|
|
|
|
| |
Tested for compatibility with VS2013.
llvm-svn: 210198
|
| |
|
|
|
|
|
|
|
| |
Straightforward implementation of UDLs, it's compatible with VS "14".
This nearly completes our implementation of C++ name mangling for the
MS-ABI.
llvm-svn: 210197
|
| |
|
|
|
|
| |
Parsing this clause, allowing it on directive ‘omp simd’ and semantic checks.
llvm-svn: 210184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates (PR19902)
This allows us to compile the following kind of code, which occurs in MSVC
headers:
template <typename> struct S {
__declspec(dllimport) static int x;
};
template <typename T> int S<T>::x;
The definition works similarly to a dllimport inline function definition and
gets available_externally linkage.
Differential Revision: http://reviews.llvm.org/D3998
llvm-svn: 210141
|
| |
|
|
|
|
|
| |
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
llvm-svn: 210137
|
| |
|
|
|
|
|
| |
Also revert r210096 which temporarily disabled the test while this was being
investigated.
llvm-svn: 210115
|
| |
|
|
|
|
| |
(want to have the sanitizer bot green)
llvm-svn: 210096
|
| |
|
|
|
|
|
|
|
| |
This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.
Differential revision: http://reviews.llvm.org/D3778
llvm-svn: 210095
|
| |
|
|
| |
llvm-svn: 210092
|
| |
|
|
|
|
|
|
|
| |
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
llvm-svn: 210091
|
| |
|
|
|
|
|
|
|
|
| |
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
llvm-svn: 210083
|
| |
|
|
|
|
| |
namespace.
llvm-svn: 210080
|
| |
|
|
|
|
|
|
|
| |
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.
llvm-svn: 210079
|
| |
|
|
| |
llvm-svn: 210064
|
| |
|
|
|
|
| |
Aliases in llvm now hold an arbitrary expression.
llvm-svn: 210063
|
| |
|
|
| |
llvm-svn: 210059
|
| |
|
|
|
|
|
|
| |
This corresponds to the same change for the MS ABI in r209908.
Differential Revision: http://reviews.llvm.org/D3993
llvm-svn: 210054
|
| |
|
|
|
|
|
| |
Allow the tests to succeed with tne signext (or other) attribute is present. The attributes
show up for Power, but not for x86*, so need to be appropriately wildcarded.
llvm-svn: 210050
|
| |
|
|
|
|
|
| |
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.
llvm-svn: 210026
|
| |
|
|
|
|
|
|
| |
Wrong patch got committed (this one isn't ready for prime time).
This reverts commit r209996.
llvm-svn: 209997
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We should treat tentative definitions as undefined for the purpose of
ODR-use linkage checking.
This broke somewhere around r149731 when tests were disabled.
Note that test coverage for these diagnostics is generally lacking due to a
separate issue (PR19910: Don't suppress unused/undefined warnings when there
are errors).
llvm-svn: 209996
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=18498
This code was resulting in a crash:
auto L = [](auto ... v) { };
L.operator()<int>(3);
The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.
This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.
Thanks to Richard Smith for the review!
http://reviews.llvm.org/D2135
llvm-svn: 209992
|
| |
|
|
|
|
|
|
|
| |
Remove redundant -fno-stack-protector run with openbsd.
Add -target to the -fstack-protector tests so they pass on openbsd.
Patch by Brad Smith.
llvm-svn: 209991
|
| |
|
|
|
|
|
| |
The tests were correctly getting skipped but the targets still mistakenly got
built.
llvm-svn: 209983
|
| |
|
|
|
|
|
|
|
|
|
| |
extension
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
|
| |
|
|
| |
llvm-svn: 209974
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.
A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.
<rdar://problem/16616623>
llvm-svn: 209966
|
| |
|
|
|
|
|
|
|
| |
Also move the attribute-specific dumping to after dumping this and
the Implicit flag.
Differential Revision: http://reviews.llvm.org/D3971
llvm-svn: 209965
|
| |
|
|
|
|
|
|
|
|
| |
identifiers
This failure mode shows up occasionally when users try to include C headers in
C++ projects or when porting from Windows. We might as well recover in the way
the user expected, thus avoiding confusing diagnostic messages at point of use.
llvm-svn: 209963
|
| |
|
|
| |
llvm-svn: 209955
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3973
llvm-svn: 209954
|
| |
|
|
|
|
| |
{extract,insert} vector element instructions.
llvm-svn: 209942
|
| |
|
|
|
|
| |
This presumably got inadvertently copied from dllimport-members.cpp.
llvm-svn: 209919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
|
| |
|
|
|
|
|
| |
an Objective-C object type other than 'id'.
// rdar://16739120
llvm-svn: 209906
|
| |
|
|
| |
llvm-svn: 209893
|
| |
|
|
|
|
| |
[basic.scope.pdecl]p10, and our current test for that is more thorough (though our test is named p9.cpp).
llvm-svn: 209892
|
| |
|
|
|
|
| |
test contents are acceptable. No diagnostics expected from this test.
llvm-svn: 209891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You could see unexpected result (*.tmp.err) with "-target x86_64-win32".
Weverything-and-remarks.cpp:11:9: warning: 'char32_t' type specifier is incompatible with C++98 [-Wc++98-compat]
typedef __char32_t char32_t;
^
Weverything-and-remarks.cpp:12:27: error: typedef redefinition with different types ('unsigned long' vs 'unsigned long long')
typedef long unsigned int size_t;
^
Weverything-and-remarks.cpp:19:62: warning: dynamic exception specifications are deprecated [-Wdeprecated]
static void assign(char_type& __c1, const char_type& __c2) throw() {
^~~~~~~
Weverything-and-remarks.cpp:19:62: note: use 'noexcept' instead
static void assign(char_type& __c1, const char_type& __c2) throw() {
^~~~~~~
noexcept
Weverything-and-remarks.cpp:25:46: warning: unused parameter '__n' [-Wunused-parameter]
size_t __n) {
^
3 warnings and 1 error generated.
llvm-svn: 209878
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
|
| |
|
|
|
|
| |
deleted default constructor
llvm-svn: 209869
|
| |
|
|
| |
llvm-svn: 209867
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics are special because they directly take a memory operand (AVX2
adds the register counterparts). Typically, other non-memop intrinsics take
registers and then it's left to isel to fold memory operands.
In order to LICM intrinsics directly reading memory, we require that no stores
are in the loop (LICM) or that the folded load accesses constant memory
(MachineLICM). When neither is the case we fail to hoist a loop-invariant
broadcast.
We can work around this limitation if we expose the load as a regular load and
then just implement the broadcast using the vector initializer syntax. This
exposes the load to LICM and other optimizations.
At the IR level this is translated into a series of insertelements. The
sequence is already recognized as a broadcast so there is no impact on the
quality of codegen.
_mm256_broadcast_pd and _mm256_broadcast_ps are not updated by this patch
because right now we lack the DAG-combiner smartness to recover the broadcast
instructions. This will be tackled in a follow-on.
There will be completing changes on the LLVM side to remove the LLVM
intrinsics and to auto-upgrade bitcode files.
Fixes <rdar://problem/16494520>
llvm-svn: 209846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
llvm-svn: 209839
|
| |
|
|
| |
llvm-svn: 209836
|
| |
|
|
| |
llvm-svn: 209831
|
| |
|
|
| |
llvm-svn: 209830
|