Revert "[flang] Detect circularly defined interfaces of procedures"

This reverts commit 93c5e6bb49ca502d266700dd292e3873dfa51bb6.

This patch updates resolve102.f90 which is now failing in 6 out 8 o

Revert "[flang] Detect circularly defined interfaces of procedures"

This reverts commit 93c5e6bb49ca502d266700dd292e3873dfa51bb6.

This patch updates resolve102.f90 which is now failing in 6 out 8 of our
public buildbots:
* http://lab.llvm.org:8011/#/builders/21/builds/9625
* http://lab.llvm.org:8011/#/builders/134/builds/2395
* http://lab.llvm.org:8011/#/builders/79/builds/6298
* http://lab.llvm.org:8011/#/builders/66/builds/2084
* http://lab.llvm.org:8011/#/builders/135/builds/2485
* http://lab.llvm.org:8011/#/builders/32/builds/3551

Please see the following revisions for more context:
* https://reviews.llvm.org/D97201
* https://reviews.llvm.org/D97749

show more ...

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure.

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.

I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.

With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure. But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.

I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function. This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.

I also fixed the error message used when reporting recursively defined dummy
procedure arguments.

I also added tests that will crash the compiler without this change.

Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ... All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.

Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory. But I was unable to create
a test that caused a problem. Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems. Symbols in enclosing or
parallel scopes can have the same name. Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.

This change supersedes D97201.

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

show more ...

Revert "[flang] Detect circularly defined interfaces of procedures"

This reverts commit 07de0846a5055015b55dc2b8faa2143f9902e549.

The original patch has caused 6 out 8 of Flang's public buildbots t

Revert "[flang] Detect circularly defined interfaces of procedures"

This reverts commit 07de0846a5055015b55dc2b8faa2143f9902e549.

The original patch has caused 6 out 8 of Flang's public buildbots to
fail. As I'm not sure what the fix should be, I'm reverting this for
now. Please see https://reviews.llvm.org/D97201 for more context and
discussion.

show more ...

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure.

[flang] Detect circularly defined interfaces of procedures

It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.

I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.

With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was
defined using the name of the procedure. But the procedure name was
being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous
symbols. I fixed this by making SymbolSet be an ordered set, which does
not use the "<" operator.

I also added tests that will crash the compiler without this change.
And I fixed the formatting on an error message from a previous update.

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

show more ...

[flang] Warn about useless explicit typing of intrinsics

Fortran 2018 explicitly permits an ignored type declaration
for the result of a generic intrinsic function. See the comment
added to Semanti

[flang] Warn about useless explicit typing of intrinsics

Fortran 2018 explicitly permits an ignored type declaration
for the result of a generic intrinsic function. See the comment
added to Semantics/expression.cpp for an explanation of why this
is somewhat dangerous and worthy of a warning.

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

show more ...

[flang] Detect circularly defined procedures

It's possible to define a procedure that has a procedure dummy argument which
names the procedure that contains it. This was causing the compiler to fal

[flang] Detect circularly defined procedures

It's possible to define a procedure that has a procedure dummy argument which
names the procedure that contains it. This was causing the compiler to fall
into an infinite loop when characterizing a call to the procedure.

Following a suggestion from Peter, I fixed this be maintaining a set of
procedure symbols that had already been seen while characterizing a procedure.
This required passing a new parameter to the functions that characterized a
Procedure, a DummyArgument, and a DummyProcedure.

I also added several tests that will crash the compiler without this change.

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

show more ...

[flang] Add TypeAndShape::MeasureElementSizeInBytes()

Split up MeasureSizeInBytes() so that array element sizes can be
calculated accurately; use the new API in some places where
DynamicType::Measur

[flang] Add TypeAndShape::MeasureElementSizeInBytes()

Split up MeasureSizeInBytes() so that array element sizes can be
calculated accurately; use the new API in some places where
DynamicType::MeasureSizeInBytes() was being used but the new
API performs better due to TypeAndShape having precise CHARACTER
length information.

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

show more ...

[flang] Improve shape & length characterization

Analyze the shape of the result of TRANSFER(ptr,array) correctly
when "ptr" is an array of deferred shape. Fixing this bug led to
some refactoring an

[flang] Improve shape & length characterization

Analyze the shape of the result of TRANSFER(ptr,array) correctly
when "ptr" is an array of deferred shape. Fixing this bug led to
some refactoring and concentration of common code in TypeAndShape
member functions with code in general shape and character length
analysis, and this led to some regression test failures that have
all been cleaned up.

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

show more ...

[flang] Infrastructure improvements in utility routines

* IsArrayElement() needs another option to control whether it
should ignore trailing component references.
* Add IsObjectPointer().
* Add co

[flang] Infrastructure improvements in utility routines

