[flang] Don't reference non-invariant symbols in shape expressions

When an array's shape involves references to symbols that are not
invariant in a scope -- the classic example being a dummy array
w

[flang] Don't reference non-invariant symbols in shape expressions

When an array's shape involves references to symbols that are not
invariant in a scope -- the classic example being a dummy array
with an explicit shape involving other dummy arguments -- the
compiler was creating shape expressions that referenced those
symbols. This might be valid if those symbols are somehow
captured and copied at each entry point to a subprogram, and
the copies referenced in the shapes instead, but that's not
the case.

This patch introduces a new expression predicate IsScopeInvariantExpr(),
which defines a class of expressions that contains constant expressions
(in the sense that the standard uses that term) as well as references
to items that may be safely accessed in a context-free way throughout
their scopes. This includes dummy arguments that are INTENT(IN)
and not VALUE, descriptor inquiries into descriptors that cannot
change, and bare LEN type parameters within the definitions of
derived types. The new predicate is then used in shape analysis
to winnow out results that would have otherwise been contextual.

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

show more ...

[flang][NFC] Document extension: scalars are trivially contiguous

The Fortran 2018 standard defines the concept of simple contiguity
in subclause 9.5.4 as a characteristic of arrays. So that scalar

[flang][NFC] Document extension: scalars are trivially contiguous

The Fortran 2018 standard defines the concept of simple contiguity
in subclause 9.5.4 as a characteristic of arrays. So that scalars
may also be used in contexts where simply contiguous arrays are
allowed, f18 treats them as single-element arrays that are trivially
contiguous. This patch documents this semantic extension and
also adds comments to the predicate that implements the concept.

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

show more ...

[flang] Better error recovery for missing THEN in ELSE IF

The THEN keyword in the "ELSE IF (test) THEN" statement is useless
syntactically, and to omit it is a common error (at least for me!)
that h

[flang] Better error recovery for missing THEN in ELSE IF

The THEN keyword in the "ELSE IF (test) THEN" statement is useless
syntactically, and to omit it is a common error (at least for me!)
that has poor error recovery. This patch changes the parser to
cough up a simple "expected 'THEN'" and still recognize the rest of
the IF construct.

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

show more ...

[flang] Enforce specification function rules on callee, not call

A function can't be a specification function if it has a dummy procedure
argument, even if it's optional and unused. So don't check

[flang] Enforce specification function rules on callee, not call

A function can't be a specification function if it has a dummy procedure
argument, even if it's optional and unused. So don't check the reference
for actual procedure arguments, but rather the characteristics of the
function.

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

show more ...

[flang] Symbol representation for dummy SubprogramDetails

Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.

subroutine subr(dummy)
interface
subroutine dummy

[flang] Symbol representation for dummy SubprogramDetails

Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.

subroutine subr(dummy)
interface
subroutine dummy(x)
real :: x
end subroutine
end interface
! ...
end subroutine

but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail. Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.

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

show more ...

[flang] Fix IsSimplyContiguous() for the case of a pointer component

The result expression for the analysis of a Component is not (longer)
valid in the expression traversal framework used by IsSimpl

[flang] Fix IsSimplyContiguous() for the case of a pointer component

The result expression for the analysis of a Component is not (longer)
valid in the expression traversal framework used by IsSimplyContiguousHelper
now that it has a tri-state result. Fix so that any result of
analyzing the component symbol is required to be true, not just
present.

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

show more ...

[flang] CheckConformance: tristate-ify result

To ensure that errors are emitted by CheckConformance and
its callers in all situations, it's necessary for the returned result
of that function to dist

[flang] CheckConformance: tristate-ify result

To ensure that errors are emitted by CheckConformance and
its callers in all situations, it's necessary for the returned result
of that function to distinguish between three possible
outcomes: the arrays are known to conform at compilation time,
the arrays are known to not conform (and a message has been
produced), and an indeterminate result in which is not possible
to determine conformance. So convert CheckConformance's
result into an optional<bool>, and convert its confusing
Boolean flag arguments into a bit-set of named flags too.

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

