[flang-commits] [flang] [flang][docs] Replace references to f18 in the docs with flang (Part 1) (PR #163577)

[Tarun Prabhu via flang-commits]

https://github.com/tarunprabhu updated https://github.com/llvm/llvm-project/pull/163577

>From 37050415e1c8647486a1a6fa969a14a7d145a5f6 Mon Sep 17 00:00:00 2001
From: Tarun Prabhu <tarun at lanl.gov>
Date: Wed, 15 Oct 2025 09:12:18 -0600
Subject: [PATCH 1/2] [flang][docs] Replace references to f18 in the docs with
 flang (Part 1)

Some light editing of some of the text was also done. The remaining
references will be replaced in a later commit.
---
 flang/docs/AssumedRank.md            | 18 +++----
 flang/docs/C++17.md                  | 22 ++++-----
 flang/docs/C++style.md               | 18 +++----
 flang/docs/Calls.md                  |  6 +--
 flang/docs/Character.md              |  8 ++--
 flang/docs/DoConcurrent.md           |  9 ++--
 flang/docs/Extensions.md             | 34 +++++++-------
 flang/docs/FortranForCProgrammers.md |  2 +-
 flang/docs/FortranIR.md              | 12 ++---
 flang/docs/GettingInvolved.md        |  2 +-
 flang/docs/Intrinsics.md             | 70 ++++++++++++++--------------
 11 files changed, 101 insertions(+), 100 deletions(-)

diff --git a/flang/docs/AssumedRank.md b/flang/docs/AssumedRank.md
index c5d2c3e3909c7..e296316f776b3 100644
--- a/flang/docs/AssumedRank.md
+++ b/flang/docs/AssumedRank.md
@@ -101,9 +101,9 @@ Assumed-rank dummies are also represented in the
 represent assumed-rank in procedure characteristics.
 
 ### Runtime Representation of Assumed-Ranks
-Assumed-ranks are implemented as CFI_cdesc_t (18.5.3) with the addition of an
-f18 specific addendum when required for the type. This is the usual f18
-descriptor, and no changes is required to represent assumed-ranks in this data
+Assumed-ranks are implemented as CFI_cdesc_t (18.5.3) with the addition of a
+Flang specific addendum when required for the type. This is the usual Flang
+descriptor, and no changes are required to represent assumed-ranks in this data
 structure. In fact, there is no difference between the runtime descriptor
 created for an assumed shape and the runtime descriptor created when the
 corresponding entity is passed as an assumed-rank.
@@ -143,11 +143,11 @@ SSA values for assumed-rank entities have an MLIR type containing a
 (additionally wrapped in a `!fir.ref` type for pointers and allocatables).
 
 Examples:
-`INTEGER :: x(..)`  -> `!fir.box<!fir.array<* x i32>>` 
+`INTEGER :: x(..)`  -> `!fir.box<!fir.array<* x i32>>`
 `CLASS(*) :: x(..)`  -> `!fir.class<!fir.array<* x none>>`
 `TYPE(*) :: x(..)`  -> `!fir.box<!fir.array<* x none>>`
 `REAL, ALLOCATABLE :: x(..)`  -> `!fir.ref<!fir.box<!fir.heap<!fir.array<* x f32>>>>`
-`TYPE(t), POINTER :: x(..)`  -> `!fir.ref<!fir.box<!fir.ptr<!fir.array<* x !fir.type<t>>>>>` 
+`TYPE(t), POINTER :: x(..)`  -> `!fir.ref<!fir.box<!fir.ptr<!fir.array<* x !fir.type<t>>>>>`
 
 All these FIR types are implemented as the address of a CFI_cdesc_t in code
 generation.
@@ -187,7 +187,7 @@ could still be relevant:
   support assumed-ranks, but `fir.box_tdesc` would require change since the
   position of the type descriptor pointer depends on the rank.
 - as `fir.allocmem` / `fir.global` result (assumed-ranks are never local/global
-  entities). 
+  entities).
 - as `fir.embox` result (When creating descriptor for an explicit shape, the
   descriptor can be created with the entity rank, and then casted via
 `fir.convert`).
@@ -449,7 +449,7 @@ subroutine test(x)
       real :: x(..)
     end subroutine
   end interface
-  
+
   real :: x(..)
   select rank (y => x)
   rank(*)
@@ -531,7 +531,7 @@ print *, len(x)
 
 ```
 %ele_size = fir.box_elesize %x : (!fir.box<!fir.array<*x!fir.char<?>>>) -> i64
-# .... divide by character KIND byte size if needed as usual 
+# .... divide by character KIND byte size if needed as usual
 ```
 #### PRESENT
 Implemented inline with `fir.is_present` which ends-up implemented as a check
@@ -564,7 +564,7 @@ present and is constant, `fir.box_dim` can also be used with the option to add
 a runtime check that RANK <= DIM. Pointers and allocatables are dereferenced,
 which in FIR currently creates a descriptor copy that cannot be simplified
 like for the previous inquiries by inserting a cast before the fir.load (the
-dimension info must be correctly copied). 
+dimension info must be correctly copied).
 
 #### LBOUND, SHAPE, and UBOUND
 When DIM is present an is present, the runtime can be used as it is currently
diff --git a/flang/docs/C++17.md b/flang/docs/C++17.md
index f36110af86847..17f0c97867823 100644
--- a/flang/docs/C++17.md
+++ b/flang/docs/C++17.md
@@ -1,12 +1,12 @@
-<!--===- docs/C++17.md 
-  
+<!--===- docs/C++17.md
+
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-  
+
 -->
 
