[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