| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
re-exporting modules from the discarded definition to the retained definition.
llvm-svn: 281429
|
| |
|
|
|
|
|
|
| |
The AST walker wasn't visiting CXXConstructExprs before.
This is a follow-up to r281395.
llvm-svn: 281413
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CUDA target attributes are used for function overloading and must not be merged.
This fixes a bug where attributes were inherited during function template
specialization in CUDA and made it impossible for specialized function
to provide its own target attributes.
Differential Revision: https://reviews.llvm.org/D24522
llvm-svn: 281406
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual
bases of size 0, which prevented adding those non-virtual bases to
CGRecordLayout's NonVirtualBases. This caused clang to assert when
CGRecordLayout::getNonVirtualBaseLLVMFieldNo was called in
EmitNullConstant. This commit fixes the bug by ignoring zero-sized
non-virtual bases in EmitNullConstant.
rdar://problem/28100139
Differential Revision: https://reviews.llvm.org/D24312
llvm-svn: 281405
|
| |
|
|
| |
llvm-svn: 281401
|
| |
|
|
| |
llvm-svn: 281399
|
| |
|
|
|
|
|
|
| |
In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations because those are not reflected
in the AST. This adds a separate check for them.
llvm-svn: 281395
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a crash-on-invalid.
When parsing type arguments and protocols,
parseObjCTypeArgsOrProtocolQualifiers() calls ParseTypeName(), which tries to
find matching tokens for '[', '(', etc whenever they appear among potential
type names. If unmatched, ParseTypeName() yields a tok::eof token stream. This
leads to crashes since the parsing at this point is not expected to go beyond
the param list closing '>'.
Fix that by properly handling tok::eof in
parseObjCTypeArgsOrProtocolQualifiers() callers.
Differential Revision: https://reviews.llvm.org/D23852
rdar://problem/25063557
llvm-svn: 281383
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: compnerd, thakis, Prazek, majnemer, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24153
llvm-svn: 281378
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: thakis, compnerd, majnemer, rsmith, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24330
llvm-svn: 281375
|
| |
|
|
|
|
|
|
|
|
|
| |
AST may contain intermediate ParenExpr nodes
between MemberExpr and ArrayToPointerDecay.
This diff adjusts the check in ExprEngine::VisitMemberExpr accordingly.
Test plan: make -j8 check-clang-analysis
Differential revision: https://reviews.llvm.org/D24484
llvm-svn: 281373
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This mostly behaves cl.exe's behavior, even though clang-cl is stricter in some
corner cases and more lenient in others (see the included test).
To make the uuid declared previously here diagnostic work correctly, tweak
stripTypeAttributesOffDeclSpec() to keep attributes in the right order.
https://reviews.llvm.org/D24469
llvm-svn: 281367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ObjC type parameter, we used to have TypedefType that is canonicalized to
id or the bound type. We can't represent "T <protocol>" and thus will lose
the type information in the following example:
@interface MyMutableDictionary<KeyType, ObjectType> : NSObject
- (void)setObject:(ObjectType)obj forKeyedSubscript:(KeyType <NSCopying>)key;
@end
MyMutableDictionary<NSString *, NSString *> *stringsByString;
NSNumber *n1, *n2;
stringsByString[n1] = n2;
--> no warning on type mismatch of the key.
To fix the problem, we introduce a new type ObjCTypeParamType that supports
a list of protocol qualifiers.
We create ObjCTypeParamType for ObjCTypeParamDecl when we create
ObjCTypeParamDecl. We also substitute ObjCTypeParamType instead of TypedefType
on an ObjCTypeParamDecl.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23080
llvm-svn: 281358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix target options for fp32/64-denormals so that
+fp64-denormals is set if fp64 is supported
-fp32-denormals if fp32 denormals is not supported, or -cl-denorms-are-zero is set
+fp32-denormals if fp32 denormals is supported and -cl-denorms-are-zero is not set
If target feature fp32/64-denormals is explicitly set, they will override default options and options deduced from -cl-denorms-are-zero.
Differential Revision: https://reviews.llvm.org/D24512
llvm-svn: 281357
|
| |
|
|
| |
llvm-svn: 281298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281293
|
| |
|
|
|
|
|
|
| |
In c++1z, static_assert is not required to have a StringLiteral message, where
previously it was required. Update the AST Reader to be able to handle a
null StringLiteral.
llvm-svn: 281286
|
| |
|
|
|
|
|
|
| |
variables.")
Differential Revision: http://reviews.llvm.org/D20415
llvm-svn: 281285
|
| |
|
|
|
|
|
|
| |
This reverts commit r281276.
Many bots are failing.
llvm-svn: 281279
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.
Also reduce a test case for this slightly.
Implementing review feedback from David Blaikie on r281057.
llvm-svn: 281278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:
```
struct sockaddr {
/* snip */
char sa_data[14];
};
void foo(const char *s) {
size_t slen = strlen(s) + 1;
size_t added_len = slen <= 14 ? 0 : slen - 14;
struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
strcpy(sa->sa_data, s);
// ...
}
```
`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.
Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).
In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.
I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.
llvm-svn: 281277
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281276
|
| |
|
|
| |
llvm-svn: 281259
|
| |
|
|
|
|
|
| |
definition as visible in the discarded definition's module, as we do for
other kinds of definition.
llvm-svn: 281258
|
| |
|
|
|
|
|
|
|
| |
MSVC emits /include directives in the .drective section for the
__dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit).
This fixes PR30347.
llvm-svn: 281189
|
| |
|
|
|
|
|
| |
Without this, no tests fail if I remove the Diag() in the first if in
Sema::mergeMSInheritanceAttr().
llvm-svn: 281136
|
| |
|
|
|
|
|
|
|
|
|
|
| |
provided before trying to print it.
This fixes a segfault that occurs when function printPretty generated by
tablegen tries to print an optional argument of attribute
objc_bridge_related.
rdar://problem/28155469
llvm-svn: 281132
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When deserializing ObjCInterfaceDecl with definition data, if we already have
a definition, try to keep the definition invariant; also pull in the
categories even if it is not what getDefinition returns (this effectively
combines categories).
rdar://27926200
rdar://26708823
llvm-svn: 281119
|
| |
|
|
|
|
|
| |
This is a spiritual re-commit of r201375 with only a brief delay
for upgrading the green dragon builders.
llvm-svn: 281094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a bug where we were unable to compile the following CUDA
file with libstdc++ (didn't try libc++):
#include <future>
void foo() { std::shared_future<int> x; }
The problem is that <future> only defines std::shared_future if
__GCC_ATOMIC_INT_LOCK_FREE > 1. When we compiled this file for device,
the macro was set to 1, and then the class didn't exist at all.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: https://reviews.llvm.org/D24407
llvm-svn: 281089
|
| |
|
|
|
|
|
| |
In post-commit review, Richard suggested a better way to fix this.
rdar://27926200
llvm-svn: 281078
|
| |
|
|
|
|
| |
Doesn't work, but needs to be enabled in order to get there.
llvm-svn: 281071
|
| |
|
|
|
|
|
|
|
|
|
| |
The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.
llvm-svn: 281057
|
| |
|
|
|
|
|
|
|
|
| |
Our limited debug info optimizations are breaking down at DLL
boundaries, so we're going to evaluate the size impact of these
settings, and possibly change the default.
Users should be able to override our settings, though.
llvm-svn: 281056
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.
This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.
llvm-svn: 281053
|
| |
|
|
|
|
|
| |
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
llvm-svn: 280999
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23643
llvm-svn: 280998
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: thakis, Prazek, compnerd, rnk
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D24311
llvm-svn: 280997
|
| |
|
|
|
|
|
|
|
|
|
| |
In C mode, if we have a visible declaration but not a visible definition, a tag
defined in the declaration should be have a visible definition. In C++ we rely
on the ODR merging, whereas in C we cannot because each declaration of a
function gets its own set of declarations in its prototype scope.
Patch developed in collaboration with Richard Smith!
llvm-svn: 280984
|
| |
|
|
|
|
|
| |
This reverts commit r280889, as the original LLVM commits broke the thumb
buildbots.
llvm-svn: 280968
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Just a test for now, adapted from x86_64 tests of XRay.
This is one of 3 commits to different repositories of XRay ARM port. The
other 2 are:
1. https://reviews.llvm.org/D23931 (LLVM)
2. https://reviews.llvm.org/D23933 (compiler-rt)
Differential Review: https://reviews.llvm.org/D23932
llvm-svn: 280889
|
| |
|
|
| |
llvm-svn: 280852
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r280553 introduced an issue where we'd emit ambiguity errors for code
like:
```
void foo(int *, int);
void foo(unsigned int *, unsigned int);
void callFoo() {
unsigned int i;
foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
// but unsigned int*->unsigned int* is better than
// int*->int*.
}
```
This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.
Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:
```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```
...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.
llvm-svn: 280847
|
| |
|
|
|
|
|
|
| |
- Should diag on a function (clang-cl warns; it's an error in cl)
- Test the attribute on nested classes (clang-cl is more permissive and more
self-consistent than cl here)
llvm-svn: 280845
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a bug causing pch to be validated even though -fno-validate-pch is set. This patch fixes it.
ASTReader relies on ASTReaderListener to initialize SuggestedPredefines, which is required for compilations using PCH. Before this change, PCHValidator is the default ASTReaderListener. After this change, when -fno-validate-pch is set, PCHValidator is disabled, but we need a replacement ASTReaderListener to initialize SuggestedPredefines. Class SimpleASTReaderListener is implemented for this purpose.
This change only affects -fno-validate-pch. There is no functional change if -fno-validate-pch is not set.
If -fno-validate-pch is not set, conflicts in predefined macros between pch and current compiler instance causes error.
If -fno-validate-pch is set, predefine macros in current compiler override those in pch so that compilation can continue.
Differential Revision: https://reviews.llvm.org/D24054
llvm-svn: 280842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C++1z 6.4.1/p2:
If the if statement is of the form if constexpr, the value of the
condition shall be a contextually converted constant expression of type
bool [...]
C++1z 5.20/p4:
[...] A contextually converted constant expression of type bool is an
expression, contextually converted to bool (Clause4), where the
converted expression is a constant expression and the conversion
sequence contains only the conversions above. [...]
Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.
An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.
Also, fixes PR28470.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24158
llvm-svn: 280838
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move the logic for doing this from the ABI argument lowering into
EmitParmDecl, which runs for all parameters. Our codegen is slightly
suboptimal in this case, as we may leave behind a dead store after
optimization, but it's 32-bit inalloca, and this fixes the bug in a
robust way.
Fixes PR30293
llvm-svn: 280836
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: There was no definition for __nop function - added inline
assembly.
Patch by Albert Gutowski!
Reviewers: rnk, thakis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24286
llvm-svn: 280826
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse pragma intrinsic, display warning if the function isn't a builtin
function in clang and suggest including intrin.h.
Patch by Albert Gutowski!
Reviewers: aaron.ballman, rnk
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D23944
llvm-svn: 280825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the virtual method comes from a secondary vtable, then the type of
the 'this' parameter should be i8*, and not a pointer to the complete
class. In the MS ABI, the 'this' parameter on entry points to the vptr
containing the virtual method that was called, so we use i8* instead of
the normal type. We had a mismatch where the CGFunctionInfo of the call
didn't match the CGFunctionInfo of the declaration, and this resulted in
some assertions, but now both sides agree the type of 'this' is i8*.
Fixes one issue raised in PR30293
llvm-svn: 280815
|