| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang] Refine how Clang dependencies are expressed #58663 Fixes #58663 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D140998 | 3 年前 | |
[flang] Portability warning and documentation for an obscure extension A quotation mark can appear in a Fortran character literal by doubling it; for example, PRINT *, "'""'" prints '"'. When those doubled quotation marks are split by a free form line continuation, the continuation line should have an ampersand before the second quotation mark. But most compilers, including this one, allow the second quotation mark to appear as the first character on the continuation line, too. So this works: print *, "'"& "'" but it really should be written as: print *, "'"& &"'" Emit a portability warning and document that we support this near-universal extension. Differential Revision: https://reviews.llvm.org/D155973 | 2 年前 | |
[flang] Honor #line and related preprocessing directives Extend the SourceFile class to take account of #line directives when computing source file positions for error messages. Adjust the output of #line directives to -E output so that they reflect any #line directives that were in the input. Differential Revision: https://reviews.llvm.org/D153910 | 3 年前 | |
[flang] Add PowerPC vec_abs, vec_nmadd, vec_msub and vec_sel intrinsics Co-authored-by: Paul Scoropan <1paulscoropan@gmail.com> Differential Revision: https://reviews.llvm.org/D154985 | 2 年前 | |
[flang] Add comdats to functions with linkonce linkage (#66516) This fixes a bug where functions generated by the MLIR Math dialect, for example ipowi, would fail to link with link.exe on Windows due to having linkonce linkage but no associated comdat. Adding the comdat on ELF also allows linkers to perform better garbage collection in the binary. Simply adding comdats to all functions with this linkage type should also cover future cases where linkonce or linkonce_odr functions might be necessary. (cherry picked from commit 5f476b80e3d472f672f5f6a719eebe2c0aadf52c) | 2 年前 | |
[flang] Add PowerPC vec_abs, vec_nmadd, vec_msub and vec_sel intrinsics Co-authored-by: Paul Scoropan <1paulscoropan@gmail.com> Differential Revision: https://reviews.llvm.org/D154985 | 2 年前 | |
[flang] Allow runtime build with AVOID_NATIVE_INT128_T=1 This patch enables the Fortran runtime support library to be built without native 128-bit integer support in the C++ compiler. Experimental: do not merge yet. Differential Revision: https://reviews.llvm.org/D154660 (cherry picked from commit 1c35c1a73907a95ce54b5a0edca513591e2bc069) | 2 年前 | |
[flang] Add comdats to functions with linkonce linkage (#66516) This fixes a bug where functions generated by the MLIR Math dialect, for example ipowi, would fail to link with link.exe on Windows due to having linkonce linkage but no associated comdat. Adding the comdat on ELF also allows linkers to perform better garbage collection in the binary. Simply adding comdats to all functions with this linkage type should also cover future cases where linkonce or linkonce_odr functions might be necessary. (cherry picked from commit 5f476b80e3d472f672f5f6a719eebe2c0aadf52c) | 2 年前 | |
[MLIR][OpenMP][OMPIRBuilder] Use target triple to initialize IsGPU flag This patch modifies the construction of the OpenMPIRBuilder in MLIR to initialize the IsGPU flag using target triple information passed down from the Flang frontend. If not present, it will default to false. This replicates the behavior currently implemented in Clang, where the CodeGenModule::createOpenMPRuntime() method creates a different CGOpenMPRuntime instance depending on the target triple, which in turn has an effect on the IsGPU flag of the OpenMPIRBuilderConfig object. Differential Revision: https://reviews.llvm.org/D151903 | 2 年前 | |
[flang] Represent unknown extent correctly in getTypeAsString Reviewed By: razvanlupusoru Differential Revision: https://reviews.llvm.org/D155655 | 2 年前 | |
[flang] Remove non-alignment based divergences from LLVM formatting. This only changs the clang-format file and adds documentation referring to the new process for formatting code. A future commit will perform a reformatting according to these new formatting settings. Original-commit: flang-compiler/f18@02531d788e7550a2455633f87d22e3f30de7a3a7 Reviewed-on: https://github.com/flang-compiler/f18/pull/945 | 6 年前 | |
[flang] Add clang-tidy check for braces around if Flang diverges from the llvm coding style in that it requires braces around the bodies of if/while/etc statements, even when the body is a single statement. This commit adds the readability-braces-around-statements check to flang's clang-tidy config file. Hopefully the premerge bots will pick it up and report violations in Phabricator. We also explicitly disable the check in the directories corresponding to the Lower and Optimizer libraries, which rely heavily on mlir and llvm and therefore follow their coding style. Likewise for the tools directory. We also fix any outstanding violations in the runtime and in lib/Semantics. Differential Revision: https://reviews.llvm.org/D104100 | 5 年前 | |
[flang] [mlir rebase] Add MLIR config and react to MLIR name changes (flang-compiler/f18#1090) [mlir rebase] Add MLIR config and react to MLIR name changes Similar to flang-compiler/f18#1085. Now use the MLIR package to set up paths for include files and libraries. Three MLIR names changed: * VectorOpsDialect to VectorDialect * AffineOpsDialect to AffineDialect * createVectorizePass to createSuperVectorizePass Update README.md to explain how to link with MLIR. Update the example gcc to version 8.3. Update drone.io config to define -DMLIR_DIR Co-authored-by: Jean Perier <jperier@nvidia.com> Original-commit: flang-compiler/f18@116f64315f6218a7f74a8ccdc25f94d322ac6344 Reviewed-on: https://github.com/flang-compiler/f18/pull/1090 | 6 年前 | |
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045 | 6 年前 | |
[flang] Fix for 541f5c4a6db35870091dd15dfa09dde751229a17 (D140524) breaking out-of-tree flang build. | 3 年前 | |
[Flang] Add code owner for the Driver Andrzej proposed the design and led the work for the Flang Driver over the past couple of years. He is continuing to function as the primary reviewer and gate-keeper of the Driver. Reviewed By: sscalpone Differential Revision: https://reviews.llvm.org/D147573 | 3 年前 | |
Rename top-level LICENSE.txt files to LICENSE.TXT This makes all the license filenames uniform across subprojects. Differential Revision: https://reviews.llvm.org/D98380 | 5 年前 | |
[Flang][Docs] Add a GettingStarted.md for build instructions This patch fix first point of https://github.com/llvm/llvm-project/issues/60730. https://flang.llvm.org/docs/ has no build instructions. This doc page is just a copy of README page so that it can be accessible from website. Differential Revision: https://reviews.llvm.org/D148070 | 3 年前 |
Flang
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.
Please note that flang is not ready yet for production usage.
Getting Started
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 LLVM's Markdown style guide.
Consult the Getting Started with Flang for information on building and running flang.