[flang-commits] [flang] [flang][NFC] Strip trailing whitespace in markdown files (1 of 2) (PR #172700)
Tarun Prabhu via flang-commits
flang-commits at lists.llvm.org
Wed Dec 17 09:31:44 PST 2025
https://github.com/tarunprabhu created https://github.com/llvm/llvm-project/pull/172700
This only strips trailing whitespace from a subset of the .md files in flang/docs. Trailing whitespace will be removed from the remaining .md files in a future commit
>From 5df706045fcc89287dc8d2e30c4fe9ee42f6dd9e Mon Sep 17 00:00:00 2001
From: Tarun Prabhu <tarun at lanl.gov>
Date: Wed, 17 Dec 2025 10:26:07 -0700
Subject: [PATCH] [flang][NFC] Strip trailing whitespace in markdown files (1
of 2)
This only strips trailing whitespace from a subset of the .md files in
flang/docs. Trailing whitespace will be removed from the remaining .md files in
a future commit
---
flang/docs/AliasingAnalysisFIR.md | 29 +++----
flang/docs/ArrayComposition.md | 6 +-
flang/docs/AssumedRank.md | 12 +--
flang/docs/C++17.md | 6 +-
flang/docs/C++style.md | 6 +-
flang/docs/ControlFlowGraph.md | 6 +-
flang/docs/DebugGeneration.md | 4 +-
flang/docs/DoConcurrent.md | 6 +-
flang/docs/DoConcurrentConversionToOpenMP.md | 4 +-
flang/docs/F202X.md | 6 +-
flang/docs/FortranIR.md | 10 +--
flang/docs/FortranLLVMTestSuite.md | 4 +-
flang/docs/ImplementingASemanticCheck.md | 52 +++++------
flang/docs/IntrinsicTypes.md | 90 ++++++++++----------
flang/docs/LabelResolution.md | 9 +-
flang/docs/ModFiles.md | 6 +-
flang/docs/f2018-grammar.md | 2 +-
17 files changed, 128 insertions(+), 130 deletions(-)
diff --git a/flang/docs/AliasingAnalysisFIR.md b/flang/docs/AliasingAnalysisFIR.md
index ffa593f1882c1..63eff7ce0299f 100644
--- a/flang/docs/AliasingAnalysisFIR.md
+++ b/flang/docs/AliasingAnalysisFIR.md
@@ -8,20 +8,20 @@
# Aliasing analysis in FIR
-This document describes the design of Alias Analysis for the FIR dialect, using the MLIR infrastructure. The intention is to use this analysis as a building block for more advanced analyses such as global code motion.
+This document describes the design of Alias Analysis for the FIR dialect, using the MLIR infrastructure. The intention is to use this analysis as a building block for more advanced analyses such as global code motion.
-The result will be
+The result will be
1. A class, implementing the [AliasAnalysis](https://github.com/llvm/llvm-project/blob/189900eb149bb55ae3787346f57c1ccbdc50fb3c/mlir/include/mlir/Analysis/AliasAnalysis.h#L232) interface. It will be able to answer two types of queries:
- AliasResult Alias (Value lhs, Value rhs)
-
+
Given two memory references, return their aliasing behavior
- ModRefResult getModRef(Operation *op, Value location)
-
- The possible results of whether a memory access modifies or references a memory location. This will not be performing a dataflow analysis. It will not take into account the instructions in the paths between the arguments. It will merely factor the type of side effects into the aliasing results.
+
+ The possible results of whether a memory access modifies or references a memory location. This will not be performing a dataflow analysis. It will not take into account the instructions in the paths between the arguments. It will merely factor the type of side effects into the aliasing results.
1. A testing pass, performing unit testing on the analysis.
-
+
The pass will take FIR as an input, look for some predefined annotations and report their aliasing behavior. This will provide a development framework that will allow for the initial implementation of a coarse analysis that can then be refined on an ongoing basis.
@@ -35,35 +35,35 @@ The result will be
- Free
- Read
- Write
-
+
An atomic read-modify-write can have both a read and write side-effect on its operands
-
- For the implementation of getModRef, the effects will also be classified as
+
+ For the implementation of getModRef, the effects will also be classified as
- Modifying (Allocate, Free, Write)
- Non-modifying (Read)
-
+
1. Absence of MemoryEffectOpInterface
- In the absence of a MemoryEffectOpInterface, the conservative assumption will have to be that there is a modifying effect on all operands.
+ In the absence of a MemoryEffectOpInterface, the conservative assumption will have to be that there is a modifying effect on all operands.
As far as user calls are concerned, this rule will be relaxed in the presence of the `INTENT(IN)` or `VALUE` attribute.
Runtime calls are not covered by the Fortran language. They are C calls which can take raw pointers by value. We will need to define some convention for their aliasing behavior
-### Memory reference:
+### Memory reference:
Any SSA value on the RHS of an operation with a memory side effect as defined above.
### Memory source:
-The storage from which a memory reference is sourced. A memory reference may not be the source of the storage and may be reached by following the use-def chain through specific operations such as fir.convert, fir.coordinate_of, fir.array_coor, fir.embox, fir.rebox, fir.box_addr….
+The storage from which a memory reference is sourced. A memory reference may not be the source of the storage and may be reached by following the use-def chain through specific operations such as fir.convert, fir.coordinate_of, fir.array_coor, fir.embox, fir.rebox, fir.box_addr….
Possible sources are:
- The LHS of an operation with Allocate side effect, this could be local or heap
- A global symbol: the RHS of fir.address_of (Note that a global symbol is not an SSA value but an attribute)
- A dummy argument: a block argument of the entry block of a func.func operation.
- Indirect source: load of memory reference stored at another memory reference
-- Unknown source: when the use-def traversal does not reach any of the sources above.
+- Unknown source: when the use-def traversal does not reach any of the sources above.
### Path to source:
Additional information can be collected on the way to the source such as type (fir.heap, fir.ptr), attributes (fir.target) and use-def chains (fir.coordinate_of, fir.array_coor, fir.declare...). Constant paths can help disambiguate aliasing.
@@ -84,4 +84,3 @@ Distinct sources are assumed to not alias except in the following cases:
1. A pointer type source may alias with any other pointer type source.
1. A source with the fir.target attribute may alias with any other pointer type source.
1. Indirect sources of non pointer type and unknown sources may alias with any source.
-
diff --git a/flang/docs/ArrayComposition.md b/flang/docs/ArrayComposition.md
index 8de1c760d281a..e57e7cf4a25bd 100644
--- a/flang/docs/ArrayComposition.md
+++ b/flang/docs/ArrayComposition.md
@@ -1,9 +1,9 @@
-<!--===- docs/ArrayComposition.md
-
+<!--===- docs/ArrayComposition.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
-
+
-->
# Array Composition
diff --git a/flang/docs/AssumedRank.md b/flang/docs/AssumedRank.md
index 0154adc7c3ad4..e296316f776b3 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 9137827911426..17f0c97867823 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 a4ca9628b56f5..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
diff --git a/flang/docs/ControlFlowGraph.md b/flang/docs/ControlFlowGraph.md
index 35eb4c4798d6d..95be3858066d2 100644
--- a/flang/docs/ControlFlowGraph.md
+++ b/flang/docs/ControlFlowGraph.md
@@ -1,9 +1,9 @@
-<!--===- docs/ControlFlowGraph.md
-
+<!--===- docs/ControlFlowGraph.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
-
+
-->
# Control Flow Graph
diff --git a/flang/docs/DebugGeneration.md b/flang/docs/DebugGeneration.md
index 9409d7e07b104..f26bb82a7c4f4 100644
--- a/flang/docs/DebugGeneration.md
+++ b/flang/docs/DebugGeneration.md
@@ -19,7 +19,7 @@ availability of the Classic Flang compiler.
By default, Flang will not generate any debug or linetable information.
Debug information will be generated if the following flags are present.
--gline-tables-only, -g1 : Emit debug line number tables only
+-gline-tables-only, -g1 : Emit debug line number tables only
-g : Emit full debug info
## Line Table Generation
@@ -170,7 +170,7 @@ which gets translated to LLVM IR's `DILocalVariable`.
Arguments work in similar way, but they present a difficulty that `DeclareOp`'s
memref points to `BlockArgument`. Unlike the op in local variable case,
the `BlockArgument` are not handled by the FIRToLLVMLowering. This can easily
-be handled by adding after conversion to LLVM dialect either in FIRToLLVMLowering
+be handled by adding after conversion to LLVM dialect either in FIRToLLVMLowering
or in a separate pass.
### Module
diff --git a/flang/docs/DoConcurrent.md b/flang/docs/DoConcurrent.md
index eba2656fc9e52..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
diff --git a/flang/docs/DoConcurrentConversionToOpenMP.md b/flang/docs/DoConcurrentConversionToOpenMP.md
index 76c54f5bbf587..78c5eb30cceb7 100644
--- a/flang/docs/DoConcurrentConversionToOpenMP.md
+++ b/flang/docs/DoConcurrentConversionToOpenMP.md
@@ -219,7 +219,7 @@ exceptions to this are:
`flang/test/Transforms/DoConcurrent/locally_destroyed_temp.f90`.
Implicit mapping detection (for mapping to the target device) is still quite
-limited and work to make it smarter is underway for both OpenMP in general
+limited and work to make it smarter is underway for both OpenMP in general
and `do concurrent` mapping.
#### Non-perfectly-nested loops' IVs
@@ -318,7 +318,7 @@ as well.
Similar to locality specifiers, mapping reductions from `do concurrent` to OpenMP
is also still an open TODO. We can potentially extend the MLIR infrastructure
-proposed in the previous section to share reduction records among the different
+proposed in the previous section to share reduction records among the different
relevant dialects as well.
### More advanced detection of loop nests
diff --git a/flang/docs/F202X.md b/flang/docs/F202X.md
index 7504561a64aa6..d1940a1858db1 100644
--- a/flang/docs/F202X.md
+++ b/flang/docs/F202X.md
@@ -1,9 +1,9 @@
-<!--===- docs/F202X.md
-
+<!--===- docs/F202X.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
-
+
-->
# A first take on Fortran 202X features for LLVM Flang
diff --git a/flang/docs/FortranIR.md b/flang/docs/FortranIR.md
index 7f3c7b2ae5241..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.
diff --git a/flang/docs/FortranLLVMTestSuite.md b/flang/docs/FortranLLVMTestSuite.md
index 8d9daa45ffbcc..79b7037be127a 100644
--- a/flang/docs/FortranLLVMTestSuite.md
+++ b/flang/docs/FortranLLVMTestSuite.md
@@ -70,6 +70,6 @@ cmake -G "Ninja" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ \
Tests from the gfortran test suite have been imported into the LLVM Test Suite.
The tests will be run automatically if the test suite is built following the
instructions described [above](#running-the-llvm-test-suite-with-fortran).
-There are additional configure-time options that can be used with the gfortran
-tests. More details about those options and their purpose can be found in
+There are additional configure-time options that can be used with the gfortran
+tests. More details about those options and their purpose can be found in
[`Fortran/gfortran/README.md`](https://github.com/llvm/llvm-test-suite/tree/main/Fortran/gfortran/README.md).
diff --git a/flang/docs/ImplementingASemanticCheck.md b/flang/docs/ImplementingASemanticCheck.md
index 598ef696ad14b..7f30a4ec54b99 100644
--- a/flang/docs/ImplementingASemanticCheck.md
+++ b/flang/docs/ImplementingASemanticCheck.md
@@ -1,9 +1,9 @@
-<!--===- docs/ImplementingASemanticCheck.md
-
+<!--===- docs/ImplementingASemanticCheck.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
-
+
-->
# How to implement a Sematic Check in Flang
@@ -16,7 +16,7 @@ local:
I recently added a semantic check to the Flang compiler front end. This document
describes my thought process and the resulting implementation.
-For more information about the compiler, start with the
+For more information about the compiler, start with the
[compiler overview](Overview.md).
## Problem definition
@@ -24,7 +24,7 @@ For more information about the compiler, start with the
In the 2018 Fortran standard, section 11.1.7.4.3, paragraph 2, states that:
```
-Except for the incrementation of the DO variable that occurs in step (3), the DO variable
+Except for the incrementation of the DO variable that occurs in step (3), the DO variable
shall neither be redefined nor become undefined while the DO construct is active.
```
One of the ways that DO variables might be redefined is if they are passed to
@@ -91,7 +91,7 @@ Here's the relevant fragment of the parse tree produced by the compiler:
| | | | | | | ActualArgSpec
| | | | | | | | ActualArg -> Expr = 'ivar'
| | | | | | | | | Designator -> DataRef -> Name = 'ivar'
-| | | EndDoStmt ->
+| | | EndDoStmt ->
```
Note that this fragment of the tree only shows four `parser::Expr` nodes,
@@ -106,7 +106,7 @@ constant 216 in the statement:
I then considered what I needed to do. I needed to detect situations where an
active DO variable was passed to a dummy argument with `INTENT(OUT)` or
`INTENT(INOUT)`. Once I detected such a situation, I needed to produce a
-message that highlighted the erroneous source code.
+message that highlighted the erroneous source code.
### Deciding where to add the code to the compiler
This new semantic check would depend on several types of information -- the
@@ -172,8 +172,8 @@ The first function is intended for dummy arguments of `INTENT(INOUT)` and
the second for `INTENT(OUT)`.
Thus I needed three pieces of
-information --
-1. the source location of the erroneous text,
+information --
+1. the source location of the erroneous text,
2. the `INTENT` of the associated dummy argument, and
3. the relevant symbol passed as the actual argument.
@@ -219,7 +219,7 @@ node to an `evaluate::ProcedureRef` node. But I knew that there was an
existing framework used in DO construct semantic checking that traversed an
`evaluate::Expr` node collecting `semantics::Symbol` nodes. I guessed that I'd
be able to use a similar framework to traverse an `evaluate::Expr` node to
-find all of the `evaluate::ActualArgument` nodes.
+find all of the `evaluate::ActualArgument` nodes.
Note that the compiler has multiple types called `Expr`. One is in the
`parser` namespace. `parser::Expr` is defined in the file
@@ -257,7 +257,7 @@ would have the second piece of information I needed.
### Determining if the actual argument is a variable
I also guessed that I could determine if the `evaluate::ActualArgument`
-consisted of a variable.
+consisted of a variable.
Once I had a symbol for the variable, I could call one of the functions:
```C++
@@ -277,7 +277,7 @@ argument was an active DO variable.
I started my implementation by adding a visitor for `parser::Expr` nodes.
Since this analysis is part of DO construct checking, I did this in
`lib/Semantics/check-do.cpp`. I added a print statement to the visitor to
-verify that my new code was actually getting executed.
+verify that my new code was actually getting executed.
In `lib/Semantics/check-do.h`, I added the declaration for the visitor:
@@ -529,7 +529,7 @@ So far, so good.
The third and last piece of information I needed was to determine if a variable
was being passed as an actual argument. In such cases, I wanted to get the
symbol table node (`semantics::Symbol`) for the variable. My starting point was the
-`evaluate::ActualArgument` node.
+`evaluate::ActualArgument` node.
I was unsure of how to do this, so I browsed through existing code to look for
how it treated `evaluate::ActualArgument` objects. Since most of the code that deals with the `evaluate` namespace is in the lib/Evaluate directory, I looked there. I ran `grep` on all of the `.cpp` files looking for
@@ -554,7 +554,7 @@ get an `evaluate::Expr<SomeType>` on which I could perform further analysis.
I also knew that the header file `include/flang/Evaluate/tools.h` held many
utility functions for dealing with `evaluate::Expr` objects. I was hoping to
find something that would determine if an `evaluate::Expr` was a variable. So
-I searched for `IsVariable` and got a hit immediately.
+I searched for `IsVariable` and got a hit immediately.
```C++
template<typename A> bool IsVariable(const A &x) {
if (auto known{IsVariableHelper{}(x)}) {
@@ -614,13 +614,13 @@ work:
}
}
}
-```
+```
Note the line that prints out the symbol table entry for the variable:
```C++
std::cout << "Found a whole variable: " << *var << "\n";
-```
+```
The compiler defines the "<<" operator for `semantics::Symbol`, which is handy
for analyzing the compiler's behavior.
@@ -665,12 +665,12 @@ compiler code accordingly:
common::Intent intent{argRef->dummyIntent()};
switch (intent) {
case common::Intent::In: std::cout << "INTENT(IN)\n"; break;
- case common::Intent::Out:
- std::cout << "INTENT(OUT)\n";
+ case common::Intent::Out:
+ std::cout << "INTENT(OUT)\n";
context_.CheckDoVarRedefine(parsedExpr.source, *var);
break;
- case common::Intent::InOut:
- std::cout << "INTENT(INOUT)\n";
+ case common::Intent::InOut:
+ std::cout << "INTENT(INOUT)\n";
context_.WarnDoVarRedefine(parsedExpr.source, *var);
break;
default: std::cout << "default INTENT\n";
@@ -679,7 +679,7 @@ compiler code accordingly:
}
}
}
-```
+```
I then ran this code on my test case, and miraculously, got the following
output:
@@ -712,7 +712,7 @@ Even sweeter.
At this point, my implementation seemed to be working. But I was concerned
about the limitations of my test case. So I augmented it to include arguments
other than `INTENT(OUT)` and more complex expressions. Luckily, my
-augmented test did not reveal any new problems.
+augmented test did not reveal any new problems.
Here's the test I ended up with:
@@ -731,7 +731,7 @@ Here's the test I ended up with:
jvar = intentOutFunc(ivar)
end do
- ! Error for passing a DO variable to an INTENT(OUT) dummy, more complex
+ ! Error for passing a DO variable to an INTENT(OUT) dummy, more complex
! expression
do ivar = 1, 10
jvar = 83 + intentInFunc(intentOutFunc(ivar))
@@ -781,10 +781,10 @@ to make sure that the names were clear. Here's what I ended up with:
if (const Symbol * var{evaluate::UnwrapWholeSymbolDataRef(*argExpr)}) {
common::Intent intent{argRef->dummyIntent()};
switch (intent) {
- case common::Intent::Out:
+ case common::Intent::Out:
context_.CheckDoVarRedefine(parsedExpr.source, *var);
break;
- case common::Intent::InOut:
+ case common::Intent::InOut:
context_.WarnDoVarRedefine(parsedExpr.source, *var);
break;
default:; // INTENT(IN) or default intent
@@ -795,7 +795,7 @@ to make sure that the names were clear. Here's what I ended up with:
}
```
-I then created a pull request to get review comments.
+I then created a pull request to get review comments.
## Responding to pull request comments
I got feedback suggesting that I use an `if` statement rather than a
diff --git a/flang/docs/IntrinsicTypes.md b/flang/docs/IntrinsicTypes.md
index 0fee1c3870245..504723185e726 100644
--- a/flang/docs/IntrinsicTypes.md
+++ b/flang/docs/IntrinsicTypes.md
@@ -27,52 +27,52 @@ in [Character.md](Character.md).
Here are the type and kind combinations supported in f18:
-INTEGER(KIND=1) 8-bit two's-complement integer
-INTEGER(KIND=2) 16-bit two's-complement integer
-INTEGER(KIND=4) 32-bit two's-complement integer
-INTEGER(KIND=8) 64-bit two's-complement integer
-INTEGER(KIND=16) 128-bit two's-complement integer
-
-REAL(KIND=2) 16-bit IEEE 754 binary16 (5e11m)
-REAL(KIND=3) 16-bit upper half of 32-bit IEEE 754 binary32 (8e8m)
-REAL(KIND=4) 32-bit IEEE 754 binary32 (8e24m)
-REAL(KIND=8) 64-bit IEEE 754 binary64 (11e53m)
-REAL(KIND=10) 80-bit extended precision with explicit normalization bit (15e64m)
-REAL(KIND=16) 128-bit IEEE 754 binary128 (15e113m)
-
-COMPLEX(KIND=2) Two 16-bit IEEE 754 binary16
-COMPLEX(KIND=3) Two 16-bit upper half of 32-bit IEEE 754 binary32
-COMPLEX(KIND=4) Two 32-bit IEEE 754 binary32
-COMPLEX(KIND=8) Two 64-bit IEEE 754 binary64
-COMPLEX(KIND=10) Two 80-bit extended precisions values
-COMPLEX(KIND=16) Two 128-bit IEEE 754 binary128
+INTEGER(KIND=1) 8-bit two's-complement integer
+INTEGER(KIND=2) 16-bit two's-complement integer
+INTEGER(KIND=4) 32-bit two's-complement integer
+INTEGER(KIND=8) 64-bit two's-complement integer
+INTEGER(KIND=16) 128-bit two's-complement integer
+
+REAL(KIND=2) 16-bit IEEE 754 binary16 (5e11m)
+REAL(KIND=3) 16-bit upper half of 32-bit IEEE 754 binary32 (8e8m)
+REAL(KIND=4) 32-bit IEEE 754 binary32 (8e24m)
+REAL(KIND=8) 64-bit IEEE 754 binary64 (11e53m)
+REAL(KIND=10) 80-bit extended precision with explicit normalization bit (15e64m)
+REAL(KIND=16) 128-bit IEEE 754 binary128 (15e113m)
+
+COMPLEX(KIND=2) Two 16-bit IEEE 754 binary16
+COMPLEX(KIND=3) Two 16-bit upper half of 32-bit IEEE 754 binary32
+COMPLEX(KIND=4) Two 32-bit IEEE 754 binary32
+COMPLEX(KIND=8) Two 64-bit IEEE 754 binary64
+COMPLEX(KIND=10) Two 80-bit extended precisions values
+COMPLEX(KIND=16) Two 128-bit IEEE 754 binary128
No
[double-double
](https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format)
quad precision type is supported.
-LOGICAL(KIND=1) 8-bit integer
-LOGICAL(KIND=2) 16-bit integer
-LOGICAL(KIND=4) 32-bit integer
-LOGICAL(KIND=8) 64-bit integer
+LOGICAL(KIND=1) 8-bit integer
+LOGICAL(KIND=2) 16-bit integer
+LOGICAL(KIND=4) 32-bit integer
+LOGICAL(KIND=8) 64-bit integer
No 128-bit logical support.
### Defaults kinds
-INTEGER 4
-REAL 4
-COMPLEX 4
-DOUBLE PRECISION 8
-LOGICAL 4
+INTEGER 4
+REAL 4
+COMPLEX 4
+DOUBLE PRECISION 8
+LOGICAL 4
-#### Modifying the default kind with default-real-8.
-REAL 8
-DOUBLE PRECISION 8
-COMPLEX 8
+#### Modifying the default kind with default-real-8.
+REAL 8
+DOUBLE PRECISION 8
+COMPLEX 8
-#### Modifying the default kind with default-integer-8:
+#### Modifying the default kind with default-integer-8:
INTEGER 8
LOGICAL 8
@@ -85,9 +85,9 @@ Module files encode the kind value for every entity.
The default logical is `LOGICAL(KIND=4)`.
Logical literal constants with kind 1, 2, 4, and 8
-share the following characteristics:
-.TRUE. is represented as 1_kind
-.FALSE. is represented as 0_kind
+share the following characteristics:
+.TRUE. is represented as 1_kind
+.FALSE. is represented as 0_kind
Tests for true is *integer value is not zero*.
@@ -99,16 +99,16 @@ use LOGICAL values to interface with other languages.
### Representations of LOGICAL variables in other compilers
#### Intel ifort / NVIDA nvfortran / PGI pgf90
-.TRUE. is represented as -1_kind
-.FALSE. is represented as 0_kind
-Any other values result in undefined behavior.
+.TRUE. is represented as -1_kind
+.FALSE. is represented as 0_kind
+Any other values result in undefined behavior.
-Values with a low-bit set are treated as .TRUE..
-Values with a low-bit clear are treated as .FALSE..
+Values with a low-bit set are treated as .TRUE..
+Values with a low-bit clear are treated as .FALSE..
#### IBM XLF
-.TRUE. is represented as 1_kind
-.FALSE. is represented as 0_kind
+.TRUE. is represented as 1_kind
+.FALSE. is represented as 0_kind
-Values with a low-bit set are treated as .TRUE..
-Values with a low-bit clear are treated as .FALSE..
+Values with a low-bit set are treated as .TRUE..
+Values with a low-bit clear are treated as .FALSE..
diff --git a/flang/docs/LabelResolution.md b/flang/docs/LabelResolution.md
index 5e2fbe72172cc..2e79e088e70c5 100644
--- a/flang/docs/LabelResolution.md
+++ b/flang/docs/LabelResolution.md
@@ -1,9 +1,9 @@
-<!--===- docs/LabelResolution.md
-
+<!--===- docs/LabelResolution.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
-
+
-->
# Semantics: Resolving Labels and Construct Names
@@ -31,7 +31,7 @@ This is the detailed design document on how these labels will be semantically ch
### Label generalities (6.2.5)
-Enforcement of the general label constraints. There are three sorts of label usage. Labels can serve
+Enforcement of the general label constraints. There are three sorts of label usage. Labels can serve
1. as a _label-do-stmt_ block range marker
1. as branching (control flow) targets
1. as specification annotations (`FORMAT` statements) for data transfer statements (I/O constructs)
@@ -291,4 +291,3 @@ The `EXIT` statement takes an optional _construct-name_.
- if the `EXIT` does not have a _construct-name_, the `EXIT` statement must appear within a _do-construct_ (C1166)
- an _exit-stmt_ must not appear in a `DO CONCURRENT` if the `EXIT` belongs to the `DO CONCURRENT` or an outer construct enclosing the `DO CONCURRENT` (C1167)
- an _exit-stmt_ must not appear in a `CHANGE TEAM` (`CRITICAL`) if the `EXIT` belongs to an outer construct enclosing the `CHANGE TEAM` (`CRITICAL`) (C1168)
-
diff --git a/flang/docs/ModFiles.md b/flang/docs/ModFiles.md
index 32d2784e9d9f0..4485770f7d24d 100644
--- a/flang/docs/ModFiles.md
+++ b/flang/docs/ModFiles.md
@@ -1,9 +1,9 @@
-<!--===- docs/ModFiles.md
-
+<!--===- docs/ModFiles.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
-
+
-->
# Module Files
diff --git a/flang/docs/f2018-grammar.md b/flang/docs/f2018-grammar.md
index 89d2184adde85..d1141c1edbeec 100644
--- a/flang/docs/f2018-grammar.md
+++ b/flang/docs/f2018-grammar.md
@@ -798,4 +798,4 @@ R1542 return-stmt -> RETURN [scalar-int-expr]
R1543 contains-stmt -> CONTAINS
R1544 stmt-function-stmt ->
function-name ( [dummy-arg-name-list] ) = scalar-expr
-```
+```
More information about the flang-commits
mailing list