commit | 32b52c5b77b1bd2df383bb1804be66581d5b1c26 | [log] [tgz] |
---|---|---|
author | peter klausler <pklausler@nvidia.com> | Tue Jan 19 17:09:55 2021 -0800 |
committer | Copybara-Service <copybara-worker@google.com> | Thu Jan 21 17:22:41 2021 -0800 |
tree | 09918b209bc7441c28e5c3e166e4994984bcbb37 | |
parent | 426d3419c4eee27d3025eee43fcf502cc60466cd [diff] |
[flang] Fix ASSOCIATE statement name resolution F18 Clause 19.4p9 says: The associate names of an ASSOCIATE construct have the scope of the block. Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block: R1102 associate-construct is: associate-stmt block end-associate-stmt Associate statement associations are currently fully processed from left to right, incorrectly interposing associating entities earlier in the list on same-named entities in the host scope. 1 program p 2 logical :: a = .false. 3 real :: b = 9.73 4 associate (b => a, a => b) 5 print*, a, b 6 end associate 7 print*, a, b 8 end Associating names 'a' and 'b' at line 4 in this code are now both aliased to logical host entity 'a' at line 2. This happens because the reference to 'b' in the second association incorrectly resolves 'b' to the entity in line 4 (already associated to 'a' at line 2), rather than the 'b' at line 3. With bridge code to process these associations, f18 output is: F F F 9.73 It should be: 9.73 F F 9.73 To fix this, names in right-hand side selector variables/expressions must all be resolved before any left-hand side entities are resolved. This is done by maintaining a stack of lists of associations, rather than a stack of associations. Each ASSOCIATE statement's list of assocations is then visited once for right-hand side processing, and once for left-hand side processing. Note that other construct associations do not have this problem. SELECT RANK and SELECT TYPE each have a single assocation, not a list. Constraint C1113 prohibits the right-hand side of a CHANGE TEAM association from referencing any left-hand side entity. Differential Revision: https://reviews.llvm.org/D95010 GitOrigin-RevId: ff3b51b0549343b6ef7d718e036116d5b502458c
Flang is a ground-up implementation of a Fortran front end written in modern C++. It started off as the f18 project (https://github.com/flang-compiler/f18) with an aim to replace the previous flang project (https://github.com/flang-compiler/flang) and address its various deficiencies. F18 was subsequently accepted into the LLVM project and rechristened as Flang.
Read more about flang in the docs directory. Start with the compiler overview.
To better understand Fortran as a language and the specific grammar accepted by flang, read Fortran For C Programmers and flang's specifications of the Fortran grammar and the OpenMP grammar.
Treatment of language extensions is covered in this document.
To understand the compilers handling of intrinsics, see the discussion of intrinsics.
To understand how a flang program communicates with libraries at runtime, see the discussion of runtime descriptors.
If you're interested in contributing to the compiler, read the style guide and also review how flang uses modern C++ features.
If you are interested in writing new documentation, follow markdown style guide from LLVM.
Flang is written in C++17.
The code has been compiled and tested with GCC versions from 7.2.0 to 9.3.0.
The code has been compiled and tested with clang version 7.0, 8.0, 9.0 and 10.0 using either GNU‘s libstdc++ or LLVM’s libc++.
The code has been compiled on AArch64, x86_64 and ppc64le servers with CentOS7, Ubuntu18.04, Rhel, MacOs, Mojave, XCode and Apple Clang version 10.0.1.
The code does not compile with Windows and a compiler that does not have support for C++17.
These instructions are for building Flang separately from LLVM; if you are building Flang alongside LLVM then follow the standard LLVM build instructions and add flang to LLVM_ENABLE_PROJECTS
instead, as detailed there.
The instructions to build LLVM can be found at https://llvm.org/docs/GettingStarted.html. If you are building flang as part of LLVM, follow those instructions and add flang to LLVM_ENABLE_PROJECTS
.
We highly recommend using the same compiler to compile both llvm and flang.
The flang CMakeList.txt file uses the variable LLVM_DIR
to find the installed LLVM components and the variable MLIR_DIR
to find the installed MLIR components.
To get the correct LLVM and MLIR libraries included in your flang build, define LLVM_DIR and MLIR_DIR on the cmake command line.
LLVM=<LLVM_BUILD_DIR>/lib/cmake/llvm \ MLIR=<LLVM_BUILD_DIR>/lib/cmake/mlir \ cmake -DLLVM_DIR=$LLVM -DMLIR_DIR=$MLIR ...
where LLVM_BUILD_DIR
is the top-level directory where LLVM was built.
By default, cmake will search for g++ on your PATH. The g++ version must be one of the supported versions in order to build flang.
Or, cmake will use the variable CXX to find the C++ compiler. CXX should include the full path to the compiler or a name that will be found on your PATH, e.g. g++-8.3, assuming g++-8.3 is on your PATH.
export CXX=g++-8.3
or
CXX=/opt/gcc-8.3/bin/g++-8.3 cmake ...
To build flang with clang, cmake needs to know how to find clang++ and the GCC library and tools that were used to build clang++.
CXX should include the full path to clang++ or clang++ should be found on your PATH.
export CXX=clang++
To specify a custom install location, add -DCMAKE_INSTALL_PREFIX=<INSTALL_PREFIX>
to the cmake command where <INSTALL_PREFIX>
is the path where flang should be installed.
To create a debug build, add -DCMAKE_BUILD_TYPE=Debug
to the cmake command. Debug builds execute slowly.
To create a release build, add -DCMAKE_BUILD_TYPE=Release
to the cmake command. Release builds execute quickly.
cd ~/flang/build cmake -DLLVM_DIR=$LLVM -DMLIR_DIR=$MLIR ~/flang/src make
The new Flang driver, flang-new
, is currently under active development and should be considered as an experimental feature. For this reason it is disabled by default. This will change once the new driver replaces the throwaway driver, flang
.
In order to build the new driver, add -DFLANG_BUILD_NEW_DRIVER=ON
to your CMake invocation line. Additionally, when building out-of-tree, use CLANG_DIR
(similarly to LLVM_DIR
and MLIR_DIR
) to find the installed Clang components.
Note: CLANG_DIR
is only required when building the new Flang driver, which currently depends on Clang.
Flang supports 2 different categories of tests
To run all tests:
cd ~/flang/build cmake -DLLVM_DIR=$LLVM -DMLIR_DIR=$MLIR ~/flang/src make test check-all
To run individual regression tests llvm-lit needs to know the lit configuration for flang. The parameters in charge of this are: flang_site_config and flang_config. And they can be set as shown below:
<path-to-llvm-lit>/llvm-lit \ --param flang_site_config=<path-to-flang-build>/test-lit/lit.site.cfg.py \ --param flang_config=<path-to-flang-build>/test-lit/lit.cfg.py \ <path-to-fortran-test>
Unit tests:
If flang was built with -DFLANG_INCLUDE_TESTS=On
(ON
by default), it is possible to generate unittests. Note: Unit-tests will be skipped for LLVM install for an out-of-tree build as it does not include googletest related headers and libraries.
There are various ways to run unit-tests.
1. make check-flang-unit 2. make check-all or make check-flang 3. <path-to-llvm-lit>/llvm-lit \ test/Unit 4. Invoking tests from <out-of-tree flang build>/unittests/<respective unit test folder>
If flang was built with -DFLANG_INCLUDE_TESTS=On
(On
by default), it is possible to generate unittests.
To run all of the flang unit tests use the check-flang-unit
target:
make check-flang-unit
To run all of the flang regression tests use the check-flang
target:
make check-flang
If flang was built with -DLINK_WITH_FIR=On
(On
by default), it is possible to generate FIR language documentation by running make flang-doc
. This will create docs/Dialect/FIRLangRef.md
in flang build directory.
To generate doxygen-style documentation from source code
-DLLVM_ENABLE_DOXYGEN=ON -DFLANG_INCLUDE_DOCS=ON
to the cmake command.cd ~/llvm-project/build cmake -DLLVM_ENABLE_DOXYGEN=ON -DFLANG_INCLUDE_DOCS=ON ../llvm make doxygen-flang
It will generate html in
<build-dir>/tools/flang/docs/doxygen/html # for flang docs
Flang documentation should preferably be written in markdown(.md)
syntax (they can be in reStructuredText(.rst)
format as well but markdown is recommended in first place), it is mostly meant to be processed by the Sphinx documentation generation system to create HTML pages which would be hosted on the webpage of flang and updated periodically.
If you would like to generate and view the HTML locally:
-DLLVM_ENABLE_SPHINX=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF
to the cmake command.cd ~/llvm-project/build cmake -DLLVM_ENABLE_SPHINX=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF ../llvm make docs-flang-html
It will generate html in
$BROWSER <build-dir>/tools/flang/docs/html/