[flang] IEEE_GET_UNDERFLOW_MODE, IEEE_SET_UNDERFLOW_MODE (#118551)

Implement IEEE_GET_UNDERFLOW_MODE and IEEE_SET_UNDERFLOW_MODE. Update
IEEE_SUPPORT_UNDERFLOW_CONTROL to enable support for indvidu

[flang] IEEE_GET_UNDERFLOW_MODE, IEEE_SET_UNDERFLOW_MODE (#118551)

Implement IEEE_GET_UNDERFLOW_MODE and IEEE_SET_UNDERFLOW_MODE. Update
IEEE_SUPPORT_UNDERFLOW_CONTROL to enable support for indvidual REAL
kinds.

show more ...

[flang][lowering] handle procedure pointers with generic name (#108043)

Handle procedure pointer with the same name as generics in lowering to avoid crashes after #107928.

[Flang] Switch to common::visit more call sites (#90018)

Switch to common::visit more call sites.

Test plan: ninja check-all

[flang] Add support for lowering directives at the CONTAINS level (#95123)

There is currently support for lowering directives that appear outside
of a module or procedure, or inside the body of a m

[flang] Add support for lowering directives at the CONTAINS level (#95123)

There is currently support for lowering directives that appear outside
of a module or procedure, or inside the body of a module or procedure.
Extend this to support directives at the CONTAINS level of a module or
procedure, such as directives 3, 5, 7 9, and 10 in:

!dir$ some directive 1
module m
!dir$ some directive 2
contains
!dir$ some directive 3
subroutine p
!dir$ some directive 4
contains
!dir$ some directive 5
subroutine s1
!dir$ some directive 6
end subroutine s1
!dir$ some directive 7
subroutine s2
!dir$ some directive 8
end subroutine s2
!dir$ some directive 9
end subroutine p
!dir$ some directive 10
end module m
!dir$ some directive 11

This is done by looking for CONTAINS statements at the module or
procedure level, while ignoring CONTAINS statements at the derived type
level.

show more ...

[flang] Fix lowering of host associated cray pointee symbols (#86121)

Cray pointee symbols can be host associated from a module or host
procedure while the related cray pointer is not explicitly as

[flang] Fix lowering of host associated cray pointee symbols (#86121)

Cray pointee symbols can be host associated from a module or host
procedure while the related cray pointer is not explicitly associated.
This caused the "not yet implemented: lowering symbol to HLFIR" to fire
when lowering a reference to the cray pointee and fetching the cray
pointer.

This patch:
- Ensures cray pointers are always instantiated when instantiating a
cray pointee.
- Fix internal procedure lowering to deal with cray pointee host
association like it does for pointers (the lowering strategy for cray
pointee is to create a pointer that is updated with the cray pointer
value before being fetched).

This should fix the bug reported in
https://github.com/llvm/llvm-project/issues/85420.

show more ...

[flang] Do not instantiate runtime info globals in functions (#80447)

Runtime globals are compiler generated globals injected in user scopes.
They are never referred to directly in lowering code, w

[flang] Do not instantiate runtime info globals in functions (#80447)

Runtime globals are compiler generated globals injected in user scopes.
They are never referred to directly in lowering code, we only need th
fur.global for them. Yet lowering was creating hlfir.declare for them in
module procedures. In modern fortran apps, this blows up the generated
IR for nothing (Types with dozens of components, type bound procedures
and parents can create in the order of 10 000 runtime info globals to
describe them, if there is a 100 module procedure, that is that is a few
million operations generated and processed in each pass for nothing).

show more ...

[flang] legacy branch target (#75628)

Branching to an endif statement from outside of the if is nonconformant:

subroutine jump(n)
goto 6
if (n == 3) then
goto 7
6 end if

[flang] legacy branch target (#75628)

Branching to an endif statement from outside of the if is nonconformant:

subroutine jump(n)
goto 6
if (n == 3) then
goto 7
6 end if
print *, 'pass'
return
7 print *, 'fail'
end

However, this branch was permitted up to f90. Account for this usage
when rewriting if constructs and if statements by suppressing rewriting
if the end statement is labeled.

show more ...

[flang] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,en

[flang] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[flang] IEEE_ARITHMETIC and IEEE_EXCEPTIONS intrinsic module procedures (#74138)

Implement a selection of intrinsic module procedures that involve
exceptions.

- IEEE_GET_FLAG
- IEEE_GET_HALTI

[flang] IEEE_ARITHMETIC and IEEE_EXCEPTIONS intrinsic module procedures (#74138)

Implement a selection of intrinsic module procedures that involve
exceptions.

- IEEE_GET_FLAG
- IEEE_GET_HALTING_MODE
- IEEE_GET_MODES
- IEEE_GET_STATUS
- IEEE_LOGB
- [f23] IEEE_MAX, IEEE_MAX_MAG, IEEE_MAX_NUM, IEEE_MAX_NUM_MAG
- [f23] IEEE_MIN, IEEE_MIN_MAG, IEEE_MIN_NUM, IEEE_MIN_NUM_MAG
- IEEE_QUIET_EQ, IEEE_QUIET_GE, IEEE_QUIET_GT,
- IEEE_QUIET_LE, IEEE_QUIET_LT, IEEE_QUIET_NE
- IEEE_SET_FLAG
- IEEE_SET_HALTING_MODE
- IEEE_SET_MODES
- IEEE_SET_STATUS
- IEEE_SIGNALING_EQ, IEEE_SIGNALING_GE, IEEE_SIGNALING_GT,
- IEEE_SIGNALING_LE, IEEE_SIGNALING_LT, IEEE_SIGNALING_NE
- IEEE_SUPPORT_FLAG
- IEEE_SUPPORT_HALTING

show more ...

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the curren

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the current module.

This came up in a test with a derived type component default initializer
of "c_null_ptr", which is replaced with the expression
"__builtin_c_ptr(address=0_8)"; the derived type name "__builtin_c_ptr"
is not available in the current scope, and the module file would fail
semantic analysis when USE'd.

The best solution that I found was to extend module file generation to
detect this case and handle it by inserting the right USE association to
the ultimate derived type symbol, possibly with renaming to a
compiler-created name in the case of a conflict.

To implement this transformation, it was necessary to fix the utility
evaluate::CollectSymbols() to include the derived type symbol from a
structure constructor. This involved extending the expression traversal
framework to visit the derived type spec of a structure constructor.
Extending CollectSymbols() caused a lowering test to fail mysteriously,
so I tracked down the code in PFTBuilder that didn't expect to see a
DerivedTypeDetails symbol and dealt with it there.

show more ...

[flang][openacc] Allow acc routine at the top level (#69936)

Some compilers allow the `$acc routine(<name>)` to be placed at the
program unit level. To be compatible, this patch enables the use of

[flang][openacc] Allow acc routine at the top level (#69936)

Some compilers allow the `$acc routine(<name>)` to be placed at the
program unit level. To be compatible, this patch enables the use of acc
routine at this level. These acc routine directives must have a name.

show more ...

[flang] IEEE_ARITHMETIC intrinsic module procedures

Implement

- IEEE_CLASS
- IEEE_COPY_SIGN
- IEEE_GET_ROUNDING_MODE
- IEEE_IS_FINITE
- IEEE_IS_NAN
- IEEE_IS_NEGATIVE
- IEEE_IS_NORMAL
- IEE

[flang] IEEE_ARITHMETIC intrinsic module procedures

Implement

- IEEE_CLASS
- IEEE_COPY_SIGN
- IEEE_GET_ROUNDING_MODE
- IEEE_IS_FINITE
- IEEE_IS_NAN
- IEEE_IS_NEGATIVE
- IEEE_IS_NORMAL
- IEEE_SET_ROUNDING_MODE
- IEEE_SIGNBIT
- IEEE_SUPPORT_ROUNDING
- IEEE_UNORDERED
- IEEE_VALUE

for all REAL kinds (2, 3, 4, 8, 10, 16) where applicable.

show more ...

[Flang][PFT] Skip continue insertion for OpenMP Loops

Unstructured regions presents some issues for OpenMP code generation.
While there are no branches out of the OpenMP region, there can be
branche

[Flang][PFT] Skip continue insertion for OpenMP Loops

Unstructured regions presents some issues for OpenMP code generation.
While there are no branches out of the OpenMP region, there can be
branches inside. This required the availability of an artificial
target at the end of an OpenMP region. This was implemented by
insertion an artifical `continue` and marking it as a target for
a branch.
(https://github.com/flang-compiler/f18-llvm-project/pull/1178)

The artificial target is not required for OpenMP loops. Since the
DO loop end can itself be a target of a branch. Moreover, insertion
of the continue between the end of the loop and the end of the
OpenMP loop construct presents problems since the OpenMP MLIR
loop construct models both the loop and the construct. This can
cause the terminator of the OpenMP loop construct to be missed.
This patch solves the issue by skipping the insertion of the
continue.

Note: This issue is only hit if the `end openmp loop` directive
is missed.

This patch fixes the issues in:
-> https://github.com/llvm/llvm-project/issues/58378
-> https://github.com/flang-compiler/f18-llvm-project/issues/1426

Fixes #58378

Reviewed By: vdonaldson

Differential Revision: https://reviews.llvm.org/D151700

show more ...

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature en

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps

... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.

Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.

More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.

Differential Revision: https://reviews.llvm.org/D150159

show more ...

[flang][lowering] Do not instantiate component symbols used in spec expr

Lowering analyse specification expressions in order to create order the
symbol instantiations in the IR (If symbol B is used

[flang][lowering] Do not instantiate component symbols used in spec expr

Lowering analyse specification expressions in order to create order the
symbol instantiations in the IR (If symbol B is used in the
specification expression of A, symbol B must be instantiated first).

This analysis was mistakenly collecting component symbols used in
component references inside specification expressions, which led
lowering to instantiate component symbols as if they were local
objects.

This patch prevents collecting component symbols during this analysis.

Differential Revision: https://reviews.llvm.org/D149328

show more ...

[flang] Set proper source location for the main function.

Take the source position for the anonymous program from its scope.
If the first evaluation is a construct or directive, then it has
null sou

[flang] Set proper source location for the main function.

Take the source position for the anonymous program from its scope.
If the first evaluation is a construct or directive, then it has
null source position.

Author: vdonaldson
Differential Revision: https://reviews.llvm.org/D146445

show more ...

[flang] Use Use *{Set,Map}::contains (NFC)

[flang] Block construct

A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.

[flang] Block construct

A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.) This is implemented by applying
basic scope processing to the block level.

Name uniquing/mangling is extended to support this. The term "block" is
heavily overloaded in Fortran standards. Prior name uniquing used tag `B`
for common block objects. Existing tag choices were modified to free up `B`
for block construct entities, and `C` for common blocks, and resolve
additional issues with other tags. The "old tag -> new tag" changes can
be summarized as:

-> B -- block construct -> new
B -> C -- common block
C -> YI -- intrinsic type descriptor; not currently generated
CT -> Y -- nonintrinsic type descriptor; not currently generated
G -> N -- namelist group
L -> -- block data; not needed -> deleted

Existing name uniquing components consist of a tag followed by a name
from user source code, such as a module, subprogram, or variable name.
Block constructs are different in that they may be anonymous. (Like other
constructs, a block may have a `block-construct-name` that can be used
in exit statements, but this name is optional.) So blocks are given a
numeric compiler-generated preorder index starting with `B1`, `B2`,
and so on, on a per-procedure basis.

Name uniquing is also modified to include component names for all
containing procedures rather than for just the immediate host. This
fixes an existing name clash bug with same-named entities in same-named
host subprograms contained in different-named containing subprograms,
and variations of the bug involving modules and submodules.

F18 clause 9.7.3.1 (Deallocation of allocatable variables) paragraph 1
has a requirement that an allocated, unsaved allocatable local variable
must be deallocated on procedure exit. The following paragraph 2 states:

When a BLOCK construct terminates, any unsaved allocated allocatable
local variable of the construct is deallocated.

Similarly, F18 clause 7.5.6.3 (When finalization occurs) paragraph 3
has a requirement that a nonpointer, nonallocatable object must be
finalized on procedure exit. The following paragraph 4 states:

A nonpointer nonallocatable local variable of a BLOCK construct
is finalized immediately before it would become undefined due to
termination of the BLOCK construct.

These deallocation and finalization requirements, along with stack
restoration requirements, require knowledge of block exits. In addition
to normal block termination at an end-block-stmt, a block may be
terminated by executing a branching statement that targets a statement
outside of the block. This includes

Single-target branch statements:
- goto
- exit
- cycle
- return

Bounded multiple-target branch statements:
- arithmetic goto
- IO statement with END, EOR, or ERR specifiers

Unbounded multiple-target branch statements:
- call with alternate return specs
- computed goto
- assigned goto

Lowering code is extended to determine if one of these branches exits
one or more relevant blocks or other constructs, and adds a mechanism to
insert any necessary deallocation, finalization, or stack restoration
code at the source of the branch. For a single-target branch it suffices
to generate the exit code just prior to taking the indicated branch.
Each target of a multiple-target branch must be analyzed individually.
Where necessary, the code must first branch to an intermediate basic
block that contains exit code, followed by a branch to the original target
statement.

This patch implements an `activeConstructStack` construct exit mechanism
that queries a new `activeConstruct` PFT bit to insert stack restoration
code at block exits. It ties in to existing code in ConvertVariable.cpp
routine `instantiateLocal` which has code for finalization, making block
exit finalization on par with subprogram exit finalization. Deallocation
is as yet unimplemented for subprograms or blocks. This may result in
memory leaks for affected objects at either the subprogram or block level.
Deallocation cases can be addressed uniformly for both scopes in a future
patch, presumably with code insertion in routine `instantiateLocal`.

The exit code mechanism is not limited to block construct exits. It is
also available for use with other constructs. In particular, it is used
to replace custom deallocation code for a select case construct character
selector expression where applicable. This functionality is also added
to select type and associate constructs. It is available for use with
other constructs, such as select rank and image control constructs,
if that turns out to be necessary.

Overlapping nonfunctional changes include eliminating "FIR" from some
routine names and eliminating obsolete spaces in comments.

show more ...

[flang] Fix optional assertion in PFTBuilder

D142279 enabled assertion in libstdc++ and one was triggered
in the PFTBuilder because an optional was access even if it was
null.
This patch fix this is

[flang] Fix optional assertion in PFTBuilder

D142279 enabled assertion in libstdc++ and one was triggered
in the PFTBuilder because an optional was access even if it was
null.
This patch fix this issue and add a regression test.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D143589

show more ...

[flang] Allow compiler directives in the specification part of a module

Lowering code currently allows for directives inside a program or
subprogram, or outside any program unit. Directives may also

[flang] Allow compiler directives in the specification part of a module

Lowering code currently allows for directives inside a program or
subprogram, or outside any program unit. Directives may also appear
in the specification part of a module, as in:

module mm
interface
subroutine ss(aa)
!dir$ ignore_tkr(tkr) aa
integer :: aa(*)
end subroutine ss
end interface
end module

With some exceptions such as OpenMP directives, most directives are
currently ignored, so this code should generate an "ignoring all compiler
directives" message.

show more ...

[flang] Control flow graph issues

Address several issues involving control flow graph generation and
structured code ops.

- Fix a problem with constructs nested inside unstructured selection
co

[flang] Control flow graph issues

Address several issues involving control flow graph generation and
structured code ops.

- Fix a problem with constructs nested inside unstructured selection
constructs. This is a general problem involving branches that are
implied rather than explicit. It is addressed in the generic genFIR
"wrapper" function that calls individual statement-specific genFIR calls.

- The previous fix requires some compensating changes in IF and DO
construct code lowering.

- Streamline the code to generate explicit DO loop variable updates.

- Fix a problem with the individual detailed genFIR calls made in the
genFIR(SelectTypeConstruct) call.

- Modify control flow graph generation to support the insertion of
deallocation and finalization code when lowering most END <construct>
statements.

show more ...

[flang] Do not convey captured globals through host link

Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple

[flang] Do not convey captured globals through host link

Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple argument of the internal procedure.
This extra tuple is in general an overhead: it must be created and
passed, and require creating thunks when taking the address of the
internal procedure.
This patch allows not using the tuple for host global variables
(from modules, common block, or local saved variables) since they can
be instantiated from the fir.global symbol in the internal procedure
instead.
Add a fir.internal_proc attribute to mlir::FuncOp for internal procedures
so that ArrayValueCopy can still detect internal procedures even if they
do not have a tuple argument.

Differential Revision: https://reviews.llvm.org/D140288

show more ...

[flang] Fix a warning

This patch fixes:

flang/lib/Lower/PFTBuilder.cpp:1042:6: error: function 'dumpScope'
is not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]

[flang] Fix build failure

[flang] Submodules

A submodule is a program unit that may contain the implementions of procedures
declared in an ancestor module or submodule.

Processing for the equivalence groups and variables de

[flang] Submodules

A submodule is a program unit that may contain the implementions of procedures
declared in an ancestor module or submodule.

Processing for the equivalence groups and variables declared in a submodule
scope is similar to existing processing for the equivalence groups and
variables in module and procedure scopes. However, module and procedure scopes
are tied directly to code in the Pre-FIR Tree (PFT), whereas processing for a
submodule must have access to an ancestor module scope that is guaranteed
to be present in a .mod file, but is not guaranteed to be in the PFT. This
difference is accommodated by tying processing directly to a front end scope.
Function scopes that can be processed on the fly are done that way; the
resulting variable information is never stored. Module and submodule scopes
whose symbol information may be needed during lowering of any number of module
procedures are instead cached on first use, and reused as needed.

These changes are a direct extension of current code. All module and submodule
variables in scope are processed, whether referenced or not. A possible
alternative would be to instead process symbols only when first used. While
this could ultimately be beneficial, such an approach must account for the
presence of equivalence groups. That information is not currently available
for on-the-fly variable processing.

Some additional changes are needed to include submodules in places where
modules must be considered, and to include separate module procedures in
places where other subprogram variants are considered. There is also a fix
for a bug involving the use of variables in an equivalence group in a
namelist group, which also involves scope processing code.

show more ...