-# C++14/17 features used in f18
+# C++14/17 features used in Flang
 
 ```{contents}
 ---
@@ -27,7 +27,7 @@ out the details of how our C++ code should look and gives
 guidance about feature usage.
 
 We have chosen to use some features of the recent C++17
-language standard in f18.
+language standard in Flang.
 The most important of these are:
 * sum types (discriminated unions) in the form of `std::variant`
 * `using` template parameter packs
@@ -41,7 +41,7 @@ in this list because it's not particularly well known.)
 ## Sum types
 
 First, some background information to explain the need for sum types
-in f18.
+in Flang.
 
 Fortran is notoriously problematic to lex and parse, as tokenization
 depends on the state of the partial parse;
@@ -57,7 +57,7 @@ a unified lexer/parser.
 We have chosen to do so because it is simpler and should reduce
 both initial bugs and long-term maintenance.
 
-Specifically, f18's parser uses the technique of recursive descent with
+Specifically, Flang's parser uses the technique of recursive descent with
 backtracking.
 It is constructed as the incremental composition of pure parsing functions
 that each, when given a context (location in the input stream plus some state),
@@ -73,7 +73,7 @@ of Fortran.
 
 The specification of Fortran uses a form of BNF with alternatives,
 optional elements, sequences, and lists.  Each of these constructs
-in the Fortran grammar maps directly in the f18 parser to both
+in the Fortran grammar maps directly in Flang's parser to both
 the means of combining other parsers as alternatives, &c., and to
 the declarations of the parse tree data structures that represent
 the results of successful parses.
@@ -87,10 +87,10 @@ The bounded polymorphism supplied by the C++17 `std::variant` fits
 those needs exactly.
 For example, production R502 in Fortran defines the top-level
 program unit of Fortran as being a function, subroutine, module, &c.
-The `struct ProgramUnit` in the f18 parse tree header file
+`struct ProgramUnit` in the Flang parse tree header file
 represents each program unit with a member that is a `std::variant`
 over the six possibilities.
-Similarly, the parser for that type in the f18 grammar has six alternatives,
+Similarly, the parser for that type in Flang's grammar has six alternatives,
 each of which constructs an instance of `ProgramUnit` upon the result of
 parsing a `Module`, `FunctionSubprogram`, and so on.
 
@@ -99,7 +99,7 @@ parse is typically implemented with overloaded functions.
 A function instantiated on `ProgramUnit` will use `std::visit` to
 identify the right alternative and perform the right actions.
 The call to `std::visit` must pass a visitor that can handle all
-of the possibilities, and f18 will fail to build if one is missing.
+of the possibilities, and Flang will fail to build if one is missing.
 
 Were we unable to use `std::variant` directly, we would likely
 have chosen to implement a local `SumType` replacement; in the
diff --git a/flang/docs/C++style.md b/flang/docs/C++style.md
index cbb96f15eb5f1..e061b61a05c6b 100644
--- a/flang/docs/C++style.md
+++ b/flang/docs/C++style.md
@@ -1,9 +1,9 @@
-<!--===- docs/C++style.md 
-  
+<!--===- docs/C++style.md
+
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-  
+
 -->
 
 # Flang C++ Style Guide
@@ -30,7 +30,7 @@ is clear on usage, follow it.
   is pretty good and comes with lots of justifications for its rules.
 * Reasonable exceptions to these guidelines can be made.
 * Be aware of some workarounds for known issues in older C++ compilers that should
-  still be able to compile f18. They are listed at the end of this document.
+  still be able to compile Flang. They are listed at the end of this document.
 
 ## In particular:
 
@@ -261,7 +261,7 @@ move semantics, member access, and comparison for equality; suitable for use in
 `std::variant<>`.
 * `std::unique_ptr<>`: A nullable pointer with ownership, null by default,
 not copyable, reassignable.
-F18 has a helpful `Deleter<>` class template that makes `unique_ptr<>`
+Flang has a helpful `Deleter<>` class template that makes `unique_ptr<>`
 easier to use with forward-referenced data types.
 * `std::shared_ptr<>`: A nullable pointer with shared ownership via reference
 counting, null by default, shallowly copyable, reassignable, and slow.
@@ -312,9 +312,9 @@ Consistency is one of many aspects in the pursuit of clarity,
 but not an end in itself.
 
 ## C++ compiler bug workarounds
-Below is a list of workarounds for C++ compiler bugs met with f18 that, even
-if the bugs are fixed in latest C++ compiler versions, need to be applied so
-that all desired tool-chains can compile f18.
+Below is a list of workarounds for C++ compiler bugs encountered when building
+Flang. Even if the bugs are fixed in latest C++ compiler versions, these need to
+be applied so that all desired tool-chains can compile Flang.
 
 ### Explicitly move noncopyable local variable into optional results
 
@@ -338,7 +338,7 @@ std::optional<CantBeCopied> fooOK() {
 }
 ```
 The underlying bug is actually not specific to `std::optional` but this is the most common
-case in f18 where the issue may occur. The actual bug can be reproduced with any class `B`
+case in Flang where the issue may occur. The actual bug can be reproduced with any class `B`
 that has a perfect forwarding constructor taking `CantBeCopied` as argument:
 `template<typename CantBeCopied> B(CantBeCopied&& x) x_{std::forward<CantBeCopied>(x)} {}`.
 In such scenarios, Ubuntu 18.04 g++ fails to instantiate the move constructor
diff --git a/flang/docs/Calls.md b/flang/docs/Calls.md
index f518dc00ed8e8..f27af1a461bac 100644
--- a/flang/docs/Calls.md
+++ b/flang/docs/Calls.md
@@ -529,7 +529,7 @@ PGI passes host instance links in descriptors in additional arguments
 that are not always successfully forwarded across implicit interfaces,
 sometimes leading to crashes when they turn out to be needed.
 
