[flang] Minor cleanup (move function into /tools.cpp) (#111587)

The semantics utility GetAllNames has declarations in two header files
and a definition that really should be in the common utilities

[flang] Minor cleanup (move function into /tools.cpp) (#111587)

The semantics utility GetAllNames has declarations in two header files
and a definition that really should be in the common utilities source
file. Remove the redudant declaration from resolve-names-utils.h and
move code from resolve-names-utils.cpp into Semantics/tools.cpp.

show more ...

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)

Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.

The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.

Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.

To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().

show more ...

[flang] Handle USE-associated symbols in module procedure interface b… (#93616)

…lock specification expressions

A subroutine or function interface block is of course allowed to
USE-associate sym

[flang] Handle USE-associated symbols in module procedure interface b… (#93616)

…lock specification expressions

A subroutine or function interface block is of course allowed to
USE-associate symbols into its scope and use them for specification
expressions. This usage works, but crashes the module file output
generator. Fix.

Fixes https://github.com/llvm/llvm-project/issues/93413.

show more ...

[flang] Fix crash in error recovery (#92786)

EQUIVALENCE set processing assumes that any arrays have explicit shape
and constant lower bounds. When an erroneous program violates those
assumptions,

[flang] Fix crash in error recovery (#92786)

EQUIVALENCE set processing assumes that any arrays have explicit shape
and constant lower bounds. When an erroneous program violates those
assumptions, the compiler crashes. Fix.

Fixes https://github.com/llvm/llvm-project/issues/92636.

show more ...

[flang] Move EQUIVALENCE object checking to check-declarations.cpp (#91259)

Move EQUIVALENCE object checking from resolve-names-utils.cpp to
check-declarations.cpp, where it can work on fully resol

[flang] Move EQUIVALENCE object checking to check-declarations.cpp (#91259)

Move EQUIVALENCE object checking from resolve-names-utils.cpp to
check-declarations.cpp, where it can work on fully resolved symbols and
reduce clutter in name resolution. Add a check for EQUIVALENCE objects
that are not ObjectEntityDetails symbols so that attempts to equivalence
a procedure are caught.

show more ...

[flang] Emit "raw" name for procedure interface in module file (#83915)

Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in

[flang] Emit "raw" name for procedure interface in module file (#83915)

Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in symbol table
entries with ProcEntityDetails. The raw symbol of the interface needs to
be the one used for emitting procedure symbols to module files.

Fixes https://github.com/llvm/llvm-project/issues/83836.

show more ...

[flang] Handle separate module procedures with INTERFACE dummy arguments (#67608)

The code that duplicates the interface of a separate module procedure
into its definition doesn't allow for a dummy

[flang] Handle separate module procedures with INTERFACE dummy arguments (#67608)

The code that duplicates the interface of a separate module procedure
into its definition doesn't allow for a dummy procedure with an explicit
INTERFACE declaration. Extend the code to handle this case.

Fixes https://github.com/llvm/llvm-project/issues/66631.

show more ...

[flang] Set SAVE attribute for EQUIVALENCEd symbols consistently. (#67078)

Example:
```
subroutine global_sub()
integer, dimension(4) :: iarr4=(/1,2,3,4/)
integer, dimension(4) :: jarr4
e

[flang] Set SAVE attribute for EQUIVALENCEd symbols consistently. (#67078)

Example:
```
subroutine global_sub()
integer, dimension(4) :: iarr4=(/1,2,3,4/)
integer, dimension(4) :: jarr4
equivalence(iarr4,jarr4)
call sub1
print *, iarr4
contains
subroutine sub1
iarr4=jarr4((/4:1:-1/))
end subroutine sub1
end subroutine global_sub
```

`iarr4` and `jarr4` are equivalenced via a global aggregate storage,
but the references inside `sub1` are lowered differently.
`iarr4` is accessed via the global aggregate storage, while `jarr4`
is accessed via the argument tuple. This confuses the FIR alias
analysis,
that claims that a host associated entity cannot alias with a global
(if they have different source and do not have Target/Pointer
attributes deduced by the alias analysis).

I am not convinced that there is an issue in the alias analysis yet.
I think we'd better lower the accesses uniformly, i.e. if one variable
from an equivalence is lowered via the global aggregate storage, then
any other variable from this equivalence should be lowered the same way
(even if they are used via host association).

This patch makes sure that all symbols from an EQUIVALENCE get
and implicit SAVE attribute, if they do not have it already and
any symbol from the EQUIVALENCE is SAVEd (explicitly or implicitly).
This makes the further lowering consistent.

show more ...

[flang] Don't complain about implicitly-typed dummy arguments inherited into an IMPLICIT NONE submodule

When a module procedure's interface is defined in an ancestor (sub)module
with an implicitly t

[flang] Don't complain about implicitly-typed dummy arguments inherited into an IMPLICIT NONE submodule

When a module procedure's interface is defined in an ancestor (sub)module
with an implicitly typed dummy argument, don't emit a bogus error in
the separate module procedure later if its submodule has IMPLICIT NONE.

Fixes llvm-test-suite/Fortran/gfortran/regression/submodule_26.f90.

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

show more ...

[flang] Support for PowerPC vector type

The following PowerPC vector type syntax is added:

VECTOR ( element-type-spec )

where element-type-sec is integer-type-spec, real-type-sec or unsigned-typ

[flang] Support for PowerPC vector type

The following PowerPC vector type syntax is added:

VECTOR ( element-type-spec )

where element-type-sec is integer-type-spec, real-type-sec or unsigned-type-spec.

Two opaque types (__VECTOR_PAIR and __VECTOR_QUAD) are also added.

A finite set of functionalities are implemented in order to support the new types:
1. declare objects
2. declare function result
3. declare type dummy arguments
4. intrinsic assignment between the new type objects (e.g. v1=v2)
5. reference functions that return the new types

Submit on behalf of @tislam @danielcchen

Authors: @tislam @danielcchen

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

show more ...

[flang] Rework handling of non-type-bound user-defined I/O

A fairly recent introduction of runtime I/O APIs called OutputDerivedType()
and InputDerivedType() didn't cover NAMELIST I/O's need to acce

[flang] Rework handling of non-type-bound user-defined I/O

A fairly recent introduction of runtime I/O APIs called OutputDerivedType()
and InputDerivedType() didn't cover NAMELIST I/O's need to access
non-type-bound generic interfaces for user-defined derived type I/O
when those generic interfaces are defined in some scope other than the
one that defines the derived type.

The patch adds a new data structure shared between lowering
and the runtime that can represent all of the cases that can
arise with non-type-bound defined I/O. It can represent
scopes in which non-type-bound defined I/O generic interfaces
are inaccessible, too, due to IMPORT statements.

The data structure is now an operand to OutputDerivedType() and
InputDerivedType() as well as a data member in the NamelistGroup
structure.

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

show more ...

[flang] Move SAVE attribute checks to declaration checking

Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly d

[flang] Move SAVE attribute checks to declaration checking

Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly during name resolution. This allows us to
catch attempts to attach explicit SAVE attributes to anything
that can't have one (constraints C859, C860).

Also delete `IsSave()`, whose few remaining uses were changed to the
more general `IsSaved()` predicate that seems more correct for
those uses, returning true for both explicit and implied SAVE
attributes.

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

show more ...

[flang] Expunge needless semantics::ProcInterface

The ProcInterface structure is used only by ProcEntityDetails; it represents
what a program might have put in parentheses in a procedure-declaration

[flang] Expunge needless semantics::ProcInterface

The ProcInterface structure is used only by ProcEntityDetails; it represents
what a program might have put in parentheses in a procedure-declaration-stmt,
either the name of a procedure interface or a declaration-type-spec.

If a procedure entity has an implicit interface, the function result
type (if any) can be kept in EntityDetails::type_, which already exists
and is currently redundant for ProcEntityDetails symbols.

All that is really needed is a nullable Symbol pointer in ProcEntityDetails
to point to the procedure's explicit interface, when it has one.

Also, catch the case where a procedure has an explicit interface
and a program attempts to also give it a type.

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

show more ...

[flang] Map symbols in expressions when copying interface symbols

Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed
later by a corresponding separate module subprogram definition in a

[flang] Map symbols in expressions when copying interface symbols

Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed
later by a corresponding separate module subprogram definition in a
MODULE PROCEDURE, the copies of the interface's dummy argument and
function result symbols that populate the initial scope of that
MODULE PROCEDURE need to have any symbol references in their types
or bounds adjusted to point to their new counterparts.

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

show more ...

[flang] Don't emit portability warnings for things in module files

Any symbol in a module file will have been already shamed with
portability warnings when the module was compiled, so don't pile
on

[flang] Don't emit portability warnings for things in module files

Any symbol in a module file will have been already shamed with
portability warnings when the module was compiled, so don't pile
on when compiling other program units that use the module.
This also silences warnings about some symbols whose names were
created or extended by the compiler to avoid clashes.

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

show more ...

Use llvm::is_contained (NFC)

[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 ...

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] 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] Allow extension cases of EQUIVALENCE with optional warnings

EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-ki

[flang] Allow extension cases of EQUIVALENCE with optional warnings

EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode. This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.

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

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] Add -fno-automatic, refine IsSaved()

This legacy option (available in other Fortran compilers with various
spellings) implies the SAVE attribute for local variables on subprograms
that are n

[flang] Add -fno-automatic, refine IsSaved()

This legacy option (available in other Fortran compilers with various
spellings) implies the SAVE attribute for local variables on subprograms
that are not explicitly RECURSIVE. The SAVE attribute essentially implies
static rather than stack storage. This was the default setting in Fortran
until surprisingly recently, so explicit SAVE statements & attributes
could be and often were omitted from older codes. Note that initialized
objects already have an implied SAVE attribute, and objects in COMMON
effectively do too, as data overlays are extinct; and since objects that are
expected to survive from one invocation of a procedure to the next in static
storage should probably be explicit initialized in the first place, so the
use cases for this option are somewhat rare, and all of them could be
handled with explicit SAVE statements or attributes.

This implicit SAVE attribute must not apply to automatic (in the Fortran sense)
local objects, whose sizes cannot be known at compilation time. To get the
semantics of IsSaved() right, the IsAutomatic() predicate was moved into
Evaluate/tools.cpp to allow for dynamic linking of the compiler. The
redundant predicate IsAutomatic() was noticed, removed, and its uses replaced.

GNU Fortran's spelling of the option (-fno-automatic) was added to
the clang-based driver and used for basic sanity testing.

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

show more ...

[flang] Fix creation of deferred shape arrays by POINTER statement

It's possible to declare deferred shape array using the POINTER
statement, for example:

POINTER :: var(:)

When analyzing POINT

[flang] Fix creation of deferred shape arrays by POINTER statement

It's possible to declare deferred shape array using the POINTER
statement, for example:

POINTER :: var(:)

When analyzing POINTER declarations, we were not capturing the array
specification information, if present. I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList". In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".

I also added a couple of small tests that fail to compile without these
changes.

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

show more ...