This document aims to give insights at the representation of polymorphic
entities in FIR and how polymorphic related constructs and features are lowered
to FIR.
Reviewed By: klausler, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131515
Add stopped_images to the list of intrinsic functions. Add a
semantics test for stopped_images.
Reviewed By: klausler, ngeorge1098
Differential Revision: https://reviews.llvm.org/D129513
Currently, FlangOptionsDocs.td doesn't specify `ExcludedFlags` which
means that in the generated documentation file we expose flags that:
* we don't necessarily won't to advertise to our users (e.g. hidden flags), or
* are not supported altogether (e.g. CL options).
This patch defines `ExcludeFlags` to fix that. The definition of
`ExcludeFlags` was copied from Clang so that LLVM frontends have
consistent documentation.
It might be a bit counter-intuitive that IncludeFlags alone is not
sufficient here. However, the current logic in ClangOptionDocEmitter.cpp
will parse IncludeFlags and print all options that contains one of the
included flags, as well as their aliases. So, for example, for -fopenmp
(which is a supported Flang option), one would also get /fopenmp (i.e.
CL mode equivalent for -fopenmp). By adding ExcludeFlags, we make sure
that such aliases are excluded.
I've also taken the liberty and moved FlangOptionsDocs.td. Originally it
was located in Flang's "flang/include" directory, but there shouldn't be
any implementation/documentation files there. Instead, I'm moving it to
the "flang/docs" directory.
Differential Revision: https://reviews.llvm.org/D130558
The options -f{no-}color-diagnostics have been supported in driver. This
supports the behaviors in scanning, parsing, and semantics, and the
behaviors are exactly the same as the driver.
To illustrate the added behaviour, consider the following input file:
```! file.f90
program m
integer :: i = k
end
```
In the following invocations, "error: Must be a constant value" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```
Note that "error: Semantic errors in file.f90" is also formatted, which
is supported in https://reviews.llvm.org/D126164.
Also note that only "error", "warning" and "portability" are formatted.
Check the following input file:
```! file2.f90
program m
integer :: i =
end
```
```
$ flang-new test2.f90
error: Could not parse test2.f90
./test2.f90:2:11: error: expected '('
integer :: i =
^
./test2.f90:2:3: in the context: statement function definition
integer :: i =
^
...
```
The "error: Could not parse test2.f90" and "error: expected '('" are
formatted. Others such as "in the context" are not formatted yet, which
may or may not be supported.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D126166
f18 intentionally does not support the spottily-implemented language extension
in which one can pass NULL() for an allocatable dummy argument. This is perhaps
a sanctioned side effect in other compilers of the fact that they pass distinct
"base address" and "descriptor address" physical arguments.
Make the error message in this case more specific to the circumstances, and
add a note to Extensions.md to clarify that this behavior is intended.
(We could, with some effort in lowering, support passing NULL for an INTENT(IN)
allocatable dummy, but let's see whether such nonconforming usage appears
in a real application before spending any more time on it.)
Differential Revision: https://reviews.llvm.org/D130380
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Note:
Some headings in the generated documentation will incorrectly
contain references to Clang, e.g.
"Flags controlling the behaviour of Clang during compilation"
This is because Options.td (Which is shared between both Clang and Flang)
contains hard-coded DocBrief sections. I couldn't find a non-intrusive way
to make this target-dependant, as such I've left this as is, and it will need revisiting later.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Describe the built-in integer, real, complex and logical
types implemented in flang, capturing the as-implemented
characteristics.
Differential Revision: https://reviews.llvm.org/D129658
In D129186, CreateFIRLangRef.py was created to help fix
formatting problems with FIRLangRef.md.
However, due to an error while rebasing, the last edit was lost,
as such the current path variables are Unix-style.
This patch addresses what was discussed in the previous patch and
now uses os.path.join instead.
Differential Revision: https://reviews.llvm.org/D129644
Previously, FIRLangRef.md was incorrectly formatted.
This was due to how FIRLangRef.md had no page header,
and so the first entry would render incorrectly.
This patch introduces a header file, which is prepended to the FIRLangRef
before it becomes a HTML file. The header is currently brief
but can be expanded upon at a later date if required.
This formatting fix also means the index page
can correctly generate a link to FIRLangRef.html and as such,
this patch also removes FIRLangRef from the sidebar and adds it to the main list of links.
Depends on D128650
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D129186
The Fortran Language Reference is currently generated via tablegen,
however isn't present on flang.llvm.org/docs/
This patch adds FIRLangRef.md to the flang/docs directoy,
and adds a link to the generated HTML file in sidebar
under the 'Documentation' heading.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D128650
In free form source, pedantic mode will elicit portability warnings
about missing spaces when a token string ends with a character that
can be in an identifier and there is no space between that last token
character and a following character that can also be part of an identifier.
This behavior doesn't really work well for the token strings that are
parsed for edit descriptors in FORMAT statements. For example, the
'F' in FORMAT(F7.3) is followed by a digit, but obviously no space is
necessary. Free form or not, FORMATs are their own odd little world.
This patch adds trailing blanks to these FORMAT edit descriptor token
parsers to disable the missing space check, and extends the documentation
for token string parsing to explain why this technique works.
Differential Revision: https://reviews.llvm.org/D129023
In, https://reviews.llvm.org/D120305, CLANG_DEFAULT_PIE_ON_LINUX was set
to `On` by default. However, neither `-fpie` nor `-fpic` are currently
supported in LLVM Flang. Hence, in this patch the behaviour controlled
with CLANG_DEFAULT_PIE_ON_LINUX is refined not to apply to Flang.
Another way to look at this is that CLANG_DEFAULT_PIE_ON_LINUX is
currently affecting both Clang and Flang. IIUC, the intention for this
CMake variable has always been to only affect Clang. This patch makes
sure that that's the case.
Without this change, you might see errors like this on X86_64:
```
/usr/bin/ld: main.o: relocation R_X86_64_32 against `.bss' can not be used when making a PIE object; recompile with -fPIC
```
I've not experienced any issues on AArch64. That's probably because on
AArch64 some object files happen to be position independent without
needing -fpie or -fpic.
Differential Revision: https://reviews.llvm.org/D128333
The prescanner does not support VMS Fortran listing control directives
(%LIST, %NOLIST, %EJECT) or continuation lines on INCLUDE lines.
Differential Revision: https://reviews.llvm.org/D127791
Add failed_images to the list of intrinsic functions. Add a
semantics test for failed_images.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D126805
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
Valentin Clement