-F18 will manage a pool of trampolines in its runtime support library
+Flang will manage a pool of trampolines in its runtime support library
 that can be used to pass internal procedures as effective arguments
 to F77ish procedures, so that
 a bare code address can serve to represent the effective argument.
@@ -569,14 +569,14 @@ Fortran 2018 explicitly enables us to do this with a correction to Fortran
 2003 in 4.3.4(5).
 
 Last, there must be reasonably permanent naming conventions used
-by the F18 runtime library for those unrestricted specific intrinsic
+by Flang's runtime library for those unrestricted specific intrinsic
 functions (table 16.2 in 16.8) and extensions that can be passed as
 arguments.
 
 In these cases where external naming is at the discretion
 of the implementation, we should use names that are not in the C language
 user namespace, begin with something that identifies
-the current incompatible version of F18, the module, the submodule, and
+the current incompatible version of Flang, the module, the submodule, and
 elemental SIMD width, and are followed by the external name.
 The parts of the external name can be separated by some character that
 is acceptable for use in LLVM IR and assembly language but not in user
diff --git a/flang/docs/Character.md b/flang/docs/Character.md
index 4e1d40774d6db..96e0a069e2ba2 100644
--- a/flang/docs/Character.md
+++ b/flang/docs/Character.md
@@ -6,7 +6,7 @@
 
 -->
 
-# Implementation of `CHARACTER` types in f18
+# Implementation of `CHARACTER` types in Flang
 
 ```{contents}
 ---
@@ -16,7 +16,7 @@ local:
 
 ## Kinds and Character Sets
 
-The f18 compiler and runtime support three kinds of the intrinsic
+The Flang compiler and runtime support three kinds of the intrinsic
 `CHARACTER` type of Fortran 2018.
 The default (`CHARACTER(KIND=1)`) holds 8-bit character codes;
 `CHARACTER(KIND=2)` holds 16-bit character codes;
@@ -108,12 +108,12 @@ The result of `//` may be used
 * as the value of a specifier of an I/O statement,
 * or as the value of a statement function.
 
-The f18 compiler has a general (but slow) means of implementing concatenation
+The Flang compiler has a general (but slow) means of implementing concatenation
 and a specialized (fast) option to optimize the most common case.
 
 ### General concatenation
 
-In the most general case, the f18 compiler's generated code and
+In the most general case, Flang's generated code and
 runtime support library represent the result as a deferred-length allocatable
 `CHARACTER` temporary scalar or array variable that is initialized
 as a zero-length array by `AllocatableInitCharacter()`
diff --git a/flang/docs/DoConcurrent.md b/flang/docs/DoConcurrent.md
index bd1008af86f6b..b3f91e32be14a 100644
--- a/flang/docs/DoConcurrent.md
+++ b/flang/docs/DoConcurrent.md
@@ -1,9 +1,9 @@
-<!--===- docs/DoConcurrent.md 
-  
+<!--===- docs/DoConcurrent.md
+
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-  
+
 -->
 
 # `DO CONCURRENT` isn't necessarily concurrent
@@ -280,7 +280,8 @@ Specifically, an easy means is required that stipulates that localization
 should apply at most only to the obvious cases of local non-pointer
 non-allocatable scalars.
 
-In the LLVM Fortran compiler project (a/k/a "flang", "f18") we considered
+In the LLVM Fortran compiler project (now known as "flang", previously also
+known as "f18") we considered
 several solutions to this problem.
 1. Add syntax (e.g., `DO PARALLEL` or `DO CONCURRENT() DEFAULT(PARALLEL)`)
    by which one can inform the compiler that it should localize only
diff --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 420b7517922b7..6d872094811e3 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -84,7 +84,7 @@ end
   be "local identifiers" and should be distinct in the "inclusive
   scope" -- i.e., not scoped by `BLOCK` constructs.
   As most (but not all) compilers implement `BLOCK` scoping of construct
-  names, so does f18, with a portability warning.
+  names, so does Flang, with a portability warning.
 * 15.6.4 paragraph 2 prohibits an implicitly typed statement function
   from sharing the same name as a symbol in its scope's host, if it
   has one.
@@ -153,7 +153,7 @@ end
   that a call to intrinsic module procedure `ieee_support_halting` with
   a constant argument has a compile time constant result in `constant
   expression` and `specification expression` contexts. In compilations
-  where this information is not known at compile time, f18 generates code
+  where this information is not known at compile time, Flang generates code
   to determine the absence or presence of this capability at runtime.
   A call to `ieee_support_halting` in contexts that the standard requires
   to be constant will generate a compilation error. `ieee_support_standard`
@@ -366,7 +366,7 @@ end
 * The legacy extension intrinsic functions `IZEXT` and `JZEXT`
   are supported; `ZEXT` has different behavior with various older
   compilers, so it is not supported.
-* f18 doesn't impose a limit on the number of continuation lines
+* Flang doesn't impose a limit on the number of continuation lines
   allowed for a single statement.
 * When a type-bound procedure declaration statement has neither interface
   nor attributes, the "::" before the bindings is optional, even
@@ -553,7 +553,7 @@ end
 * Fortran explicitly ignores type declaration statements when they
   attempt to type the name of a generic intrinsic function (8.2 p3).
   One can declare `CHARACTER::COS` and still get a real result
-  from `COS(3.14159)`, for example.  f18 will complain when a
+  from `COS(3.14159)`, for example.  Flang will complain when a
   generic intrinsic function's inferred result type does not
   match an explicit declaration.  This message is a warning.
 
@@ -570,7 +570,7 @@ end
 
 ## Standard features that might as well not be
 
