[flang-commits] [flang] [flang][docs] Fix broken flang website (PR #80363)
Tarun Prabhu via flang-commits
flang-commits at lists.llvm.org
Thu Feb 1 15:33:33 PST 2024
https://github.com/tarunprabhu created https://github.com/llvm/llvm-project/pull/80363
These are several fixes for the flang site. The look has been changed to match clang since flang, like clang, is a frontend. Some broken links were removed. Most fixes are to secton titles so the table of contents is generated correctly. A minor typo has been fixed.
>From f04b0d8594e7669ce5addb1f8b61ba73b3f71668 Mon Sep 17 00:00:00 2001
From: Tarun Prabhu <tarun at lanl.gov>
Date: Thu, 1 Feb 2024 15:54:17 -0700
Subject: [PATCH] [flang][docs] Fix broken flang website
These are several fixes for the flang site. The look has been changed to match
clang since flang, like clang, is a frontend. Some broken links were removed.
Most fixes are to secton titles so the table of contents is generated
correctly. A minor typo has been fixed.
---
flang/docs/AliasingAnalysisFIR.md | 4 +-
flang/docs/FIRArrayOperations.md | 2 +-
flang/docs/FlangDriver.md | 26 ++++-----
flang/docs/HighLevelFIR.md | 26 +++++----
flang/docs/OpenACC-descriptor-management.md | 2 +-
flang/docs/Overview.md | 18 +++---
flang/docs/ParameterizedDerivedTypes.md | 62 ++++++++++-----------
flang/docs/PolymorphicEntities.md | 4 +-
flang/docs/ProcedurePointer.md | 4 +-
flang/docs/conf.py | 21 ++-----
flang/docs/index.md | 4 +-
11 files changed, 81 insertions(+), 92 deletions(-)
diff --git a/flang/docs/AliasingAnalysisFIR.md b/flang/docs/AliasingAnalysisFIR.md
index 1522bbd4f0d2a..ffa593f1882c1 100644
--- a/flang/docs/AliasingAnalysisFIR.md
+++ b/flang/docs/AliasingAnalysisFIR.md
@@ -74,12 +74,12 @@ Because of block arguments, a memory reference may have multiple sources. If a b
### Pointer type
A type `fir.box<fir.ptr<T>>` or `fir.ptr<T>`
-# Aliasing rules
+## Aliasing rules
The goal is to match [Fortran’s rule for aliasing](Aliasing.md). However FIR is all we have at this stage so the hope is that we can define an algorithm using the information from FIR to properly model Fortran’s aliasing rules. Wherever there is a gap, we may have to refine the algorithm, add information in FIR or both. Though, with the introduction of the fir.declare operation, most of the source level information relevant to aliasing will be populated in FIR.
The first attempt to determine aliasing will be at the coarsest level: the source level. The answer to the query will be ‘yes’, ‘no’, ‘maybe’. If the answer is ‘yes’ or ‘no’, the query is complete. If the answer is ‘maybe’ then further analysis is required until a definite answer is reached. If no finer analysis is available then 'maybe' is returned.
-## Coarse rules
+### Coarse rules
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.
diff --git a/flang/docs/FIRArrayOperations.md b/flang/docs/FIRArrayOperations.md
index 6f9ffb2c5a070..230409bd04a94 100644
--- a/flang/docs/FIRArrayOperations.md
+++ b/flang/docs/FIRArrayOperations.md
@@ -90,7 +90,7 @@ reference, and its semantics guarantee immutability.
// a fir.store here into array %a does not change %v
```
-# array_merge_store
+## array_merge_store
The `array_merge_store` operation stores a merged array value to memory.
diff --git a/flang/docs/FlangDriver.md b/flang/docs/FlangDriver.md
index ae0e6edd6006c..814f3eb12cfcb 100644
--- a/flang/docs/FlangDriver.md
+++ b/flang/docs/FlangDriver.md
@@ -383,7 +383,7 @@ At this point you should be able to trigger that frontend action that you have
just added using your new frontend option.
-# CMake Support
+## CMake Support
As of [#7246](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7246)
(and soon to be released CMake 3.24.0), `cmake` can detect `flang-new` as a
supported Fortran compiler. You can configure your CMake projects to use
@@ -397,7 +397,7 @@ You should see the following in the output:
```
where `<version>` corresponds to the LLVM Flang version.
-# Testing
+## Testing
In LIT, we define two variables that you can use to invoke Flang's drivers:
* `%flang` is expanded as `flang-new` (i.e. the compiler driver)
* `%flang_fc1` is expanded as `flang-new -fc1` (i.e. the frontend driver)
@@ -416,7 +416,7 @@ test as only available on Unix-like systems (i.e. systems that contain a Unix
shell). In practice this means that the corresponding test is skipped on
Windows.
-# Frontend Driver Plugins
+## Frontend Driver Plugins
Plugins are an extension to the frontend driver that make it possible to run
extra user defined frontend actions, in the form of a specialization of a
`PluginParseTreeAction`. These actions are run during compilation, after
@@ -429,7 +429,7 @@ plugins. The process for using plugins includes:
Flang plugins are limited to `flang-new -fc1` and are currently only available /
been tested on Linux.
-## Creating a Plugin
+### Creating a Plugin
There are three parts required for plugins to work:
1. [`PluginParseTreeAction` subclass](#a-pluginparsetreeaction-subclass)
1. [Implementation of `ExecuteAction`](#implementation-of-executeaction)
@@ -439,7 +439,7 @@ There is an example plugin located in `flang/example/PrintFlangFunctionNames`
that demonstrates these points by using the `ParseTree` API to print out
function and subroutine names declared in the input file.
-### A `PluginParseTreeAction` Subclass
+#### A `PluginParseTreeAction` Subclass
This subclass will wrap everything together and represent the `FrontendAction`
corresponding to your plugin. It will need to inherit from
`PluginParseTreeAction` (defined in `flang/include/flang/FrontendActions.h`), in
@@ -449,7 +449,7 @@ can be registered, e.g.
class PrintFunctionNamesAction : public PluginParseTreeAction
```
-### Implementation of `ExecuteAction`
+#### Implementation of `ExecuteAction`
Like in other frontend actions, the driver looks for an `ExecuteAction` function
to run, so in order for your plugin to do something, you will need to implement
the `ExecuteAction` method in your plugin class. This method will contain the
@@ -494,7 +494,7 @@ defined in `flang/include/flang/Parser/parse-tree.h`. In the example, there is a
the `FunctionStmt` struct and prints it. This function will be run after every
`FunctionStmt` node is visited in the parse tree.
-### Plugin Registration
+#### Plugin Registration
A plugin registry is used to store names and descriptions of a collection of
plugins. The Flang plugin registry, defined in
`flang/include/flang/Frontend/FrontendPluginRegistry.h`, is an alias of
@@ -509,7 +509,7 @@ static FrontendPluginRegistry::Add<PrintFunctionNamesAction> X(
"print-fns", "Print Function names");
```
-## Loading and Running a Plugin
+### Loading and Running a Plugin
In order to use plugins, there are 2 command line options made available to the
frontend driver, `flang-new -fc1`:
* [`-load <dsopath>`](#the--load-dsopath-option) for loading the dynamic shared
@@ -525,19 +525,19 @@ Both these options are parsed in `flang/lib/Frontend/CompilerInvocation.cpp` and
fulfil their actions in
`flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp`
-### The `-load <dsopath>` option
+#### The `-load <dsopath>` option
This loads the plugin shared object library, with the path given at `<dsopath>`,
using `LoadLibraryPermantly` from LLVM's `llvm::sys::DynamicLibrary`, which
itself uses `dlopen`. During this stage, the plugin is registered with the
registration line from the plugin, storing the name and description.
-### The `-plugin <name>` option
+#### The `-plugin <name>` option
This sets `frontend::ActionKind programAction` in `FrontendOptions` to
`PluginAction`, through which it searches the plugin registry for the plugin
name from `<name>`. If found, it returns the instantiated plugin, otherwise it
reports an error diagnostic and returns `nullptr`.
-## Enabling In-Tree Plugins
+### Enabling In-Tree Plugins
For in-tree plugins, there is the CMake flag `FLANG_PLUGIN_SUPPORT`, enabled by
default, that controls the exporting of executable symbols from `flang-new`,
which plugins need access to. Additionally, there is the CMake flag
@@ -547,7 +547,7 @@ example programs are built. This includes plugins that are in the
`flang/examples/CMakeLists.txt`, for example, the `PrintFlangFunctionNames`
plugin. It is also possible to develop plugins out-of-tree.
-## Limitations
+### Limitations
Note that the traversal API presented here is under active development and
might change in the future. We expect it to evolve as support for new
language features are added. This document and the examples will be updated
@@ -564,7 +564,7 @@ to re-analyze expressions and modify scope or symbols. You can check
[Semantics.md](Semantics.md) for more details on how `ParseTree` is edited
e.g. during the semantic checks.
-# LLVM Pass Plugins
+## LLVM Pass Plugins
Pass plugins are dynamic shared objects that consist of one or more LLVM IR
passes. The `-fpass-plugin` option enables these passes to be passed to the
diff --git a/flang/docs/HighLevelFIR.md b/flang/docs/HighLevelFIR.md
index 15b2d44a08f9f..de8dc5a1959bb 100644
--- a/flang/docs/HighLevelFIR.md
+++ b/flang/docs/HighLevelFIR.md
@@ -1,3 +1,5 @@
+# High-Level Fortran IR (HLFIR)
+
The approach of FIR and lowering design so far was to start with the minimal set
of IR operations that could allow implementing the core aspects of Fortran (like
memory allocations, array addressing, runtime descriptors, and structured
@@ -41,9 +43,9 @@ The core impact on lowering will be:
relevant.
-# Variable and Expression value concepts in HLFIR
+## Variable and Expression value concepts in HLFIR
-## Strengthening the variable concept
+### Strengthening the variable concept
Fortran variables are currently represented in FIR as mlir::Value with reference
or box type coming from special operations or block arguments. They are either
@@ -128,7 +130,7 @@ from the caller scope name and the function name.). In general, fir.declare
will allow to view every memory storage as a variable, and this will be used to
describe and use compiler created array temporaries.
-## Adding an expression value concept in HLFIR
+### Adding an expression value concept in HLFIR
Currently, Fortran expressions can be represented as SSA values for scalar
logical, integer, real, and complex expressions. Scalar character or
@@ -1353,9 +1355,9 @@ will be inlined, hlfir.forall will be rewritten into normal loops taking into
account the alias analysis, and hlfir.assign/hlfir.designate operations will be
lowered to fir.array_coor and fir.store operations).
-# Alternatives that were not retained
+## Alternatives that were not retained
-## Using a non-MLIR based mutable CFG representation
+### Using a non-MLIR based mutable CFG representation
An option would have been to extend the PFT to describe expressions in a way
that can be annotated and modified with the ability to introduce temporaries.
@@ -1364,9 +1366,9 @@ infrastructure and data structures while FIR is already using MLIR
infrastructure, so enriching FIR seems a smoother approach and will benefit from
the MLIR infrastructure experience that was gained.
-## Using symbols for HLFIR variables
+### Using symbols for HLFIR variables
-### Using attributes as pseudo variable symbols
+#### Using attributes as pseudo variable symbols
Instead of restricting the memory types an HLFIR variable can have, it was
force the defining operation of HLFIR variable SSA values to always be
@@ -1390,7 +1392,7 @@ doing code motion, and whose complexity would be increased by the naming
constraints.
-### Using MLIR symbols for variables
+#### Using MLIR symbols for variables
Using MLIR symbols for HLFIR variables has been rejected because MLIR symbols
are mainly intended to deal with globals and functions that may refer to each
@@ -1407,9 +1409,9 @@ Using SSA values also makes the transition and mixture with lower-level FIR
operations smoother: a variable SSA usage can simply be replaced by lower-level
FIR operations using the same SSA value.
-## Using some existing MLIR dialects for the high-level Fortran.
+### Using some existing MLIR dialects for the high-level Fortran.
-### Why not using Linalg dialect?
+#### Why not using Linalg dialect?
The linalg dialects offers a powerful way to represent array operations: the
linalg.generic operation takes a set of input and output arrays, a related set
@@ -1438,7 +1440,7 @@ semi-affine cases).
So using linalg is for now left as an optimization pass opportunity in some
cases that could be experimented.
-### Why not using Shape dialect?
+#### Why not using Shape dialect?
MLIR shape dialect gives a set of operations to manipulate shapes. The
shape.meet operation is exactly similar with hlfir.shape_meet, except that it
@@ -1451,7 +1453,7 @@ shape.meet The shape dialect is a lot more complex because it is intended to
deal with computations involving dynamically ranked entity, which is not the
case in Fortran (assumed rank usage in Fortran is greatly limited).
-## Using embox/rebox and box as an alternative to fir.declare/hlfir.designate and hlfir.expr/ variable concept
+### Using embox/rebox and box as an alternative to fir.declare/hlfir.designate and hlfir.expr/ variable concept
All Fortran entities (*) can be described at runtime by a fir.box, except for
some attributes that are not part of the runtime descriptors (like TARGET,
diff --git a/flang/docs/OpenACC-descriptor-management.md b/flang/docs/OpenACC-descriptor-management.md
index 73f906459aab5..0b5103000d8e7 100644
--- a/flang/docs/OpenACC-descriptor-management.md
+++ b/flang/docs/OpenACC-descriptor-management.md
@@ -429,6 +429,6 @@ All the "is-present" checks and the data actions for the auxiliary pointers must
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 `FortranRuntime` and `liboffload`. The F18 driver adds `FortranOffloadRuntime` for linking under `-fopenacc`/`-fopenmp` (and maybe additional switches like `-fopenmp-targets`).
-# TODOs:
+## TODOs:
* Cover the detach action.
diff --git a/flang/docs/Overview.md b/flang/docs/Overview.md
index 561e9cfcf95c3..6eba19ea3a3c0 100644
--- a/flang/docs/Overview.md
+++ b/flang/docs/Overview.md
@@ -39,12 +39,12 @@ produce a readable version of the outputs.
Each detailed phase produces either correct output or fatal errors.
-# Analysis
+## Analysis
This high level phase validates that the program is correct and creates all of
the information needed for lowering.
-## Prescan and Preprocess
+### Prescan and Preprocess
See [Preprocessing.md](Preprocessing.md).
@@ -69,7 +69,7 @@ See [Preprocessing.md](Preprocessing.md).
- `flang-new -fc1 -fdebug-dump-provenance src.f90` dumps provenance
information
-## Parsing
+### Parsing
**Input:** Cooked character stream
@@ -85,7 +85,7 @@ representing a syntactically correct program, rooted at the program unit. See:
- `flang-new -fc1 -fdebug-dump-parsing-log src.f90` runs an instrumented parse and dumps the log
- `flang-new -fc1 -fdebug-measure-parse-tree src.f90` measures the parse tree
-## Semantic processing
+### Semantic processing
**Input:** the parse tree, the cooked character stream, and provenance
information
@@ -125,12 +125,12 @@ At the end of semantic processing, all validation of the user's program is compl
- `flang-new -fc1 -fdebug-dump-symbols src.f90` dumps the symbol table
- `flang-new -fc1 -fdebug-dump-all src.f90` dumps both the parse tree and the symbol table
-# Lowering
+## Lowering
Lowering takes the parse tree and symbol table produced by analysis and
produces LLVM IR.
-## Create the lowering bridge
+### Create the lowering bridge
**Inputs:**
- the parse tree
@@ -148,7 +148,7 @@ The lowering bridge is a container that holds all of the information needed for
**Entry point:** lower::LoweringBridge::create
-## Initial lowering
+### Initial lowering
**Input:** the lowering bridge
@@ -166,7 +166,7 @@ parse tree. The compiler walks the PFT generating FIR.
- `flang-new -fc1 -fdebug-dump-pft src.f90` dumps the pre-FIR tree
- `flang-new -fc1 -emit-mlir src.f90` dumps the FIR to the files src.mlir
-## Transformation passes
+### Transformation passes
**Input:** initial version of the FIR code
@@ -183,7 +183,7 @@ LLVM IR representation of the program.
- `flang-new -mmlir --mlir-print-ir-after-all -S src.f90` dumps the FIR code after each pass to standard error
- `flang-new -fc1 -emit-llvm src.f90` dumps the LLVM IR to src.ll
-# Object code generation and linking
+## Object code generation and linking
After the LLVM IR is created, the flang driver invokes LLVM's existing
infrastructure to generate object code and invoke a linker to create the
diff --git a/flang/docs/ParameterizedDerivedTypes.md b/flang/docs/ParameterizedDerivedTypes.md
index 34c8894c76918..851775b123b43 100644
--- a/flang/docs/ParameterizedDerivedTypes.md
+++ b/flang/docs/ParameterizedDerivedTypes.md
@@ -7,7 +7,7 @@ type parameters are of integer type.
This document aims to give insights at the representation of PDTs in FIR and how
PDTs related constructs and features are lowered to FIR.
-# Fortran standard
+## Fortran standard
Here is a list of the sections and constraints of the Fortran standard involved
for parameterized derived types.
@@ -22,9 +22,9 @@ for parameterized derived types.
The constraints are implemented and tested in flang.
-## The two types of PDTs
+### The two types of PDTs
-### PDT with kind type parameter
+#### PDT with kind type parameter
PDTs with kind type parameter are already implemented in flang. Since the kind
type parameter shall be a constant expression, it can be determined at
@@ -48,7 +48,7 @@ Lowering makes the distinction between the two types by giving them different
names `@_QFE.kp.t.1` and `@_QFE.kp.t.2`. More information about the unique names
can be found here: `flang/docs/BijectiveInternalNameUniquing.md`
-### PDT with length type parameter
+#### PDT with length type parameter
Two PDTs with the same derived type and the same kind type parameters but
different length type parameters are not distinct types. Unlike the kind type
@@ -92,7 +92,7 @@ two possibilities.
These solutions have pros and cons and more details are given in the next few
sections.
-#### Implementing PDT with inlined components
+##### Implementing PDT with inlined components
In case of `len_type1`, the size, offset, etc. of `fld1` and `fld2` depend on
the runtime values of `i` and `j` when the components are inlined into the
@@ -114,7 +114,7 @@ type len_type1(i, j)
end type
```
-#### Implementing PDT with outlined components
+##### Implementing PDT with outlined components
A level of indirection can be used and `fld1` and `fld2` are then outlined
as shown in `len_type2`. _compiler_allocatable_ is here only to show which
@@ -144,7 +144,7 @@ types as it could require temporaries depending how the memory is allocated.
The outlined solution is also problematic for unformatted I/O as the
indirections need to be followed correctly when reading or writing records.
-#### Example of nested PDTs
+##### Example of nested PDTs
PDTs can be nested. Here are some example used later in the document.
@@ -165,7 +165,7 @@ type len_type4(i, j)
end type
```
-#### Example with array slice
+##### Example with array slice
Let's take an example with an array slice to see the advantages and
disadvantages of the two solutions.
@@ -222,7 +222,7 @@ The size of the PDTs need to be computed at runtime. This is already the case
for dynamic allocation sizes since it is possible for arrays to have dynamic
shapes, etc.
-### Support of PDTs in other compilers
+#### Support of PDTs in other compilers
1) Nested PDTs
2) Array of PDTs
@@ -250,7 +250,7 @@ crash = compiler crash or runtime crash
no = doesn't compile with no crash
```
-#### Field inlining in lowering
+##### Field inlining in lowering
A PDT with length type parameters has a list of 1 or more type parameters that
are runtime values. These length type parameter values can be present in
@@ -373,7 +373,7 @@ computation.
%5 = fir.field_index i, !fir.type<_QMmod1Tt{l:i32,i:!fir.array<?xi32>}>(%n : i32)
```
-### Length type parameter with expression
+#### Length type parameter with expression
The component of a PDT can be defined with expressions including the length
type parameters.
@@ -405,7 +405,7 @@ At any place where the a PDT is initialized, the lowering would make the
evaluation and their values saved in the addendum and pointed to by the
descriptor.
-### `ALLOCATE`/`DEALLOCATE` statements
+#### `ALLOCATE`/`DEALLOCATE` statements
The allocation and deallocation of PDTs are delegated to the runtime.
@@ -481,7 +481,7 @@ NULLIFY(p)
%0 = fir.call @_FortranAPointerNullifyDerived(%desc, %type) : (!fir.box<none>, !fir.tdesc) -> ()
```
-### Formatted I/O
+#### Formatted I/O
The I/O runtime internals are described in this file:
`flang/docs/IORuntimeInternals.md`.
@@ -532,7 +532,7 @@ func.func @_QMpdtPprint_pdt() {
}
```
-### Unformatted I/O
+#### Unformatted I/O
The entry point in the runtime for unformatted I/O is similar than the one for
formatted I/O. A call to `_FortranAioOutputDescriptor` with the correct
@@ -540,14 +540,14 @@ descriptor is also issued by the lowering. For unformatted I/O, the runtime is
calling `UnformattedDescriptorIO` from `flang/runtime/descriptor-io.h`.
This function will need to be updated to support the chosen solution for PDTs.
-### Default component initialization of local variables
+#### Default component initialization of local variables
Default initializers for components with length type parameters need to be
processed as the derived type instance is created.
The length parameters block must also be created and attached to the addendum.
See _New f18addendum_ section for more information.
-### Assignment
+#### Assignment
As mentioned in 10.2.1.2 (8), for an assignment, each length type parameter of
the variable shall have the same value as the corresponding type parameter
@@ -586,7 +586,7 @@ the lhs, it is deallocated first and allocated with the rhs length type
parameters information (F'2018 10.2.1.3(3)). There is code in the runtime to
handle this already. It will need to be updated for the new f18addendum.
-### Finalization
+#### Finalization
A final subroutine is called for a PDT if the subroutine has the same kind type
parameters and rank as the entity to be finalized. The final subroutine is
@@ -643,7 +643,7 @@ type(t(kind(0.0d0))) d(n,n)
end subroutine
```
-### Type parameter inquiry
+#### Type parameter inquiry
Type parameter inquiry is used to get the value of a type parameter in a PDT.
@@ -677,7 +677,7 @@ a compiler generated function is used to computed its value.
The length type parameters are indexed in declaration order; i.e., 0 is the
first length type parameter in the deepest base type.
-### PDTs and polymorphism
+#### PDTs and polymorphism
In some cases with polymorphic entities, it is necessary to copy the length
type parameters from a descriptor to another. With the current design this is
@@ -753,7 +753,7 @@ the callee. This includes array of PDTs and derived-type with PDT components.
The example describe one of the corner case where the length type parameter
would be lost if the descriptor is not passed.
-### Example that require a descriptor
+#### Example that require a descriptor
Because of the length type parameters store in the addendum, it is required in
some case to pass the PDT with a descriptor to preserve the length type
@@ -816,7 +816,7 @@ end
Because of the use case described above, PDTs, array of PDTs or derived-type
with PDT components will be passed by descriptor.
-## FIR operations with length type parameters
+### FIR operations with length type parameters
Couple of operations have length type parameters as operands already in their
design. For some operations, length type parameters are likely needed with
@@ -827,7 +827,7 @@ parameters are in it.
The operations will be updated if needed during the implementation of the
chosen solution.
-### `fir.alloca`
+#### `fir.alloca`
This primitive operation is used to allocate an object on the stack. When
allocating a PDT, the length type parameters are passed to the
@@ -840,7 +840,7 @@ operation so its size can be computed accordingly.
// %i is the ssa value of the length type parameter
```
-### `fir.allocmem`
+#### `fir.allocmem`
This operation is used to create a heap memory reference suitable for storing a
value of the given type. When creating a PDT, the length type parameters are
@@ -854,7 +854,7 @@ passed so the size can be computed accordingly.
fir.freemem %0 : !fir.type<_QMmod1Tpdt{i:i32,data:!fir.array<?xf32>}>
```
-### `fir.embox`
+#### `fir.embox`
The `fir.embox` operation create a boxed reference value. In the case of PDTs
the length type parameters can be passed as well to the operation.
@@ -887,7 +887,7 @@ func.func @_QMpdt_initPlocal() {
}
```
-### `fir.field_index`
+#### `fir.field_index`
The `fir.field_index` operation is used to generate a field offset value from
a field identifier in a derived-type. The operation takes length type parameter
@@ -902,7 +902,7 @@ values with a PDT so it can compute a correct offset.
return %3
```
-### `fir.len_param_index`
+#### `fir.len_param_index`
This operation is used to get the length type parameter offset in from a PDT.
@@ -916,7 +916,7 @@ func.func @_QPpdt_len_value(%arg0: !fir.box<!fir.type<t1{l:i32,!fir.array<?xi32>
}
```
-### `fir.save_result`
+#### `fir.save_result`
Save the result of a function returning an array, box, or record type value into
a memory location given the shape and LEN parameters of the result. Length type
@@ -933,7 +933,7 @@ func.func @return_pdt(%buffer: !fir.ref<!fir.type<t2(l1:i32,l2:i32){x:f32}>>) {
}
```
-### `fir.array_*` operations
+##### `fir.array_*` operations
The current design of the different `fir.array_*` operations include length type
parameters operands. This is designed to use PDT without descriptor directly in
@@ -952,7 +952,7 @@ FIR.
---
-## Implementation choice
+### Implementation choice
While both solutions have pros and cons, we want to implement the outlined
solution.
@@ -961,7 +961,7 @@ solution.
---
-# Testing
+## Testing
- Lowering part is tested with LIT tests in tree
- PDTs involved a lot of runtime information so executable
@@ -969,7 +969,7 @@ solution.
---
-# Current TODOs
+## Current TODOs
Current list of TODOs in lowering:
- `flang/lib/Lower/Allocatable.cpp:461` not yet implement: derived type length parameters in allocate
- `flang/lib/Lower/Allocatable.cpp:645` not yet implement: deferred length type parameters
diff --git a/flang/docs/PolymorphicEntities.md b/flang/docs/PolymorphicEntities.md
index 8eabc9eb3c6ab..befcc53127a4a 100644
--- a/flang/docs/PolymorphicEntities.md
+++ b/flang/docs/PolymorphicEntities.md
@@ -874,7 +874,7 @@ dynamic type of polymorphic entities.
```
---
-# Testing
+## Testing
- Lowering part is tested with LIT tests in tree
- Polymorphic entities involved a lot of runtime information so executable
@@ -882,7 +882,7 @@ dynamic type of polymorphic entities.
---
-# Current TODOs
+## Current TODOs
Current list of TODOs in lowering:
- `flang/lib/Lower/Bridge.cpp:448` not yet implemented: create polymorphic host associated copy
- `flang/lib/Lower/CallInterface.cpp:795` not yet implemented: support for polymorphic types
diff --git a/flang/docs/ProcedurePointer.md b/flang/docs/ProcedurePointer.md
index da4848ff197bd..77e54bb505c7b 100644
--- a/flang/docs/ProcedurePointer.md
+++ b/flang/docs/ProcedurePointer.md
@@ -422,7 +422,7 @@ func.func @proc_pointer_component(%arg0 : !fir.boxproc<(!fir.ref<i32>) -> f32>,
---
-# Testing
+## Testing
The lowering part is tested with LIT tests in tree, but the execution tests are
useful for full testing.
@@ -452,7 +452,7 @@ The tests should include the following
---
-# Current TODOs
+## Current TODOs
Current list of TODOs in lowering:
- `flang/lib/Lower/CallInterface.cpp:708`: not yet implemented: procedure pointer result not yet handled
- `flang/lib/Lower/CallInterface.cpp:961`: not yet implemented: procedure pointer arguments
diff --git a/flang/docs/conf.py b/flang/docs/conf.py
index 6f4e2dd4ec87d..a34f7bf4a2100 100644
--- a/flang/docs/conf.py
+++ b/flang/docs/conf.py
@@ -95,15 +95,12 @@
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-html_theme = "llvm-theme"
+html_theme = "haiku"
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
-html_theme_options = {"nosidebar": False}
-
-# Add any paths that contain custom themes here, relative to this directory.
-html_theme_path = ["_themes"]
+# html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
# html_theme_path = []
@@ -127,11 +124,7 @@
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ["_static"]
-
-html_context = {
- "css_files": ["_static/llvm.css"],
-}
+# html_static_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
@@ -142,13 +135,7 @@
# html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
-html_sidebars = {
- "**": [
- "indexsidebar.html",
- "searchbox.html",
- ]
-}
-
+# html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
diff --git a/flang/docs/index.md b/flang/docs/index.md
index a619507140893..ff8f4a22d5eb5 100644
--- a/flang/docs/index.md
+++ b/flang/docs/index.md
@@ -6,7 +6,7 @@ referred to as "LLVM Flang" to differentiate itself from ["Classic
Flang"](https://github.com/flang-compiler/flang) - these are two separate and
independent Fortran compilers. LLVM Flang is under active development. While it
is capable of generating executables for a number of examples, some
-functionality is still missing. See [GettingInvolved](GettingInvolved) for tips
+functionality is still missing. See [Getting Involved](GettingInvolved) for tips
on how to get in touch with us and to learn more about the current status.
```{eval-rst}
@@ -66,6 +66,7 @@ on how to get in touch with us and to learn more about the current status.
LabelResolution
ModFiles
OpenACC
+ OpenACC-descriptor-management.md
OpenMP-4.5-grammar.md
OpenMP-semantics
OptionComparison
@@ -87,6 +88,5 @@ on how to get in touch with us and to learn more about the current status.
```{eval-rst}
* :ref:`genindex`
-* :ref:`modindex`
* :ref:`search`
```
More information about the flang-commits
mailing list