| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Reapplying patch in r272777 which was reverted
because the llvm patch which added support
for generating the mcrr/mcrr2 instructions
from the intrinsic was causing an assertion
failure. This has now been fixed in llvm.
llvm-svn: 272983
|
| |
|
|
|
|
| |
Use the marketing name for the MSVC release as pointed out by Nico Weber!
llvm-svn: 272979
|
| |
|
|
|
|
|
|
|
| |
This patch fixes a bug where we'd segfault (in some cases) if we saw a
variadic function with one or more pass_object_size arguments.
Differential Revision: http://reviews.llvm.org/D17462
llvm-svn: 272971
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
llvm-svn: 272963
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19764
llvm-svn: 272962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
earlier scopes
This code should be an error:
void foo(int);
void f3() {
int foo(float);
{
float foo(int); // expected-error {{functions that differ only in their return type cannot be overloaded}}
}
}
the foo(float) function declared at function scope should not hide the float(int)
while trying to redeclare functions.
Differential Revision: http://reviews.llvm.org/D19763
llvm-svn: 272961
|
| |
|
|
|
|
|
| |
This won't always be enough info to call a virtual method from the
debugger, but it's a start.
llvm-svn: 272944
|
| |
|
|
|
|
|
| |
Sibling patch to r272932:
http://reviews.llvm.org/rL272932
llvm-svn: 272933
|
| |
|
|
|
|
|
|
| |
so that they are compatible to what the runtime library expects.
An issue in one of the regression tests was fixed for 32-bit hosts.
llvm-svn: 272931
|
| |
|
|
|
|
|
|
| |
that they are compatible to what the runtime library expects.
Was causing trouble in one of the regression tests for a 32-bit address space.
llvm-svn: 272908
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compatible to what the runtime library expects.
Summary:
This patch fixes an issue detected when firstprivate variables are passed to an OpenMP outlined function vararg list. Currently they are not compatible with what the runtime library expects causing malfunction in some targets.
This patch fixes the issue by moving the casting logic already in place for offloading to the common code that creates the outline function and arguments and updates the regression tests accordingly.
Reviewers: hfinkel, arpith-jacob, carlo.bertolli, kkwli0, ABataev
Subscribers: cfe-commits, caomhin
Differential Revision: http://reviews.llvm.org/D21150
llvm-svn: 272900
|
| |
|
|
|
|
|
|
| |
This is now supported for ARM, AArch64, PowerPC, SystemZ, SPARC, Mips.
Differential Revision: http://reviews.llvm.org/D19589
llvm-svn: 272893
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the last patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Use IAMCU linker output format
* Link with IAMCU crt objects
* Link with IAMCU libraries
Differential Revision: http://reviews.llvm.org/D20675
llvm-svn: 272885
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Differential Revision: http://reviews.llvm.org/D19274
llvm-svn: 272883
|
| |
|
|
| |
llvm-svn: 272867
|
| |
|
|
|
|
|
|
| |
MS ABI types
We implemented the mangling for this a long time ago.
llvm-svn: 272862
|
| |
|
|
|
|
|
|
|
| |
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously if you did e.g.
$ clang -march=haswell -x cuda foo.cu
we would pass "-march=haswell -march=sm_20" down to the ptxas tool.
This causes it to assert, and rightly so!
Reviewers: tra
Subscribers: cfe-commits, echristo
Differential Revision: http://reviews.llvm.org/D21419
llvm-svn: 272857
|
| |
|
|
|
|
| |
Broken in r272717 because of no test coverage.
llvm-svn: 272853
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in the code comment, a potential follow-on would be to remove
the builtins themselves. Other than ord/unord, this already works as
expected. Eg:
typedef float v4sf __attribute__((__vector_size__(16)));
v4sf fcmpgt(v4sf a, v4sf b) { return a > b; }
Differential Revision: http://reviews.llvm.org/D21268
llvm-svn: 272840
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is adding command-line support for the MSVC buffer security check.
The buffer security check is turned on with the '/GS' compiler switch.
https://msdn.microsoft.com/en-us/library/8dbf701c.aspx
The MSVC buffer security check in implemented here:
http://reviews.llvm.org/D20346
Reviewers: hans, rnk
Subscribers: chrisha, cfe-commits, rnk, hans, thakis
Differential Revision: http://reviews.llvm.org/D20347
llvm-svn: 272832
|
| |
|
|
|
|
|
| |
Sibling patch to r272806:
http://reviews.llvm.org/rL272806
llvm-svn: 272807
|
| |
|
|
|
|
|
|
| |
remove accidentally checked-in code.
Related to revision r272782
llvm-svn: 272798
|
| |
|
|
|
|
|
| |
added in the llvm patch is causing an assertion
to fail.
llvm-svn: 272790
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 272789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When static variables are used in inline functions in header files anything that
uses that function ends up with a reference to the variable. Because
RecursiveASTVisitor uses the inline functions in LambdaCapture that use static
variables any AST plugin that uses RecursiveASTVisitor, such as the
PrintFunctionNames example, ends up with a reference to these variables. This is
bad on Windows when building with MSVC with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON
as variables used across a DLL boundary need to be explicitly dllimported in
the DLL using them.
This patch avoids that by adjusting LambdaCapture to be similar to before
r263921, with a capture of either 'this' or a VLA represented by a null Decl
pointer in DeclAndBits with an extra flag added to the bits to distinguish
between the two. This requires the use of an extra bit, and while Decl does
happen to be sufficiently aligned to allow this it's done in a way that means
PointerIntPair doesn't realise it and gives an assertion failure. Therefore I
also adjust Decl slightly to use LLVM_ALIGNAS to allow this.
Differential Revision: http://reviews.llvm.org/D20732
llvm-svn: 272788
|
| |
|
|
| |
llvm-svn: 272787
|
| |
|
|
|
|
|
|
| |
implemented in the back-end.
Differential Revision: http://reviews.llvm.org/D19798
llvm-svn: 272782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch adds intrinsics for mrrc/mrrc2. The
intrinsics for mrrc/mrrc2 return a single
uint64_t to represent two 32 bit values.
The mcrr/mcrr2 intrinsic was changed to
accept a single uint64_t instead of two
32 bit values as the input for consistency.
Differential Revision: http://reviews.llvm.org/D21179
llvm-svn: 272777
|
| |
|
|
|
|
|
|
| |
in template"
This reverts commit 0253605771b8bd9d414aba74fe2742c730d6fd1a.
llvm-svn: 272776
|
| |
|
|
|
|
|
|
|
|
| |
instantiation.
Added checks for non-dependent context when trygin to capture
non-constant schedule chunk expression for proper codegen of outlined
functions.
llvm-svn: 272775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
llvm-svn: 272774
|
| |
|
|
|
|
| |
checked against null.
llvm-svn: 272755
|
| |
|
|
|
|
|
| |
Earlier versions of MSVC did not include inttypes.h. Ensure that we dont try to
include_next on those releases.
llvm-svn: 272741
|
| |
|
|
|
|
|
| |
--dependent-lib arguments for the sanitizer libraries must be emitted when
coverage is enabled w/o any sanitizers.
llvm-svn: 272735
|
| |
|
|
|
|
| |
Reviewed as part of http://reviews.llvm.org/D20444
llvm-svn: 272720
|
| |
|
|
|
|
|
| |
The reason is that this (a) seems to work just fine and (b) useful when building stuff with
sanitizer+coverage, but need to exclude the sanitizer for a particular source file.
llvm-svn: 272717
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20339
llvm-svn: 272710
|
| |
|
|
| |
llvm-svn: 272702
|
| |
|
|
| |
llvm-svn: 272701
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: do not add existing includes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21323
llvm-svn: 272669
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before, this could be formatted at all (with BracketAlignmentStyle
AlwaysBreak):
foo = <Bar[]>[
1, /* */
2
];
llvm-svn: 272668
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21322
llvm-svn: 272667
|
| |
|
|
|
|
|
|
|
|
|
| |
The two patches together enable clang to support targets like
"x86_64-pc-linux-musl" and build binaries against musl-libc instead of
glibc. This make it easy for clang to work on some musl-based systems
like Alpine Linux and certain flavors of Gentoo.
Patch by Lei Zhang.
llvm-svn: 272662
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20626
llvm-svn: 272658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of these is specified the corresponding loop metadata is generated:
!{!"llvm.loop.distribute.enable", i1 true/false}
As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally. Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.
There are some slight differences compared to the existing loop pragmas.
1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.
2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'. So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas. We just need to check for duplicates of
the same pragma.
Reviewers: rsmith, dexonsmith, aaron.ballman
Subscribers: bob.wilson, cfe-commits, hfinkel
Differential Revision: http://reviews.llvm.org/D19403
llvm-svn: 272656
|
| |
|
|
| |
llvm-svn: 272654
|
| |
|
|
|
|
|
|
| |
This new diagnostic is causing some false positives that have to be addressed.
This reverts commit 272552
llvm-svn: 272653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalid cases.
Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
error: unknown target ABI 'n64'
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21023
llvm-svn: 272645
|
| |
|
|
|
|
|
|
|
|
|
|
| |
See https://llvm.org/bugs/show_bug.cgi?id=28100.
In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.
All regression tests pass.
Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.
llvm-svn: 272631
|