I changed the set of files that are built for experimental CUDA/OMP
builds, i.e. the files with enabled device support are built
as such and the rest of the files are built just for the host target.
With this change we can build Flang runtime library that is fully functional
on the host target, so in-tree targets like check-flang become operational.
Reviewed By: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D155029
OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
wasn't allowing ENCODING= to be changed. Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)
Differential Revision: https://reviews.llvm.org/D154379
We intentionally process NAMELIST groups in a scope after having
resolved all of the names in that scope. This means that a name
whose first appearance in a scope is in the NAMELIST group resolves
to a local object, if any, rather than to any host associated object.
The standard is unclear on this point, and there is no clear
precedent in other compilers.
This patch doesn't implement this choice -- that was done long ago --
but just documents the behavior in Extensions.md.
Differential Revision: https://reviews.llvm.org/D154375
Add a document that summarizes Fortran 202X's upcoming
features and their urgency for implementation.
Differential Revision: https://reviews.llvm.org/D153916
Some compiler treat `acc routine` without a parallelism clause as
if seq is present. Relax the parser rule to allow acc routine
without clause. The default clause will be handled in lowering.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D153896
These are initial changes to experiment with building the Fortran runtime
as a CUDA or OpenMP target offload library.
The initial patch defines a set of macros that have to be used consistently
in Flang runtime source code so that it can be built for different
offload devices using different programming models (CUDA, HIP, OpenMP target
offload). Currently supported modes are:
* CUDA: Flang runtime may be built as a fatlib for the host and a set
of CUDA architectures specified during the build. The packaging
of the device code is done by the CUDA toolchain and may differ
from toolchan to toolchain.
* OpenMP offload:
- host_device mode: Flang runtime may be built as a fatlib for the host
and a set of OpenMP offload architectures. The packaging
of the device code is done by the OpenMP offload compiler and may differ
from compiler to compiler.
OpenMP offload 'nohost' mode is a TODO to match the build setup
of libomptarget/DeviceRTL. Flang runtime will be built as LLVM Bitcode
library using Clang/LLVM toolchain. The host part of the library
will be "empty", so there will be two distributable object: the host
Flang runtime and dummy host library with device Flang runtime pieces
packaged using clang-offload-packager and clang.
In all supported modes, enabling parts of Flang runtime for the device
compilation can be done iteratively to make the patches observable.
Note that at any point in time the resulting library may have unresolved
references to not yet enabled parts of Flang runtime.
Example cmake/make commands for building with Clang for NVPTX target:
cmake \
-DFLANG_EXPERIMENTAL_CUDA_RUNTIME=ON \
-DCMAKE_CUDA_ARCHITECTURES=80 \
-DCMAKE_C_COMPILER=/clang_nvptx/bin/clang \
-DCMAKE_CXX_COMPILER=/clang_nvptx/bin/clang++ \
-DCMAKE_CUDA_COMPILER=/clang_nvptx/bin/clang \
/llvm-project/flang/runtime/
make -j FortranRuntime
Example cmake/make commands for building with Clang OpenMP offload:
cmake \
-DFLANG_EXPERIMENTAL_OMP_OFFLOAD_BUILD="host_device" \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DFLANG_OMP_DEVICE_ARCHITECTURES="sm_80" \
../flang/runtime/
make -j FortranRuntime
Differential Revision: https://reviews.llvm.org/D151173
When `AssignOp` is used with LHS that is a compiler generated temporary
special care must be taken to initialize the temporary and avoid
finalizations of its components. This change-set adds optional
`temporary_lhs` attribute for `AssignOp` to convey this information
to HLFIR-to-FIR conversion pass. Currently, this results in
calling `AssignTemporary` runtime for doing the assignment.
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D152482
Make the keyword `loop` optional for the end driective on combined
construct. This done to extend compatibility with other compiler that
allow this.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D151856
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols, including implicitly typed
names from NAMELIST groups and specification expressions in module subprograms,
have been created in its scope.
Fixes https://github.com/llvm/llvm-project/issues/62598.
Differential Revision: https://reviews.llvm.org/D150307
Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.
This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149877
They don't convey any useful information and make the documentation
unnecessarily hard to read.
Differential Revision: https://reviews.llvm.org/D149641
This reverts commit 876df74dd4.
My understanding (based on https://reviews.llvm.org/D149429) is that
this patch has caused all of Flang's buildbots to fail. I'm not really
able to verify 100% as the buildbot UI is incredibly slow ATM. I am
reverting either way so that we can discuss the right solution offline.
Add --undefined=_QQmain to the link line, so that a Fortran main program
will be included in the link job even if it is in an archive (unless we
are building a shared object). For now, this is only applied to the Gnu
toolchain.
We also add a section on the linker invocation to docs/FlangDriver.md.
The new tests require llvm-ar to construct an archive we can include in
the link job. This is a new dependency for flang/test (which already
depends on similar tools such as llvm-objdump).
See discussions in
https://github.com/llvm/llvm-project/issues/54787
which this patch fixes.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D134821
Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148254
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
Update the design document to reflect the actual implementation
of polymorphic entities.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D147665
The extents, if any, of the HARVEST= actual argument must be known
at execution time for the call to be implemented.
Differential Revision: https://reviews.llvm.org/D147391
When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some other compilers) emit a portability
warning when the names all resolve to the same symbol.
Differential Revision: https://reviews.llvm.org/D147388
Add an entry to the Extensions document describing how we
don't care about conflicts between module names and non-global
items. (This is a case where it would be a nontrivial amount
of work to catch an "error" that is only a standard conformance
issue, not anything that would prevent a program from working.)
Differential Revision: https://reviews.llvm.org/D147387
Flang was missing value normalization for logical<->integer conversions
which is required by Flang specification. The shrinking logical<->logical
conversions were also incorrectly truncating the input.
This change performs value normalization for all logical<->integer
conversions and logical<->logical conversions between different kinds.
Note that value normalization is not strictly required for
logical(kind=k1)->logical(kind=k2) conversions when k1 < k2.
Differential Revision: https://reviews.llvm.org/D147019
Presently, semantics doesn't check for discrepancies between known
constant corresponding LEN type parameters between the declared type
of an allocatable/pointer and either the type-spec or the SOURCE=/MOLD=
on an ALLOCATE statement.
This allows discrepancies between character lengths to go unchecked.
Some compilers accept mismatched character lengths on SOURCE=/MOLD=
and the allocate object, and that's useful and unambiguous feature
that already works in f18 via truncation or padding. A portability
warning should issue, however.
But for mismatched character lengths between an allocate object and
an explicit type-spec, and for any mismatch between derived type
LEN type parameters, an error is appropriate.
Differential Revision: https://reviews.llvm.org/D146583
Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.
Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.
Differential Revision: https://reviews.llvm.org/D146576
This operation will be used to transform MATMUL(TRANSPOSE(a), b). The
transformation will go in the following stages:
1. Lowering to hlfir.transpose and hlfir.matmul
2. Canonicalise to hlfir.matmul_transpose
3. hlfir.matmul_transpose will be lowered to FIR as a new runtime
library call
Step 2 (and this operation) are included for consistency with the other
hlfir intrinsic operations and to avoid mixing concerns in the intrinsic
lowering pass.
In step 3, a new runtime library call is used because this operation is
most easily implemented in one go (the transposed indexing actually
makes the indexing simpler than for a normal matrix multiplication). In
the long run, it is intended that HLFIR will allow the same buffer
to be shared between different runtime calls without temporary
allocations, but in this specific case we can do even better than that
with a dedicated implementation.
This should speed up galgel from SPEC2000 (but this hadn't been tested
yet). The optimization was implemented in Classic Flang.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D145957
Without this change the problem is that flangOmpReport and
flangPrintFunctionNames libraries are not built under 'all',
but they are imported targets via LLVMExports.cmake so that
any out-of-tree build that configures upon LLVM+Flang package
will get this CMake error:
```
The imported target "flangPrintFunctionNames" references the file
".../lib/flangPrintFunctionNames.so"
but this file does not exist.
```
flang-aarch64-out-of-tree buildbot (https://lab.llvm.org/buildbot/#/builders/175)
does not catch this issue, because it does not enable Flang on the first stage.
This change gets rid of FLANG_BUILD_EXAMPLES in favor of LLVM_BUILD_EXAMPLES
and uses available LLVM CMake macros to add example executables/libraries.
Differential Revision: https://reviews.llvm.org/D145992
Some Fortran compilers allow kinds of LOGICAL other than C_BOOL
for the types of dummy arguments to interoperable (BIND(C))
procedures. As any kind of LOGICAL can be converted to any
other without loss of information, this seems to be a useful
unambiguous extension that is attested in real codes; accept it
for scalars with a portability warning.
Differential Revision: https://reviews.llvm.org/D145968
Declaration checking in semantics was only examining symbols with
explicit BIND(C) attributes; extend it to also check dummy arguments
to such procedures.
Differential Revision: https://reviews.llvm.org/D145746
As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON blocks from specification expressions
before an explicit type-declaration-stmt appears for those variables
under IMPLICIT NONE, so long as those variables are later explicitly typed
with the types that regular implicit typing rules would have given them
(usually default INTEGER).
F18 implemented this extension for dummy arguments, but not variables in
COMMON blocks. Extend the extension to also accept variables in COMMON.
Differential Revision: https://reviews.llvm.org/D145743
The Fortran 2018 standard, perhaps as an attempt to prevent ambiguity
in older compilers, requires that a statement function appear in an
explicit type declaration statement if its name is also accessible
from a host scope. F18 processes the specification parts of inner
procedures first, so we don't need this requirement to prevent
ambiguity, and can only really check it retrospectively after name
resolution. Emit a portability warning when appropriate.
Differential Revision: https://reviews.llvm.org/D145100
A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.) This is implemented by applying
basic scope processing to the block level.
Name uniquing/mangling is extended to support this. The term "block" is
heavily overloaded in Fortran standards. Prior name uniquing used tag `B`
for common block objects. Existing tag choices were modified to free up `B`
for block construct entities, and `C` for common blocks, and resolve
additional issues with other tags. The "old tag -> new tag" changes can
be summarized as:
-> B -- block construct -> new
B -> C -- common block
C -> YI -- intrinsic type descriptor; not currently generated
CT -> Y -- nonintrinsic type descriptor; not currently generated
G -> N -- namelist group
L -> -- block data; not needed -> deleted
Existing name uniquing components consist of a tag followed by a name
from user source code, such as a module, subprogram, or variable name.
Block constructs are different in that they may be anonymous. (Like other
constructs, a block may have a `block-construct-name` that can be used
in exit statements, but this name is optional.) So blocks are given a
numeric compiler-generated preorder index starting with `B1`, `B2`,
and so on, on a per-procedure basis.
Name uniquing is also modified to include component names for all
containing procedures rather than for just the immediate host. This
fixes an existing name clash bug with same-named entities in same-named
host subprograms contained in different-named containing subprograms,
and variations of the bug involving modules and submodules.
F18 clause 9.7.3.1 (Deallocation of allocatable variables) paragraph 1
has a requirement that an allocated, unsaved allocatable local variable
must be deallocated on procedure exit. The following paragraph 2 states:
When a BLOCK construct terminates, any unsaved allocated allocatable
local variable of the construct is deallocated.
Similarly, F18 clause 7.5.6.3 (When finalization occurs) paragraph 3
has a requirement that a nonpointer, nonallocatable object must be
finalized on procedure exit. The following paragraph 4 states:
A nonpointer nonallocatable local variable of a BLOCK construct
is finalized immediately before it would become undefined due to
termination of the BLOCK construct.
These deallocation and finalization requirements, along with stack
restoration requirements, require knowledge of block exits. In addition
to normal block termination at an end-block-stmt, a block may be
terminated by executing a branching statement that targets a statement
outside of the block. This includes
Single-target branch statements:
- goto
- exit
- cycle
- return
Bounded multiple-target branch statements:
- arithmetic goto
- IO statement with END, EOR, or ERR specifiers
Unbounded multiple-target branch statements:
- call with alternate return specs
- computed goto
- assigned goto
Lowering code is extended to determine if one of these branches exits
one or more relevant blocks or other constructs, and adds a mechanism to
insert any necessary deallocation, finalization, or stack restoration
code at the source of the branch. For a single-target branch it suffices
to generate the exit code just prior to taking the indicated branch.
Each target of a multiple-target branch must be analyzed individually.
Where necessary, the code must first branch to an intermediate basic
block that contains exit code, followed by a branch to the original target
statement.
This patch implements an `activeConstructStack` construct exit mechanism
that queries a new `activeConstruct` PFT bit to insert stack restoration
code at block exits. It ties in to existing code in ConvertVariable.cpp
routine `instantiateLocal` which has code for finalization, making block
exit finalization on par with subprogram exit finalization. Deallocation
is as yet unimplemented for subprograms or blocks. This may result in
memory leaks for affected objects at either the subprogram or block level.
Deallocation cases can be addressed uniformly for both scopes in a future
patch, presumably with code insertion in routine `instantiateLocal`.
The exit code mechanism is not limited to block construct exits. It is
also available for use with other constructs. In particular, it is used
to replace custom deallocation code for a select case construct character
selector expression where applicable. This functionality is also added
to select type and associate constructs. It is available for use with
other constructs, such as select rank and image control constructs,
if that turns out to be necessary.
Overlapping nonfunctional changes include eliminating "FIR" from some
routine names and eliminating obsolete spaces in comments.
This PR makes flang emit a warning when the user passes an unsupported gfortran warning flag in as a CLI arg. This PR also checks each `-W` argument instead of just looking at the last one passed in.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D143301
f18 accepts statement labels in fixed form source even if they follow
a semicolon -- i.e., they're not in the fixed form's label field.
Emit a warning for such usage.
Differential Revision: https://reviews.llvm.org/D143817
When a USE of a module precedes its definition in the same source
file, ensure that the module is processed by name resolution before
the USE statement. This prevents the risk of the USE statement using
an obsolete module file that is later overwritten during the same
compilation.
Differential Revision: https://reviews.llvm.org/D143799
f18 implements BLOCK scoping for construct names, like most but not all Fortran
compilers, but in the 2018 standard such names are defined to be local identifiers
whose scope is the inclusive scope -- i.e., the subprogram or main program.
Detect usage that depends on this extension and emit a portability warning.
Differential Revision: https://reviews.llvm.org/D143776
The implementation of -fstack-arrays was added in
https://reviews.llvm.org/D140415
The new macro BoolOptionWithoutMarshalling in Options.td avoids
generating code to store the flags in clang data structures. For
example, writing something like
defm stack_arrays : BoolOption<"f", "stack-arrays",
CodeGenOpts<"StackArrays">, [...]
Would generate code referring to `clang::CodeGenOpts::StackArrays`, which
does not exist.
Differential Revision: https://reviews.llvm.org/D140972
The standard's specification for the ASSOCIATED() intrinsic function
describes its optional second argument (TARGET=) as being required
to be a valid target for a pointer assignment statement in which the
first argument (POINTER=) was the left-hand side. Some Fortran compilers
apparently interpret this text as a requirement that the POINTER= argument
actually be a valid left-hand side to a pointer assignment statement,
and emit an error if it is not so. This particularly affects the
use of an explicit NULL pointer as the first argument.
Such usage is well-defined, benign, useful, and supported by at least
two other compilers, so we should continue to accept it. This patch
adds a portability warning and some documentation.
In order to implement the portability warning in the best way, the
special checks on calls to the ASSOCIATED() intrinsic function have
been moved from intrinsic processing to Semantics/check-calls.cpp,
whence they have access to semantics' toolchest. Special checks for
other intrinsic functions might also migrate in the future in order
to keep them all in one place.
Differential Revision: https://reviews.llvm.org/D142768
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
