[flang-commits] [flang] e866c44 - [flang][docs] Replace references to f18 with flang (Part 2)
via flang-commits
flang-commits at lists.llvm.org
Mon Oct 27 08:12:14 PDT 2025
Author: Tarun Prabhu
Date: 2025-10-27T09:12:08-06:00
New Revision: e866c44b4936656ab91b8679044413331a225063
URL: https://github.com/llvm/llvm-project/commit/e866c44b4936656ab91b8679044413331a225063
DIFF: https://github.com/llvm/llvm-project/commit/e866c44b4936656ab91b8679044413331a225063.diff
LOG: [flang][docs] Replace references to f18 with flang (Part 2)
IntrinsicTypes.md has not been edited because, at the time that this PR was posted, there was another open PR updating that file. The replacement of f18 with flang will either be performed as part of that PR, or in a later commit.
Added:
Modified:
flang/docs/IORuntimeInternals.md
flang/docs/ModFiles.md
flang/docs/OpenACC-descriptor-management.md
flang/docs/OpenMP-semantics.md
flang/docs/OptionComparison.md
flang/docs/Parsing.md
flang/docs/Preprocessing.md
flang/docs/RuntimeDescriptor.md
flang/docs/RuntimeTypeInfo.md
Removed:
################################################################################
diff --git a/flang/docs/IORuntimeInternals.md b/flang/docs/IORuntimeInternals.md
index d4e321348b2de..a2d3971c9ef2a 100644
--- a/flang/docs/IORuntimeInternals.md
+++ b/flang/docs/IORuntimeInternals.md
@@ -15,7 +15,7 @@ local:
```
This note is meant to be an overview of the design of the *implementation*
-of the f18 Fortran compiler's runtime support library for I/O statements.
+of Flang's runtime support library for I/O statements.
The *interface* to the I/O runtime support library is defined in the
C++ header file `runtime/io-api.h`.
@@ -66,7 +66,7 @@ modified with optional template arguments that override their
allocators and deallocators.
Conversions between the many binary floating-point formats supported
-by f18 and their decimal representations are performed with the same
+by Flang and their decimal representations are performed with the same
template library of fast conversion algorithms used to interpret
floating-point values in Fortran source programs and to emit them
to module files.
@@ -245,7 +245,7 @@ for this purpose.
### `IoStatementState`
-F18's Fortran I/O runtime support library defines and implements an API
+Flang's Fortran I/O runtime support library defines and implements an API
that uses a sequence of function calls to implement each Fortran I/O
statement.
The state of each I/O statement in progress is maintained in some
diff --git a/flang/docs/ModFiles.md b/flang/docs/ModFiles.md
index fc05c2677fc26..32d2784e9d9f0 100644
--- a/flang/docs/ModFiles.md
+++ b/flang/docs/ModFiles.md
@@ -36,7 +36,7 @@ but this one doesn't.
The disadvantage of using the same name as other compilers is that it is not
clear which compiler created a `.mod` file and files from multiple compilers
cannot be in the same directory. This can be solved by adding something
-between the module name and extension, e.g. `<modulename>-f18.mod`. When
+between the module name and extension, e.g. `<modulename>-flang.mod`. When
this is needed, Flang accepts the option `-module-suffix` to alter the suffix.
## Format
diff --git a/flang/docs/OpenACC-descriptor-management.md b/flang/docs/OpenACC-descriptor-management.md
index 008c57937e23b..7a6e6b4346348 100644
--- a/flang/docs/OpenACC-descriptor-management.md
+++ b/flang/docs/OpenACC-descriptor-management.md
@@ -300,7 +300,7 @@ contains
### Other variables
-F18 compiler also uses descriptors for assumed-shape, assumed-rank, polymorphic, ... variables. The OpenACC specification does not prescribe how an implementation should manage the descriptors for such variables. In many (all?) cases the descriptors of these variables have a local scope of a single subprogram, and if a descriptor of such a variable is created on the device, then its live range must be limited on the device by the invocation of the subprogram (with any OpenACC constructs inside it).
+Flang also uses descriptors for assumed-shape, assumed-rank, polymorphic, ... variables. The OpenACC specification does not prescribe how an implementation should manage the descriptors for such variables. In many (all?) cases the descriptors of these variables have a local scope of a single subprogram, and if a descriptor of such a variable is created on the device, then its live range must be limited on the device by the invocation of the subprogram (with any OpenACC constructs inside it).
For example:
@@ -330,15 +330,15 @@ Pointer attachment for POINTER and ALLOCATABLE variables is a "composite" runtim
## Representing pointer attachment in MLIR OpenACC dialect
-The Fortran pointer attachment logic specified by OpenACC is not trivial, and in order to be expressed in a language independent MLIR OpenACC dialect we propose to use recipes for delegating the complexity of the implementation to F18 runtime.
+The Fortran pointer attachment logic specified by OpenACC is not trivial, and in order to be expressed in a language independent MLIR OpenACC dialect we propose to use recipes for delegating the complexity of the implementation to Flang's runtime.
```Fortran
!$acc enter data attach(d%p)
```
-The frontend generates an `acc.attach` data operation with `augPtr` being an address of the F18 descriptor representing a POINTER/ALLOCATABLE variable. Note that `augPtr` refers to an abstract augmented pointer structure, which is handled in a language specific manner by the code provided by the `attachRecipe` reference.
+The frontend generates an `acc.attach` data operation with `augPtr` being an address of the Flang descriptor representing a POINTER/ALLOCATABLE variable. Note that `augPtr` refers to an abstract augmented pointer structure, which is handled in a language specific manner by the code provided by the `attachRecipe` reference.
-The `attachRecipe` is a callback that takes `varPtr` and `augPtr` pointers, and the section's `offset` and `size` computed from the `bounds` operand of `acc.attach`. Fortran FE passes these arguments directly to F18 runtime that is aware of the descriptor structure and does all the required checks and device memory updates for the device copy of the descriptor, including the attachment counters updates.
+The `attachRecipe` is a callback that takes `varPtr` and `augPtr` pointers, and the section's `offset` and `size` computed from the `bounds` operand of `acc.attach`. Fortran FE passes these arguments directly to Flang's runtime that is aware of the descriptor structure and does all the required checks and device memory updates for the device copy of the descriptor, including the attachment counters updates.
```
acc.attach.recipe @attach_ref :
@@ -387,7 +387,7 @@ For other data clauses there is an implied ordering that the data action happens
Here, the `copyin` of the data is followed by the pointer attachment.
-### F18 runtime support
+### Flang runtime support
The `OpenACCAttachDescriptor` API is defined like this:
@@ -427,7 +427,7 @@ The implementation's behavior may be described as (OpenACC 2.7.2):
All the "is-present" checks and the data actions for the auxiliary pointers must be performed atomically with regards to the present counters bookkeeping.
-The API relies on the primitives provided by `liboffload`, so it is provided by a new F18 runtime library, e.g. `FortranOffloadRuntime`, that depends on `flang_rt.runtime` and `liboffload`. The F18 driver adds `FortranOffloadRuntime` for linking under `-fopenacc`/`-fopenmp` (and maybe additional switches like `-fopenmp-targets`).
+The API relies on the primitives provided by `liboffload`, so it is provided by a new Flang runtime library, e.g. `FortranOffloadRuntime`, that depends on `flang_rt.runtime` and `liboffload`. Flang's driver adds `FortranOffloadRuntime` for linking under `-fopenacc`/`-fopenmp` (and maybe additional switches like `-fopenmp-targets`).
## TODOs:
diff --git a/flang/docs/OpenMP-semantics.md b/flang/docs/OpenMP-semantics.md
index 57938afba62dd..9ba7595ce6130 100644
--- a/flang/docs/OpenMP-semantics.md
+++ b/flang/docs/OpenMP-semantics.md
@@ -14,7 +14,7 @@ local:
---
```
-## OpenMP for F18
+## OpenMP for Flang
1. Define and document the parse tree representation for
* Directives (listed below)
@@ -68,7 +68,7 @@ starting from `!$OMP`.
In `parser-tree.h`,
`OpenMPDeclarativeConstruct` is part
of the `SpecificationConstruct` and `SpecificationPart`
-in F18 because
+in Flang because
a declarative directive can only be placed in the specification part
of a Fortran program.
diff --git a/flang/docs/OptionComparison.md b/flang/docs/OptionComparison.md
index fb65498fa1f44..934750a07e9bb 100644
--- a/flang/docs/OptionComparison.md
+++ b/flang/docs/OptionComparison.md
@@ -8,7 +8,7 @@
# Compiler options comparison
-This document catalogs the options processed by F18's peers/competitors. Much of the document is taken up by a set of tables that list the options categorized into
diff erent topics. Some of the table headings link to more information about the contents of the tables. For example, the table on **Standards conformance** options links to <a href=#standards">notes on Standards conformance</a>.
+This document catalogs the options processed by Flang's peers/competitors. Much of the document is taken up by a set of tables that list the options categorized into
diff erent topics. Some of the table headings link to more information about the contents of the tables. For example, the table on **Standards conformance** options links to <a href=#standards">notes on Standards conformance</a>.
**There's also important information in the ___[Appendix section](#appendix)___ near the end of the document on how this data was gathered and what ___is___ and ___is not___ included in this document.**
diff --git a/flang/docs/Parsing.md b/flang/docs/Parsing.md
index bedc1ea6aee97..ccc73a1d98524 100644
--- a/flang/docs/Parsing.md
+++ b/flang/docs/Parsing.md
@@ -6,7 +6,7 @@
-->
-# The F18 Parser
+# The Flang Parser
```{contents}
---
diff --git a/flang/docs/Preprocessing.md b/flang/docs/Preprocessing.md
index db815b9244edf..5df07bc125686 100644
--- a/flang/docs/Preprocessing.md
+++ b/flang/docs/Preprocessing.md
@@ -163,7 +163,7 @@ The first block of tests (`pp0*.F`) are all fixed-form source files;
the second block (`pp1*.F90`) are free-form source files.
```
-f18
+flang
| pgfortran
| | ifort
| | | gfortran
diff --git a/flang/docs/RuntimeDescriptor.md b/flang/docs/RuntimeDescriptor.md
index e6ce825b04402..c90bad5d18ee1 100644
--- a/flang/docs/RuntimeDescriptor.md
+++ b/flang/docs/RuntimeDescriptor.md
@@ -399,7 +399,7 @@ pointer.
This design in the Standard precludes the use of static descriptors that
could be associated with dynamic base addresses.
-The F18 runtime cannot use just the mandated interoperable
+Flang's runtime cannot use just the mandated interoperable
`struct CFI_cdesc_t` argument descriptor structure as its
all-purpose data descriptor.
It has no information about derived type components, overridable
diff --git a/flang/docs/RuntimeTypeInfo.md b/flang/docs/RuntimeTypeInfo.md
index 8bd5551c66678..16fff4dd563ee 100644
--- a/flang/docs/RuntimeTypeInfo.md
+++ b/flang/docs/RuntimeTypeInfo.md
@@ -27,7 +27,7 @@ The runtime library uses *derived type description* tables to represent
the relevant characteristics of derived types.
This note summarizes the requirements for these descriptions.
-The semantics phase of the F18 frontend constructs derived type
+The semantics phase of Flang's frontend constructs derived type
descriptions from its scoped symbol table after name resolution
and semantic constraint checking have succeeded.
The lowering phase then transfers the tables to the static
@@ -85,7 +85,7 @@ bindings, and they do so in alphabetical order of binding name.
(This is an arbitrary choice -- we could also define them to
appear in binding declaration order, I suppose -- but a consistent
ordering should be used so that relocatables generated by distinct
-versions of the F18 compiler will have a better chance to interoperate.)
+versions of Flang will have a better chance to interoperate.)
### Type parameter values and "same type" testing
@@ -143,7 +143,7 @@ This means that it may or may not be passed by means of a descriptor.
Note that a `FINAL` subroutine with a scalar argument does not define
a finalizer for array objects unless the subroutine is elemental
(and probably `IMPURE`).
-This seems to be a language pitfall and F18 will emit a
+This seems to be a language pitfall and Flang will emit a
warning when an array of a finalizable derived type is declared
with a rank lacking a `FINAL` subroutine when other ranks do have one.
More information about the flang-commits
mailing list