summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOpenMP.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [OPENMP]Fix PR41767: diagnose DSA for variables in clauses with default(none).Alexey Bataev2019-05-091-3/+95
| | | | | | | | | If the combined directive has default(none) clause and has clauses for inner directive that reference some variables, for which data-sharing attributes are not specified, the error messages should be emitted for such variables. llvm-svn: 360365
* [OPENMP]Fix PR41768: check DSA for globals with default(none) clauses.Alexey Bataev2019-05-091-2/+23
| | | | | | | | If the default(none) was specified for the construct, we might miss diagnostic for the globals without explicitly specified data-sharing attributes. Patch fixes this problem. llvm-svn: 360362
* Revert "[OPENMP]Fix PR41768: check DSA for globals with `default(none)` ↵Roman Lebedev2019-05-091-7/+1
| | | | | | | | | | | | clauses." This has introduced (exposed?) a crash in clang sema, that does not happen without this patch. I'll followup in the original bugreport and commit with reproducer. This reverts commit r360061. llvm-svn: 360327
* Revert "[OPENMP]Fix PR41767: diagnose DSA for variables in clauses with ↵Roman Lebedev2019-05-091-96/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default(none)." This implementation isn't sound as per the standard. It erroneously diagnoses e.g. the following case: ``` $ cat test.cpp void f(int n) { #pragma omp parallel default(none) if(n) ; } ``` ``` $ ./bin/clang -fopenmp test.cpp test.cpp:2:40: error: variable 'n' must have explicitly specified data sharing attributes #pragma omp parallel default(none) if(n) ^ test.cpp:2:31: note: explicit data sharing attribute requested here #pragma omp parallel default(none) if(n) ^ 1 error generated. ``` As per OpenMP Application Programming Interface Version 5.0 November 2018: * 2.19.4.1default Clause The default clause explicitly determines the data-sharing attributes of variables that are referenced *in a parallel, teams, or task generating construct and would otherwise be implicitly determined (see Section 2.19.1.1 on page 270). * 2.6.1 Determining the Number of Threads for a parallel Region Using a variable in an if or num_threads clause expression of a parallel construct causes an implicit reference to the variable in all enclosing constructs. The if clause expression and the num_threads clause expression are evaluated in the context outside of the parallel construct, This reverts commit r360073. llvm-svn: 360326
* [OPENMP]Fix PR41767: diagnose DSA for variables in clauses withAlexey Bataev2019-05-061-3/+96
| | | | | | | | | | | default(none). If the combined directive has default(none) clause and has clauses for inner directive that reference some variables, for which data-sharing attributes are not specified, the error messages should be emitted for such variables. llvm-svn: 360073
* [OPENMP]Fix PR41768: check DSA for globals with `default(none)` clauses.Alexey Bataev2019-05-061-1/+7
| | | | | | | | If the `default(none)` was specified for the construct, we might miss diagnostic for the globals without explicitly specified data-sharing attributes. Patch fixes this problem. llvm-svn: 360061
* [OPENMP]Fix PR41617: crash on template instantiation.Alexey Bataev2019-04-291-1/+1
| | | | | | | Fixed the crash on the template instantiation when trying to check the data locality in the current instantiation scope. llvm-svn: 359459
* [OPENMP]Added check for non-random access types for the dependent loopAlexey Bataev2019-04-261-51/+78
| | | | | | | | | | | counters. According to the OpenMP 5.0, For any associated loop where the b or lb expression is not loop invariant with respect to the outermost loop, the var-outer that appears in the expression may not have a random access iterator type. llvm-svn: 359340
* [OPENMP] Improved check for the linear dependency in the non-rectangularAlexey Bataev2019-04-251-5/+29
| | | | | | | | | loop nests. Added a checks that the initializer/condition expressions depend only only of the single previous loop iteration variable. llvm-svn: 359200
* [OPENMP]Initial support for non-rectangular loop nest.Alexey Bataev2019-04-241-13/+87
| | | | | | | Added basic semantic analysis for the non-rectangular loop nests for OpenMP 5.0 support. llvm-svn: 359132
* [OpenMP] Add checks for requires and target directives.Gheorghe-Teodor Bercea2019-04-181-0/+43
| | | | | | | | | | | | | | | | Summary: The requires directive containing target related clauses must appear before any target region in the compilation unit. Reviewers: ABataev, AlexEichenberger, caomhin Reviewed By: ABataev Subscribers: guansong, jfb, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60875 llvm-svn: 358709
* [OPENMP]Allow allocate directive on parameters.Alexey Bataev2019-04-091-3/+0
| | | | | | Patch allows to use allocate directives on the function parameters. llvm-svn: 358016
* [OPENMP]Fix lookup of the user-defined reductions in C.Alexey Bataev2019-04-041-11/+13
| | | | | | Fixed the regression of the lookup of user-defined reductions for C. llvm-svn: 357708
* [OPENMP]Allocate clause allocator in target region.Alexey Bataev2019-04-011-0/+9
| | | | | | | | | | According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, allocate clauses that appear on a target construct or on constructs in a target region must specify an allocator expression unless a requires directive with the dynamic_allocators clause is present in the same compilation unit. Patch adds a check for this restriction. llvm-svn: 357412
* [OPENMP] Check that allocated variables are used in private clauses.Alexey Bataev2019-04-011-131/+226
| | | | | | | | | | According to OpenMP 5.0 standard, 2.11.4 allocate Clause, Restrictions, For any list item that is specified in the allocate clause on a directive, a data-sharing attribute clause that may create a private copy of that list item must be specified on the same directive. Patch adds the checks for this restriction. llvm-svn: 357390
* [OPENMP]Add check for undefined behavior with thread allocators onAlexey Bataev2019-03-281-0/+33
| | | | | | | | | | | | target and task-based directives. According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, For task, taskloop or target directives, allocation requests to memory allocators with the trait access set to thread result in unspecified behavior. Patch introduces a check for omp_thread_mem_alloc predefined allocator on target- and trask-based directives. llvm-svn: 357205
* Make helper functions static. NFC.Benjamin Kramer2019-03-281-4/+5
| | | | llvm-svn: 357187
* [OPENMP]Initial support for 'allocate' clause.Alexey Bataev2019-03-271-1/+56
| | | | | | Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CorrectionCandidateCallback unless we are going to do some typo correction The various CorrectionCandidateCallbacks are currently heap-allocated unconditionally. This was needed because of delayed typo correction. However these allocations represent currently 15.4% of all allocations (number of allocations) when parsing all of Boost (!), mostly because of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes and isCXXDeclarationSpecifier. Note that all of these callback objects are small. Let's not do this. Instead initially allocate the callback on the stack, and only do a heap allocation if we are going to do some typo correction. Do this by: 1. Adding a clone function to each callback, which will do a polymorphic clone of the callback. This clone function is required to be implemented by every callback (of which there is a fair amount). Make sure this is the case by making it pure virtual. 2. Use this clone function when we are going to try to correct a typo. This additionally cut the time of -fsyntax-only on all of Boost by 0.5% (not that much, but still something). No functional changes intended. Differential Revision: https://reviews.llvm.org/D58827 Reviewed By: rnk llvm-svn: 356925
* [OPENMP]Add missing comment, NFC.Alexey Bataev2019-03-221-0/+4
| | | | llvm-svn: 356759
* [OPENMP]Allow no allocator clause in target regions with requiresAlexey Bataev2019-03-221-1/+12
| | | | | | | | | | | | dynamic_allocators. According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions, allocate directives that appear in a target region must specify an allocator clause unless a requires directive with the dynamic_allocators clause is present in the same compilation unit. Patch adds a check for a presence of the requires directive with the dynamic_allocators clause. llvm-svn: 356758
* [OPENMP]Emit error message for allocate directive without allocatorAlexey Bataev2019-03-221-1/+5
| | | | | | | | | | | clause in target region. According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions, allocate directives that appear in a target region must specify an allocator clause unless a requires directive with the dynamic_allocators clause is present in the same compilation unit. llvm-svn: 356752
* [OPENMP]Simplify the check for the predefined allocators, NFC.Alexey Bataev2019-03-211-39/+7
| | | | | | | | Previously implemented check required the reevaluation of the already evaluated predefined allocator kind for the global variables. Patch simplifies this evaluation and removes extra code. llvm-svn: 356699
* [OPENMP]Improve detection of omp_allocator_handle_t type and predefinedAlexey Bataev2019-03-201-27/+104
| | | | | | | | | | | allocators. It is better to deduce omp_allocator_handle_t type from the predefined allocators, because omp.h header might not define it explicitly. Plus, it allows to identify the predefined allocators correctly when trying to build the allcoator for the global variables. llvm-svn: 356607
* [clang][OpeMP] Model OpenMP structured-block in AST (PR40563)Roman Lebedev2019-03-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3: ``` structured block For C/C++, an executable statement, possibly compound, with a single entry at the top and a single exit at the bottom, or an OpenMP construct. COMMENT: See Section 2.1 on page 38 for restrictions on structured blocks. ``` ``` 2.1 Directive Format Some executable directives include a structured block. A structured block: • may contain infinite loops where the point of exit is never reached; • may halt due to an IEEE exception; • may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a _Noreturn specifier (in C) or a noreturn attribute (in C/C++); • may be an expression statement, iteration statement, selection statement, or try block, provided that the corresponding compound statement obtained by enclosing it in { and } would be a structured block; and Restrictions Restrictions to structured blocks are as follows: • Entry to a structured block must not be the result of a branch. • The point of exit cannot be a branch out of the structured block. C / C++ • The point of entry to a structured block must not be a call to setjmp(). • longjmp() and throw() must not violate the entry/exit criteria. ``` Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`, in the same sense as with the normal `noexcept` functions in C++. I.e. if throw happens, and it attempts to travel out of the `noexcept` function (here: out of the current structured-block), then the program terminates. Now, one of course can say that since it is explicitly prohibited by the Specification, then any and all programs that violate this Specification contain undefined behavior, and are unspecified, and thus no one should care about them. Just don't write broken code /s But i'm not sure this is a reasonable approach. I have personally had oss-fuzz issues of this origin - exception thrown inside of an OpenMP structured-block that is not caught, thus causing program termination. This issue isn't all that hard to catch, it's not any particularly different from diagnosing the same situation with the normal `noexcept` function. Now, clang static analyzer does not presently model exceptions. But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check, and it is even refactored as a `ExceptionAnalyzer` class for reuse. So it would be trivial to use that analyzer to check for exceptions escaping out of OpenMP structured blocks. (D59466) All that sounds too great to be true. Indeed, there is a caveat. Presently, it's practically impossible to do. To check a OpenMP structured block you need to somehow 'get' the OpenMP structured block, and you can't because it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation. Now, it is of course possible to write e.g. some AST matcher that would e.g. match every OpenMP executable directive, and then return the whatever `Stmt` is the structured block of said executable directive, if any. But i said //practically//. This isn't practical for the following reasons: 1. This **will** bitrot. That matcher will need to be kept up-to-date, and refreshed with every new OpenMP spec version. 2. Every single piece of code that would want that knowledge would need to have such matcher. Well, okay, if it is an AST matcher, it could be shared. But then you still have `RecursiveASTVisitor` and friends. `2 > 1`, so now you have code duplication. So it would be reasonable (and is fully within clang AST spirit) to not force every single consumer to do that work, but instead store that knowledge in the correct, and appropriate place - AST, class structure. Now, there is another hoop we need to get through. It isn't fully obvious //how// to model this. The best solution would of course be to simply add a `OMPStructuredBlock` transparent node. It would be optimal, it would give us two properties: * Given this `OMPExecutableDirective`, what's it OpenMP structured block? * It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`) But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`. (even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween). So i'm not sure whether or not we could re-create AST statements after they were already created? There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12 ``` 1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity. 2. You will need to support serialization/deserialization. 3. You will need to support template instantiation. 4. You will need to support codegen and take this new construct to account in each OpenMP directive. ``` Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts. Part 1: * Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class, that will tell whether this directive is stand-alone or not, as per the spec. We need it because we can't just check for the existance of associated statements, see code comment. * Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself, that assert that this is not a stand-alone directive, and either return the correct loop body if this is a loop-like directive, or the captured statement. This way, given an `OMPExecutableDirective`, we can get it's structured block. Also, since the knowledge is ingrained into the clang OpenMP implementation, it will not cause any duplication, and //hopefully// won't bitrot. Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach. Thus, there is a second part needed: * How can we check whether a given `Stmt*` is `OMPStructuredBlock`? Well, we can't really, in general. I can see this workaround: ``` class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> { using Base = RecursiveASTVisitor<FunctionASTVisitor>; public: bool VisitOMPExecDir(OMPExecDir *D) { OmpStructuredStmts.emplace_back(D.getStructuredStmt()); } bool VisitSOMETHINGELSE(???) { if(InOmpStructuredStmt) HI! } bool TraverseStmt(Stmt *Node) { if (!Node) return Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) ++InOmpStructuredStmt; Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) { OmpStructuredStmts.pop_back(); --InOmpStructuredStmt; } return true; } std::vector<Stmt*> OmpStructuredStmts; int InOmpStructuredStmt = 0; }; ``` But i really don't see using it in practice. It's just too intrusive; and again, requires knowledge duplication. .. but no. The solution lies right on the ground. Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself? This does not appear to have any impact on the memory footprint of the clang AST, since it's just a single extra bit in the bitfield. At least the static assertions don't fail. Thus, indeed, we can achieve both of the properties without a new AST node. We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`, by just calling the `getStructuredBlock()` that we just added. Test coverage that demonstrates all this has been added. This isn't as great with serialization though. Most of it does not use abbrevs, so we do end up paying the full price (4 bytes?) instead of a single bit. That price, of course, can be reclaimed by using abbrevs. In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly. I'm not seeing a third solution. If there is one, it would be interesting to hear about it. ("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.) Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]]. Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr Reviewed By: ABataev, gribozavr Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D59214 llvm-svn: 356570
* [OPENMP]Warn if the different allocator is used for the variable.Alexey Bataev2019-03-191-5/+66
| | | | | | | | If the allocator was specified for the variable and next one is found with the different allocator, the warning is emitted, and the allocator is ignored. llvm-svn: 356513
* [OPENMP]Check that global vars require predefined allocator.Alexey Bataev2019-03-191-0/+37
| | | | | | | | | | According to OpenMP, 2.11.3 allocate Directive, Restrictions, C / C++, if a list item has a static storage type, the allocator expression in the allocator clause must be a constant expression that evaluates to one of the predefined memory allocator values. Added check for this restriction. llvm-svn: 356496
* Refactor cast<>'s in if conditionals, which can only assert on failure.Don Hinton2019-03-191-1/+1
| | | | | | | | | | | | | | | | | Summary: This patch refactors several instances of cast<> used in if conditionals. Since cast<> asserts on failure, the else branch can never be taken. In some cases, the fix is to replace cast<> with dyn_cast<>. While others required the removal of the conditional and some minor refactoring. A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html Differential Revision: https://reviews.llvm.org/D59529 llvm-svn: 356441
* [OPENMP]Fix crash for the ordered(n) clause.Alexey Bataev2019-03-141-2/+1
| | | | | | | | If the doacross lop construct is used and the loop counter is declare outside of the loop, the compiler might crash trying to get the address of the loop counter. Patch fixes this problem. llvm-svn: 356198
* [OPENMP]Disable ADL in C for user-defined reductions.Alexey Bataev2019-03-131-29/+31
| | | | | | C does not support ADL, disable it for C to prevent compiler crash. llvm-svn: 356089
* [OPENMP 5.0]Initial support for 'allocator' clause.Alexey Bataev2019-03-121-8/+58
| | | | | | | Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
* [OPENMP]Fix codegen for declare target link in target regions.Alexey Bataev2019-03-111-2/+46
| | | | | | | | If the declare target link global is used in the target region indirectly (used in the inner parallel, teams, etc. regions), we may miss this variable and it leads to incorrect codegen. llvm-svn: 355858
* [OPENMP 5.0]Add initial support for 'allocate' directive.Alexey Bataev2019-03-071-11/+64
| | | | | | | Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
* [OPENMP]Delay emission of the error for unsupported types.Alexey Bataev2019-02-271-0/+12
| | | | | | | If the type is unsupported on the device side, it still must be emitted, but we should emit errors for operations with such types. llvm-svn: 355027
* [OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.Michael Kruse2019-02-251-33/+30
| | | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
* [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.Michael Kruse2019-02-221-34/+40
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
* [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier.Michael Kruse2019-02-191-83/+248
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
* [OPENMP]Delay emission of the error messages for the exceptions.Alexey Bataev2019-02-081-0/+50
| | | | | | | | | | Fixed diagnostic emission for the exceptions support in case of the compilation of OpenMP code for the devices. From now on, it uses delayed diagnostics mechanism, previously used for CUDA only. It allow to diagnose not allowed used of exceptions only in functions that are going to be codegen'ed. llvm-svn: 353542
* Revert "[OPENMP]Initial support for the delayed diagnostics."Alexey Bataev2019-02-081-50/+0
| | | | | | | This reverts commit r353540. Erroneously committed, need to fix the message and description. llvm-svn: 353541
* [OPENMP]Initial support for the delayed diagnostics.Alexey Bataev2019-02-081-0/+50
| | | | | | | | | It is important to delay the emission of the diagnostic messages for the functions unless it is proved that the function is going to be used on the device side. It is required to support compilation with some of the target-specific system headers. llvm-svn: 353540
* Test commit. NFCPatrick Lyster2019-02-061-1/+1
| | | | llvm-svn: 353320
* [OPENMP] issue error messages for multiple teams contructs in a target constructKelvin Li2019-02-051-1/+3
| | | | | | | | | | | | | | | | The fix is to issue error messages if there are more than one teams construct inside a target constructs. #pragma omp target { #pragma omp teams { ... } #pragma omp teams { ... } } llvm-svn: 353186
* [opaque pointer types] Fix the CallInfo passed to EmitCall in someJames Y Knight2019-02-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | edge cases. Currently, EmitCall emits a call instruction with a function type derived from the pointee-type of the callee. This *should* be the same as the type created from the CallInfo parameter, but in some cases an incorrect CallInfo was being passed. All of these fixes were discovered by the addition of the assert in EmitCall which verifies that the passed-in CallInfo matches the Callee's function type. As far as I know, these issues caused no bugs at the moment, as the correct types were ultimately being emitted. But, some would become problematic when pointee types are removed. List of fixes: * arrangeCXXConstructorCall was passing an incorrect value for the number of Required args, when calling an inheriting constructor where the inherited constructor is variadic. (The inheriting constructor doesn't actually get passed any of the user's args, but the code was calculating it as if it did). * arrangeFreeFunctionLikeCall was not including the count of the pass_object_size arguments in the count of required args. * OpenCL uses other address spaces for the "this" pointer. However, commonEmitCXXMemberOrOperatorCall was not annotating the address space on the "this" argument of the call. * Destructor calls were being created with EmitCXXMemberOrOperatorCall instead of EmitCXXDestructorCall in a few places. This was a problem because the calling convention sometimes has destructors returning "this" rather than void, and the latter function knows about that, and sets up the types properly (through calling arrangeCXXStructorDeclaration), while the former does not. * generateObjCGetterBody: the 'objc_getProperty' function returns type 'id', but was being called as if it returned the particular property's type. (That is of course the *dynamic* return type, and there's a downcast immediately after.) * OpenMP user-defined reduction functions (#pragma omp declare reduction) can be called with a subclass of the declared type. In such case, the call was being setup as if the function had been actually declared to take the subtype, rather than the base type. Differential Revision: https://reviews.llvm.org/D57664 llvm-svn: 353181
* Revert "[AST][OpenMP] OpenMP Sections / Section constructs contain ↵Roman Lebedev2019-02-011-14/+0
| | | | | | | | | | | | Structured blocks" Further reviews (D57594, D57615) have revealed that this was not reviewed, and that the differential's description was not read during the review, thus rendering this commit invalid. This reverts commit r352882. llvm-svn: 352933
* [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.Michael Kruse2019-02-011-0/+146
| | | | | | | | | | | | | | | | | This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
* [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocksRoman Lebedev2019-02-011-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I'm working on a clang-tidy check, much like existing [[ http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]], to detect when an exception might escape out of an OpenMP construct it isn't supposed to escape from. For that i will be using the `nothrow` bit of `CapturedDecl`s. While that bit is already correctly set for some constructs, e.g. `#pragma omp parallel`: https://godbolt.org/z/2La7pv it isn't set for the `#pragma omp sections`, or `#pragma omp section`: https://godbolt.org/z/qZ-EbP If i'm reading [[ https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf | `OpenMP Application Programming Interface Version 5.0 November 2018` ]] correctly, they should be, as per `2.8.1 sections Construct`, starting with page 86: * The sections construct is a non-iterative worksharing construct that contains a set of **structured blocks** that are to be distributed among and executed by the threads in a team. Each **structured block** is executed once by one of the threads in the team in the context of its implicit task. * The syntax of the sections construct is as follows: #pragma omp sections [clause[ [,] clause] ... ] new-line { [#pragma omp section new-line] **structured-block** ... * Description Each **structured block** in the sections construct is preceded by a section directive except possibly **the first block**, for which a preceding section directive is optional. * Restrictions • The code enclosed in a sections construct must be a **structured block**. * A throw executed inside a sections region must cause execution to resume within the same section of the sections region, and the same thread that threw the exception must catch it. Reviewers: ABataev, #openmp Reviewed By: ABataev Subscribers: guansong, openmp-commits, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D57585 llvm-svn: 352882
* Test commit: fix typoSergi Mateo Bellido2019-02-011-1/+1
| | | | llvm-svn: 352842
* [OPENMP]Fix PR40513: lastprivate taskloop counter.Alexey Bataev2019-01-291-4/+1
| | | | | | | | We don't need to use the predetermined data-sharing attributes for the loop counters if the user explicitly specified correct data-sharing attributes for such variables. llvm-svn: 352543
* [OPENMP]Make the loop with unsigned counter countable.Alexey Bataev2019-01-291-17/+71
| | | | | | | | According to the report, better to keep the original strict compare operation as the loop condition with unsigned loop counters to make the loop countable. This allows further loop transformations. llvm-svn: 352526
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
OpenPOWER on IntegriCloud