[PATCH] D82903: [flang] Bug fix for ambiguous references to data and functions

Pete Steinfeld via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 1 10:48:41 PDT 2020


PeteSteinfeld marked an inline comment as done.
PeteSteinfeld added inline comments.


================
Comment at: flang/lib/Semantics/resolve-names.cpp:7030
+  // not have symbols
+  ExecutionPartSkimmer{*this}.Walk(node.exec());
 }
----------------
PeteSteinfeld wrote:
> tskeith wrote:
> > PeteSteinfeld wrote:
> > > tskeith wrote:
> > > > Why does this require an extra pass over the parse tree. Can't this check be done as part of `ResolveExecutionParts` where `ArrayElement` nodes are handled?
> > > The problem I ran into was dealing with blocks and their associated scopes.  When processing the specification parts, I couldn't find symbols declared in blocks.  I tried eliminating the pass in `ResolveSpecificationParts`, but that broke processing of subprograms as dummy arguments.
> > I was referring to this call, not the one in `ResolveSpecificationParts`. Immediately above here we walk the execution parts. The will include the `ArrayElement` node. Why can't `NoteExecutablePartArrayElement` be done as part of that walk?
> Thanks for clarifying.  It may be possible to do that.  I'll investigate.
@tskeith , you were correct that we can handle detection of `ArrayElement` references in the main `ResolveNames` pass of the execution part.  I'll be pushing a change soon with this implementation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82903/new/

https://reviews.llvm.org/D82903





More information about the llvm-commits mailing list