Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
llvm-svn: 262737
Clauses with post-update expressions always have pre-init statement. So
OMPClauseWithPreInit now is the base for OMPClauseWithPostUpdate.
llvm-svn: 262696
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
llvm-svn: 262582
I should have checked and imported D's in-class initializer.
Instead I accidentally used ToField's in-class initializer,
which is always NULL so ToField will never get one.
<rdar://problem/24943405>
llvm-svn: 262576
Previously, the ASTImporter, when copying a FieldDecl, would make the
new FieldDecl use the exact same in-class initializer as the original
FieldDecl, which is a problem since the initializer is in the wrong AST.
The initializer must be imported, just like all the other parts of the
field.
Doug Gregor reviewed this fix.
<rdar://problem/24943405>
llvm-svn: 262572
This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.
llvm-svn: 262506
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
llvm-svn: 262493
OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch supports codegen for non-static
data members in 'reduction' clauses.
llvm-svn: 262460
ARC ownership-convention function type modifications.
According to the Itanium ABI, vendor extended qualifiers are
supposed to be mangled in reverse-alphabetical order before
any CVR qualifiers. The ARC function type conventions are
plausibly order-significant (they are associated with the
function type), which permits us to ignore the need to correctly
inter-order them with any other vendor qualifiers on the parameter
and return types.
Implementing these rules correctly is technically an ABI break.
Apple is comfortable with the risk of incompatibility here for
the ARC features, and I believe that address-space qualification
is still uncommon enough to allow us to adopt the conforming
rule without serious risk. Still, targets which make heavy
use of address space qualification may want to revert to the
non-conforming order.
llvm-svn: 262414
to allow arbitrary data to be associated with a parameter.
Also, fix a bug where we apparently haven't been serializing
this information for the last N years.
llvm-svn: 262278
OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch adds initial parsing/semantic
analysis for data members support in 'reduction' clauses.
llvm-svn: 262199
If the availability context is `FunctionTemplateDecl`, we should look
through it to the `FunctionDecl`. This prevents a diagnostic in the
following case:
class C __attribute__((unavailable));
template <class T> void foo(C&) __attribute__((unavailable));
This adds tests for availability in templates in many other cases, but
that was the only case that failed before this patch.
I added a feature `__has_feature(attribute_availability_in_templates)`
so users can test for this.
rdar://problem/24561029
llvm-svn: 262050
A member expression's base doesn't always have an impact on what the
member decl would evaluate to. In such a case, the base is used as a
poor man's scope qualifier.
This fixes PR26738.
Differential Revision: http://reviews.llvm.org/D17619
llvm-svn: 261975
OpenMP 4.5 allows to privatize non-static member decls in non-static
member functions. Patch captures such decls by reference in general (for
bitfields, by value) and then operates with this capture. For bitfields,
at the end of codegen for lastprivates original bitfield is updated with the value of captured copy.
llvm-svn: 261824
r261297 called hasUserProvidedDefaultConstructor() to check if defining a
const object is ok. This is incorrect for this example:
struct X { template<typename ...T> X(T...); int n; };
const X x; // formerly OK, now bogus error
Instead, track if a class has a defaulted default constructor, and disallow
a const object for classes that either have defaulted default constructors or
if they need an implicit constructor.
Bug report and fix approach by Richard Smith, thanks!
llvm-svn: 261770
"aligned", by Vladimir Yakovlev
Fix clang/gcc incompatibility of bitfields layout in the presence of
pragma packed and attributes aligned and packed.
Differential Revision: http://reviews.llvm.org/D17023
llvm-svn: 261321
For templates, fields can have incomplete types:
template <class T>
struct A2 {
struct B;
B b;
};
Don't try to touch the DefinitionData of those fields.
llvm-svn: 261301
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
llvm-svn: 261297
Expressions inside 'schedule'|'dist_schedule' clause must be captured in
combined directives to avoid possible crash during codegen. Patch
improves handling of such constructs
llvm-svn: 260954
This patch fixes the following bugs in __builtin_classify_type implementation:
1) Support for member functions and fields
2) Same behavior as GCC in C mode (specifically, return integer_type_class for
enums and pointer_type_class for function pointers and arrays). Behavior in
C++ mode didn't changed.
Also, it refactors the whole implementation, by replacing a sequence of
if-else-if with a couple of switches.
Differential Revision: http://reviews.llvm.org/D16846
llvm-svn: 260881
Enable it for USRs and names when indexing.
Forward references can have different template argument names; including them
makes USRs and names unstable, since the name depends on whether we saw a forward reference or not.
llvm-svn: 260866
Fix a crash while parsing this code:
struct X {
friend constexpr int foo(X*) { return 12; }
static constexpr int j = foo(static_cast<X*>(nullptr));
};
Differential Revision: http://reviews.llvm.org/D16973
llvm-svn: 260675
The library functions defined in the C99 standard headers
are not available (OpenCL v1.2 s6.9.f).
This change stops treating OpenCL builtin functions as standard C lib
functions to eliminate warning messages about printf format string.
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16812
llvm-svn: 260671
This reverts commit r260449.
We would supress our emission of vftable definitions if we thought
another translation unit would provide the definition because we saw an
explicit instantiation declaration. This is not the case with
dllimport, we want to synthesize a definition of the vftable regardless.
This fixes PR26569.
llvm-svn: 260548
OMPCapturedExprDecl allows caopturing not only of fielddecls, but also
other expressions. It also allows to simplify codegen for several
clauses.
llvm-svn: 260492
Referencing a dllimported vtable is impossible in a constexpr
constructor. It would be friendlier to C++ programmers if we
synthesized a copy of the vftable which referenced imported virtual
functions. This would let us initialize the object in a way which
preserves both the intent to import functionality from another DLL while
also making constexpr work.
Differential Revision: http://reviews.llvm.org/D17061
llvm-svn: 260388
OpenMP 4.5 introduces privatization of non-static data members of current class in non-static member functions.
To correctly handle such kind of privatization a new (pseudo)declaration VarDecl-based node is added. It allows to reuse an existing code for capturing variables in Lambdas/Block/Captured blocks of code for correct privatization and codegen.
llvm-svn: 260077
Codegen for array sections/array subscripts worked only for expressions with arrays as base. Patch fixes codegen for bases with pointer/reference types.
llvm-svn: 259776
Per review feedback the name was wrong and it can be used outside
Objective-C.
Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type. I'm worried that this will also affect
users' code. So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup. This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.
rdar://problem/24425801
llvm-svn: 259734
Original message:
Make CF constant string decl visible to name lookup to fix module errors
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259721
Summary:
This patch adds parsing + sema for the target parallel for directive along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16759
llvm-svn: 259654
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259624
actual source name of the typedef or a vendor mangling) but at least it stands
a chance of demangling now.
We would also benefit from some test coverage of this (OpenCL +
__attribute__((overloadable)) is probably required to reach this).
llvm-svn: 259618
For ObjCXX, we can create a CastExpr with Kind being CK_UserDefinedConversion
and SubExpr being BlockExpr. Specifically one can return BlockExpr from
BuildCXXMemberCallExpr and the result can be used to build a CastExpr.
Fix the assumption in CastExpr::getSubExprAsWritten that SubExpr can only
be CXXMemberCallExpr.
rdar://problem/24364077
llvm-svn: 259591
When all the arguments of a template are elided, print "A<...>" instead of
"A<[2 * ...]>". Also remove comment fragment that means nothing.
llvm-svn: 259445
PropertyMap used to map IdentifierInfo (name of the property) to
ObjcPropertyDecl *. Now that a class property can have the same name as
an instance property, we change PropertyMap to map a pair <IdentifierInfo *,
unsigned> to ObjcPropertyDecl *.
Also update a few places from iterating over instance_properties to
iterating over all properties.
rdar://23891898
llvm-svn: 259119
Add "enum ObjCPropertyQueryKind" to a few APIs that used to only take the name
of the property: ObjCPropertyDecl::findPropertyDecl,
ObjCContainerDecl::FindPropertyDeclaration,
ObjCInterfaceDecl::FindPropertyVisibleInPrimaryClass,
ObjCImplDecl::FindPropertyImplDecl, and Sema::ActOnPropertyImplDecl.
ObjCPropertyQueryKind currently has 3 values:
OBJC_PR_query_unknown, OBJC_PR_query_instance, OBJC_PR_query_class
This extra parameter specifies that we are looking for an instance property with
the given name, or a class property with the given name, or any property with
the given name (if both exist, the instance property will be returned).
rdar://23891898
llvm-svn: 259070
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
This is the third patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258834
Summary:
This patch adds parsing + sema for the target parallel directive and its clauses along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16553
Rebased to current trunk and updated test cases.
llvm-svn: 258832
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258824
Summary:
This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others).
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16527
llvm-svn: 258817
__GetExceptionInfo triggered Sema::LazilyCreateBuiltin which tries to
create a non-templated function decl. This is unnecessary and
ill-advised, there is no need for us to create a declaration for such a
builtin.
This fixes PR26298.
llvm-svn: 258762
Tag and specifier printing can be suppressed in Decl::printGroup, but these suppressions leak into the initializers. Thus
int *x = ((void *)0), *y = ((void *)0);
gets printed as
int *x = ((void *)0), *y = ((*)0);
And
struct { struct Z z; } z = {(struct Z){}};
gets printed as
struct { struct Z z; } z = {(){}};
The stops the suppressions from leaking into the initializers.
Patch by Nick Sumner!
Differential Revision: http://reviews.llvm.org/D16438
llvm-svn: 258679
Support for the following OpenMP 4.5 restriction on 'target enter data' and 'target exit data':
- A map-type must be specified in all map clauses.
I have to save 'IsMapTypeImplicit' when parsing a map clause to support this constraint and for more informative error messages. This helps me support the following case:
#pragma omp target enter data map(r) // expected-error {{map type must be specified for '#pragma omp target enter data'}}
and distinguish it from:
#pragma omp target enter data map(tofrom: r) // expected-error {{map type 'tofrom' is not allowed for '#pragma omp target enter data'}}
Patch by Arpith Jacob. Thanks!
llvm-svn: 258179
We might get into bad situations where we try to embed the signature of
an inner lambda into an outer lambda which cannot work: the inner lambda
wants to embed the name of the outer lambda!
Instead, omit the return type for lambdas.
This fixes PR26105.
N.B. While we are here, make lambdas nested within functions use an
artificial scope so that they can get demangled.
llvm-svn: 258003
1) Print qualifiers for templates with zero arguments
2) Add a few more tests for the template type diffing refactoring.
Specifically, PR24587 has been fixed and has a test case from
http://reviews.llvm.org/D15384
3) Adds asserts to check the DiffTree is in correct state when moving nodes
4) Rename the field FromType and ToType since it is heavily used within
member functions.
llvm-svn: 257870
Remove an old assertion that does not hold. It is possible for a template
argument to be a declaration in one instantiation and an integer in another.
Create two new diff kinds for these (decl vs int and int vs decl).
llvm-svn: 257869
Save the integer type when diffing integers in template type diffing. When
integers are different sizes, print out the type along with the integer value.
Also with the type information, print true and false instead of 1 and 0 for
boolean values.
llvm-svn: 257861
If available, use the canonical template argument to fill in information for
template type diffing instead of attempting to special case and evaluate Expr's
for the value. Since those are the values used in template instantiation,
we don't have to worry about difference between our evaluator and theirs. Also
move the nullptr template arguments from DiffKind::Expression to
DiffKind::Declaration and allow DiffKind::Declaration to set an Expr. The only
effect that should result is that a named nullptr will show up as
'ptr aka nullptr' in diagnostics.
llvm-svn: 257853
Value, type, and instantiation dependence were not being handled
correctly for CUDAKernelCallExpr AST nodes. As a result, if an
undeclared identifier was used in the triple-angle-bracket kernel call
configuration, there would be no error during parsing, and there would
be a crash during code gen. This patch makes sure that an error will be
issued during parsing in this case, just as there would be for any other
use of an undeclared identifier in C++.
Patch by Jason Henline.
Reviewers: jlebar, rsmith
Differential Revision: http://reviews.llvm.org/D15858
llvm-svn: 257839
Modify the TSTiterator to have two internal iterators, which will walk
the provided sugared type and the desugared type. This will provide better
access to the template argument information. No functional changes.
llvm-svn: 257838
1) Instead of using pairs of From/To* fields, combine fields into a struct
TemplateArgInfo and have two in each DiffNode.
2) Use default initialization in DiffNode so that the constructor shows the
only field that is initialized differently on construction.
3) Use Set and Get functions per each DiffKind to make sure all fields for the
diff is set. In one case, the Expr fields were not set.
4) Don't print boolean literals for boolean template arguments. This prevents
printing 'false aka 0'
Only #3 has a functional change, which is reflected in the test change.
llvm-svn: 257831
In {CG,}ExprConstant.cpp, we weren't treating vector splats properly.
This patch makes us treat splats more properly.
Additionally, this patch adds a new cast kind which allows a bool->int
cast to result in -1 or 0, instead of 1 or 0 (for true and false,
respectively), so we can sanely model OpenCL bool->int casts in the AST.
Differential Revision: http://reviews.llvm.org/D14877
llvm-svn: 257559
1) When dumping a declaration that declares a name for a type, also dump the named type.
2) Add a #pragma clang __debug dump X, that dumps the lookup results for X in
the current context.
llvm-svn: 257529
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
into IDNS_Tag in C++, because they conflict with redeclarations of tags. (This
doesn't affect elaborated-type-specifier lookup, which looks for IDNS_Type in
C++).
llvm-svn: 256985
By storing the instantiated expression back in the ParmVarDecl,
we remove the last need for separately storing the sub-expression
of a CXXDefaultArgExpr. This makes PCH/Modules merging quite
simple: CXXDefaultArgExpr records are serialized as references
to the ParmVarDecl, and we ignore redundant attempts to overwrite
the instantiated expression.
This has some extremely marginal impact on user-facing semantics.
However, the major effect is that it avoids IRGen errors about
conflicting definitions due to lambdas in the argument being
instantiated multiple times while sharing the same mangling.
It should also slightly improve memory usage and module file size.
rdar://23810407
llvm-svn: 256983
Only function template specializations are exempt from being added to
the NameBackReferences. Redundant variable template specializations
should be appropriately substituted.
llvm-svn: 256623
We didn't add the artificial pass_object_size arguments to the
backreference map which bloated the size of manglings which involved
pass_object_size with duplicate types.
This lets us go from:
?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z
to:
?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z
llvm-svn: 256622
for types which are used as pointees in PointerUnions, PointerIntPairs,
and DenseMap pointer keys.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
I think this is the last patch for getting Clang clean here!!!
llvm-svn: 256615
keys, and PointerIntPairs where the pointee types are incomplete
out-of-line to where we have the complete type.
This is the standard pattern used throughout the AST library to address
the inherently mutually cross referenced nature of the AST.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256612
SmallVector<.., 16> (16!!!!) objects to a simple SmallVector of pairs.
This no longer de-duplicates the common function pointers used during
deallocation, but this doesn't really seem worth the complexity and
overhead of managing the map-of-vectors. Notably, there is no reason to
assume that functions have the 4-byte alignment that DenseMap relies on,
and indeed this prevents checking the alignment of the DenseMap keys
because we can't even meaningfully query the alignment of functions
using our existing alignment tools.
Generally, function pointers don't seem like a great idea for keys in
a DenseMap. =]
I chatted with Richard Smith about this a bit as well and have written
down a FIXME because this *does* waste some memory and in general seems
a very clumsy memory management strategy. He would like to see a more
fundamental fix eventually here that tries to build a better pattern.
llvm-svn: 256610
indicating the nature of the default argument in a ParmVarDecl.
Instead, this adds a proper enum stored exclusively in the ParmVarDecl
bits (which we have plenty of) for this. This even allows us to track
a previously unrepresented state in Clang when we parse a function
declaration with a default argument on a parameter but we cannot even
form an invalid expression node (for example, it is an invalid token).
Now, we can model this state in the AST at least, and potentially
improve recovery in this area in the future.
I've also cleaned up the functions managing both variable initializer
expressions and parameter default argument expresssions as much as
possible. I've left some comments about further improvements based on
a discussion with Richard Smith. Lots of credit to him for walking me
through exactly which of the *many* tradeoffs here he felt was the best
fit.
Should be NFC for now. I've tried my best to preserve existing behavior.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
llvm-svn: 256609
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
Also remove now-redundant explicit alignment specification on some of
the classes converted prior to TrailingObjects automatically ensuring
proper alignment.
llvm-svn: 256585
MSVC doesn't implement a mangling for C99's _Complex so we must invent
our own.
For now, treating it like a class type called _Complex in the __clang
namespace.
This means that 'void f(__Complex int))'
will demangle as: 'void f(struct __clang::_Complex<int>)'
llvm-svn: 256583
So, also:
- Moved the TemplateArgumentLoc array out of the
ASTTemplateKWAndArgsInfo class (making it a simple fixed-size object),
to avoid needing to have a variable-length object as part of a
variable-length object. Now the objects that have a
ASTTemplateKWAndArgsInfo also have some TemplateArgumentLoc objects
appended directly.
- Removed some internal-use accessors which became simply a wrapper on
getTrailingObjects.
- Moved MemberNameQualifier out of the MemberExpr class, renamed it
MemberExprNameQualifier, because the template can't
refer to a class nested within the class it's defining.
llvm-svn: 256570
MSVC doesn't implement a mangling for C11's _Atomic so we must invent
our own.
For now, treating it like a class type called _Atomic in the __clang
namespace.
This means that 'void f(__Atomic(int))'
will demangle as: 'void f(struct __clang::_Atomic<int>)'
llvm-svn: 256557
We used to produce a type which demangled to:
union __clang_vec8_F
That 'F' is the mangling for 'short' but it is present in the mangled
name in an inappropriate place, leading to it not getting demangled.
Instead, create a synthetic class type in a synthetic namespace called
__clang. With this, it now demangles to:
union __clang::__vector<short,8>
llvm-svn: 256556
LocInfoType is a helper type used internally inside Sema and Parser, it
does not exist in valid AST. LocInfoType uses code value outside the
range of valid Type codes, as a result, dumping such type causes error.
The fix allows correct dumping LocInfoType.
llvm-svn: 256503
OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size])
Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’.
OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size])
Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’.
llvm-svn: 256487
Doing so required separating them so that the former doesn't inherit
from the latter anymore. Investigating that, it became clear that the
inheritance wasn't actually providing real value in any case.
So also:
- Remove a bunch of redundant functions (getExplicitTemplateArgs,
getOptionalExplicitTemplateArgs) on various Expr subclasses which
depended on the inheritance relationship.
- Switched external callers to use pre-existing accessors that return the
data they're actually interested in (getTemplateArgs,
getNumTemplateArgs, etc).
- Switched internal callers to use pre-existing getTemplateKWAndArgsInfo.
llvm-svn: 256359
OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct.
llvm-svn: 255986
C++ emits vtables for classes that have key function present in the
current TU. While we compile CUDA the fact that key function was found
in this TU does not mean that we are going to generate code for it. E.g.
vtable for a class with host-only methods should not (and can not) be
generated on device side, because we'll never generate code for them
during device-side compilation.
This patch adds an extra CUDA-specific check during key method computation
and filters out potential key methods that are not suitable for this side
of CUDA compilation.
When we codegen vtable, entries for unsuitable methods are set to null.
Differential Revision: http://reviews.llvm.org/D15309
llvm-svn: 255911
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
llvm-svn: 255346
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
llvm-svn: 255337
implicitly-concatenated string literals. When looking for the start of a token
in the inline assembly, start from the end of the previous token, not the start
of the entire string.
Patch by Yunlian Jiang!
llvm-svn: 255198
OpenMP 4.5 adds directives 'taskloop' and 'taskloop simd'. These directives support clause 'num_tasks'. Patch adds parsing/semantic analysis for this clause.
llvm-svn: 255008
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.
llvm-svn: 254992
OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause.
llvm-svn: 254903
OpenMP 4.5 adds 'taskloop' and 'taskloop simd' directives. These directives have new 'nogroup' clause. Patch adds basic parsing/sema support for this clause.
llvm-svn: 254899
to treat as an ICE results in undefined behavior. Instead, return the "natural"
result of the operation (signed wraparound / inf / nan).
llvm-svn: 254699
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
Summary:
This patch implements the 4.5 specification for the implicit data maps. OpenMP 4.5 specification changes the default way data is captured into a target region. All the non-aggregate kinds are passed by value by default. This required activating the capturing by value during SEMA for the target region. All the non-aggregate values that can be encoded in the size of a pointer are properly casted and forwarded to the runtime library. On top of fixing the previous weird behavior for mapping pointers in nested data regions (an explicit map was always required), this also improves performance as the number of allocations/transactions to the device per non-aggregate map are reduced from two to only one - instead of passing a reference and the value, only the value passed.
Explicit maps will be added later on once firstprivate, private, and map clauses' SEMA and parsing are available.
Reviewers: hfinkel, rjmccall, ABataev
Subscribers: cfe-commits, carlo.bertolli
Differential Revision: http://reviews.llvm.org/D14940
llvm-svn: 254521
OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives.
llvm-svn: 254398
MSVC supports 'property' attribute and allows to apply it to the declaration of an empty array in a class or structure definition.
For example:
```
__declspec(property(get=GetX, put=PutX)) int x[];
```
The above statement indicates that x[] can be used with one or more array indices. In this case, i=p->x[a][b] will be turned into i=p->GetX(a, b), and p->x[a][b] = i will be turned into p->PutX(a, b, i);
Differential Revision: http://reviews.llvm.org/D13336
llvm-svn: 254067
When RAV traverses a Stmt or Expr node, if the corresponding Traverse*
functions have not been overridden, it will now use data recursion to walk
those nodes. We arrange this to be an unobservable optimization to RAV
subclasses, and to gracefully degrade as parts of the visitation are overridden
with functions that might observe the visitation.
For instance, if an RAV subclass overrides TraverseUnaryNot, we will ensure
that there are real recursive stack frames for those traversals, but we'll
use data recursion for all other traversals.
This removes the need for DataRecursiveASTVisitor, and for the
'shouldUseDataRecursionFor' extension point, both of which are removed by this
change.
llvm-svn: 253948
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
llvm-svn: 253534
In the Microsoft ABI, the vftable is laid out in the order in the
declaration order of the entities defined within it.
Obviously, only virtual methods end up in the vftable but they will be
placed into the table at the same position as the first entity with the
same name.
llvm-svn: 253523
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
Summary: Use "auto" when the type name is redundant
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14501
llvm-svn: 252494
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
llvm-svn: 252036
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)
llvm-svn: 251898
A 'readonly' Objective-C property declared in the primary class can
effectively be shadowed by a 'readwrite' property declared within an
extension of that class, so long as the types and attributes of the
two property declarations are compatible.
Previously, this functionality was implemented by back-patching the
original 'readonly' property to make it 'readwrite', destroying source
information and causing some hideously redundant, incorrect
code. Simplify the implementation to express how this should actually
be modeled: as a separate property declaration in the extension that
shadows (via the name lookup rules) the declaration in the primary
class. While here, correct some broken Fix-Its, eliminate a pile of
redundant code, clean up the ARC migrator's handling of properties
declared in extensions, and fix debug info's naming of methods that
come from categories.
A wonderous side effect of doing this write is that it eliminates the
"AddedObjCPropertyInClassExtension" method from the AST mutation
listener, which in turn eliminates the last place where we rewrite
entire declarations in a chained PCH file or a module file. This
change (which fixes rdar://problem/18475765) will allow us to
eliminate the rewritten-decls logic from the serialization library,
and fixes a crash (rdar://problem/23247794) illustrated by the
test/PCH/chain-categories.m example.
llvm-svn: 251874
This sets the mostly expected Darwin default ABI options for these two
platforms. Active changes from these defaults for watchOS are in a later patch.
llvm-svn: 251708
This relands r250831 after some fixes to shrink the ParentMap overall
with one addtional tweak: nodes with pointer identity (e.g. Decl* and
friends) can be store more efficiently so I put them in a separate map.
All other nodes (so far only TypeLoc and NNSLoc) go in a different map
keyed on DynTypedNode. This further uglifies the code but significantly
reduces memory overhead.
Overall this change still make ParentMap significantly larger but it's
nowhere as bad as before. I see about 25 MB over baseline (pre-r251008)
on X86ISelLowering.cpp. If this becomes an issue we could consider
splitting the maps further as DynTypedNode is still larger (32 bytes)
than a single TypeLoc (16 bytes) but I didn't want to introduce even
more complexity now.
Differential Revision: http://reviews.llvm.org/D14011
llvm-svn: 251101
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
These are by far the most common types to be parents in the AST so it makes
sense to optimize for them. Put them directly into the value of the map.
This currently saves 32 bytes per parent in the map and a pointer
indirection at the cost of some additional complexity in the code.
Sadly this means we cannot return an ArrayRef from getParents anymore, add
a proxy class that can own a single DynTypedNode and otherwise behaves
exactly the same as ArrayRef.
For example on a random large file (X86ISelLowering.cpp) this reduces the
size of the parent map by 24 MB.
Differential Revision: http://reviews.llvm.org/D13976
llvm-svn: 251008
We believed that internal linkage variables at global scope which are
not variable template specializations did not have to be mangled.
However, static anonymous unions have no identifier and therefore must
be mangled.
This fixes PR18204.
llvm-svn: 250997
Putting DynTypedNode in the ParentMap bloats its memory foot print.
Before the void* key had 8 bytes, now we're at 40 bytes per key which
can mean multiple gigabytes increase for large ASTs and this count
doesn't even include all the added TypeLoc nodes. Revert until I come
up with a better data structure.
This reverts commit r250831.
llvm-svn: 250889
Firstly this changes the type of parent map to be keyed on DynTypedNode to
simplify the following changes. This comes with a DenseMapInfo for
DynTypedNode, which is a bit incomplete still and will probably only work
for parentmap right now.
Then the RecursiveASTVisitor in ASTContext is updated and finally
ASTMatchers hasParent and hasAncestor learn about the new functionality.
Now ParentMap is only missing TemplateArgumentLocs and CXXCtorInitializers.
Differential Revision: http://reviews.llvm.org/D13897
llvm-svn: 250831
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
Out-of-line definitions of static data members which have an inline
initializer must get GVA_DiscardableODR linkage instead of
GVA_StrongExternal linkage.
MSVC 2013's behavior is different with respect to this and would cause
link errors if one TU provided a definition while another did not.
MSVC 2015 fixed this bug, making this OK. Note that the 2015 behavior
is always compatible with 2013: it never produces a strong definition.
This essentially reverts r237787.
llvm-svn: 250757
r246877 made __builtin_object_size substantially more aggressive with
unknown bases if Type=1 or Type=3, which causes issues when we encounter
code like this:
struct Foo {
int a;
char str[1];
};
const char str[] = "Hello, World!";
struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str));
strcpy(&f->str, str);
__builtin_object_size(&f->str, 1) would hand back 1, which is
technically correct given the type of Foo, but the type of Foo lies to
us about how many bytes are available in this case.
This patch adds support for this "writing off the end" idiom -- we now
answer conservatively when we're given the address of the very last
member in a struct.
Differential Revision: http://reviews.llvm.org/D12169
llvm-svn: 250488
Automatically insert line feed after pretty printing of all pragma-like attributes + fix printing of pragma-like pragmas on declarations.
Differential Revision: http://reviews.llvm.org/D13546
llvm-svn: 250017
No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.
llvm-svn: 249656
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
their associated .cpp file.
Previous refactorings long long ago had split out the above categories
of classes from Stmt.h into their own header files, but failed to also
split the Stmt.cpp implementation file similarly. Do so for
readability's sake.
llvm-svn: 249131
This was already being done when injecting the VBPtr, but not
when injecting the VFPtr. This fixes a number of tests in LLDB's
test suite.
Reviewed by: David Majnemer
Differential Revision: http://reviews.llvm.org/D13276
llvm-svn: 249085
Objective-C ARC lifetime qualifiers are dropped when canonicalizing
function types. Perform the same adjustment before comparing the
deduced result types of lambdas. Fixes rdar://problem/22344904.
llvm-svn: 249065
James Y Knight