Fortran 2018 requires that a compiler allow objects whose rank + corank
is 15, and that's our maximum; detect and diagnose violations.
Differential Revision: https://reviews.llvm.org/D125153
Evaluate real-valued references to the intrinsic functions MODULO
and MOD at compilation time without recourse to an external math
library.
Differential Revision: https://reviews.llvm.org/D125151
Fold references to the intrinsic function DIM with constant real
arguments. And clean up folding of comparisons with NaNs to address
a problem noticed in testing -- NaNs should successfully compare
unequal to all values, including themselves, instead of failing all
comparisons.
Differential Revision: https://reviews.llvm.org/D125146
This patch adds lowering for task construct from Fortran to
`omp.task` operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.
Reviewed By: kiranchandramohan, peixin
Differential Revision: https://reviews.llvm.org/D124138
In a function, ENTRY E without an explicit RESULT() creates a
function result entity also named E that is storage associated with
the enclosing function's result. f18 was emitting an incorrect error
message if that function result E was referenced without any
declaration prior to its ENTRY statement when it should have been
implicitly declared instead.
Differential Revision: https://reviews.llvm.org/D125144
As is already supported for dummy procedures, we need to also accept
declarations of procedure pointers that consist of a POINTER attribute
statement followed by an INTERFACE block. (The case of an INTERFACE
block followed by a POINTER statement already works.)
While cleaning this case up, adjust the utility predicate IsProcedurePointer()
to recognize it (namely a SubprogramDetails symbol with Attr::POINTER)
and delete IsProcName(). Extend tests, and add better comments to
symbol.h to document the two ways in which procedure pointers are
represented.
Differential Revision: https://reviews.llvm.org/D125139
The semantic test for an intrinsic assignment to a polymorphic
derived type entity from a type that is an extension of its base
type was reversed, so it would allow assignments that it shouldn't
and disallowed some that it should; and the test case for it
incorectly assumed that the invalid semantics were correct.
Fix the code and the test, and add a new test for the invalid
case (LHS type is an extension of the RHS type).
Differential Revision: https://reviews.llvm.org/D125135
The rules in the Fortran standard for specification expressions
are full of special cases and exceptions, and semantics didn't get
them exactly right. It is valid to refer to an INTENT(OUT) dummy
argument in a specification expression in the context of a
specification inquiry function like SIZE(); it is not valid to
reference an OPTIONAL dummy argument outside of the context of
PRESENT. This patch makes the specification expression checker
a little context-sensitive about whether it's examining an actual
argument of a specification inquiry intrinsic function or not.
Differential Revision: https://reviews.llvm.org/D125131
DATA statements in inner procedures were not treating undeclared objects
as implicitly declared variables if the DATA statement appeared in a
specification part; they were treated as host-associated symbols instead.
This was incorrect. Fix DATA statement name resolution to always treat
DATA as if it had appeared in the executable part.
Differential Revision: https://reviews.llvm.org/D125129
A disassociated procedure pointer is allowed to be passed as an absent
actual argument that corresponds to an optional dummy procedure,
but not NULL(); accept that case as well.
Differential Revision: https://reviews.llvm.org/D125127
The type compatibility checks for the ARRAY= argument and the dummy
arguments and result of the OPERATION= argument to the REDUCE intrinsic
function need to allow for parameterized data types with LEN parameters.
(Their values are required to be identical but this is not a numbered
constraint requiring a compilation time check).
Differential Revision: https://reviews.llvm.org/D125124
Functions returning ALLOCATABLE or POINTER arrays have descriptor inquiries in
their results' shape expressions that won't compare equal. These functions
need only be checked for compatible ranks (& of course other characteristics).
Differential Revision: https://reviews.llvm.org/D125123
The utility UnwrapConvertedExpr() was failing to unwrap a
converted TypeParamInquiry operation when called from runtime
derived type description table construction, leading to an
abort in semantics.
Differential Revision: https://reviews.llvm.org/D125119
Structure contructors for instances of parameterized derived types
must have their components' values folded in the context of the values
of the type parameters.
Differential Revision: https://reviews.llvm.org/D125116
Actual arguments whose lengths are less than the expected length
of their corresponding dummy argument are errors; but this needs
to be refined. Short actual arguments that are variables remain
errors, but those that are expressions can be (again) extended on
the right with blanks.
Differential Revision: https://reviews.llvm.org/D125115
The construction of the dimension order vector used to populate the
result array was incorrect, leading to a scrambled-looking result
for rank-3 and higher results. Fix, and extend tests.
Differential Revision: https://reviews.llvm.org/D125113
The standard requires that the operands of the intrinsic function
SIGN() must have the same type (INTEGER or REAL), but they are not
required to have the same kind.
Differential Revision: https://reviews.llvm.org/D125105
The related real number system inquiry functions SPACING()
and RRSPACING() can be folded for constant arguments.
See 16.9.164 & 16.9.180 in Fortran 2018.
Differential Revision: https://reviews.llvm.org/D125100
When the result can be known at compilation time, fold it.
Success depends on whether the operands are polymorphic.
When neither one is polymorphic, the result is known and can
be either .TRUE. or .FALSE.; when either one is polymorphic,
a .FALSE. result still can be discerned.
Differential Revision: https://reviews.llvm.org/D125062
A BACKSPACE statement on a unit after a READ or WRITE with ADVANCE="NO"
must reset the position to the beginning of the record, not to the
beginning of the previous one.
Differential Revision: https://reviews.llvm.org/D125057
I'm emitting zero characters for (G0) formatting of CHARACTER values
instead of using their lengths to determine the output field width.
Differential Revision: https://reviews.llvm.org/D125056
A repeated format item group with an unlimited ('*') repetition count
can appear only as the last item at the top level of a format; it can't
be nested in more parentheses and it can't be followed by anything
else.
Differential Revision: https://reviews.llvm.org/D125054
When formatted CHARACTER input runs into the end of an input record,
the runtime usually fills the remainder of the variable with spaces,
but this should be conditional, and not done when PAD='NO'.
And while here, add some better comments to two members of connection.h
to make their non-obvious relationship more clear.
Differential Revision: https://reviews.llvm.org/D125053
The closing parenthesis needs to be consumed when a NaN
with parenthesized (ignored) information is read on the
real input path that preprocesses input characters before
passing them to the decimal-to-binary converter.
Differential Revision: https://reviews.llvm.org/D125048
The ifdef is not required in the header, common::int128_t is always
defined. The function declaration must be available in lowering
regardless of the host int128_t support.
Differential Revision: https://reviews.llvm.org/D125211
When processing an entry-stmt in name resolution, attrs_ was
reset before SetBindNameOn was called, causing the symbol to lose
the binding label information.
Differential Revision: https://reviews.llvm.org/D125097
As Fortran 2018 5.2.2 states, a program shall consist of exactly one
main program. Add this semantic check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125186
This was leftover from when the standard dialect was destroyed, and
when FuncOp moved to the func dialect. Now that these transitions
have settled a bit we can drop these.
Most updates were handled using a simple regex: replace `^( *)func` with `$1func.func`
Differential Revision: https://reviews.llvm.org/D124146
The code below causes flang to crash with an exception.
After fixing the crash flang with an internal error "no symbol found for 'bar'"
This change fixes all the issues.
program name
implicit none
integer, parameter :: bar = 1
integer foo(bar) /bar*2/
end program name
Reviewed By: kiranchandramohan, klausler
Differential Revision: https://reviews.llvm.org/D124914
As Fortran 2018 states, in each where-assignment-stmt, the mask-expr and
the variable being defined shall be arrays of the same shape. The
previous check does not consider checking if it is an array.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125022
As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type parameters and an external function with
assumed character length may be associated with a dummy argument with
explicit character length. As Fortran 2018 15.5.2.9 point 7, if an
external procedure is used as an actual argument, it can be explicitly
declared to have the EXTERNAL attribute. This supports the external
procedure passed as actual argument with implicit character type, either
explicit character length or assumed character length.
Reviewed By: Jean Perier, klausler
Differential Revision: https://reviews.llvm.org/D124345
For arrays without a constant interior or arrays of character with
dynamic length arrays, the data types are converted to a pointer to the
element type, so the scale size of the constant extents needs to be
counted. The previous AllocaOp conversion does not consider the arrays
of character with dynamic length arrays, and the previous AllocMemOp
conversion does not consider arrays without a constant interior. This
fixes them and refactors the code so that it can be shared. Also add
the test cases.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D124766
The OpenMP worksharing loop operation in the dialect is a proper loop
operation and not a container of a loop. So we have to lower the
parse-tree OpenMP loop construct and the do-loop inside the construct
to a omp.wsloop operation and there should not be a fir.do_loop inside
it. This is achieved by skipping fir.do_loop creation and calling genFIR
for the nested evaluations in the lowering of the do construct.
Note: Handling of more clauses, parallel do, storage of loop index variable etc will come in separate patches.
Part of the upstreaming effort to move LLVM Flang from fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project to the LLVM Project.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D125024
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Shraiysh Vaishay <Shraiysh.Vaishay@amd.com>
The FIR `do_loop` is designed as a structured operation with a single
block inside it. Presence of unstructured constructs like jumps, exits
inside the loop will cause the loop to be marked as unstructured. These
loops are lowered using the `control-flow` dialect branch operations.
Fortran semantics do not allow the loop variable to be modified inside
the loop. To prevent accidental modification, the iteration of the
loop is modeled by two variables, trip-count and loop-variable.
-> The trip-count and loop-variable are initialized in the pre-header.
The trip-count is set as (end-start+step)/step where end, start and
step have the usual meanings. The loop-variable is initialized to start.
-> The header block contains a conditional branch instruction which
selects between branching to the body of the loop or the exit block
depending on the value of the trip-count.
-> Inside the body, the trip-count is decremented and the loop-variable
incremented by the step value. Finally it branches to the header of the
loop.
Part of the upstreaming effort to move LLVM Flang from fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project to the LLVM Project.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D124837
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
This patch adds support for `-save-temps` in `flang-new`, Flang's
compiler driver. The semantics of this option are inherited from Clang.
The file extension for temporary Fortran preprocessed files is set to
`i`. This is identical to what Clang uses for C (or C++) preprocessed
files. I have tried researching what other compilers do here, but I
couldn't find any definitive answers. One GFortran thread [1] suggests
that indeed it is not clear what the right approach should be.
Normally, various phases in Clang/Flang are combined. The `-save-temps`
option works by forcing the compiler to run every phase separately. As
there is no integrated assembler driver in Flang, user will have to use
`-save-temps` together with `-fno-integrated-as`. Otherwise, an
invocation to the integrated assembler would be generated generated,
which is going to fail (i.e. something equivalent to `clang -cc1as` from
Clang).
There are no specific plans for implementing an integrated assembler for
Flang for now. One possible solution would be to share it entirely with
Clang.
Note that on Windows you will get the following error when using
`-fno-integrated-as`:
```bash
flang-new: error: there is no external assembler that can be used on this platform
```
Unfortunately, I don't have access to a Windows machine to investigate
this. Instead, I marked the tests in this patch as unsupported on
Windows.
[1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615
Differential Revision: https://reviews.llvm.org/D124669
This seems to be the consensus in
https://github.com/flang-compiler/f18-llvm-project/issues/1316
The patch adds ExternalNameConversion to the default FIR CodeGen pass
pipeline, right before the FIRtoLLVM pass. It also adds a flag to
optionally disable it, and sets it in `tco`. In other words, `flang-new`
and `flang-new -fc1` will both run the pass by default, whereas `tco`
will not, so none of the tests need to be updated.
Differential Revision: https://reviews.llvm.org/D121171
If a programmer is able to compile and link a program that contains types that
are not yet supported by the runtime, it must be because they're not yet
implemented.
This change will make it easier to find unimplemented code in tests.
Differential Revision: https://reviews.llvm.org/D125046
The fallback attribute parse path is parsing a Type attribute, but this results
in a really unintuitive error message: `expected non-function type`, which
doesn't really hint at tall that we were trying to parse an attribute. This
commit fixes this by trying to optionally parse a type, and on failure
emitting an error that we were expecting an attribute.
Differential Revision: https://reviews.llvm.org/D124870
In https://reviews.llvm.org/D124667, I added tests that check the
generated assembly. I verified the assembly on AArch64 and X86_64, but
the PPC Flang buildbot [1] started failing (i.e. the assembly was not
generic enough).
In order to fix this, I'm changing these tests to be only run on
AAarch64 - that's the architecture that most of public Flang buildbots
use.
I'm hoping that this is straightforward enough and am merging it without
a review.
[1] https://lab.llvm.org/buildbot/#/builders/21/builds/40256
This change makes sure that Flang's driver recognises LLVM IR and BC as
supported file formats. To this end, `isFortran` is extended and renamed
as `isSupportedByFlang` (the latter better reflects the new
functionality).
New tests are added to verify that the target triple is correctly
overridden by the frontend driver's default value or the value specified
with `-triple`. Strictly speaking, this is not a functionality that's
new in this patch (it was added in D124664). This patch simply enables
us to write such tests and hence I'm including them here.
Differential Revision: https://reviews.llvm.org/D124667
All frontend actions that generate code (MLIR, LLVM IR/BC,
Assembly/Object Code) are re-factored as essentially one action,
`CodeGenAction`, with minor specialisations. To facilate all this,
`CodeGenAction` is extended to hold `TargetMachine` and backend action
type (MLIR vs LLVM IR vs LLVM BC vs Assembly vs Object Code).
`CodeGenAction` is no longer a pure abstract class and the
corresponding `ExecuteAction` is implemented so that it covers all use
cases. All this allows a much better code re-use.
Key functionality is extracted into some helpful hooks:
* `SetUpTargetMachine`
* `GetOutputStream`
* `EmitObjectCodeHelper`
* `EmitBCHelper`
I hope that this clarifies the overall structure. I suspect that we may
need to revisit this again as the functionality grows in complexity.
Differential Revision: https://reviews.llvm.org/D124665
Flang transformational runtime was previously reporting conformity
issues in a zero based fashion to describe which dimension is non
conformant. This may confuse Fortran user, especially when the message
is about a dimension other than the first one.
Differential Revision: https://reviews.llvm.org/D124941
*SUMMARY*
Currently, the frontend driver assumes that a target triple is either:
* provided by the frontend itself (e.g. when lowering and generating
code),
* specified through the `-triple/-target` command line flags.
If `-triple/-target` is not used, the frontend will simply use the host
triple.
This is going to be insufficient when e.g. consuming an LLVM IR file
that has no triple specified (reading LLVM files is WIP, see D124667).
We shouldn't require the triple to be specified via the command line in
such situation. Instead, the frontend driver should contain a good
default, e.g. the host triple.
This patch updates Flang's `CompilerInvocation` to do just that, i.e.
defines its default target triple. Similarly to Clang:
* the default `CompilerInvocation` triple is set as the host triple,
* the value specified with `-triple` takes precedence over the frontend
driver default and the current module triple,
* the frontend driver default takes precedence over the module triple.
*TESTS*
This change requires 2 unit tests to be updated. That's because relevant
frontend actions are updated to assume that there's always a valid
triple available in the current `CompilerInvocation`. This update is
required because the unit tests bypass the regular `CompilerInvocation`
set-up (in particular, they don't call
`CompilerInvocation::CreateFromArgs`). I've also taken the liberty to
disable the pre-precossor formatting in the affected unit tests as well
(it is not required).
No new tests are added. As `flang-new -fc1` does not support consuming
LLVM IR files just yet, it is not possible to compile an LLVM IR file
without a triple. More specifically, atm all LLVM IR files are generated
and stored internally and the driver makes sure that these contain a
valid target triple. This is about to change in D124667 (which adds
support for reading LLVM IR/BC files) and that's where tests for
exercising the default frontend driver triple will be added.
*WHAT DOES CLANG DO?*
For reference, the default target triple for Clang's
`CompilerInvocation` is set through option marshalling infra [1] in
Options.td. Please check the definition of the `-triple` flag:
```
def triple : Separate<["-"], "triple">,
HelpText<"Specify target triple (e.g. i686-apple-darwin9)">,
MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">,
AlwaysEmit, Normalizer<"normalizeTriple">;
```
Ideally, we should re-use the marshalling infra in Flang.
[1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure
Differential Revision: https://reviews.llvm.org/D124664
When we pass an alternate return specifier to a regular (not an asterisk)
dummy argument, flang would throw an internal compiler error of
derefencing a null pointer.
To avoid the ICE, a check was added.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D123947
The RETURN statement is allowed in functions and subroutines, but not
in main programs. It is however a common extension, which we also
implement, to allow RETURN from main programs -- we only issue a
portability warning when -pedantic or -std=f2018 are set.
This patch fixes false positives for this portability warning, where it
was triggered also when RETURN was present in functions or subroutines.
Fixexs #55080
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D124732
This patch restricts the value of `if` clause expression to an I1 value.
It also restricts the value of `num_threads` clause expression to an I32
value.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124142
