- User Since
- Sep 18 2020, 5:18 AM (29 w, 2 d)
Tue, Mar 16
Update test case directive1.td for TableGen changes
Sun, Mar 14
Mar 1 2021
Feb 28 2021
@kiranchandramohan The test case flang/test/Semantics/resolve102.f90 is failing with the error messages possibly due to the commit
Add TODO and comments for the data structures
Feb 24 2021
Feb 12 2021
Check threadprivate variables in symbols with HostAssocDetails
Feb 11 2021
Feb 5 2021
Address review comments and rebase
Feb 3 2021
Feb 2 2021
Add check for cycle statements leaving OpenMP structured blocks
Feb 1 2021
Thanks for the detailed listing. I think the second message in the do loop checks (non-openmp) is also not listed as an error. But they still check for that in the tests.
- you can follow what they do for the do loop checks (non-openmp)
- Add the two separate messages in the tests.
Modify error messages to identify branch into or branch out of openmp structued blocks
Jan 30 2021
I am not familiar with that. I can look up if required. But what I am suggesting is to do what is similar to the do loop checks like the following.$ ./bin/flang ../flang/test/Semantics/doconcurrent03.f90 ../flang/test/Semantics/doconcurrent03.f90:11:9: error: Control flow escapes from DO CONCURRENT goto 20 ^^^^^^^ ../flang/test/Semantics/doconcurrent03.f90:9:3: Enclosing DO CONCURRENT statement do 10 concurrent (i = 1:10) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ../flang/test/Semantics/doconcurrent03.f90:18:3: branch into loop body from outside goto 30 ^^^^^^^ ../flang/test/Semantics/doconcurrent03.f90:9:3: the loop branched into do 10 concurrent (i = 1:10) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ `
Jan 29 2021
Jan 28 2021
@kiranchandramohan I guess the checks work for all the OpenMP constructs . I have added the code for omp critical constructs to identify the invalid entry and branch to/from errors.
Use the logic in resolve-directives.cpp instead of 'LabelEnforce' to identify control flow escaping the OpenMP constructs.
Jan 25 2021
@kiranchandramohan We can maybe remove void LabelEnforce::Post(const parser::AssignStmt &); check from LabelEnforce as it detects the error when there is only AssignStmt.
The control flow escaping from 'CONSTRUCT' would make sense for parser::AssignStmt only when the assigned label is used in the goto stmt (AssignedGoto) in the same context as below.
Jan 22 2021
I tried to make use of the CheckBranchesIntoDoBody function, but since it involves the use of multiple functions and types defined in resolve-labels.cpp such as using ProxyForScope, LabeledStatementInfoTuplePOD, SourceStatementInfoTuplePOD and also the labels, scopes and other details are being identified as part of the walk in ParseTreeAnalyzer class, it would be more complex to reuse these functions.
Handle all the statements invloving labels and branches.
Jan 19 2021
Jan 18 2021
Address review comments
Jan 15 2021
Use parse-tree walk to check the validity of assignments and expressions in workshare construct .
Jan 14 2021
@kiranchandramohan To make use of parse-tree walk to check all the assignments and expressions in OpenMP Workshare constructs , is it preferred to add a class in check-omp-structure.cpp specific for workshare or add a generic class in Semantics/tools.cpp to collect all the assignments and expressions and then iterate over all the assignments / expressions identified in the walk?
Jan 12 2021
Jan 11 2021
Jan 9 2021
@kiranchandramohan Updated the patch to handle all the checks on workshare construct . Since the WhereConstruct and ForallConstructs have nested WhereStmt/WhereConstructs and ForAllStmt/ForallConstructs , separate functions are added to handle the same recursively.
- Handle uses of non-elemental functions in the workshare construct
- Handle the nested where/forall constructs enclosed in the workshare construct
- Apply the restrictions on workshare to OpenMP critical construct enclosed in workshare construct
Jan 5 2021
Update to latest syntax of Omp Reduction clause
Dec 30 2020
@kiranchandramohan @sameeranjoshi Will the patch https://reviews.llvm.org/D93105 be committed to the master again?
If so , the function void GetSymbolsInDesignatorList(const std::list<parser::Designator> &, SymbolSourceMap &); would not be required.
Handle all the private symbols in enclosing context for firstprivate and lastprivate clauses
Dec 25 2020
Dec 17 2020
Dec 16 2020
Check invalid branch into/from all the openMP constructs with structured blocks
Dec 14 2020
"Variables that appear in namelist statements, in variable format expressions, or in expressions for statement function definitions, may not appear in a firstprivate clause."
Dec 11 2020
Rebase and apply clang-format
Dec 6 2020
Dec 2 2020
Addressed review comments and combined the test cases
Nov 30 2020
Nov 26 2020
Added a flag in symbol.h to identify the symbols in namelist
Nov 23 2020
@kiranchandramohan Updated the reply for each of the inline comments.
Address review comments.
Rebase with latest master
Nov 22 2020
@kiranchandramohan In the test file omp-clause-validity01.f90 , the following no symbol found errors are not being thrown.
Nov 21 2020
Nov 17 2020
Modified the logic to identify all the variables in namelist statements
Nov 16 2020
Nov 12 2020
Add test case omp-depend03.f90 for usage of coarray in the depend clause
Nov 4 2020
Oct 28 2020
Moved the pointer check to separate function as per review comment
Oct 27 2020
Removed redundant code used to resolve threadprivate directive as per review comments.
Oct 26 2020
Oct 21 2020
Oct 19 2020
Address the review comments and update the summary.
Oct 15 2020
Added positive test cases , formatting as per review comments
Oct 14 2020
Sep 23 2020
@DavidTruby Thanks !
Sep 22 2020
Sep 20 2020
Add test cases for more OpenMP constructs