show more ...

[flang] Refine checks for pointer initialization targets

f18 was emitting a bogus error message about the lack of a TARGET
attribute when a pointer was initialized with a component of a
variable tha

[flang] Refine checks for pointer initialization targets

f18 was emitting a bogus error message about the lack of a TARGET
attribute when a pointer was initialized with a component of a
variable that was a legitimate TARGET.

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

show more ...

[flang] Fix problems with constant arrays with lower bounds that are not 1

There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating t

[flang] Fix problems with constant arrays with lower bounds that are not 1

There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating the folded array to have lower
bounds of 1 but, we were not re-adjusting their lower bounds to the
declared values. Second, we were not calculating the extents correctly.
Both of these problems led to bogus error messages.

I fixed the first problem by adjusting the lower bounds in
NonPointerInitializationExpr() in Evaluate/check-expression.cpp. I wrote the
class ArrayConstantBoundChanger, which is similar to the existing class
ScalarConstantExpander. In the process of implementing and testing it, I found
a bug that I fixed in ScalarConstantExpander which caused it to infinitely
recurse on parenthesized expressions. I also removed the unrelated class
ScalarExpansionVisitor, which was not used.

I fixed the second problem by changing the formula that calculates upper bounds
in in the function ComputeUpperBound() in Evaluate/shape.cpp.

I added tests that trigger the bogus error messages mentioned above along with
a constant folding tests that uses array operands with shapes that conform but
have different bounds.

In the process of adding tests, I discovered that tests in
Evaluate/folding09.f90 and folding16.f90 were written incorrectly, and I
fixed them. This also revealed a bug in contant folding of the
intrinsic "lbounds" which I plan to fix in a later change.

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

show more ...

[flang] Create names to allow access to inaccessible specifics

When a reference to a generic interface occurs in a specification
expression that must be emitted to a module file, we have a problem
w

[flang] Create names to allow access to inaccessible specifics

When a reference to a generic interface occurs in a specification
expression that must be emitted to a module file, we have a problem
when the generic resolves to a function whose name is inaccessible
due to being PRIVATE or due to a conflict with another use of the
same name in the scope. In these cases, construct a new name for
the specific procedure and emit a renaming USE to the module file.
Also, relax enforcement of PRIVATE when analyzing module files.

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

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] Clean up TODO comments and fix one (DATA constant ambiguity)

Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in

[flang] Clean up TODO comments and fix one (DATA constant ambiguity)

Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.

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

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] Correct handling of null pointer initializers

Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsi

[flang] Correct handling of null pointer initializers

Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsic function NULL() with no actual
arguments.

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

show more ...

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-as

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.

Updated to fix a circular dependence between shared library
binaries that was introduced by the original patch.

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

show more ...

Revert "[flang] Fix CheckSpecificationExpr handling of associated names"

This reverts commit b670189975f5ba4e8ef22c74724c610287b69c28.

This patch causes shared library builds (BUILD_SHARED_LIBS=ON)

Revert "[flang] Fix CheckSpecificationExpr handling of associated names"

This reverts commit b670189975f5ba4e8ef22c74724c610287b69c28.

This patch causes shared library builds (BUILD_SHARED_LIBS=ON) to fail:
* http://lab.llvm.org:8011/#/builders/33/builds/626

I wasn't able to identify any easy fix, hence reverting.

show more ...

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-as

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.

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

show more ...

[flang] Check shape conformance on initializers

Specifically, ensure that initializers conform with their objects
according to 8.2 para 4.

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

[flang] Make `TypeParamInquiry` monomorphic

Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic represent

[flang] Make `TypeParamInquiry` monomorphic

Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic representation that results in a SubscriptInteger
that can then be converted.

This is a minor simplification, but it's worth doing because
it is believed to also be a work-around for bugs in the MSVC
compiler with overload resolution that affect the expression
traversal framework.

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

show more ...

[flang] Fixes for RESHAPE()

I fixed an assert caused by passing an empty array as the source= argument to
RESHAPE(). In the process, I noticed that there were no tests for RESHAPE(),
so I wrote a t

