summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive.Alexey Bataev2016-04-121-5/+22
| | | | | | | | | | The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
* [OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive.Alexey Bataev2016-04-121-4/+16
| | | | | | | | | The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
* [OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive.Alexey Bataev2016-04-121-4/+31
| | | | | | | | | OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
* [OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd'Alexey Bataev2016-04-071-0/+21
| | | | | | | | | | | | construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
* Semantic analysis for the swiftcall calling convention.John McCall2016-03-031-0/+6
| | | | | | | I've tried to keep the infrastructure behind parameter ABI treatments fairly general. llvm-svn: 262587
* [OPENMP 4.0] Initial support for 'omp declare reduction' construct.Alexey Bataev2016-03-031-0/+75
| | | | | | | | | | | | | | | | | 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
* Improve some infrastructure for extended parameter infos andJohn McCall2016-03-031-0/+8
| | | | | | | fix a bug with the instantiation of ns_consumed parameter attributes in ARC. llvm-svn: 262551
* Serialize `#pragma detect_mismatch`.Nico Weber2016-03-021-0/+5
| | | | | | | 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
* Serialize `#pragma comment`.Nico Weber2016-03-021-0/+5
| | | | | | | | | | | | | | `#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
* Fix the template instantiation of ExtParameterInfos; tests to follow.John McCall2016-03-011-2/+3
| | | | llvm-svn: 262289
* Fix assertion failure on MaybeODRUseExprs.Manman Ren2016-02-241-0/+2
| | | | | | | | | | | | | | | | | | In VisitNonTypeTemplateParamDecl, before SubstExpr with the default argument, we should create a ConstantEvaluated ExpressionEvaluationContext. Without this, it is possible to use a PotentiallyEvaluated ExpressionEvaluationContext; and MaybeODRUseExprs will not be cleared when popping the context, causing assertion failure. This is similar to how we handle the context before SubstExpr with the default argument, in SubstDefaultTemplateArgument. Part of PR13986. rdar://24480205 Differential Revision: http://reviews.llvm.org/D17576 llvm-svn: 261803
* [OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC.Alexey Bataev2016-02-111-2/+2
| | | | | | | | OMPCapturedExprDecl allows caopturing not only of fielddecls, but also other expressions. It also allows to simplify codegen for several clauses. llvm-svn: 260492
* [OPENMP 4.5] Ccapture/codegen of private non-static data members.Alexey Bataev2016-02-081-0/+5
| | | | | | | 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
* Fix for PR8901: attribute "mode" rejected for enums and dependent types.Denis Zobnin2016-02-021-0/+13
| | | | | | | | | Allow "mode" attribute for enum types, except for vector modes, for compatibility with GCC. Support "mode" attribute with dependent types. Differential Revision: http://reviews.llvm.org/D16219 llvm-svn: 259497
* Include RecordDecls from anonymous unions in the AST.Nico Weber2016-01-281-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For void f() { union { int i; }; } clang used to omit the RecordDecl from the anonymous union from the AST. That's because the code creating it only called PushOnScopeChains(), which adds it to the current DeclContext, which here is the function's DeclContext. But RecursiveASTVisitor doesn't descent into all decls in a FunctionDecl. Instead, for DeclContexts that contain statements, return the RecordDecl so that it can be included in the DeclStmt containing the VarDecl for the union. Interesting bits from the AST before this change: |-FunctionDecl | `-CompoundStmt | |-DeclStmt | | `-VarDecl 0x589cd60 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit After this change: -FunctionDecl | `-CompoundStmt | |-DeclStmt | | |-CXXRecordDecl 0x4612e48 <col:3, col:18> col:3 union definition | | | |-FieldDecl 0x4612f70 <col:11, col:15> col:15 referenced i 'int' | | `-VarDecl 0x4613010 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit This is now closer to how anonymous struct and unions are represented as members of structs. It also enabled deleting some one-off code in the template instantiation code. Finally, it fixes a crash with ASTMatchers, see the included test case (this fixes http://crbug.com/580749). llvm-svn: 259079
* ArrayRef-ize TemplateParameterList. NFCDavid Majnemer2015-12-271-1/+1
| | | | llvm-svn: 256463
* [Sema] Implement __make_integer_seqDavid Majnemer2015-11-041-0/+5
| | | | | | | | | | | | | | | | | | 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
* [MSVC Compat] Try to treat an implicit, fixed enum as an unfixed enumDavid Majnemer2015-10-081-1/+2
| | | | | | | | | | | | | | | | | | consider the following: enum E *p; enum E { e }; The above snippet is not ANSI C because 'enum E' has not bee defined when we are processing the declaration of 'p'; however, it is a popular extension to make the above work. This would fail using the Microsoft enum semantics because the definition of 'E' would implicitly have a fixed underlying type of 'int' which would trigger diagnostic messages about a mismatch between the declaration and the definition. Instead, treat fixed underlying types as not fixed for the purposes of the diagnostic. llvm-svn: 249674
* [MS ABI] Correctly mangle classes without names for linkage purposesDavid Majnemer2015-08-311-13/+18
| | | | | | | | | | | | | | | | A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
* Instantiate function declarations in instantiated functions.Serge Pavlov2015-08-231-6/+1
| | | | | | | | | | | | | | | | | If a function declaration is found inside a template function as in: template<class T> void f() { void g(int x = T::v) except(T::w); } it must be instantiated along with the enclosing template function, including default arguments and exception specification. Together with the patch committed in r240974 this implements DR1484. Differential Revision: http://reviews.llvm.org/D11194 llvm-svn: 245810
* If a variable template is inside a context with template arguments that is ↵Nick Lewycky2015-08-101-0/+1
| | | | | | being instantiated, and that instantiation fails, fail our instantiation instead of crashing. Errors have already been emitted. llvm-svn: 244515
* [AST] ArrayRefize template param list info setters. No functionality change ↵Benjamin Kramer2015-08-051-3/+3
| | | | | | intended. llvm-svn: 244028
* [Sema] Allocate SmallVector to the right size.Benjamin Kramer2015-08-041-1/+1
| | | | | | | | | | SmallVector::set_size does not reallocate the vector. Sadly I have no idea how to test this. The vector never has more than one member in all of the regression tests. Found by inspection. llvm-svn: 243987
* [Sema] Range-loopify SemaTemplateInstantiateDecl.cpp. NFC.Davide Italiano2015-07-021-8/+6
| | | | llvm-svn: 241291
* Instantiation of local class members.Serge Pavlov2015-06-291-1/+9
| | | | | | | | | | | | If a function containing a local class is instantiated, instantiate all of local class member, including default arguments and exception specifications. This change fixes PR21332 and thus implements DR1484. Differential Revision: http://reviews.llvm.org/D9990 llvm-svn: 240974
* [modules] Fix merging of default template arguments onto friend templates.Richard Smith2015-06-161-3/+3
| | | | | | | | | Previously we'd complain about redefinition of default arguments when we instantiated a class with a friend template that inherits its default argument, because we propagate the default template arguemnt onto the friend when we reload the AST. llvm-svn: 239857
* Refactor storage of default template arguments.Richard Smith2015-06-101-4/+4
| | | | | | | This is just a preparatory step towards fixing visibility for default template arguments in modules builds. llvm-svn: 239447
* Limit set of types instantiated in FindInstantiatedDecl.Serge Pavlov2015-05-151-3/+19
| | | | | | | | Starting from r236426 FindInstantiatedDecl may instantiate types that are referenced before definition. This change limit the set of types that can be instantiated by this function. llvm-svn: 237434
* PR20625: Instantiate static constexpr member function of a local struct in a ↵Richard Smith2015-05-111-0/+8
| | | | | | | | | | | | | | | function template earlier. This is necessary in order to allow the use of a constexpr member function, or a member function with deduced return type, of a local class within a surrounding instantiated function template specialization. Patch by Michael Park! This re-commits r236063, which was reverted in r236134, along with a fix for a delayed template parsing bug that was exposed by this change. llvm-svn: 237064
* Get rid of compiler warning.Serge Pavlov2015-05-041-1/+1
| | | | llvm-svn: 236431
* Instantiate incomplete class used in template method.Serge Pavlov2015-05-041-0/+8
| | | | | | | | | | | If a class is absent from instantiation and is incomplete, instantiate it as an incomplete class thus avoiding compiler crash. This change fixes PR18653. Differential Revision: http://reviews.llvm.org/D8281 llvm-svn: 236426
* Revert r236063 due to regression with -fdelayed-template-parsing.Richard Smith2015-04-291-8/+0
| | | | llvm-svn: 236134
* PR20625: Instantiate static constexpr member function of a local struct in a ↵Richard Smith2015-04-291-0/+8
| | | | | | | | | | | | function template earlier. This is necessary in order to allow the use of a constexpr member function, or a member function with deduced return type, of a local class within a surrounding instantiated function template specialization. Patch by Michael Park! llvm-svn: 236063
* [cuda] Allow using integral non-type template parameters as launch_bounds ↵Artem Belevich2015-04-211-0/+32
| | | | | | | | | | | | | | | | attribute arguments. - Changed CUDALaunchBounds arguments from integers to Expr* so they can be saved in AST for instantiation. - Added support for template instantiation of launch_bounds attrubute. - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo:: SetTargetAttributes() where it can be done after template instantiation. - Added a warning on negative launch_bounds arguments. - Amended test cases. Differential Revision: http://reviews.llvm.org/D8985 llvm-svn: 235452
* Move the logic to avoid double global emission from Sema to CodeGenReid Kleckner2015-04-151-14/+7
| | | | | | | | | | | Reverts the code changes from r234675 but keeps the test case. We were already maintaining a DenseMap of globals with dynamic initializers anyway. Fixes the test case from PR23234. llvm-svn: 234961
* Only notify consumers about static data members of class templates onceReid Kleckner2015-04-111-7/+14
| | | | llvm-svn: 234675
* Revert "Mark instantiated function decls as inline specified if any pattern is"Reid Kleckner2015-04-071-15/+5
| | | | | | | | | | | | | | | | | | | It breaks down on this test case: void foo(); template <typename T> class C { friend void foo(); }; inline void foo() {} C<int> c; We shouldn't be marking the instantiation of the friend decl of foo as inline-specified. It may be possible to fix this by determining if the full definition is part of the current template, but it seems better to rever tot green until we come up with a full solution. This reverts commit r233817, as well as follow-ups r233820 and r233821. llvm-svn: 234355
* Mark instantiated function decls as inline specified if any pattern isReid Kleckner2015-04-011-5/+15
| | | | | | | | | | | | A function template pattern can be declared without the 'inline' specifier and defined later with the 'inline' specifier. However, during instantiation, we were only looking at the canonical decl to see if we should mark the instantiated decl as inline specified. Since the instantiated decl actually represents many pattern declarations, put the inline specifier on the instantiation decl if any of the pattern decls have it. llvm-svn: 233817
* Replace Sema's map of locally-scoped extern "C" declarations with a DeclContextRichard Smith2015-03-071-0/+5
| | | | | | | | | | of extern "C" declarations. This is simpler and vastly more efficient for modules builds (we no longer need to load *all* extern "C" declarations to determine if we have a redeclaration). No functionality change intended. llvm-svn: 231538
* Address review feedback from r215780: Use a flag insteda of the heap. No ↵Nico Weber2015-01-181-24/+12
| | | | | | behavior change. llvm-svn: 226389
* Instantiation of a CXXMethodDecl may fail when the parameter type cannot be ↵Nick Lewycky2015-01-021-2/+4
| | | | | | | | | | | | instantiated. Do not crash in this case. Fixes PR22040! The FIXME in the test is caused by TemplateDeclInstantiator::VisitCXXRecordDecl returning a nullptr instead of creating an invalid decl. This is a common pattern across all of TemplateDeclInstantiator, so I'm not comfortable changing it. The reason it's not invalid in the class template is due to support for an MSVC extension, see r137573. llvm-svn: 225071
* Instantiate exception specifications when instantiating function types (otherRichard Smith2014-11-121-133/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. This is a re-commit of r219977: r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2. (That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of 'this' within a template.) r219977 was a re-commit of r217995, r218011, and r218053: r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC. (Incorrect overload resolution in the presence of using-declarations.) It was re-committed in r219977 with a workaround for the MSVC rejects-valid. r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of unbraced range-based for loop). llvm-svn: 221750
* Prune CRLF.NAKAMURA Takumi2014-10-271-2/+2
| | | | llvm-svn: 220678
* Don't forget to substitute into the qualifier when instantiating the definitionRichard Smith2014-10-171-19/+29
| | | | | | | of a member function of a class template that is defined outside the template. This substitution can actually fail in some weird cases. llvm-svn: 220085
* Revert r219977, "Re-commit r217995 and follow-up patches (r217997, r218011, ↵NAKAMURA Takumi2014-10-171-35/+133
| | | | | | | | | | | | | r218053). These were" It broke some builders. I guess it'd be reproducible with --vg. Failing Tests (3): Clang :: CXX/except/except.spec/p1.cpp Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp Clang :: SemaTemplate/instantiate-exception-spec.cpp llvm-svn: 220038
* Re-commit r217995 and follow-up patches (r217997, r218011, r218053). These wereRichard Smith2014-10-161-133/+35
| | | | | | | | | | | | | | | reverted in r218058 because they triggered a rejects-valid bug in MSVC. Original commit message from r217995: Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. llvm-svn: 219977
* Adding attributes to the IndirectFieldDecl that we generate for anonymous ↵Aaron Ballman2014-10-151-4/+5
| | | | | | struct/union fields. This fixes PR20930. llvm-svn: 219807
* [modules] Merging for class-scope using-declarations.Richard Smith2014-10-141-6/+7
| | | | llvm-svn: 219657
* [modules] When instantiating a class member, don't expect to find the previousRichard Smith2014-10-111-12/+33
| | | | | | | declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
* Initial support for the align_value attributeHal Finkel2014-10-021-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
OpenPOWER on IntegriCloud