When an explicit MODULE procedure is defined in the same (sub)module
as its interface, and the interface was defined in a generic
interface of the same name, bogus errors about symbols already
having been defined will ensue. Cleaning up this aspect of name
resolution and symbol table management requires marking the
place-holding SubprogramNameDetails symbols of explicit MODULE
subprograms as such, ensuring that that attribute is not inherited
if the SubprogramNameDetails symbol is recycled as a SubprogramDetails,
and gathering some code that should have been common between
BeginSubprogram() and BeginMpSubprogram() together in one
new routine.
Differential Revision: https://reviews.llvm.org/D134446
Replace most tests of the explicit Attr::ELEMENTAL symbol flag with
a new predicate IsElementalProcedure() that works correctly for alternate
ENTRY points and does the right thing for procedure interfaces that
reference elemental intrinsic functions like SIN() whose elemental
nature does not propagate.
Differential Revision: https://reviews.llvm.org/D129022
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().
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
Fortran admits a few ways to have multiple symbols with the
same name in the same scope. Two of them involve generic
interfaces (from INTERFACE or GENERIC, the syntax doesn't matter);
these are allowed to inhabit a scope with either a derived type or
a subprogram that is also a specific procedure of the generic.
(But not both a derived type and a subprogram; they could not
cohabit a scope anyway, generic or not.)
In cases of USE association, f18 needs to be capable of combining
use-associated generic interfaces with other use-associated entities.
Two generics get merged (this case was nearly correct); a generic
and a derived type can merge into a GenericDetails with a shadowed
derivedType(); and a generic can replace or ignore a use-associated
procedure of the same name so long as that procedure is already
one of its specifics.
Further, these modifications to the use-associated generic
interface must be made to a local copy of the symbol. The previous
code was messing directly with the symbol in the module's scope.
The fix is basically a reimplementation of the member function
DoAddUse() in name resolution.
Differential Revision: https://reviews.llvm.org/D123704
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
The symbol table, name resolution, and semantic checks for module
subprograms -- esp. for MODULE FUNCTION and MODULE SUBROUTINE, but
also MODULE PROCEDURE -- essentially assumed that the subprogram
would be defined in a submodule of the (sub)module containing its
interface. However, it is conforming to instead declare a module
subprogram in the *same* (sub)module as its interface, and we need
to handle that case.
Since this case involves two symbols in the same scope with the same
name, the symbol table details for subprograms have been extended
with a pointer to the original module interface, rather than relying
on searching in scopes.
Differential Revision: https://reviews.llvm.org/D120839
Derived types with allocatable and pointer components cannot
be used in I/O data transfer statements unless they have defined
I/O procedures available (as type-bound or regular generics).
These cases are caught as errors by the I/O runtime library,
but it would be better if they were flagged during compilation.
(Address comment in review: don't use explicit name string lengths.)
Differential Revision: https://reviews.llvm.org/D120675
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
Helps debugging when working with symbol/expression issue. The dump
method is easy to call in the debugger.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Differential Revision: https://reviews.llvm.org/D110856
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
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
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
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
When merging use associations into a generic, we weren't handling
the case where the name that was use associated was itself a use
association. This is fixed by following that association to its
ultimate symbol (`useUltimate` in `DoAddUse`).
An example of the bug is `m12d` in `resolve17.f90`. `g` is associated
with `gc` in `m12c` which is associated with `gb` in `m12b`. It was that
last association that we weren't correctly following.
Differential Revision: https://reviews.llvm.org/D93343
When the same generic name is use-associated from two modules, the
generics are merged into a single one in the current scope. This change
fixes some bugs in that process.
When a generic is merged, it can have two specific procedures with the
same name as the generic (c.f. module m7c in modfile07.f90). We were
disallowing that by checking for duplicate names in the generic rather
than duplicate symbols. Changing `namesSeen` to `symbolsSeen` in
`ResolveSpecificsInGeneric` fixes that.
We weren't including each USE of those generics in the .mod file so in
some cases they were incorrect. Extend GenericDetails to specify all
use-associated symbols that are merged into the generic. This is used to
write out .mod files correctly.
The distinguishability check for specific procedures of a generic
sometimes have to refer to procedures from a use-associated generic in
error messages. In that case we don't have the source location of the
procedure so adapt the message to say where is was use-associated from.
This requires passing the scope through the checks to make that
determination.
Differential Revision: https://reviews.llvm.org/D92492
Fortran's FINAL feature is sensitive to object rank.
When an object's rank excludes it from finalization, but
the type has FINAL subroutines for other ranks, emit
a warning. This should be especially helpful in the
case of a scalar FINAL subroutine not being declared
(IMPURE) ELEMENTAL.
Differential revision: https://reviews.llvm.org/D90495
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
The Microsoft compiler seems to have difficulties to decide between a const/non-const method of a captured object context in a closure. The error message is:
```
symbol.cpp(261): error C2668: 'Fortran::semantics::Symbol::detailsIf': ambiguous call to overloaded function
symbol.h(535): note: could be 'const D *Fortran::semantics::Symbol::detailsIf<Fortran::semantics::DerivedTypeDetails>(void) const'
symbol.h(534): note: or 'D *Fortran::semantics::Symbol::detailsIf<Fortran::semantics::DerivedTypeDetails>(void)'
symbol.cpp(261): note: while trying to match the argument list '()'
```
Explicitly using the this-pointer resolves this problem.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D88052
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Differential Revision: https://reviews.llvm.org/D87535
The result of a statement function may require an implicit conversion
to match its result type. Add that to the expression that represents
the statement function body in SubprogramDetails.
Extract the analysis of that expression into a separate function.
Dump the statement function expression as part of the dump of
SubprogramDetails.
Differential Revision: https://reviews.llvm.org/D84452
Summary:
When a program unit creates a generic based on one defined in a module, the
function `CopyFrom()` is called to create the `GenericDetails`. This function
copied the `specificProcs_` but failed to copy the `bindingNames_`. If the
function `CheckGeneric()` then gets called, it tries to index into the empty
binding names and causes the crash.
I fixed this by adding code to `CopyFrom()` to copy the binding names.
I also added a test that causes the crash.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D83491
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
Summary:
Initially on github I worked on semantic checks.Then I tried some compile-time
test of the rank value, they were failing as there were no symbols
generated for them inside SELECT RANK's scope.So I went further to
add new symbol in each scope, also added the respective 'rank: '
field for a symbol when we dump the symboltable. I added a field to
keep track of the rank in AssocEntityDetails class.This caused shape
analysis framework to become inconsistent. So shape analysis framework
was updated to handle this new representation.
* I added more tests for above changes.
* On phabricator I addressed some minor changes.
* Lastly I worked on review comments.
Reviewers: klausler,sscalpone,DavidTruby,kiranchandramohan,tskeith,anchu-rajendran,kiranktp
Reviewed By:klausler, DavidTruby, tskeith
Subscribers:#flang-commits, #llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78623
Add a way to get mutable equivalence sets to Scope so that they can
have sizes and offsets assigned to them.
Change CommonBlockDetails to have mutable symbols so that they can have
sizes and offets assigned to them. This also allows the removal of some
`const_cast`s.
Add MutableSymbolRef and MutableSymbolVector as mutable analogs to
SymbolRef and SymbolVector. Replace uses of equivalent types with those
names.
Differential Revision: https://reviews.llvm.org/D79346
Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are processed
first. Add alignment to CommonBlockDetails to record the required
alignment of the common block.
For equivalence sets, each object depends on the one that is forced to
occur first in memory. The rest are recorded in the dependents_ map and
have offsets assigned after the other symbols are done.
Differential Revision: https://reviews.llvm.org/D79347
Summary:
Add size and offset properties to symbols, representing their byte size
and offset within their enclosing scope.
Add size and align properties to scopes so that they are available for
scopes representing derived types.
Add ComputeOffsets pass over the symbol table to fill in those fields.
Compute descriptor size based on rank and length parameters. Extract
DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor
to share the code.
Add Scope::GetSymbols to get symbols in canonical order.
compute-offsets.cpp and mod-file.cpp both need to process symbols in the
order in which they are declared. Move the collecting of those symbols
into Scope so that it can be shared.
Add symbol size and offset to output of `-fdebug-dump-symbols` and use
that in some tests.
Still to do:
- make size and alignment rules configurable based on target
- use offsets to check EQUIVALENCE statements
Differential Revision: https://reviews.llvm.org/D78680
Summary:
Move InstantiateComponent and InstantiateIntrinsicType from symbol.cpp
to type.cpp as that is where they are called.
Put both in InstantiateHelper class to better isolate them.
Add CreateDerivedTypeSpec in InstantiateHelper.
Add non-const forms for AsIntrinsic and AsDerived to avoid const_cast.
No functional changes.
Reviewers: DavidTruby, klausler, PeteSteinfeld, jdoerfert
Reviewed By: klausler
Subscribers: llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78678
There is no printf formatting string for std::int64_t. Instead we have
to cast to std::intmax_t and use `%jd`. This change simplifies that by
automatically converting std::int64_t to std::intmax_t when formatting
messages.
Original-commit: flang-compiler/f18@8a2343dfff
Reviewed-on: https://github.com/flang-compiler/f18/pull/1101
Tree-same-pre-rewrite: false
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@a3507d44b8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
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@d121578af1
Reviewed-on: https://github.com/flang-compiler/f18/pull/1080
When a misparsed FunctionReference was converted to a StructureConstructor,
the components accessed were not checked for accessibility.
The conversion happens in expression analysis so that where the accessibity
must be checked. So move `CheckAccessibleComponent` to `tools.h` so that it
can be shared by `resolve-names.cpp` and `expression.cpp`.
Add FindModuleContaining to help implement this and use it other places.
Check that an access-spec can only appear in a module.
Remove some unnecessary "semantics::" qualifiers.
Original-commit: flang-compiler/f18@99ce156e49
Reviewed-on: https://github.com/flang-compiler/f18/pull/1046
Peter Klausler