I brought the overview document up to date and added information for
most compilation phases to dump out the reeults of the phase.
Differential Revision: https://reviews.llvm.org/D140241
Constraint C1529 requires that the base object of a type-bound procedure
reference be a scalar if the TBP has the NOPASS attribute. Most
compilers do not enforce this constraint and it does not appear to
have any implementation justification, so emit portability warning.
On the other hand, we fail to enforce C919 for references to
procedure pointer components, whose base objects must of course
be scalars in order to avoid ambiguity and empty arrays, whether
NOPASS is present or not.
Differential Revision: https://reviews.llvm.org/D140148
Most attributes apply to only object or only procedure entities,
and attempts to apply them to other kinds of symbol table entries
are caught in name resolution when ConvertToObjectEntity() or
ConvertToProcEntity() fails. However, the POINTER attribute can
be applied to both, and name resolution can't perform that conversion
yet, and as a result we don't catch many kinds of silly errors.
Fix by ensuring that the symbol is of a type that could eventually
become an object or procedure entity if it is not one already.
Differential Revision: https://reviews.llvm.org/D140137
clang -cc1 accepts -Ofast. I did not add it to flang -fc1 because this
seems redundant because the compiler driver will always resolve -Ofast
into -O3 -ffast-math (I added a test for this).
-menable-infs is removed from the frontend-forwarding test because if
all of the fast-math component flags are present, these will be resolved
into the fast-math flag. Instead -menable-infs is tested in the
fast-math test.
Specifying -ffast-math to the compiler driver causes linker invocations
to include crtfastmath.o.
RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554
Differential Revision: https://reviews.llvm.org/D138675
This supports the codegen for global procedure pointer in BoxedProcedure
pass. Reset the boxproc type.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138273
This supports the codegen for procedure pointer component in
BoxedProcedure pass. Also fix the FIR in ProcedurePointer.md so that
all the cases can be run using `tco` to generate the LLVM IR.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136842
Modules, submodules, main programs, and BLOCK DATA subprograms have names
that cannot be used within their scope, so we allow those names to be
used for other entities in the scope. This might not be entirely
conformant with the language standard, so warn about it.
Differential Revision: https://reviews.llvm.org/D139146
Standard Fortran allows type-bound procedure bindings to only
be called, and disallows them from being used in other contexts
where a procedure name can be: as the target of a procedure pointer
assignment statement, and as an actual argument that corresponds
to a dummy procedure. So long as the interfaces match, there's
no good reason for these uses to be errors, and there some obvious
use cases in polymorphic programming. So emit portability warnings
rather than errors, and document this usage as an extension.
Differential Revision: https://reviews.llvm.org/D139127
In a derived type definition, a type bound procedure declaration
statement with neither interface nor attributes is required by constraint
C768 to have the optional "::" between the PROCEDURE keyword and the
bindings if any binding has a renaming with "=>". The colons are
not actually necessary for a correct and unambiguous parse, so
emit a warning when they are missing.
Differential Revision: https://reviews.llvm.org/D139065
When checking the specific procedures of a generic interface for a
match against a given set of actual arguments, be sure to not match
a function against a subroutine call or vice versa. (We generally
catch and warn about attempts to declare mixed interfaces, but they
are usually conforming and can be inadvertently created when generics
are merged due to USE and host association.)
Differential Revision: https://reviews.llvm.org/D139059
f18 doesn't have any limit on continuation lines in fixed or free form
source (other than available memory), but the standard does. Emit
a portability warning when it is exceeded.
Differential Revision: https://reviews.llvm.org/D139055
The standard does *not* require that a real or imaginary part of a complex
literal constant be a scalar if it is a named constant. Downgrade a
recently installed check to a portability warning, and document it.
Differential Revision: https://reviews.llvm.org/D139046
The functionality of LSHIFT and RSHIFT intrinsics is the same as the
standard SHIFTL and SHIFTA intrinsics respectively. The patch is to
alias the two intrinsics to the standardized ones.
Differential Revision: https://reviews.llvm.org/D138839
After more considerations and experience, switch to one of the
alternative plan for HLFIR variable that will avoid requiring naming
designators and having to maintain and update names in attributes after
inlining of code duplication.
The cost is the increase of fir.box usage, which in most cases should
be removed when lowering from HLFIR to FIR.
Differential Revision: https://reviews.llvm.org/D137634
Pass plugins are compiled and linked dynamically by default. Setting
`LLVM_${NAME}_LINK_INTO_TOOLS` to `ON` turns the project into a
statically linked extension. Projects like Polly can be used this way by
adding `-DLLVM_POLLY_LINK_INTO_TOOLS=ON` to the `cmake` command.
The changes in this patch makes the PassBuilder in Flang aware of
statically linked pass plugins, see the documentation for more details:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/WritingAnLLVMNewPMPass.rst#id21
Differential Revision: https://reviews.llvm.org/D137673
Change-Id: Id1aa501dcb4821d0ec779f375cc8e8d6b0b92fce
This patch adds the -fpass-plugin option to flang which dynamically loads LLVM
passes from the shared object passed as the argument to the flag. The behavior
of the option is designed to replicate that of the same option in clang and
thus has the same capabilities and limitations.
Features:
Multiple instances of -fpass-plugin=path-to-file can be specified and each
of the files will be loaded in that order.
The flag can be passed to both flang-new and flang-new -fc1.
The flag will be listed when the -help flag is passed to both flang-new and
flang-new -fc1. It will also be listed when the --help-hidden flag is passed.
Limitations:
Dynamically loaded plugins are not supported in clang on Windows and are not
supported in flang either.
Addenda:
Some minor stylistic changes are made in the files that were modified to
enable this functionality. Those changes make the naming of functions more
consistent, but do not change any functionality that is not directly
related to enabling -fpass-plugin.
Differential Revision: https://reviews.llvm.org/D129156
OpenMP 5.0 adds support for the "requires" directive. This patch adds parser support for it in flang.
Differential revision: https://reviews.llvm.org/D136867
Add the atomic subroutine, atomic_xor, to the list of
intrinsic subroutines, add its last dummy argument to a check
for a coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137196
This design document proposes lowering FIR complex number operations
through the MLIR complex dialect.
Differential Revision: https://reviews.llvm.org/D134364
This document aims to give insights at the representation of procdure
pointers in FIR.
Reviewed By: PeteSteinfeld, jeanPerier, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D136840
The infrastructure in semantics that is used to check that the
left-hand sides of normal assignment statements are really definable
variables was not being used to check whether the LHSs of pointer assignments
are modifiable, and so most cases of unmodifiable pointers are left
undiagnosed. Rework the semantics checking for pointer assignments,
NULLIFY statements, pointer dummy arguments, &c. so that cases of
unmodifiable pointers are properly caught. This has been done
by extracting all the various definability checking code that has
been implemented for different contexts in Fortran into one new
facility.
The new consolidated definability checking code returns messages
meant to be attached as "because: " explanations to context-dependent
errors like "left-hand side of assignment is not definable".
These new error message texts and their attached explanations
affect many existing tests, which have been updated. The testing
infrastructure was extended by another patch to properly compare
warnings and explanatory messages, which had been ignored until
recently.
Differential Revision: https://reviews.llvm.org/D136979
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
When allocating a polymorphic entity, its type descriptor can come
from the declared type or can be provided in the allocate statement.
This patch adds lowering for allocate on polymorphic by calling
the `AllocatableInitDerived` runtime function with the correct
type descriptor. Some adaptation are made in the code generation
to accept fir.class where it is appropriate.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136426
This document describes a new HLFIR dialect with a new value type
(hlfir.expr) and some new higher level FIR operations to make lowering
to FIR more straightforward and make pattern matching of high level
Fortran concepts (array and character assignments, character operations,
and transformational intrinsics) easier in FIR.
This should allow implementing the remaining gaps in Fortran 95 features
without increasing the lowering code complexity too much, and get a
clean start for the remaining F2003 and F2018 features.
Differential Revision: https://reviews.llvm.org/D134285
Summarize current understanding of Fortran's guarantees to a compiler
(or in other words, restrictions on programs and programmers)
about aliasing.
Differential Revision: https://reviews.llvm.org/D135214
An ASSOCIATE or SELECT TYPE statement's selector whose "right-hand side" is the result
of a reference to a function that returns a pointer must be usable as a valid target
(but not as a pointer).
Differential Revision: https://reviews.llvm.org/D135211
f18 emits an error message when the same name is used in a scope
for both a procedure and a generic interface, and the procedure is
not a specific procedure of the generic interface. It may be
questionable usage, and not portable, but it does not appear to
be non-conforming by a strict reading of the standard, and many
popular Fortran compilers accept it.
Differential Revision: https://reviews.llvm.org/D135205
This reverts commit 43fe6f7cc3.
Reverting this as CI breaks.
To reproduce, run check-flang, and it will fail with an error saying
.../lib/Bye.so not found in pass-plugin.f90
Add the -fpass-plugin option to flang which dynamically loads LLVM passes from the
shared object passed as the argument to the flag. The behavior of the option is
designed to replicate that of the same option in clang and thus has the same
capabilities and limitations.
- Multiple instances of -fpass-plugin=path-to-file can be specified and each of the
files will be loaded in that order.
- The flag can be passed to both flang-new and flang-new -fc1.
Differential Revision: https://reviews.llvm.org/D129156
Add the collective subroutine, co_broadcast, to the list
of intrinsic subroutines. Add co_broadcast to the check
for coindexed objects for the first, third, and fourth dummy
arguments. Update the co_broadcast semantics test.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134786
Some Fortran compilers accept user-defined ELEMENTAL procedures as actual
arguments corresponding to (necessarily) non-ELEMENTAL dummy procedures;
most do not, and f18 is one of them. Document the fact that this is not
a supported extension.
Differential Revision: https://reviews.llvm.org/D134399
Fortran is not clear about the semantics of
```
subroutine subr
integer n = 1
block
data n/2/
end block
end subroutine
```
which could be interpreted as having two variables, each
named 'n', or as having one variable 'n' with invalid double
initialization. Precedents from existing compilers are also
in disagreement.
The most common interpretation, however, agrees with a subtle
reading of the standard: BLOCK constructs scope names that have
local specifications, and a DATA statement is a declaration
construct, not a specification construct. So this example is
*not* acceptable.
Differential Revision: https://reviews.llvm.org/D134391
This document aims to give insights at the representation of parameterized
derived-type (PDTs) in FIR and how PDTs are lowered to FIR and interact
with the runtime.
Reviewed By: jeanPerier, klausler
Differential Revision: https://reviews.llvm.org/D133096
Add the coarray intrinsic functions, lcobound and ucobound, to the
list of intrinsics. For both of these functions, add a check to
ensure that if the optional dim argument is present and statically
checkable, its value is in the inclusive range of 1 and the corank
of the coarray argument. In the semantics tests for lcobound and
ucobound, remove the XFAIL directive, add the ERROR directives and
add additional standard-conforming and non-standard conforming
calls.
Reviewed By: klausler, craig.rasmussen
Differential Revision: https://reviews.llvm.org/D126721
There are two scenarios here:
1. Standalone flang build, where we use an installed clang-tblgen
binary. We need to use find_package() to find it.
2. Combined build of clang and flang, where we want to use the
path specified in CLANG_TABLEGEN_EXE during the clang build --
however, this variable was previously not exported.
The new implementation matches what is done for mlir-tblgen.
Differential Revision: https://reviews.llvm.org/D131475
The goal of this document is to:
- Allow the community to contribute to flang design by defining the
expectations.
- Ensure there is a minimum of consistency between future design docs.
Differential Revision: https://reviews.llvm.org/D130166
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: awarzynski, clementval
Differential Revision: https://reviews.llvm.org/D130844
Support these legacy extension intrinsic functions with unambiguous
semantics in those existing compilers that support them by means
of recognizing them as aliases for standard intrinsics (IMAG) or
with simple rewrites (IZEXT, JZEXT). Note that ZEXT has different
semantics in different existing compilers, so we will not support it
due to lack of a broad unambiguous precedent.
Differential Revision: https://reviews.llvm.org/D132154
