[flang] Handle module subprogram with interface in same (sub)module when writing module file

There's a few (3) cases where Fortran allows two distinct symbols to have
the same name in the same scope

[flang] Handle module subprogram with interface in same (sub)module when writing module file

There's a few (3) cases where Fortran allows two distinct symbols to have
the same name in the same scope. Module file output copes with only two of
them. The third involves a separate module procedure that isn't separate:
both the procedure and its declared interface appear in the same (sub)module.
Fix to ensure that the interface is included in the module file output, so
that the module file reader doesn't suffer a bogus error about a "separate
module procedure without an interface".

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

show more ...

[flang] Distinguish intrinsic module USE in module files; correct search paths

In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on

[flang] Distinguish intrinsic module USE in module files; correct search paths

In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on their USE statements. And
ensure that the current working directory (".") cannot override the intrinsic
module search path when trying to locate an intrinsic module.

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

show more ...

[flang] Avoid spurious warnings from reading module files

When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, e

[flang] Avoid spurious warnings from reading module files

When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.

Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.

Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.

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

show more ...

[flang] Allow global scope names that clash with intrinsic modules

Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modul

[flang] Allow global scope names that clash with intrinsic modules

Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modules.

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

show more ...

[flang] Fix crash from PDT component init in module file

Semantics now needs to preserve the parse trees from module files,
in case they contain parameterized derived type definitions with
component

[flang] Fix crash from PDT component init in module file

Semantics now needs to preserve the parse trees from module files,
in case they contain parameterized derived type definitions with
component initializers that may require re-analysis during PDT
instantiation. Save them in the SemanticsContext.

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

show more ...

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().

show more ...

[flang] Handle parameter-dependent types in PDT initializers

For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyz

[flang] Handle parameter-dependent types in PDT initializers

For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,

type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type

To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.

This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.

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

show more ...

[flang] Support export/import OpenMP Threadprivate Flag

The information about OpenMP/OpenACC declarative directives in modules
should be carried in export mod files. This supports export OpenMP
Thre

[flang] Support export/import OpenMP Threadprivate Flag

The information about OpenMP/OpenACC declarative directives in modules
should be carried in export mod files. This supports export OpenMP
Threadprivate directive and import OpenMP declarative directives.

Reviewed By: kiranchandramohan

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

show more ...

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/build

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/builds/4346
* https://lab.llvm.org/buildbot/#/builders/180/builds/3803
* https://lab.llvm.org/buildbot/#/builders/175/builds/10419
* https://lab.llvm.org/buildbot/#/builders/191/builds/4318
* https://lab.llvm.org/buildbot/#/builders/173/builds/4274
* https://lab.llvm.org/buildbot/#/builders/181/builds/4297

All these bots failed with a time-out:
```
command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill
```
I'm guessing that that's due to template instantiations failing at some
point (https://reviews.llvm.org/D122441 introduced a custom
implementation of std::visit). Everything seems fine when either:
* building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12)
* building on AArch64 with GCC (tested with GCC 11)

show more ...

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

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

show more ...

[flang] Include missing internal interfaces in .mod files

Interfaces which are internal to a procedure need to be included in
module files if (and only if) they are referenced in the interface of
th

[flang] Include missing internal interfaces in .mod files

Interfaces which are internal to a procedure need to be included in
module files if (and only if) they are referenced in the interface of
the procedure. That is, they are needed if they are the interfaces of
dummy or return value procedures.

Fixes #53420

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

show more ...

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

Differenti

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

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

show more ...

[flang] Add nonfatal message classes

F18 presently has fatal and non-fatal diagnostic messages. We'd like
to make non-fatal warnings stand out better in the output of the compiler.

This will turn

[flang] Add nonfatal message classes

F18 presently has fatal and non-fatal diagnostic messages. We'd like
to make non-fatal warnings stand out better in the output of the compiler.

This will turn out to be a large change that affects many files.
This patch is just the first part. It converts a Boolean isFatal_ data
member of the message classes into a severity code, and defines four
of these codes (Error, Warning, Portability, and a catch-all Other).

Later patches will result from sweeping over the parser and semantics,
changing most non-fatal diagnostic messages into warnings and portability
notes.

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

show more ...

[flang] Fix module file missing USE for shadowed derived type

When a module uses a derived type that is shadowed by a generic
interface, the module file was missing a USE statement for the
name. De

[flang] Fix module file missing USE for shadowed derived type

When a module uses a derived type that is shadowed by a generic
interface, the module file was missing a USE statement for the
name. Detect and handle this situation.

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

show more ...

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

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

show more ...

[flang] Implement semantics for DEC STRUCTURE/RECORD

Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE.

