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
A bogus error message is appearing for structure constructors containing
values that correspond to unlimited polymorphic allocatable components.
A value of any type can actually be used.
Differential Revision: https://reviews.llvm.org/D117154
As per https://github.com/flang-compiler/f18-llvm-project/issues/1344,
the `flang` bash script works fine with 4.4.19 and requiring
4.4.23 is too restrictive. Rather than keep updating the patch level,
this patch removes this particular check (so that it will only check the
major and minor versions instead).
As this is both rather straightforward and urgent, I'm merging this
without a review.
The "pad=" argument in the intrinsic function table entry for RESHAPE
has a Rank::Array constraint, and that would be fine if not for RESHAPE
already having an earlier argument that's Rank::Array. It's the only
intrinsic that has multiple Rank::Array arguments. The checking for
the Rank::Array constraint was enforcing that multiple occurrences
of it have the same rank in a call, and that's not appropriate.
Differential Revision: https://reviews.llvm.org/D117149
When preprocessing "# ARG" in function-like macro expansion,
the preprocessor needs to pop the previously-pushed '#' token
from the end of the resulting token sequence after detecting the
argument name. The code to do this was just wrong in a couple of
ways.
Differential Revision: https://reviews.llvm.org/D117148
There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.
The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
- i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D116626
When converting a fir.alloca of an array to the LLVM dialect, we used to
multiply the allocated size by all the constant factors encoded in the
array type. This is fine when the array type is converted to the element
type for the purposes of the allocation, but if it's converted to an
array type, then we might be allocating too much space. For example, for
`%2 = fir.alloca !fir.array<8x16x32xf32>, %0, %1` we would allocate
%0 * %1 * 8 * 16 * 32 x llvm.array<32 x array<16 * array<8 x f32>>>. We
really only need to allocate %0 * %1 such arrays.
This patch fixes the issue by taking note of the array type that we're
trying to allocate. It tries to match the behaviour of
LLVMTypeConverter::convertPointerLike, which returns a pointer to the
element type only when the array type doesn't have a constant interior.
We consequently only multiply with the constant factors in the array
type if the array type doesn't have a constant interior.
This has the nice side effect that it gets rid of some redundant
multiplications with the constant 1 in some cases.
Differential Revision: https://reviews.llvm.org/D116926
The `flang` wrapper script has been written in a relatively modern
version of Bash and it fails on systems with older versions. This patch
makes the script check the version of Bash being used to run it and
generates an error when unsupported version is used.
This was discussed in more detail in:
* https://github.com/flang-compiler/f18-llvm-project/issues/1344.
Many thanks to Anthony Cabrera for the suggestion and for identifying
the oldest version of Bash that we can use here.
Differential Revision: https://reviews.llvm.org/D116608
Cover more of the code paths from LLVMTypeConverter::convertPointerLike
and LLVMTypeConverter::convertSequenceType.
Differential Revision: https://reviews.llvm.org/D116927
I recently had an email exchange on flang-dev that revealed that the
documentation on how to build flang is incorrect. This update fixes
that.
Differential Revision: https://reviews.llvm.org/D116566
Currently, something like `print *, size(foo(n,m))` was rewritten
to `print *, size(foo_result_symbol)` when foo result is a non constant
shape array. This cannot be processed by lowering or reprocessed by a
Fortran compiler since the syntax is wrong (`foo_result_symbol` is
unknown on the caller side) and the arguments are lost when they might
be required to compute the result shape.
It is not possible (and probably not desired) to make GetShape fail in
general in such case since returning nullopt seems only expected for
scalars or assumed rank (see GetRank usage in lib/Semantics/check-call.cpp),
and returning a vector with nullopt extent may trigger some checks to
believe they are facing an assumed size (like here in intrinsic argument
checks: 196204c72c/flang/lib/Evaluate/intrinsics.cpp (L1530)).
Hence, I went for a solution that limits the rewrite change to folding
(where the original expression is returned if the shape depends on a non
constant shape from a call).
I added a non default option to GetShapeHelper that prevents the rewrite
of shape inquiry on calls to descriptor inquiries. At first I wanted to
avoid touching GetShapeHelper, but it would require to re-implement all
its logic to determine if the shape comes from a function call or not
(the expression could be `size(1+foo(n,m))`). So added an alternate
entry point to GetShapeHelper seemed the cleanest solution to me.
Differential Revision: https://reviews.llvm.org/D116933
See the docs in the new function for details.
I think I found every instance of this copy pasted code. Polly could
also use it, but currently does something different, so I will save the
behavior change for a future revision.
We get the shared, non-installed CMake modules following the pattern
established in D116472.
It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.
Reviewed By: beanz, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116521
This patch updates the `flang` bash scripts to differentiate between
object files provided by the user and intermediate object files
generated by the script. The latter are an "implementation detail" that
should not be visible to the end user (i.e. deleted before the scripts
exits). The former should be preserved.
Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1348
Differential Revision: https://reviews.llvm.org/D116590
This supports the following checks for THREADPRIVATE Directive:
```
[5.1] 2.21.2 THREADPRIVATE Directive
A threadprivate variable must not appear in any clause except the
copyin, copyprivate, schedule, num_threads, thread_limit, and if clauses.
```
This supports the following checks for DECLARE TARGET Directive:
```
[5.1] 2.14.7 Declare Target Directive
A threadprivate variable cannot appear in the directive.
```
Besides, procedure name and the entity with PARAMETER attribute cannot
be in the threadprivate directive. The main program name and module name
cannot be in the threadprivate directive and declare target directive.
There is no clear description or restriction about the entity with
PARAMETER attribute in OpenMP 5.1 Specification, and a warning is given.
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D114941
F18 constraint C1308 is:
For the G edit descriptor, e shall not be specified if w is zero.
For an edit descriptor such as 'G0.2E4', change the error message from:
error: Unexpected 'e' in 'G0' edit descriptor
To:
error: A 'G0' edit descriptor must not have an 'e' value
Uses the recursive type conversion implemented in D113579, D113580.
Tests check for recursive and mutually recursive types.
Note: The downstream implementation for recursive types is a bit old
and is based on a static map. This was removed while upstreaming
(https://reviews.llvm.org/D112961) based on review comments. Since
the recursive type conversion is now available in MLIR we are using
that. If this patch is accepted we can use the same in the downstream
implementation.
Part of upstreaming flang from fir-dev branch of https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D115937
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools.
Reviewed By: Ericson2314
Differential Revision: https://reviews.llvm.org/D116472
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115569
This patch adds the support for `atomic compare` in parser. The support
in Sema and CodeGen will come soon. For now, it simply eimits an error when it
is encountered.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D115561
Test a range of acceptable forms of co_max calls, including
combinations of keyword and non-keyword actual arguments of
numeric types. Also test that several invalid forms of
co_max call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113083
Test various acceptable forms of co_min calls, including
combinations of keyword and non-keyword actual arguments of
integer, real, and character types. Also test that several
invalid forms of co_min call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113077
Test a range of acceptable forms of co_reduce calls, including
combinations of keyword and non-keyword actual arguments of
numeric types. Also test that several invalid forms of
co_reduce call generate the correct error messages.
Reviewed By: kiranchandramohan, ktras, ekieri
Differential Revision: https://reviews.llvm.org/D113086
This patch extends the `FIRToLLVMLowering` pass in Flang by extending
the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR
instructions (i.e. `CoordinateOpConversion::doRewrite`). The following
case is added:
3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or
`!fir.ref<!fir.type>`).
3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or
`!fir.ptr<!fir.type>`).
From the point of view of the conversion, 3.1 and 3.2 are currently identical.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Originally written by:
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Depends on: D114159
Differential Revision: https://reviews.llvm.org/D115333
With this change, the following invocations will be treated as errors
(multiple actions are specified):
```
$ flang-new -fc1 -E -fsyntax-only file.95
$ flang-new -fc1 -fsyntax-only -fdebug-dump-symbols file.95
```
In the examples above it is not clear whether it is `-fsyntax-only` or
the other action that is run (i.e. `-E` or `-fdebug-dump-symbols`). It
makes sense to disallow such usage. This should also lead to cleaner and
clearer tests (the `RUN` lines using `%flang_fc1` will only allow one
action).
This change means that `flang-new -fc1` and `clang -cc1` will behave
differently when multiple action options are specified. As frontend
drivers are mostly used by compiler developers, this shouldn't affect or
confuse the compiler end-users. Also, `flang-new` and `clang` remain
consistent.
Tests are updated accordingly. More specifically, I've made sure that
every test specifies only one action. I've also taken the opportunity to
simplify "multiple-input-files.f90" a bit.
Differential Revision: https://reviews.llvm.org/D111781
Move the Factory.h header file to flang/Optimizer/Builder.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D115801
This pass can reclassify memory allocations (fir.alloca, fir.allocmem)
based on heuristics and settings. The intention is to allow better
performance and workarounds for conditions such as environments with
limited stack space.
Currently, implements two conversions from stack to heap allocation.
1. If a stack allocation is an array larger than some threshold value
make it a heap allocation.
2. If a stack allocation is an array with a runtime evaluated size make
it a heap allocation.
Add a lit test for both suboptions.
Reviewed By: PeteSteinfeld, vdonaldson
Differential Revision: https://reviews.llvm.org/D115763
Rather than represent the mixed real/complex subexpression x*(a,b)
as (x*a,x*b), use (x,0)*(a,b) to avoid a potential code duplication
in current lowering code. Same for mixed division, and for mixed
integer*complex and integer/complex cases.
Differential Review: https://reviews.llvm.org/D115732
kindMap variable is declared in the Setup function but passed as
a reference to the firBuilder class. The firBuilder is declared in
the class and hence its lifetime exceeds that of kindMap. This can
lead to undefined behaviour. Move the kindMap variable into the class
to avoid this.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D115631
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR
instructions.
The following cases are currently supported:
1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or
`!fir.box`)
2. the input object is wrapped in a `!fir.box` (including e.g.
`!fir.array`).
Note that `!fir.complex` inside a `!fir.box` falls under case 1. above
(i.e. it's a special case regardless of the wrapping type).
This is part of the upstreaming effort from the `!fir-dev` branch in [1].
Differential Revision: https://reviews.llvm.org/D114159
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Array constructors with implied DO loops that oversee structure
constructors were being prematurely folded into invalid constants
containing symbolic references to the ac-implied-do indices,
because they are indeed "constant expressions" as that term is
used in the Fortran standard and implemented as IsConstantExpr().
What's actually needed in structure constructor folding is a
test for actual constant values, which is what results from
folding them later with repetition in the context of folding
an ac-implied-do.
Differential Revision: https://reviews.llvm.org/D115470
Change dialect (and remove now redundant accessors) to generate both
form of accessors of being generated. Tried to keep this change
reasonably minimal (this also includes keeping note about not generating
getType accessor to avoid shadowing).
Differential Revision: https://reviews.llvm.org/D115420
- Join indirection and rank into a single value `flags`
- Make the struct a plain C struct.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D115464
Some of the function name in the comment didn't match
their actual name in the runtime. This patch fixes that.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D115076
Prior to the introduction of the FLUSH statement in Fortran 2003,
implementations provided a FLUSH subroutine.
We can't yet put Fortran code into the runtime, so this subroutine
is in C++ with a Fortran-mangled entry point name.
Differential Revision: https://reviews.llvm.org/D115289
This patch introduces a bunch of builder functions
to create function calls to runtime ragged arrays functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114535
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch is part of the upstreaming effort from the fir-dev branch.
Address review comments
- move CHECK blocks to after the mlir code in the test file
- fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace
- fix a few nits
- remove TODO in favor of notifyMatchFailure
- removed unnecessary CHECK line from convert-to-llvm.fir
- rebase on main - add TODO back in
- get successfull test of TODO in AllocMemOp converion of derived type with LEN params
- clearer comments and reduced use of auto
- move defintion of computeDerivedTypeSize to fix build error
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D114104
The XRebox Op is formed by the codegen rewrite which makes it easier to
convert the operation to LLVM. The XRebox op includes the information
from the rebox op and the associated slice, shift, and shape ops.
During the conversion process a new descriptor is created for reboxing.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D114709
Peter Klausler