* IsArrayElement() needs another option to control whether it
should ignore trailing component references.
* Add IsObjectPointer().
* Add const Scope& variants of IsFunction() and IsProcedure().
* Make TypeAndShape::Characterize() work with procedure bindings.
* Handle CHARACTER length in MeasureSizeInBytes().
* Fine-tune FindExternallyVisibleObject()'s handling of dummy arguments
to conform with Fortran 2018: only INTENT(IN) and dummy pointers
in pure functions signify; update two tests accordingly.

Also: resolve some stylistic inconsistencies and add a missing
"const" in the expression traversal template framework.

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

show more ...

[flang] Fix classification of shape inquiries in specification exprs

In some contexts, including the motivating case of determining whether
the expressions that define the shape of a variable are "c

[flang] Fix classification of shape inquiries in specification exprs

In some contexts, including the motivating case of determining whether
the expressions that define the shape of a variable are "constant expressions"
in the sense of the Fortran standard, expression rewriting via Fold()
is not necessary, and should not be required. The inquiry intrinsics LBOUND,
UBOUND, and SIZE work correctly now in specification expressions and are
classified correctly as being constant expressions (or not). Getting this right
led to a fair amount of API clean-up as a consequence, including the
folding of shapes and TypeAndShape objects, and new APIs for shapes
that do not fold for those cases where folding isn't needed. Further,
the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any
associations of their symbols and work transparently on use-, host-, and
construct-association symbols; the tools used to resolve those associations have
been defined and documented more precisely, and their clients adjusted as needed.

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

show more ...

[flang] Implement STORAGE_SIZE(), SIZEOF(), C_SIZEOF()

STORAGE_SIZE() is a standard inquiry intrinsic (size in bits
of an array element of the same type as the argument); SIZEOF()
is a common extens

[flang] Implement STORAGE_SIZE(), SIZEOF(), C_SIZEOF()

STORAGE_SIZE() is a standard inquiry intrinsic (size in bits
of an array element of the same type as the argument); SIZEOF()
is a common extension that returns the size in bytes of its
argument; C_SIZEOF() is a renaming of SIZEOF() in module ISO_C_BINDING.

STORAGE_SIZE() and SIZEOF() are implemented via rewrites to
expressions; these expressions will be constant when the necessary
type parameters and bounds are also constant.

Code to calculate the sizes of types (with and without alignment)
was isolated into Evaluate/type.* and /characteristics.*.
Code in Semantics/compute-offsets.* to calculate sizes and alignments
of derived types' scopes was exposed so that it can be called at type
instantiation time (earlier than before) so that these inquiry intrinsics
could be called from specification expressions.

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

show more ...

[flang] Fix false error message for "ptr => func()" array conformance

Pointers must have deferred shapes, so CheckConformance must be
extended to allow for them.

Differential Revision: https://revi

[flang] Fix false error message for "ptr => func()" array conformance

Pointers must have deferred shapes, so CheckConformance must be
extended to allow for them.

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

show more ...

[flang] Improve initializer semantics, esp. for component default values

This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other com

[flang] Improve initializer semantics, esp. for component default values

This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development. We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding. Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.

Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
derived type instantiations so that the user can figure out which
instance caused a problem with a component, have been added as part
of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
is passed as an argument rather than just its intrinsic procedure table;
this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
actually is a single constant value and to validate a non-pointer
variable initializer or object component default value
* shape conformance checking has additional arguments that control
whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
a crash, which might be useful in the future

TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.

Differential Review: https://reviews.llvm.org/D92783

show more ...

[flang] Fix actual argument character length and length error reporting

Ensure that character length is properly calculated for
actual arguments to intrinsics, and that source provenance
information

[flang] Fix actual argument character length and length error reporting

Ensure that character length is properly calculated for
actual arguments to intrinsics, and that source provenance
information is available when expression analysis calls
folding in cases where the length is invalid.

Differential revision: https://reviews.llvm.org/D90636

show more ...

[flang] Document and use intrinsic subroutine argument intents

Check INTENT(OUT)/INTENT(INOUT) constraints for actual argument
of intrinsic procedure calls.
- Adding a common::Intent field to the In

[flang] Document and use intrinsic subroutine argument intents

Check INTENT(OUT)/INTENT(INOUT) constraints for actual argument
of intrinsic procedure calls.
- Adding a common::Intent field to the IntrinsicDummyArgument
in the intrinsic table.
- Propagating it to the DummyDataObject intent field so that it can
later be used in CheckExplicitDataArg semantic checks.
- Add related tests.
- Fix regression (C846 false error), C846 INTENT(OUT) rule does
not apply to intrinsic call. Propagate the information that we
are in an intrinsic call up to CheckExplicitDataArg (that is
doing this check). Still enforce C846 on intrinsics other than MOVE_ALLOC (for which
allocatable coarrays are explicitly allowed) since it's not clear it is allowed in all
intrinsics and allowing this would lead to runtime penalties in the intrinsic runtime.

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