[flang] Implement semantics for DEC STRUCTURE/RECORD

Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.

These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.

Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.

This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.

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

show more ...

[flang] Adjust names in Semantics that imply too much (NFC)

Some kinds of Fortran arrays are declared with the same syntax,
and it is impossible to tell from a shape (:, :) or (*) whether
the object

[flang] Adjust names in Semantics that imply too much (NFC)

Some kinds of Fortran arrays are declared with the same syntax,
and it is impossible to tell from a shape (:, :) or (*) whether
the object is assumed shape, deferred shape, assumed size, implied
shape, or whatever without recourse to more information about the
symbol in question. This patch softens the names of some predicate
functions (IsAssumedShape to CanBeAssumedShape) and makes others
more reflective of the syntax they represent (isAssumed to isStar)
in an attempt to encourage coders to seek and find definitive
predicate functions whose names deliver what they seem to mean.

Address TODO comments in IsSimplyContiguous() by using the
updated IsAssumedShape() predicate.

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

show more ...

[flang] Make builtin types more easily accessible; use them

Rearrange the contents of __builtin_* module files a little and
make sure that semantics implicitly USEs the module __Fortran_builtins
bef

[flang] Make builtin types more easily accessible; use them

Rearrange the contents of __builtin_* module files a little and
make sure that semantics implicitly USEs the module __Fortran_builtins
before processing each source file. This ensures that the special derived
types for TEAM_TYPE, EVENT_TYPE, LOCK_TYPE, &c. exist in the symbol table
where they will be available for use in coarray intrinsic function
processing.

Update IsTeamType() to exploit access to the __Fortran_builtins
module rather than applying ad hoc name tests. Move it and some
other utilities from Semantics/tools.* to Evaluate/tools.* to make
them available to intrinsics processing.

Add/correct the intrinsic table definitions for GET_TEAM, TEAM_NUMBER,
and THIS_IMAGE to exercise the built-in TEAM_TYPE as an argument and
as a result.

Add/correct/extend tests accordingly.

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

show more ...

[flang] Include default component initialization in static initializers

The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include

[flang] Include default component initialization in static initializers

The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include derived type
component default initializations, overriding those default values
without complaint with values from explicit DATA statement or declaration
initializations when they overlap. This also has to work for objects
with storage association due to EQUIVALENCE. When storage association causes
default component initializations to overlap, emit errors if and only
if the values differ (See Fortran 2018 subclause 19.5.3, esp. paragraph
10).

The f18 front-end has a module that analyzes and converts DATA statements
into equivalent static initializers for objects. For storage-associated
objects, compiler-generated objects are created that overlay the entire
association and fill it with a combined initializer. This "data-to-inits"
module already exists, and this patch is essentially extension and
clean-up of its machinery to complete the job.

Also: emit EQUIVALENCE to module files; mark compiler-created symbols
and *don't* emit those to module files; check non-static EQUIVALENCE
sets for conflicting default component initializations, so lowering
doesn't have to check them or emit diagnostics.

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

show more ...

[flang] Accept & fold IEEE_SELECTED_REAL_KIND

F18 supports the standard intrinsic function SELECTED_REAL_KIND
but not its synonym in the standard module IEEE_ARITHMETIC
named IEEE_SELECTED_REAL_KIND

[flang] Accept & fold IEEE_SELECTED_REAL_KIND

F18 supports the standard intrinsic function SELECTED_REAL_KIND
but not its synonym in the standard module IEEE_ARITHMETIC
named IEEE_SELECTED_REAL_KIND until this patch.

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

show more ...

[flang] Save binding labels as strings

Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and

[flang] Save binding labels as strings

Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.

So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.

Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.

Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.

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

show more ...

Revert "[flang] Save binding labels as strings"

This reverts commit eb4ad0e3e3635194c21dccdd1c52027e632d2996.

This was causing a crash compiling omp_lib.f90

[flang] Save binding labels as strings

Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and

[flang] Save binding labels as strings

Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.

So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.

Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.

Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.

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

show more ...

[flang] Refine symbol sorting

Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-orde

[flang] Refine symbol sorting

Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-ordered sets must
not be used for Symbols that might be subjected to name
replacement during name resolution, and address-ordered
sets must not be used (without sorting) in circumstances
where the order of their contents affects the output of the
compiler.

All set<> and map<> instances in the compiler that are keyed
by Symbols now have explicit Compare types in their template
instantiations. Symbol::operator< is no more.

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

show more ...

[flang] Improve "Error reading module file" error message

Instead of using a message attachment with further details,
emit the details as part of a single message.

Differential Revision: https://re

[flang] Improve "Error reading module file" error message

Instead of using a message attachment with further details,
emit the details as part of a single message.

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

show more ...