It's possible for the module file generation code to think that it needs
to (re)generate a module file for a dependent module read from a
hermetic module file, if it defines contains a procedure imported via
renaming due to a name clash. Adjust the logic that determines whether a
module file should be written to include a check for having originated
in a module file.
When emitting the modules on which a module depends under the
-fhermetic-module-files options, eliminate duplicates by name rather
than by symbol addresses. This way, when a dependent module is in the
symbol table more than once due to the use of a nested hermetic module,
it doesn't get emitted multiple times to the new module file.
This adds another puzzle piece for the support of OpenMP DECLARE
REDUCTION functionality.
This adds support for operators with derived types, as well as declaring
multiple different types with the same name or operator.
A new detail class for UserReductionDetials is introduced to hold the
list of types supported for a given reduction declaration.
Tests for parsing and symbol generation added.
Declare reduction is still not supported to lowering, it will generate a
"Not yet implemented" fatal error.
Fixes#141306Fixes#97241Fixes#92832Fixes#66453
---------
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
When one hermetic module file uses another, a later compilation may
crash in semantics when it itself is used, since the module file reader
sets the "current hermetic module file scope" to null after reading one
rather than saving and restoring that pointer.
OpenACC routines annotations in separate compilation units currently get
ignored, which leads to errors in compilation. There are two reason for
currently ignoring open acc routine information and this PR is
addressing both.
- The module file reader doesn't read back in openacc directives from
module files.
- Simple fix in `flang/lib/Semantics/mod-file.cpp`
- The lowering to HLFIR doesn't generate routine directives for symbols
imported from other modules that are openacc routines.
- This is the majority of this diff, and is address by the changes that
start in `flang/lib/Lower/CallInterface.cpp`.
The map of symbols requiring new local aliases for USE association needs
to use the symbols' ultimate resolutions to avoid missing cases that can
arise in convoluted codes with lots of confusing renamings.
Fixes https://github.com/llvm/llvm-project/issues/132435.
The relationship between a Cray pointee and its pointer is not in the
symbol table entry, but instead in a per-scope map. Use this information
to ensure that if a pointee/pointer is needed in the module file, so is
its pointer/pointee.
Fixes https://github.com/llvm/llvm-project/issues/130270.
This PR is a follow-up to #128655.
It adds another test to ensure deterministic ordering in `.mod` files
and includes related changes to prevent non-deterministic ordering
caused by iterating over a set ordered by heap pointers. This issue is
particularly noticeable when using Flang as a library and compiling the
same files multiple times.
The reduced test case is as minimal as possible. We were unable to
reproduce the issue with a smaller set of files.
Modules read from module files must have their symbols tagged with the
ModFile flag to suppress all warnings messages that might be emitted for
their contents. (Actionable warnings will have been emitted when the
modules were originally compiled, so we don't want to repeat them later
when the modules are USE'd.) The module symbols of the additional
modules in hermetic module files were not being tagged with that flag;
fix.
This PR adds a test to ensure deterministic ordering in `.mod` files. It
also includes related changes to prevent non-deterministic symbol
ordering caused by pointers outside the cooked source. This issue is
particularly noticeable when using Flang as a library and compiling the
same files multiple times.
When harvesting and formatting symbols USE'd from other modules, don't
emit USE statements to module files for names unless they come from the
topmost scope of the module. There was a check to prevent names from
derived type scopes from escaping in this way, but it must be made more
general to prevent other cases like dummy arguments in interfaces.
Fixes https://github.com/llvm/llvm-project/issues/124716.
An assertion in module file generation didn't allow for a case that has
arisen in a test; remove it, extend commentary, and add a regression
test.
Fixes https://github.com/llvm/llvm-project/issues/123534.
Instead of "Cannot read ...", distinguish true errors in finding and
parsing module files from problems with unexpected hash codes by using
"Cannot parse" or "Cannot use" wording as appropriate.
`ModFileReader::Say()` flags all messages as errors, but Flang was
mistakenly suppressing two errors when the `-w` flag was used, as they
were incorrectly conditioned to warning suppression. This fix ensures
that errors are reported regardless of the `-w` flag.
This commit also replaces two uses of `_warn_en_US` with `_err_en_US` to
prevent potential confusion in the future.
(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().
A recent fix to the emission of derived type names to module files
exposed a regression in the case of a derived type that (1) has the same
name as a generic procedure interface and (2) has undergone renaming
through USE association before (3) being used in a declaration
significant to a module procedure interface. Fix.
Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such references would
resolve to symbols in the enclosing scope.)
This change causes the symbols for the type parameters to be created
when the TYPE statement is processed in name resolution. They are
TypeParamDetails symbols with no KIND/LEN attribute set, and they shadow
any symbols of the same name in the enclosing scope.
When the type parameter declarations are processed, the KIND/LEN
attributes are set. Any earlier reference to a type parameter with no
KIND/LEN attribute elicits an error.
Some members of TypeParamDetails have been retyped &/or renamed.
Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their module files with USE statements and special comments with hash
codes in them to ensure that those USE statements resolve to the same
modules that were used to build the module when its module file was
generated.
This scheme prevents unchecked module file growth in large applications
by not emitting USE-associated symbols redundantly. This problem can be
especially bad when derived type definitions must be repeated in the
module files of their clients, and the clients of those modules, and so
on. However, this scheme has the disadvantage that clients of modules
must be compiled with dependent modules in the module search path.
This new -fhermetic-module-files option causes module file output to be
free of dependences on any non-intrinsic module files; dependent modules
are instead emitted as part of the module file, rather than being
USE-associated. It is intended for top level library module files that
are shipped with binary libraries when it is not convenient to collect
and ship their dependent module files as well.
Fixes https://github.com/llvm/llvm-project/issues/97398.
https://github.com/llvm/llvm-project/pull/93106 introduced some
necessary fixes to module file generation, but has also caused a
regression. The module file output can include bogus attempts to
USE-associate symbols local to derived type scopes, like components and
bindings. Fix, and extend a test.
When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for it -- either with a name that is already available via USE
association with renaming, or by means of a new private USE association,
possibly with renaming to avoid a clash.
Module file output was dealing properly with names of derived types, but
wasn't accounting for symbols that appear in expressions other than
initializations. This was specifically a problem with an application
module that had a call to a NOPASS type-bound procedure in an array
bound specification expression, which semantics had resolved to the name
of a private module function.
This patch implements renaming, when necessary, for all symbols
appearing in expressions and type names, and replaces the previous
implementation of derived type renaming. It also gets a little smarter
about avoiding the creation of compiler-generated names when a name from
another module has been brought into scope already by means of USE
association with renaming.
This option is a compilation action that parses a source file and
performs semantic analysis on it, like the existing -fdebug-unparse
option does. Its output, however, is preceded by the effective contents
of all of the non-intrinsic modules on which it depends but does not
define, transitively preceded by the closure of all of those modules'
dependencies.
The output from this option is therefore the analyzed parse tree for a
source file encapsulated with all of its non-intrinsic module
dependencies. This output may be useful for extracting code from large
applications for use as an attachment to a bug report, or as input to a
test case reduction tool for problem isolation.
…Warn()
Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.
A sanity CHECK() in mod-file.cpp needs to allow for USE association of a
derived type that has the same name as a locally defined generic
interface.
Fixes https://github.com/llvm/llvm-project/issues/90192.
Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculation of its
value is deferred until it is needed so that the effects of
-fdefault-integer-8 or -fdefault-real-8 are reflected. Emit a warning
when NUMERIC_STORAGE_SIZE is used from the module file and the default
integer and real sizes do not match.
Fixes https://github.com/llvm/llvm-project/issues/87476.
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.
f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the following contents.
This hash is currently used only to protect module files against
corruption and truncation.
Extend the use of these hashes to catch or avoid some error cases. When
one module file depends upon another, note its hash in additional module
file header comments. This allows the compiler to detect when the module
dependency is on a module file that has been updated. Further, it allows
the compiler to find the right module file dependency when the same
module file name appears in multiple directories on the module search
path.
The order in which module files are written, when multiple modules
appear in a source file, is such that every dependency is written before
the module(s) that depend upon it, so that their hashes are known.
A warning is emitted when a module file is not the first hit on the
module file search path.
Further work is needed to add a compiler option that emits (larger)
stand-alone module files that incorporate copies of their dependencies
rather than relying on search paths. This will be desirable for
application libraries that want to ship only "top-level" module files
without needing to include their dependencies.
Another future work item would be to admit multiple modules in the same
compilation with the same name if they have distinct hashes.
When a generic procedure interface, either declared or the result of
merging two use-associated generics, has two specific procedures
that are not distinguishable according to the rules in F'2023
subclause 15.4.3.4.5, emit a portability warning rather than a
hard error message. The rules in that subclause are not adequate
to detect pairs of specific procedures that admit an ambiguous
reference, as demonstrated by a case that arose in pFUnit. Further,
these distinguishability checks, even if sufficient to the task
of detecting pairs of specifics capable of ambiguous references,
should only apply to pairs where *every* reference would have to
be ambiguous -- and this can and is validated at every reference
anyway. Last, only XLF enforces these incomplete and needless
distinguishability rules -- every other compiler seems to just
check that each procedure reference resolves to exactly one
specific procedure.
If the standard were to complete lose subclause 15.4.3.4.5 and
its related note (C.11.6) -- which admits that the rules are
incomplete! -- and simply require that each generic procedure
reference resolve unambiguously to exactly one specific, nobody
would miss them. This patch changes this compiler to give them
lip service when requested, but they are now otherwise ignored.
Fortran allows the name of a generic interface to be the same as the
name of a derived type or specific procedure. When this happens, it
causes the code in module file generation to miss the symbol of a
derived type when scanning for symbols in initialization expressions
that need to be imported. Fix.
Procedure interfaces emitted to module files are including IMPORT
statements for some symbols that don't need to be imported (base types
and procedure interfaces for components of imported derived types) and
omitting others (procedure interfaces for bindings in locally-defined
derived types that are material to the interface).
... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the current module.
This came up in a test with a derived type component default initializer
of "c_null_ptr", which is replaced with the expression
"__builtin_c_ptr(address=0_8)"; the derived type name "__builtin_c_ptr"
is not available in the current scope, and the module file would fail
semantic analysis when USE'd.
The best solution that I found was to extend module file generation to
detect this case and handle it by inserting the right USE association to
the ultimate derived type symbol, possibly with renaming to a
compiler-created name in the case of a conflict.
To implement this transformation, it was necessary to fix the utility
evaluate::CollectSymbols() to include the derived type symbol from a
structure constructor. This involved extending the expression traversal
framework to visit the derived type spec of a structure constructor.
Extending CollectSymbols() caused a lowering test to fail mysteriously,
so I tracked down the code in PFTBuilder that didn't expect to see a
DerivedTypeDetails symbol and dealt with it there.
Name resolution creates symbols for submodules in their parents' scopes.
This can lead to bogus errors about name clashes between submodule names
and other entities in the parents' scopes.
Create symbols for submodules but do not add them to a scope's
dictionary.
If it happens that a symbol has an implicit SAVE attribute,
we have to omit it in the mod file writer. Otherwise it may
violate F202X C862:
The SAVE attribute shall not be specified for... an object that is
in a common block.
This patch propagates the acc routine information
to the module file so they can be used by the caller.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158541
Name resolutions defers all resolution and checking of specific procedures
in non-type-bound generic interfaces to the end of the specification part.
This prevents expression analysis of references to generic functions in
specification expressions in interfaces from resolving.
Example (now a new test case in modfile07.f90):
```
module m12
interface generic
module procedure specific
end interface
interface
module subroutine s(a1,a2)
character(*) a1
character(generic(a1)) a2 ! <--
end
end interface
contains
pure integer function specific(x)
character(*), intent(in) :: x
specific = len(x)
end
end
```
The solution is to partially resolve specific procedures as they are
defined for each generic, when they can be resolved, with the final
pass at the end of the specification part to finish up any forward
references and emit the necessary error messages.
Making this fix caused some issues in module file output, which have
all been resolved by making this simplifying change: generics are
now all emitted to module file specification parts as their own
group of declarations at the end of the specification part,
followed only by namelists and COMMON blocks.
Differential Revision: https://reviews.llvm.org/D157346
Distinguish between copyin and copyin with the readonly modifier.
Depends on D157121
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157125
OpenACC and OpenMP directive are
emitted in the module file. Just reorganized the code
so this is well separated and do not pollute the main
Fortran part.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157143
F18 produce a module file with a declaration part. This patch
propagates the OpenACC declare information in the module file along the variable
declaration.
Depends on D157042
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157121
Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=. Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.
Differential Revision: https://reviews.llvm.org/D145107
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
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