show more ...

[flang] Failed call to CHECK() for call to ASSOCIATED(NULL())

Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to
fail.

I fixed this by changing the entry for "ASSOCIATED" i

[flang] Failed call to CHECK() for call to ASSOCIATED(NULL())

Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to
fail.

I fixed this by changing the entry for "ASSOCIATED" in the intrinsics table to
accept "AnyPointer" which contains a new "KindCode" of "pointerType". I also
changed the function "FromActual()" to return a typeless intrinsic when called
on a pointer, which duplicates its behavior for BOZ literals. This required
changing the analysis of procedure arguments. While testing processing for
procedure arguments, I found another bad call to `CHECK()` which I fixed.

I made several other changes:
-- I implemented constant folding for ASSOCIATED().
-- I fixed handling of NULL() in relational operations.
-- I implemented semantic analysis for ASSOCIATED().
-- I noticed that the semantics for ASSOCIATED() are similar to those for
pointer assignment. So I extracted the code that pointer assignment uses
for procedure pointer compatibility to a place where it could be used by
the semantic analysis for ASSOCIATED().
-- I couldn't figure out how to make the general semantic analysis for
procedure arguments work with ASSOCIATED()'s second argument, which can
be either a pointer or a target. So I stopped using normal semantic
analysis for arguments for ASSOCIATED().
-- I added tests for all of this.

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

show more ...

[flang] Track CHARACTER length better in TypeAndShape

CHARACTER length expressions were not always being
captured or computed as part of procedure "characteristics",
leading to test failures due to

[flang] Track CHARACTER length better in TypeAndShape

CHARACTER length expressions were not always being
captured or computed as part of procedure "characteristics",
leading to test failures due to an inability to compute
memory size expressions accurately.

Differential revision: https://reviews.llvm.org/D88689

show more ...

[flang] Semantic analysis for FINAL subroutines

Represent FINAL subroutines in the symbol table entries of
derived types. Enforce constraints. Update tests that have
inadvertent violations or modi

[flang] Semantic analysis for FINAL subroutines

Represent FINAL subroutines in the symbol table entries of
derived types. Enforce constraints. Update tests that have
inadvertent violations or modified messages. Added a test.

The specific procedure distinguishability checking code for generics
was used to enforce distinguishability of FINAL procedures.
(Also cleaned up some confusion and redundancy noticed in the
type compatibility infrastructure while digging into that area.)

Differential revision: https://reviews.llvm.org/D88613

show more ...

[flang] CHARACTER(*) return does not require explicit interface

Fortran 2018 15.4.2.2(4)(c) says nonassumed or explicit non-constant
length parameter require explicit interface. The "nonassumed" par

[flang] CHARACTER(*) return does not require explicit interface

Fortran 2018 15.4.2.2(4)(c) says nonassumed or explicit non-constant
length parameter require explicit interface. The "nonassumed" part was
missing in f18 characteristic analysis causing CanBeCalledViaImplicitInterface
to return false for `CHARACTER(*) function foo()` like interfaces.

Reviewed By: klausler

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

show more ...

[flang] Implement shape analysis of TRANSFER intrinsic function result

The shape (esp. the size) of the result of a call to TRANSFER
is implemented according to the definition in the standard.

Diff

[flang] Implement shape analysis of TRANSFER intrinsic function result

The shape (esp. the size) of the result of a call to TRANSFER
is implemented according to the definition in the standard.

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

show more ...

[flang] DATA stmt processing (part 3/4): Remaining prep work

Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing

[flang] DATA stmt processing (part 3/4): Remaining prep work

Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing
via conversion to initializers.

Reviewed By: PeteSteinfeld

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

show more ...

[flang] Reformat with latest clang-format and .clang-format

Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094

[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code

[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]

As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()

It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries

*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.

[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Running clang-format-7

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Removing residue of ostream library

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@a3507d44b8911e6024033aa583c1dc54e0eb89fd
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047

show more ...

[flang] Check module subprogram against separate module procedure

When a module subprogram has the MODULE prefix the following must match
with the corresponding separate module procedure interface b

[flang] Check module subprogram against separate module procedure

When a module subprogram has the MODULE prefix the following must match
with the corresponding separate module procedure interface body:
- C1549: characteristics and dummy argument names
- C1550: binding label
- C1551: NON_RECURSIVE prefix

SubprogramMatchHelper performs all of these checks.

Rename separate-module-procs.f90 to separate-mp01.f90 so we can have
separate-mp02.f90 (etc).

Make ShapesAreCompatible public in characteristics.h.

Add Scope::IsSubmodule.

Original-commit: flang-compiler/f18@d121578af17109de3cea23617e4b8239971b5527
Reviewed-on: https://github.com/flang-compiler/f18/pull/1080

show more ...

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...