-* f18 supports designators with constant expressions, properly
+* Flang supports designators with constant expressions, properly
   constrained, as initial data targets for data pointers in
   initializers of variable and component declarations and in
   `DATA` statements; e.g., `REAL, POINTER :: P => T(1:10:2)`.
@@ -587,8 +587,8 @@ end
 * The standard doesn't explicitly require that a named constant that
   appears as part of a complex-literal-constant be a scalar, but
   most compilers emit an error when an array appears.
-  f18 supports them with a portability warning.
-* f18 does not enforce a blanket prohibition against generic
+  Flang supports them with a portability warning.
+* Flang does not enforce a blanket prohibition against generic
   interfaces containing a mixture of functions and subroutines.
   We allow both to appear, unlike several other Fortran compilers.
   This is especially desirable when two generics of the same
@@ -655,7 +655,7 @@ end
   treat them as references to implicitly typed local variables, and
   load uninitialized values.
 
-  In f18, we chose to emit an error message for this case since the standard
+  In Flang, we chose to emit an error message for this case since the standard
   is unclear, the usage is not portable, and the issue can be easily resolved
   by adding a declaration.
 
@@ -686,7 +686,7 @@ end
 
 * When a `DATA` statement in a `BLOCK` construct could be construed as
   either initializing a host-associated object or declaring a new local
-  initialized object, f18 interprets the standard's classification of
+  initialized object, Flang interprets the standard's classification of
   a `DATA` statement as being a "declaration" rather than a "specification"
   construct, and notes that the `BLOCK` construct is defined as localizing
   names that have specifications in the `BLOCK` construct.
@@ -703,7 +703,7 @@ end subroutine
   Other Fortran compilers disagree with each other in their interpretations
   of this example.
   The precedent among the most commonly used compilers
-  agrees with f18's interpretation: a `DATA` statement without any other
+  agrees with Flang's interpretation: a `DATA` statement without any other
   specification of the name refers to the host-associated object.
 
 * Many Fortran compilers allow a non-generic procedure to be `USE`-associated
