| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
When tools like llvm-cov show regions, it's much easier to understand
what's happening if the condition of an if shows a counter as well as
the body.
llvm-svn: 229813
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The definition for _mm256_insert_epi64 was taking an int, which would get
truncated before being inserted in the vector.
Original patch by Joshua Magee!
Reviewers: bruno, craig.topper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7179
llvm-svn: 229811
|
| |
|
|
|
|
|
| |
We didn't have enough qualificaiton before the scope specifier and we
had too much qualification in the destructor name itself.
llvm-svn: 229809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
|
| |
|
|
|
|
| |
conversion.
llvm-svn: 229792
|
| |
|
|
|
|
| |
support incremental transition to modules.
llvm-svn: 229788
|
| |
|
|
|
|
| |
Committing patch http://reviews.llvm.org/D6800.
llvm-svn: 229783
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The coverage mapping generation code previously generated a large
number of redundant coverage regions and then tried to merge similar
ones back together. This then relied on some awkward heuristics to
prevent combining of regions that were importantly different but
happened to have the same count. The end result was inefficient and
hard to follow.
Now, we more carefully create the regions we actually want. This makes
it much easier to create regions at precise locations as well as
making the basic approach quite a bit easier to follow. There's still
a fair bit of complexity here dealing with included code and macro
expansions, but that's pretty hard to avoid without significantly
reducing the quality of data we provide.
I had to modify quite a few tests where the source ranges became more
precise or the old ranges seemed to be wrong anyways, and I've added
quite a few new tests since a large number of constructs didn't seem
to be tested before.
llvm-svn: 229748
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 229726
|
| |
|
|
|
|
|
|
|
| |
extern "C" declarations should be considered like global declarations
for mangling purposes.
Differential Revision: http://reviews.llvm.org/D7718
llvm-svn: 229724
|
| |
|
|
|
|
|
|
|
|
|
| |
What's going on here is that the ternary operator produces a std::string rvalue
that the StringRef points to. I'd hoped bugs like this were a thing of the past
with our asan testing but apparently this code path is only used when LLVM is
configured with a custom --with-c-include-dirs setting.
Unbreaks bootstrapping with GCC5 on Fedora (PR22625), patch by Jonathan Wakely!
llvm-svn: 229719
|
| |
|
|
|
|
|
|
| |
This fixes PR22492, which is in response to CWG issue #1204.
Per the CWG issue 'contexpr' variables are now allowed in
for range loops.
llvm-svn: 229716
|
| |
|
|
|
|
|
|
| |
Based on Java annotation support and style.
Patch by Martin Probst.
llvm-svn: 229703
|
| |
|
|
|
|
|
|
|
|
| |
This adds support for JavaScript class definitions (again following
TypeScript & AtScript style). This only required support for
visibility modifiers in JS, everything else was already working.
Patch by Martin Probst, thank you.
llvm-svn: 229701
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for type annotations that follow TypeScript's,
Flow's, and AtScript's syntax style.
Patch by Martin Probst, thank you.
Review: http://reviews.llvm.org/D7721
llvm-svn: 229700
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7148
llvm-svn: 229680
|
| |
|
|
|
|
|
|
| |
The member gets invalidated as elements are added to the dense set. Directly
access the underlying pointer instead. Not sure how to create a test case for
this :-(. Maybe Richard can help.
llvm-svn: 229673
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We attempted to be compatible with GCC's buggy mangling for templates
with a declaration for a template argument.
However, we weren't completely successful in copying their bug in cases
like:
char foo;
template <char &C> decltype(C) f() { return foo; };
template char &f<foo>();
Instead, just follow the ABI specification. This fixes PR22621.
llvm-svn: 229644
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation is to fix a crash on
struct S {} s;
Foo S::~S() { s.~S(); }
What was happening here was that S::~S() was marked as invalid since its
return type is invalid, and as a consequence CheckFunctionDeclaration() wasn't
called and S::~S() didn't get merged into S's implicit destructor. This way,
the class ended up with two destructors, which confused the overload printer
when it suddenly had to print two possible destructors for `s.~S()`.
In addition to fixing the crash, this change also seems to improve diagnostics
in a few other places, see test changes.
Crash found by SLi's bot.
llvm-svn: 229639
|
| |
|
|
| |
llvm-svn: 229637
|
| |
|
|
|
|
|
| |
Un-parameterize the warning as there is exactly one attribute added in C++14.
Partially addresses post-commit review comments from Richard Smith.
llvm-svn: 229636
|
| |
|
|
| |
llvm-svn: 229616
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Our mangling of <destructor-name> wasn't quite right: we'd introduce
mangling substitutions where one shouldn't be possible. We also didn't
correctly handle the case where the destroyed type was not dependent but
still a TemplateSpecializationType.
N.B. There isn't a mangling for a template-template parameter showing up
as the destroyed type. We do the 'obvious' thing and mangle the index
of the parameter.
llvm-svn: 229615
|
| |
|
|
|
|
| |
-fdefine-sized-deallocation, and from DefaultSizedDelete to DefineSizedDeallocation.
llvm-svn: 229597
|
| |
|
|
| |
llvm-svn: 229593
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 229557
|
| |
|
|
|
|
| |
Reverting this while build bot failures are investigated.
llvm-svn: 229550
|
| |
|
|
|
|
|
|
| |
This fixes PR22492, which is in response to CWG issue #1204.
Per the CWG issue 'contexpr' variables are now allowed in
for range loops.
llvm-svn: 229543
|
| |
|
|
|
|
| |
Found by SLi's bot.
llvm-svn: 229532
|
| |
|
|
|
|
| |
the -target-abi use and those features don't exist anymore.
llvm-svn: 229526
|
| |
|
|
| |
llvm-svn: 229510
|
| |
|
|
|
|
| |
Same functionality, but hoists the vector growth out of the loop.
llvm-svn: 229508
|
| |
|
|
|
|
|
| |
This should help LSan detect leaks where operator new would otherwise be
optimized out.
llvm-svn: 229498
|
| |
|
|
| |
llvm-svn: 229486
|
| |
|
|
| |
llvm-svn: 229485
|
| |
|
|
|
|
| |
instead of intrinsics. This should allow the instrinsics to removed from the backend.
llvm-svn: 229474
|
| |
|
|
|
|
| |
that handles both.
llvm-svn: 229469
|
| |
|
|
|
|
| |
This code is unreachable since its already marked for non-custom handling in llvm's IntrinsicsX86.td file.
llvm-svn: 229468
|
| |
|
|
|
|
|
| |
warning when property getter is used in direct method call
and return value of property is unused. rdar://19773512
llvm-svn: 229458
|
| |
|
|
|
|
| |
diagnosed.
llvm-svn: 229454
|
| |
|
|
| |
llvm-svn: 229450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
|
| |
|
|
|
|
|
|
|
| |
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case that we diagnosed an invalid attribute due to missing or present
arguments, we would return false, indicating to the caller that the parsing
failed. However, we would have added the attribute in ParseAttributeArgsCommon
(which may have been called indirectly through ParseGNUAttributeArgs).
Returning true in this case ensures that a second copy of the attribute is not
added.
I haven't added a test case for this as the existing test will cover this with
the next commit which diagnoses a C++14 attribute applied in C++11 mode. Rather
than duplicating the existing test case, allow the tree to remain without a test
between this and the next change. We would see double warnings in the
[[deprecated()]] applied to a declaration in C++11 mode, which will cause an
error in the cxx0x-attributes test.
llvm-svn: 229446
|
| |
|
|
| |
llvm-svn: 229435
|
| |
|
|
|
|
| |
Update for the API change in r229433
llvm-svn: 229434
|
| |
|
|
| |
llvm-svn: 229432
|
| |
|
|
| |
llvm-svn: 229428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass and return in registers
This is a patch for PR22563 ( http://llvm.org/bugs/show_bug.cgi?id=22563 ).
We were not correctly unwrapping a single 256-bit AVX vector that was defined as an array of 1 inside a struct.
We would generate a <4 x float> param/return value instead of <8 x float> and lose half of the vector.
Differential Revision: http://reviews.llvm.org/D7614
llvm-svn: 229408
|