Difficulties with In-Tree Build of Flang

Hi Justin,

The flang script reads from standard input if a source file is not provided on the command line. It appears to hang, but it’s really just waiting for input.

Flang isn’t hooked up to a code generator yet, so instead, by default, flang generates another Fortran source file and tries to compile that file with a different compiler. The default is pgf90, but you can set the environment variable F18_FC to be a different compiler, like gfortran.

The flang script that you are running is just a throwaway driver until the real driver is ready. That work is under development right now, but I don’t know when it will be ready. Until then, we have this quirky script that lets us test flang semantics.

  • Steve

Hello Justin,

The new driver will take a while to implement. Internally we are aiming for LLVM 12, but that depends on many factors. First we'd like to refactor some bits of Clang's driver so that it is easy to re-use them in Flang.

- Andrzej

Thanks for the replies, Andrzej and Steve,

This placeholder driver may be sufficient for my purposes for now. My goal is to use Flang to implement some high-level transformations for the Adaptive MPI project, those being converting: global variables into !omp threadprivate() variables, and LUNs with hardcoded values into virtualized ones. Does Flang provide a mechanism for manipulating the AST directly? If not, are there any code rewriting mechanisms (a la Clang) or should these manipulations be performed at the FIR-level? Any guidance on this matter would be appreciated, I scanned through the documentation and did not immediately see any discussion of code manipulation.


Justin Szaday
PhD Student in Computer Science
University of Illinois at Urbana-Champaign

Hi Justin,

You can use the flang front end (f18) to do source-to-source transformations. Check out the -funparse option. Sorry, I’m not familiar with the APIs to rewrite the AST. Maybe someone else can answer that.

  • Steve

Hi Justin,

I think basically you have to walk the parse tree with a mutator class. The mutator class needs to have Pre and Post functions defined. The Pre/Post functions can be specialised for the nodes that you are interested in. And these functions get called while visiting those nodes. You can perform the transformations in these Pre/Post functions.

→ OpenMP loop rewriting might be a good example to consult.

In the parse-tree representation (include/flang/Parser/parse-tree.h), the OpenMPLoopConstruct is a tuple of OmpBeginLoopDirective, DoConstruct and OmpEndLoopDirective. The DoConstruct and OmpEndLoopDirective fields are not filled during parsing. The pass in the above file fills these fields. The pass does the following rewriting transformation (copied from the source file).

// Original:

// ExecutableConstruct → OpenMPConstruct → OpenMPLoopConstruct

// OmpBeginLoopDirective

// ExecutableConstruct → DoConstruct

// ExecutableConstruct → OmpEndLoopDirective (if available)

// After rewriting:

// ExecutableConstruct → OpenMPConstruct → OpenMPLoopConstruct

// OmpBeginLoopDirective

// DoConstruct

// OmpEndLoopDirective (if available)

→ Another example would be lib/Semantics/rewrite-parse-tree.cpp. The pass here corrects some ambiguous parsing performed by the Flang parser.


Hi all

I feel like we could make a few simple tweaks to the throwaway driver to make it a bit friendlier in situations like Justin’s.

  • If flang, when invoked with no input source files, printed a message explaining that it was waiting on standard input then that would immediately have allowed Justin to understand what was happening rather than have to contact the list.
  • Additionally, we could do a better job in the –help screen of explaining the default Flang behaviour when invoked without input files and with input files, including the F18_FC setting. That would have helped him interpret the failure he was getting.
  • We could easily support -h as a synonym to –help, -help and -? which we already support, which would then have helped him find that info.

I have posted some patches for review that do all three of these things:




I feel like we should try and get this cherry picked to the LLVM 11 branch also.