[flang] Fixes for RESHAPE()

I fixed an assert caused by passing an empty array as the source= argument to
RESHAPE(). In the process, I noticed that there were no tests for RESHAPE(),
so I wrote a test that covers all the description in 16.9.163. In the process,
I made the error messages more consistent and descriptive. I also changed the
test to see if a reference to an intrinsic function was a constant to say that
it is a constant if it's a refererence to an invalid intrinsic. This avoids
emitting multiple messages for the same erroneous source.

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

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] Fix IsConstantExpr for division expressions

Summary:
Fortran::evaluate::IsConstantExpr did not check that the numerator
was a constant expression. This patch fixes the issue.

Reviewers: Dav

[flang] Fix IsConstantExpr for division expressions

Summary:
Fortran::evaluate::IsConstantExpr did not check that the numerator
was a constant expression. This patch fixes the issue.

Reviewers: DavidTruby, klausler, schweitz, PeteSteinfeld, jdoerfert, sscalpone

Reviewed By: klausler, PeteSteinfeld, sscalpone

Subscribers: llvm-commits

Tags: #llvm, #flang

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

show more ...

[flang] Implemented 2 Semantic checks for DATA statement and fixed a few bugs

Summary
- Implemented C876, C877
- Fixed IsConstantExpr to check C879
- Fixed bugs in few test cases - data01.f90,

[flang] Implemented 2 Semantic checks for DATA statement and fixed a few bugs

Summary
- Implemented C876, C877
- Fixed IsConstantExpr to check C879
- Fixed bugs in few test cases - data01.f90, block-data01.f90,
pre-fir-tree02.f90
- Modified implementation of C8106 to identify all automatic objects
and modified equivalence01.f90 to reflect the changes

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

show more ...

[flang][NFC] Remove link-time dependency of Evaluate on Semantics

Summary:
Some Symbol-related functions used in Evaluate were moved to
Evaluate/tools.h. This includes changing some member functions

[flang][NFC] Remove link-time dependency of Evaluate on Semantics

Summary:
Some Symbol-related functions used in Evaluate were moved to
Evaluate/tools.h. This includes changing some member functions that were
replaced by non-member functions `IsDummy`, `GetUsedModule`, and
`CountLenParameters`.

Some member functions were made inline in `Scope`, `Symbol`,
`ArraySpec`, and `DeclTypeSpec`. The definitions were preceded by a
comment explaining why they are inline.

`IsConstantShape` was expanded inline in `IsDescriptor` because it isn't
used anywhere else

After this change, at least when compiling with clang on macos,
`libFortranEvaluate.a` has no undefined symbols that are satisfied by
`libFortranSemantics.a`.

Reviewers: klausler, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby

Reviewed By: PeteSteinfeld

Subscribers: llvm-commits

Tags: #flang, #llvm

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

show more ...

[flang] Constraint checks C751 to C760

Summary:
Many of these were already implemented, and I just annotated the tests and/or
the code.

C752 was a simple check to verify that CONTIGUOUS components

[flang] Constraint checks C751 to C760

Summary:
Many of these were already implemented, and I just annotated the tests and/or
the code.

C752 was a simple check to verify that CONTIGUOUS components are arrays with

C754 proved to be virtually identical to C750 that I implemented previously.
This caused me to remove the distinction between specification expressions for
type parameters and bounds expressions that I'd previously created.
the POINTER attribute.

I also changed the error messages to specify that errors in specification
expressions could arise from either bad derived type components or type
parameters.

In cases where we detect a type param that was not declared, I created a symbol
marked as erroneous. That avoids subsequent semantic process for expressions
containing the symbol. This change caused me to adjust tests resolve33.f90 and
resolve34.f90. Also, I avoided putting out error messages for erroneous type
param symbols in `OkToAddComponent()` in resolve-names.cpp and in
`EvaluateParameters()`, type.cpp.

C756 checks that procedure components have the POINTER attribute.

Reviewers: tskeith, klausler, DavidTruby

Subscribers: llvm-commits

Tags: #llvm, #flang

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

show more ...