@@ -729,7 +729,7 @@ module m2
 end module
 ```
 
-  This case elicits a warning from f18, as it should not be treated
+  This case elicits a warning from Flang, as it should not be treated
   any differently than the same case with the non-generic procedure of
   the same name being defined in the same scope rather than being
   `USE`-associated into it, which is explicitly non-conforming in the
@@ -747,7 +747,7 @@ end module
   symbols, much less appear in specification inquiries, and there are
   application codes that expect exterior symbols whose names match
   components to be visible in a derived-type definition's default initialization
-  expressions, and so f18 follows that precedent.
+  expressions, and so Flang follows that precedent.
 
 * 19.3.1p1 "Within its scope, a local identifier of an entity of class (1)
   or class (4) shall not be the same as a global identifier used in that scope..."
@@ -769,17 +769,17 @@ end module
   left-hand side for a pointer assignment statement, and we emit a
   portability warning when it is not.
 
-* F18 allows a `USE` statement to reference a module that is defined later
+* Flang allows a `USE` statement to reference a module that is defined later
   in the same compilation unit, so long as mutual dependencies do not form
   a cycle.
   This feature forestalls any risk of such a `USE` statement reading an
   obsolete module file from a previous compilation and then overwriting
   that file later.
 
-* F18 allows `OPTIONAL` dummy arguments to interoperable procedures
+* Flang allows `OPTIONAL` dummy arguments to interoperable procedures
   unless they are `VALUE` (C865).
 
-* F18 processes the `NAMELIST` group declarations in a scope after it
+* Flang processes the `NAMELIST` group declarations in a scope after it
   has resolved all of the names in that scope.  This means that names
   that appear before their local declarations do not resolve to host
   associated objects and do not elicit errors about improper redeclarations
@@ -862,11 +862,11 @@ print *, [(j,j=1,10)]
 
 * The Fortran standard doesn't mention integer overflow explicitly. In many cases,
   however, integer overflow makes programs non-conforming.
-  F18 follows other widely-used Fortran compilers. Specifically, f18 assumes
+  Flang follows other widely-used Fortran compilers. Specifically, Flang assumes
   integer overflow never occurs in address calculations and increment of
   do-variable unless the option `-fwrapv` is enabled.
 
-* Two new ieee_round_type values were added in f18 beyond the four values
+* Two new ieee_round_type values were added in Flang beyond the four values
   defined in f03 and f08: ieee_away and ieee_other. Contemporary hardware
   typically does not have support for these rounding modes;
   ieee_support_rounding calls for these values return false.
diff --git a/flang/docs/FortranForCProgrammers.md b/flang/docs/FortranForCProgrammers.md
index 135e6b71711d3..9023fdc8a6038 100644
--- a/flang/docs/FortranForCProgrammers.md
+++ b/flang/docs/FortranForCProgrammers.md
@@ -304,7 +304,7 @@ Preprocessing behavior varies across implementations and one should not depend o
 much portability.
 Preprocessing is typically requested by the use of a capitalized filename
 suffix (e.g., "foo.F90") or a compiler command line option.
-(Since the F18 compiler always runs its built-in preprocessing stage,
+(Since Flang always runs its built-in preprocessing stage,
 no special option or filename suffix is required.)
 
 ## "Object Oriented" Programming
diff --git a/flang/docs/FortranIR.md b/flang/docs/FortranIR.md
index f9f8f6416b37a..9622887e35cff 100644
--- a/flang/docs/FortranIR.md
+++ b/flang/docs/FortranIR.md
@@ -1,9 +1,9 @@
-<!--===- docs/FortranIR.md 
-  
+<!--===- docs/FortranIR.md
+
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-  
+
 -->
 
 # Design: Fortran IR
@@ -95,7 +95,7 @@ The CFG can be directly constructed by traversing the parse tree, threading cont
 
 * Pro: Straightforward implementation when control-flow is well-structured as the contextual state parallels the syntax of the language closely.
 * Con: The contextual state needed can become large and difficult to manage in the presence of unstructured control-flow. For example, not every labeled statement in Fortran may be a control-flow destination.
-* Con: The contextual state must deal with the recursive nature of the parse tree. 
+* Con: The contextual state must deal with the recursive nature of the parse tree.
 * Con: Complexity. Since structured constructs cohabitate with unstructured constructs, the context needs to carry information about all combinations until the basic blocks and relations are fully elaborated.
 
 #### Alternative: linearized approach (decomposing the problem)
@@ -104,7 +104,7 @@ Instead of constructing the CFG directly from a parse tree traversal, an interme
 
 While each control-flow source statement is explicit in the traversal, it can be the case that not all of the targets have been traversed yet (references to forward basic blocks), and those basic blocks will not yet have been created.  These relations can be captured at the time the source is traversed, added to a to do list, and then completed when all the basic blocks for the procedure have been created. Specifically, at the point when we create a terminator all information is known to create the FIR terminator, however all basic blocks that may be referenced may not have been created. Those are resolved in one final "clean up" pass over a list of closures.
 
-* Con: An extra representation must be defined and constructed.  
+* Con: An extra representation must be defined and constructed.
 * Pro: This representation reifies all the information that is referred to as contextual state in the direct approach.
 * Pro: Constructing the linearized form can be done with a simple traversal of the parse tree.
 * Pro: Once composed the linearized form can be traversed and a CFG directly constructed.  This greatly reduces bookkeeping of contextual state.
@@ -171,7 +171,7 @@ FIR is intentionally similar to SIL from the statement level up to the level of
 Program, procedure, region, and basic block all leverage code from LLVM, in much the same way as SIL. These data structures have significant investment and engineering behind their use in compilers, and it makes sense to leverage that work.
 
 * Pro: Uses LLVM data structures, pervasive in compiler projects such as LLVM, SIL, etc.
-* Pro: Get used to seeing and using LLVM, as f18 aims to be an LLVM project
+* Pro: Get used to seeing and using LLVM, as Flang aims to be an LLVM project
 * Con: Uses LLVM data structures, which the project has been avoiding
 
 #### Alternative: C++ Standard Template Library
diff --git a/flang/docs/GettingInvolved.md b/flang/docs/GettingInvolved.md
index 79af78897c9e4..2d283422b7308 100644
--- a/flang/docs/GettingInvolved.md
+++ b/flang/docs/GettingInvolved.md
@@ -41,7 +41,7 @@ Contributions to Flang are done using GitHub Pull Requests and follow the
 ### Flang Slack Workspace
 
 -   There is a Slack workspace dedicated to Flang.
--   There are a number of topic-oriented channels available (e.g., #driver, #f18-semantics, #fir).
+-   There are a number of topic-oriented channels available (e.g., #driver, #fir).
 -   Add yourself via the *[invitation link](https://join.slack.com/t/flang-compiler/shared_invite/zt-2pcn51lh-VrRQL_YUOkxA_1CEfMGQhw "title")*
 
 ## Calls
diff --git a/flang/docs/Intrinsics.md b/flang/docs/Intrinsics.md
index 34b6559e4345f..2f0d2b6cbf23d 100644
--- a/flang/docs/Intrinsics.md
+++ b/flang/docs/Intrinsics.md
@@ -19,7 +19,7 @@ of functions or subroutines with similar interfaces as an aid to
 comprehension beyond that which might be gained from the standard's
 alphabetical list.
 
-A brief status of intrinsic procedure support in f18 is also given at the end.
+A brief status of intrinsic procedure support in Flang is also given at the end.
 
 Few procedures are actually described here apart from their interfaces; see the
 Fortran 2018 standard (section 16) for the complete story.
@@ -733,20 +733,20 @@ In case the invocation would be an error if the procedure were the intrinsic
 leaves two choices to the compiler: emit an error about the intrinsic invocation,
 or consider this is an external procedure and emit no error.
 
-f18 will always consider this case to be the intrinsic and emit errors, unless the procedure
+Flang will always consider this case to be the intrinsic and emit errors, unless the procedure
 is used as a function (resp. subroutine) and the intrinsic is a subroutine (resp. function).
 The table below gives some examples of decisions made by Fortran compilers in such case.
 
 | What is ACOS ?     | Bad intrinsic call       | External with warning |  External no warning | Other error |
 | --- | --- | --- | --- | --- |
-| `print*, ACOS()`     | gfortran, nag, xlf, f18  |  ifort                |  nvfortran           | |
-| `print*, ACOS(I)`    | gfortran, nag, xlf, f18  |  ifort                |  nvfortran           | |
-| `print*, ACOS(X=I)`  | gfortran, nag, xlf, f18  |  ifort                |                      | nvfortran (keyword on implicit extrenal )|
-| `print*, ACOS(X, X)` | gfortran, nag, xlf, f18  |  ifort                |  nvfortran           | |
-| `CALL ACOS(X)`       |                          |                       |  gfortran, nag, xlf, nvfortran, ifort, f18  | |
+| `print*, ACOS()`     | gfortran, nag, xlf, flang  |  ifort                |  nvfortran           | |
+| `print*, ACOS(I)`    | gfortran, nag, xlf, flang  |  ifort                |  nvfortran           | |
+| `print*, ACOS(X=I)`  | gfortran, nag, xlf, flang  |  ifort                |                      | nvfortran (keyword on implicit extrenal )|
+| `print*, ACOS(X, X)` | gfortran, nag, xlf, flang  |  ifort                |  nvfortran           | |
+| `CALL ACOS(X)`       |                          |                       |  gfortran, nag, xlf, nvfortran, ifort, flang  | |
 
 
-The rationale for f18 behavior is that when referring to a procedure with an
+The rationale for Flang behavior is that when referring to a procedure with an
 argument number or type that does not match the intrinsic specification, it seems safer to block
 the rather likely case where the user is using the intrinsic the wrong way.
 In case the user wanted to refer to an external function, he can add an explicit EXTERNAL
@@ -759,13 +759,13 @@ Also note that in general, the standard gives the compiler the right to consider
 any procedure that is not explicitly external as a non standard intrinsic (section 4.2 point 4).
 So it is highly advised for the programmer to use EXTERNAL statements to prevent any ambiguity.
 
-## Intrinsic Procedure Support in f18
-This section gives an overview of the support inside f18 libraries for the
+## Intrinsic Procedure Support in Flang
+This section gives an overview of the support inside Flang libraries for the
 intrinsic procedures listed above.
-It may be outdated, refer to f18 code base for the actual support status.
+It may be outdated, refer to Flang code base for the actual support status.
 
 ### Semantic Analysis
-F18 semantic expression analysis phase detects intrinsic procedure references,
+Flang semantic expression analysis phase detects intrinsic procedure references,
 validates the argument types and deduces the return types.
 This phase currently supports all the intrinsic procedures listed above but the ones in the table below.
 
@@ -789,17 +789,17 @@ Constant Expressions may be used to define kind arguments. Therefore, the semant
 expression analysis phase must be able to fold references to intrinsic functions
 listed in section 10.1.12.
 
-F18 intrinsic function folding is either performed by implementations directly
-operating on f18 scalar types or by using host runtime functions and
-host hardware types. F18 supports folding elemental intrinsic functions over
+Flang intrinsic function folding is either performed by implementations directly
+operating on Flang scalar types or by using host runtime functions and
+host hardware types. Flang supports folding elemental intrinsic functions over
 arrays when an implementation is provided for the scalars (regardless of whether
 it is using host hardware types or not).
 The status of intrinsic function folding support is given in the sub-sections below.
 
 #### Intrinsic Functions with Host Independent Folding Support
-Implementations using f18 scalar types enables folding intrinsic functions
-on any host and with any possible type kind supported by f18. The intrinsic functions
-listed below are folded using host independent implementations.
+Implementations using Flang scalar types enables folding intrinsic functions
+on any host and with any possible type kind supported by Flang. The intrinsic
+functions listed below are folded using host independent implementations.
 
 | Return Type | Intrinsic Functions with Host Independent Folding Support|
 | --- | --- |
@@ -810,12 +810,12 @@ listed below are folded using host independent implementations.
 
 #### Intrinsic Functions with Host Dependent Folding Support
 Implementations using the host runtime may not be available for all supported
-f18 types depending on the host hardware types and the libraries available on the host.
+Flang types depending on the hardware type of the and the libraries available on it.
 The actual support on a host depends on what the host hardware types are.
 The list below gives the functions that are folded using host runtime and the related C/C++ types.
-F18 automatically detects if these types match an f18 scalar type. If so,
-folding of the intrinsic functions will be possible for the related f18 scalar type,
-otherwise an error message will be produced by f18 when attempting to fold related intrinsic functions.
+Flang automatically detects if these types match an Flang scalar type. If so,
+folding of the intrinsic functions will be possible for the related Flang scalar type,
+otherwise an error message will be produced by Flang when attempting to fold related intrinsic functions.
 
 | C/C++ Host Type | Intrinsic Functions with Host Standard C++ Library Based Folding Support |
 | --- | --- |
@@ -823,17 +823,17 @@ otherwise an error message will be produced by f18 when attempting to fold relat
 | std::complex for float, double and long double| ACOS, ACOSH, ASIN, ASINH, ATAN, ATANH, COS, COSH, EXP, LOG, SIN, SINH, SQRT, TAN, TANH |
 
 On top of the default usage of C++ standard library functions for folding described
-in the table above, it is possible to compile f18 evaluate library with
+in the table above, it is possible to compile Flang evaluate library with
 [libpgmath](https://github.com/flang-compiler/flang/tree/master/runtime/libpgmath)
 so that it can be used for folding. To do so, one must have a compiled version
 of the libpgmath library available on the host and add
-`-DLIBPGMATH_DIR=<path to the compiled shared libpgmath library>` to the f18 cmake command.
+`-DLIBPGMATH_DIR=<path to the compiled shared libpgmath library>` to the Flang cmake command.
 
 Libpgmath comes with real and complex functions that replace C++ standard library
 float and double functions to fold all the intrinsic functions listed in the table above.
-It has no long double versions. If the host long double matches an f18 scalar type,
+It has no long double versions. If the host long double matches a Flang scalar type,
 C++ standard library functions will still be used for folding expressions with this scalar type.
-Libpgmath adds the possibility to fold the following functions for f18 real scalar
+Libpgmath adds the possibility to fold the following functions for Flang's real scalar
 types related to host float and double types.
 
 | C/C++ Host Type | Additional Intrinsic Function Folding Support with Libpgmath (Optional) |
@@ -841,10 +841,10 @@ types related to host float and double types.
 |float and double| BESSEL_J0, BESSEL_J1, BESSEL_JN (elemental only), BESSEL_Y0, BESSEL_Y1, BESSEL_Yn (elemental only), DERFC_SCALED, ERFC_SCALED, QERFC_SCALED |
 
 Libpgmath comes in three variants (precise, relaxed and fast). So far, only the
-precise version is used for intrinsic function folding in f18. It guarantees the greatest numerical precision.
+precise version is used for intrinsic function folding in Flang. It guarantees the greatest numerical precision.
 
 ### Intrinsic Functions with Missing Folding Support
-The following intrinsic functions are allowed in constant expressions but f18
+The following intrinsic functions are allowed in constant expressions but Flang
 is not yet able to fold them. Note that there might be constraints on the arguments
 so that these intrinsics can be used in constant expressions (see section 10.1.12 of Fortran 2018 standard).
 
@@ -1133,8 +1133,8 @@ end program rename_proc
 - **Standard:**  GNU extension
 - **Class:**     function
 - **Syntax:**    result = `SECNDS(refTime)`
-- **Arguments:** 
- 
+- **Arguments:**
+
 | ARGUMENT  | INTENT |      TYPE     |          KIND           |           Description                    |
 |-----------|--------|---------------|-------------------------|------------------------------------------|
 | `refTime` | `IN`   | `REAL, scalar`| REAL(KIND=4), required  | Reference time in seconds since midnight |
@@ -1157,16 +1157,16 @@ END PROGRAM example_secnds
 since midnight minus a user-supplied reference time `refTime`. Uses `REAL(KIND=8)` for higher precision.
 
 #### Usage and Info
-- **Standard:** PGI extension  
-- **Class:**     function  
-- **Syntax:**    result = `DSECNDS(refTime)`  
-- **Arguments:** 
+- **Standard:** PGI extension
+- **Class:**     function
+- **Syntax:**    result = `DSECNDS(refTime)`
+- **Arguments:**
 
 | ARGUMENT  | INTENT |      TYPE     |          KIND           |           Description                    |
 |-----------|--------|---------------|-------------------------|------------------------------------------|
 | `refTime` | `IN`   | `REAL, scalar`| REAL(KIND=8), required  | Reference time in seconds since midnight |
 
-- **Return Value:** REAL(KIND=8), scalar — seconds elapsed since `refTime`.  
+- **Return Value:** REAL(KIND=8), scalar — seconds elapsed since `refTime`.
 - **Purity:** Impure
 
 #### Example

>From 950c4e8757d8e8e3bb75d5e1a1173c05f7014036 Mon Sep 17 00:00:00 2001
From: Tarun Prabhu <tarun at lanl.gov>
Date: Mon, 20 Oct 2025 10:09:03 -0600
Subject: [PATCH 2/2] Don't remove trailing whitespace as part of this PR

---
 flang/docs/AssumedRank.md  | 12 ++++++------
 flang/docs/C++17.md        |  6 +++---
 flang/docs/C++style.md     |  6 +++---
 flang/docs/DoConcurrent.md |  6 +++---
 flang/docs/FortranIR.md    | 10 +++++-----
 flang/docs/Intrinsics.md   | 14 +++++++-------
 6 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/flang/docs/AssumedRank.md b/flang/docs/AssumedRank.md
index e296316f776b3..0154adc7c3ad4 100644
--- a/flang/docs/AssumedRank.md
+++ b/flang/docs/AssumedRank.md
@@ -143,11 +143,11 @@ SSA values for assumed-rank entities have an MLIR type containing a
 (additionally wrapped in a `!fir.ref` type for pointers and allocatables).
 
 Examples:
-`INTEGER :: x(..)`  -> `!fir.box<!fir.array<* x i32>>`
+`INTEGER :: x(..)`  -> `!fir.box<!fir.array<* x i32>>` 
 `CLASS(*) :: x(..)`  -> `!fir.class<!fir.array<* x none>>`
 `TYPE(*) :: x(..)`  -> `!fir.box<!fir.array<* x none>>`
 `REAL, ALLOCATABLE :: x(..)`  -> `!fir.ref<!fir.box<!fir.heap<!fir.array<* x f32>>>>`
-`TYPE(t), POINTER :: x(..)`  -> `!fir.ref<!fir.box<!fir.ptr<!fir.array<* x !fir.type<t>>>>>`
+`TYPE(t), POINTER :: x(..)`  -> `!fir.ref<!fir.box<!fir.ptr<!fir.array<* x !fir.type<t>>>>>` 
 
 All these FIR types are implemented as the address of a CFI_cdesc_t in code
 generation.
@@ -187,7 +187,7 @@ could still be relevant:
   support assumed-ranks, but `fir.box_tdesc` would require change since the
   position of the type descriptor pointer depends on the rank.
 - as `fir.allocmem` / `fir.global` result (assumed-ranks are never local/global
-  entities).
+  entities). 
 - as `fir.embox` result (When creating descriptor for an explicit shape, the
   descriptor can be created with the entity rank, and then casted via
 `fir.convert`).
@@ -449,7 +449,7 @@ subroutine test(x)
       real :: x(..)
     end subroutine
   end interface
-
+  
   real :: x(..)
   select rank (y => x)
   rank(*)
@@ -531,7 +531,7 @@ print *, len(x)
 
 ```
 %ele_size = fir.box_elesize %x : (!fir.box<!fir.array<*x!fir.char<?>>>) -> i64
