[PATCH] D108530: [flang][OpenMP] Fix one bug in parsing depend(sink: vec)
Peixin Qiao via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 24 06:35:30 PDT 2021
peixin added a comment.
@kiranchandramohan Thanks for pointing out the problem. I think you are right.
I guess the problem is that the name resolution has not been finished. I tried the following change and the command `ninja check-flang` works fine.
diff --git a/flang/lib/Semantics/rewrite-parse-tree.cpp b/flang/lib/Semantics/rewrite-parse-tree.cpp
index 071a668de7fd..ff0a38117a73 100644
--- a/flang/lib/Semantics/rewrite-parse-tree.cpp
+++ b/flang/lib/Semantics/rewrite-parse-tree.cpp
@@ -46,6 +46,7 @@ public:
// Name resolution yet implemented:
// TODO: Can some/all of these now be enabled?
+ bool Pre(parser::Name &);
bool Pre(parser::EquivalenceStmt &) { return false; }
bool Pre(parser::Keyword &) { return false; }
bool Pre(parser::EntryStmt &) { return false; }
In addition, the following code can pass the frontend compilation and the name "j" is dumped in parser tree. I am not sure if this check should be implemented in the name resolution or semantic check.
!$omp do ordered(1)
do i = 2, N
!$omp ordered depend(sink: j - 1)
B(i) = bar(A(i), B(i-1))
end do
| | | | | | | Name = 'j'
| | | | | | | OmpDependSinkVecLength
| | | | | | | | DefinedOperator -> IntrinsicOperator = Subtract
| | | | | | | | Scalar -> Integer -> Constant -> Expr = '1_4'
| | | | | | | | | LiteralConstant -> IntLiteralConstant = '1'
Is it ok to use this fix and leave "TODO" here for temporary fix? I need this for lowering `depend(sink: vec)`. Or can I post the question of the name resolution on slack and let someone who knows the implementation of the name resolution fix it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D108530/new/
https://reviews.llvm.org/D108530
More information about the llvm-commits
mailing list