The restrictions on the relationship between a "kP" scale factor
and a Ew.d/Dw.d/Gw.d significant digit count are not enforced for
output editing when there is no nonzero scale factor in effect.
(An error message about a bad scale factor is confusing if no kP
control edit descriptor has been used.) Document this usage in
Extensions.md.
Differential Revision: https://reviews.llvm.org/D127435
This is a follow-up of https://reviews.llvm.org/D125832
(see also https://reviews.llvm.org/D125788 for more context). It simply
removes any remaining references to the `flang` bash script. Note that
that `flang-to-external-fc` remains intact.
This felt worthwhile mentioning in the release notes, which have not
been updated since LLVM 12 (we are approaching LLVM 15 now). I took the
liberty of removing all of the out-dated content and added a note about
the renaming.
Differential Revision: https://reviews.llvm.org/D127094
When running the llvm-test-suite with flang, we get a lot of failures
because of the output of the `STOP` statement. We can workaround them by
setting `NO_STOP_MESSAGE=1` in the environment. This patch adds a few
words about it to the docs about the Fortran part of the llvm-test-suite.
See also https://reviews.llvm.org/D126360
F18 doesn't accept INTEGER operands to the intrinsic LOGICAL operations;
some compilers do. This usage is not portable, and not just because it's
non-conforming -- the bit representations of LOGICAL also vary between
compilers and options. The "MIL-STD" bit intrinsics IAND() & al. have been
avaiable since the late 70's and should be used instead.
Differential Revision: https://reviews.llvm.org/D126798
As an extension for REAL literals, we allow an exponent letter which
matches an explicit kind-param. The standard requires the exponent
to be 'E' if a kind-param is present. This patch
- documents this extension in Extensions.md
- enables a portability warning if it is used with -pedantic
The test case for this, kinds05.f90, needs D125804, which makes
test_errors.py test warnings as well, to actually test the warnings.
I include it already now to keep things together, it will do no harm
(I hope ...).
We also add WARNING-directives to the test kinds04.f90 in preparation
for D125804. As the exponent-letter 'Q' does not imply the same kind
on all platforms, the emitted warnings are platform-dependent.
Therefore, the test is duplicated into two variants which are run
conditionally.
Finally, we promote the portability warning for when the exponent letter
is neither 'E' nor matching the kind-param to a standard warning.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126459
When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
Notes from the Flang Biweekly Sync calls have been merged into the same document as the notes from the Flang Technical calls. This patch updates the link in the GettingInvolved document to point to the new location.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D124689
Semantics is not preventing a named common block to appear with
different size in a same file (named common block should always have
the same storage size (see Fortran 2018 8.10.2.5), but it is a common
extension to accept different sizes).
Lowering was not coping with this well, since it just use the first
common block appearance, starting with BLOCK DATAs to define common
blocks (this also was an issue with the blank common block, which can
legally appear with different size in different scoping units).
Semantics is also not preventing named common from being initialized
outside of a BLOCK DATA, and lowering was dealing badly with this,
since it only gave an initial value to common blocks Globals if the
first common block appearance, starting with BLOCK DATAs had an initial
value.
Semantics is also allowing blank common to be initialized, while
lowering was assuming this would never happen, and was never creating
an initial value for it.
Lastly, semantics was not complaining if a COMMON block was initialized
in several scoping unit in a same file, while lowering can only generate
one of these initial value.
To fix this, add a structure to keep track of COMMON block properties
(biggest size, and initial value if any) at the Program level. Once the
size of a common block appearance is know, the common block appearance
is checked against this information. It allows semantics to emit an error
in case of multiple initialization in different scopes of a same common
block, and to warn in case named common blocks appears with different
sizes. Lastly, this allows lowering to use the Program level info about
common blocks to emit the right GlobalOp for a Common Block, regardless
of the COMMON Block appearances order: It emits a GlobalOp with the
biggest size, whose lowest bytes are initialized with the initial value
if any is given in a scope where the common block appears.
Lowering is updated to go emit the common blocks before anything else so
that the related GlobalOps are available when lowering the scopes where
common block appear. It is also updated to not assume that blank common
are never initialized.
Differential Revision: https://reviews.llvm.org/D124622
This patch adds a few new member methods in the `PluginParseTreeAction`
frontend action base class. With these new methods, the plugin API
becomes independent of the driver internals. In particular, plugin
writers no longer require the `CompilerInstance.h` header file to access
various driver data structures (instead, they can use newly added
hooks).
This change is desirable as `CompilerInstance.h` includes various
headers from Clang (both explicitly and implicitly). Some of these
header files are generated at build time (through TableGen) and
including them creates a dependency on some of Clang's build targets.
However, plugins in Flang should not depend on Clang build targets.
Note that plugins might still work fine most of the time, even without
this change and without adding Clang build targets as dependency in
plugin's CMake definition. Indeed, these Clang build targets are often
generated early in the build process. However, that's not guaranteed and
we did notice that on occasions plugins would fail to build.
Differential Revision: https://reviews.llvm.org/D120999
To avoid clashing with names of user derived types, the redundant
syntax TYPE(intrinsic type spec) must be interpreted as a monomorphic
derived type when "intrinsic type spec" is a single word. This
affects TYPE(BYTE) and TYPE(DOUBLECOMPLEX), but not TYPE(DOUBLE COMPLEX)
in free form source.
Differential Revision: https://reviews.llvm.org/D123724
Support the names AND, OR, and XOR for the generic intrinsic
functions IAND, IOR, and IEOR respectively.
Differential Revision: https://reviews.llvm.org/D122034
LBOUND must return 1 for an empty dimension, no matter what
explicit expression might appear in a declaration or arrive in
a descriptor.
Differential Revision: https://reviews.llvm.org/D121488
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
The standard explicitly allows a comma to be omitted between a 'P'
edit descriptor and a following numeric edit descriptor (e.g., 1PE10.1),
and before and after a '/' edit descriptor, but otherwise requires them
between edit descriptors. Most implementations, however, only require
commas where they prevent ambiguity, and accept things like 1XI10.
This extension is already assumed by the static FORMAT checker in
semantics. Patch the runtime to behave accordingly.
Differential Revision: https://reviews.llvm.org/D120747
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
Implements a near-universal extension in which NAMELIST
input will skip over unrelated namelist groups in the
input stream until the group with the requested name appears.
Differential Revision: https://reviews.llvm.org/D117843
Consistent with previously documented policy, in which
BOZ literals are accepted in non-standard-conforming circumstances
where they can be converted to an unambiguous known numeric type,
allow BOZ literals to be passed as an actual argument in a reference
to a procedure whose explicit interface has a corresponding dummy
argument with a numeric type to which the BOZ literal may be
converted. Improve error messages associated with BOZ literal
actual arguments, too: don't emit multiple errors.
Differential Revision: https://reviews.llvm.org/D117698
Very old (pre-'77 standard) codes would use arrays initialized
with Hollerith literals, typically in DATA, as modifiable
formats.
Differential Revision: https://reviews.llvm.org/D117344
Derived types with SEQUENCE must have data components of sequence
types; but this rule is relaxed as common an extension in the case of
pointer components, whose targets' types are not really relevant
to the implementation requirements of sequence types.
Differential Revision: https://reviews.llvm.org/D117158
It's not conforming to specify the SAVE attribute more than
once for a variable, but it also doesn't hurt anything and
isn't fatal in other Fortran compilers. Downgrade the
message to a warning for better portability.
Differential Revision: https://reviews.llvm.org/D117153
This is nonconformant usage, but widely accepted as an extension.
Downgrade the error message to a warning.
Differential Revision: https://reviews.llvm.org/D117152
We already accept assignments of INTEGER to LOGICAL (& vice versa)
as an extension, but not initialization. Extend initialization
to cover those cases.
(Also fix misspelling in nearby comment as suggested by code reviewer.)
Decouple an inadvertent dependence cycle by moving two
one-line function definitions into a header file.
Differential Revision: https://reviews.llvm.org/D117159
Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.
These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.
Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.
This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.
Differential Revision: https://reviews.llvm.org/D117151
RECL= is required for direct access I/O, but is permitted
as well for sequential I/O, where it is defined by the
standard to specify a maximum record (line) length.
The standard does not say what should happen when an
sequential formatted input record appears whose length is
unequal to RECL= when it is specified.
Precedents from other compilers are unclear: one raises an error,
some honor RECL= as an effective truncation, and a few ignore the
situation. On output, all other compilers tested raised an
error when an attempt is made to emit a record longer than RECL=.
This patch treats RECL= as effective truncation on input and
as a hard limit with error on output, and also ensures that
RECL= can be set *longer* than the actual input record lengths.
Differential Revision: https://reviews.llvm.org/D115102
[NFC] As part of using inclusive language within the llvm project, this patch:
- replaces master with main in C++style.md to match the renaming of the master
branch,
- removes master from `FortranIR.md` where it is superfluous,
- renames a logical variable in `pre-fir-tree04.f90` containing master.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D113923
This is a near-universal language extension; external unit 0
is preconnected to the standard error output.
Differential Revision: https://reviews.llvm.org/D114298
Please note that the updated documentation reflects the design that we are
working towards, but haven't implemented competely yet. We took this approach
in order to provide a more holisitic and complete overview of the design.
In particular, this document assumes that Flang's frontend and compiler
driver can already generate code. This is still work-in-progress and is
being developed on the `fir-dev` branch in the F18 repository [1].
[1] https://github.com/flang-compiler/f18-llvm-project/tree/fir-dev
Differential Revision: https://reviews.llvm.org/D111573
[NFC] As part of using inclusive language within the llvm project,
this patch replaces master with main when referring to `.chm` files.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D113299
A CHARACTER variable used as an output format may contain
unquoted tab characters, which are treated as if they had
been quoted. This is an extension supported by all other
Fortran compilers to which I have access.
Differential Revision: https://reviews.llvm.org/D112350
Don't try to convert INTEGER argument expressions to the kind of
the dummy argument when performing generic resolution; specific
procedures may be distinguished only by their kinds.
Differential Revision: https://reviews.llvm.org/D112240
Allocatable dummy arguments can be used to distinguish
two specific procedures in a generic interface when
it is the case that exactly one of them is polymorphic
or exactly one of them is unlimited polymorphic. The
standard requires that an actual argument corresponding
to an (unlimited) polymorphic allocatable dummy argument
must also be an (unlimited) polymorphic allocatable, so an
actual argument that's acceptable to one procedure must
necessarily be a bad match for the other.
Differential Revision: https://reviews.llvm.org/D112237
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
To get proper wrap-around behavior for the various kind parameter
values of the optional COUNT= and COUNT_MAX= dummy arguments to
the intrinsic subroutine SYSTEM_CLOCK, add an extra argument to
the APIs for lowering to pass the integer kind of the actual argument.
Avoid confusion by requiring that both actual arguments have the same
kind when both are present. The results of the runtime functions
remain std::int64_t and lowering should still convert them before
storing to the actual argument variables.
Rework the implementation a bit to accomodate the dynamic
specification of the kind parameter, and to clean up some coding
issues with preprocessing and templates.
Use the kind of the COUNT=/COUNT_MAX= actual arguments to determine
the clock's resolution, where possible, in conformance with other
Fortran implementations.
Differential Revision: https://reviews.llvm.org/D111281
Add explicit documentation for a couple of cases where the Fortran
standard has been observed to be ambiguous or nonspecific and we've
had to choose the behavior of the implementation from some possible
alternatives (and may be distinct from other implementations).
Differential Revision: https://reviews.llvm.org/D111446
Support the extension intrinsic subroutines EXIT([status]) and ABORT()
in the intrinsic table and runtime support library. Lowering remains
to be done.
Differential Revision: https://reviews.llvm.org/D110741
Added 'this_image()' to the list of functions that are evaluated as intrinsic.
Added IsCoarray functions to determine if an expression is a coarray (corank > 1).
Added save attribute to coarray variables in test file, this_image.f90.
reviewers: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D108059
This reverts commit 81f8ad1769.
This seems to break the shared libs build
(linaro-flang-aarch64-sharedlibs bot) with:
undefined reference to `Fortran::semantics::IsCoarray(Fortran::semantics::Symbol const&)
(from tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/tools.cpp.o)
When linking lib/libFortranEvaluate.so.14git
Added 'this_image()' to the list of functions that are evaluated as intrinsic.
Added IsCoarray functions to determine if an expression is a coarray (corank > 1).
Added save attribute to coarray variables in test file, this_image.f90.
reviewers: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D108059
The index of an implied DO loop in a DATA statement or array
constructor is defined by Fortran 2018 to have scope over its
implied DO loop. This definition is unfortunate, because it
requires the implied DO loop's bounds expressions to be in the
scope of the index variable. Consequently, in code like
integer, parameter :: j = 5
real, save :: a(5) = [(j, j=1, j)]
the upper bound of the loop is a reference to the index variable,
not the parameter in the enclosing scope.
This patch limits the scope of the index variable to the "body"
of the implied DO loop as one would naturally expect, with a warning.
I would have preferred to make this a hard error, but most Fortran
compilers treat this case as f18 now does. If the standard
were to be fixed, the warning could be made optional.
Differential Revision: https://reviews.llvm.org/D108595