-# .... divide by character KIND byte size if needed as usual
+# .... divide by character KIND byte size if needed as usual 
 ```
 #### PRESENT
 Implemented inline with `fir.is_present` which ends-up implemented as a check
@@ -564,7 +564,7 @@ present and is constant, `fir.box_dim` can also be used with the option to add
 a runtime check that RANK <= DIM. Pointers and allocatables are dereferenced,
 which in FIR currently creates a descriptor copy that cannot be simplified
 like for the previous inquiries by inserting a cast before the fir.load (the
-dimension info must be correctly copied).
+dimension info must be correctly copied). 
 
 #### LBOUND, SHAPE, and UBOUND
 When DIM is present an is present, the runtime can be used as it is currently
diff --git a/flang/docs/C++17.md b/flang/docs/C++17.md
index 17f0c97867823..9137827911426 100644
--- a/flang/docs/C++17.md
+++ b/flang/docs/C++17.md
@@ -1,9 +1,9 @@
-<!--===- docs/C++17.md
-
+<!--===- docs/C++17.md 
+  
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
+  
 -->
 
 # C++14/17 features used in Flang
diff --git a/flang/docs/C++style.md b/flang/docs/C++style.md
index e061b61a05c6b..a4ca9628b56f5 100644
--- a/flang/docs/C++style.md
+++ b/flang/docs/C++style.md
@@ -1,9 +1,9 @@
-<!--===- docs/C++style.md
-
+<!--===- docs/C++style.md 
+  
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
+  
 -->
 
 # Flang C++ Style Guide
diff --git a/flang/docs/DoConcurrent.md b/flang/docs/DoConcurrent.md
index b3f91e32be14a..eba2656fc9e52 100644
--- a/flang/docs/DoConcurrent.md
+++ b/flang/docs/DoConcurrent.md
@@ -1,9 +1,9 @@
-<!--===- docs/DoConcurrent.md
-
+<!--===- docs/DoConcurrent.md 
+  
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
+  
 -->
 
 # `DO CONCURRENT` isn't necessarily concurrent
diff --git a/flang/docs/FortranIR.md b/flang/docs/FortranIR.md
index 9622887e35cff..7f3c7b2ae5241 100644
--- a/flang/docs/FortranIR.md
+++ b/flang/docs/FortranIR.md
@@ -1,9 +1,9 @@
-<!--===- docs/FortranIR.md
-
+<!--===- docs/FortranIR.md 
+  
    Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
    See https://llvm.org/LICENSE.txt for license information.
    SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
+  
 -->
 
 # Design: Fortran IR
@@ -95,7 +95,7 @@ The CFG can be directly constructed by traversing the parse tree, threading cont
 
 * Pro: Straightforward implementation when control-flow is well-structured as the contextual state parallels the syntax of the language closely.
 * Con: The contextual state needed can become large and difficult to manage in the presence of unstructured control-flow. For example, not every labeled statement in Fortran may be a control-flow destination.
-* Con: The contextual state must deal with the recursive nature of the parse tree.
+* Con: The contextual state must deal with the recursive nature of the parse tree. 
 * Con: Complexity. Since structured constructs cohabitate with unstructured constructs, the context needs to carry information about all combinations until the basic blocks and relations are fully elaborated.
 
 #### Alternative: linearized approach (decomposing the problem)
@@ -104,7 +104,7 @@ Instead of constructing the CFG directly from a parse tree traversal, an interme
 
 While each control-flow source statement is explicit in the traversal, it can be the case that not all of the targets have been traversed yet (references to forward basic blocks), and those basic blocks will not yet have been created.  These relations can be captured at the time the source is traversed, added to a to do list, and then completed when all the basic blocks for the procedure have been created. Specifically, at the point when we create a terminator all information is known to create the FIR terminator, however all basic blocks that may be referenced may not have been created. Those are resolved in one final "clean up" pass over a list of closures.
 
-* Con: An extra representation must be defined and constructed.
+* Con: An extra representation must be defined and constructed.  
 * Pro: This representation reifies all the information that is referred to as contextual state in the direct approach.
 * Pro: Constructing the linearized form can be done with a simple traversal of the parse tree.
 * Pro: Once composed the linearized form can be traversed and a CFG directly constructed.  This greatly reduces bookkeeping of contextual state.
diff --git a/flang/docs/Intrinsics.md b/flang/docs/Intrinsics.md
index 2f0d2b6cbf23d..9a43980ae62db 100644
--- a/flang/docs/Intrinsics.md
+++ b/flang/docs/Intrinsics.md
@@ -1133,8 +1133,8 @@ end program rename_proc
 - **Standard:**  GNU extension
 - **Class:**     function
 - **Syntax:**    result = `SECNDS(refTime)`
-- **Arguments:**
-
+- **Arguments:** 
+ 
 | ARGUMENT  | INTENT |      TYPE     |          KIND           |           Description                    |
 |-----------|--------|---------------|-------------------------|------------------------------------------|
 | `refTime` | `IN`   | `REAL, scalar`| REAL(KIND=4), required  | Reference time in seconds since midnight |
@@ -1157,16 +1157,16 @@ END PROGRAM example_secnds
 since midnight minus a user-supplied reference time `refTime`. Uses `REAL(KIND=8)` for higher precision.
 
 #### Usage and Info
-- **Standard:** PGI extension
-- **Class:**     function
-- **Syntax:**    result = `DSECNDS(refTime)`
-- **Arguments:**
+- **Standard:** PGI extension  
+- **Class:**     function  
+- **Syntax:**    result = `DSECNDS(refTime)`  
+- **Arguments:** 
 
 | ARGUMENT  | INTENT |      TYPE     |          KIND           |           Description                    |
 |-----------|--------|---------------|-------------------------|------------------------------------------|
 | `refTime` | `IN`   | `REAL, scalar`| REAL(KIND=8), required  | Reference time in seconds since midnight |
 
-- **Return Value:** REAL(KIND=8), scalar — seconds elapsed since `refTime`.
+- **Return Value:** REAL(KIND=8), scalar — seconds elapsed since `refTime`.  
 - **Purity:** Impure
 
 #### Example