Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
The following semantic check is removed in OpenMP Version 5.0:
```
Taskloop simd construct restrictions: No reduction clause can be specified.
```
Also fix several typos.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D105874
Name resolution is always creating symbols with HostAssocDetails
for host variable names inside internal procedures. This helps lowering
identifying and dealing with such variables inside internal procedures.
However, the case where the variable appears in an ArrayRef mis-parsed
as a FunctionRef goes through a different name resolution path that did
not create such HostAssocDetails when needed. Pointer assignment RHS
are also skipping this path.
Add the logic to create HostAssocDetails for host symbols inisde internal
procedures that appear in mis-parsed ArrayRef or in pointer assignment RHS.
Differential Revision: https://reviews.llvm.org/D105464
With derived type description tables now available to the
runtime library, it is possible to implement the concept
of "child" I/O statements in the runtime and use them to
convert instances of derived type I/O data transfers into
calls to user-defined subroutines when they have been specified
for a type. (See Fortran 2018, subclauses 12.6.4.8 & 13.7.6).
- Support formatted, list-directed, and NAMELIST
transfers to internal parent units; support these, and unformatted
transfers, for external parent units.
- Support nested child defined derived type I/O.
- Parse DT'foo'(v-list) FORMAT data edit descriptors and passes
their strings &/or v-list values as arguments to the defined
formatted I/O routines.
- Fix problems with this feature encountered in semantics and
FORMAT valiation during development and end-to-end testing.
- Convert typeInfo::SpecialBinding from a struct to a class
after adding a member function.
Differential Revision: https://reviews.llvm.org/D104930
There are situations where the arguments of intrinsics must be
conformable, which is defined in section 3.36. This means they must
have "the same shape, or one being an array and the other being scalar".
But the check we were actually making was that their ranks were the same.
This change fixes that and adds a test for the UNPACK intrinsic, where
the FIELD argument "shall be conformable with MASK".
Differential Revision: https://reviews.llvm.org/D104936
This patch adds a new option for the new Flang driver:
`-fno-analyzed-objects-for-unparse`. The semantics are similar to
`-funparse-typed-exprs-to-f18-fc` from `f18`. For consistency, the
latter is replaced with `-fno-analyzed-objects-for-unparse`.
The new option controls the behaviour of the unparser (i.e. the action
corresponding to `-fdebug-unparse`). The default behaviour is to use the
analyzed objects when unparsing. The new flag can be used to turn this
off, so that the original parse-tree objects are used. The analyzed
objects are generated during the semantic checks [1].
This patch also updates the semantics of
`-fno-analyzed-objects-for-unparse`/`-funparse-typed-exprs-to-f18-fc`
in `f18`, so that this flag is always taken into account when `Unparse`
is used (this way the semantics in `f18` and `flang-new` are identical).
The added test file is based on example from Peter Steinfeld.
[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/Semantics.md
Differential Revision: https://reviews.llvm.org/D103612
Refactor the recently-implemented MAXVAL/MINVAL folding so
that the parts that can be used to implement other reduction
transformational intrinsic function folding are exposed.
Use them to implement folding of IALL, IANY, IPARITY,
SUM. and PRODUCT. Replace the folding of ALL & ANY to
use the new infrastructure and become able to handle DIM=
arguments.
Differential Revision: https://reviews.llvm.org/D104562
This patch adds the following nesting check for `barrier` constructs:
```
A barrier region may not be closely nested inside a worksharing, loop, task, taskloop, critical, ordered, atomic, or master region.
```
Also adds a test case for the check,
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99888
This is *not* user-defined derived type I/O, but rather Fortran's
built-in capabilities for using derived type data in I/O lists
and NAMELIST groups.
This feature depends on having the derived type description tables
that are created by Semantics available, passed through compilation
as initialized static objects to which pointers can be targeted
in the descriptors of I/O list items and NAMELIST groups.
NAMELIST processing now handles component references on input
(e.g., "&GROUP x%component = 123 /").
The C++ perspectives of the derived type information records
were transformed into proper classes when it was necessary to add
member functions to them.
The code in Semantics that generates derived type information
was changed to emit derived type components in component order,
not alphabetic order.
Differential Revision: https://reviews.llvm.org/D104485
When a function is called in a specification expression, it must be
sufficiently defined, and cannot be a recursive call (10.1.11(5)).
The best fix for this is to change the contract for the procedure
characterization infrastructure to catch and report such errors,
and to guarantee that it does emit errors on failed characterizations.
Some call sites were adjusted to avoid cascades.
Differential Revision: https://reviews.llvm.org/D104330
Implement constant folding for the reduction transformational
intrinsic functions MAXVAL and MINVAL.
In anticipation of more folding work to follow, with (I hope)
some common infrastructure, these two have been implemented in a
new header file.
Differential Revision: https://reviews.llvm.org/D104337
The test added in https://reviews.llvm.org/D104305 will only work with
the new driver and should be marked as such.
Sending this without a review as it's fairly straightforward and fixes
test failures for developers that don't want to build the new driver.
When a program attempts to put something like a subprogram
into an array constructor, emit an error rather than crashing.
Differential Revision: https://reviews.llvm.org/D104336
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
This is a recommit of 7ddbf26, with 2 fixes:
* Replace C++ comments with C comments
* Only enable the test if libFortranRuntime.a exists (this might not be
the case if e.g. BUILD_SHARED_LIBS=On)
Differential Revision: https://reviews.llvm.org/D104290
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
Differential Revision: https://reviews.llvm.org/D104290
The new option will run the semantic checks and then dump the parse tree
and all the symbols. This is equivalent to running the driver twice,
once with `-fdebug-dump-parse-tree` and then with
the `-fdebug-dump-symbols` action flag.
Currently we wouldn't be able to achieve the same by simply running:
```
flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file>
```
That's because the new driver will only run one frontend action per
invocation (both of the flags used here are action flags). Diverging
from this design would lead to costly compromises and it's best avoided.
We may want to consider re-designing our debugging actions (and action
options) in the future so that there's more code re-use. For now, I'm
focusing on making sure that we support all the major cases requested by
our users.
Differential Revision: https://reviews.llvm.org/D104305
I added the only check that wasn't already tested along with tests for
many valid and invalid arguments.
Differential Revision: https://reviews.llvm.org/D104318
This patch adds the 4th Fortran specific semantic check for the OpenMP
allocate directive: "If a list item has the SAVE attribute, is a common
block name, or is declared in the scope of a module, then only predefined
memory allocator parameters can be used in the allocator clause".
Code in this patch was based on code from https://reviews.llvm.org/D93549/new/.
Differential Revision: https://reviews.llvm.org/D102400
It's possible to have several USE statements for the same module that
have different mixes of rename clauses and ONLY clauses. The presence
of a rename cause has the effect of hiding a previously associated name,
and the presence of an ONLY clause forces the name to be visible even in
the presence of a rename.
I fixed this by keeping track of the names that appear on rename and ONLY
clauses. Then, when processing the USE association of a name, I check to see
if it previously appeared in a rename clause and not in a USE clause. If so, I
remove its USE associated symbol. Also, when USE associating all of the names
in a module, I do not USE associate names that have appeared in rename clauses.
I also added a test.
Differential Revision: https://reviews.llvm.org/D104130
Allow the lit test suite to run under Windows. This encompasses the following changes:
* Define `lit_tools_dir` for flang's test configuration
* Replace `(<command> || true)` idiom with `not <command>`
* Add `REQUIRES: shell` on tests that invoke a shell script
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D89368
Adding the `-init-only` option and corresponding frontend action to
generate a diagnostic.
`-init-only` vs `-test-io`:
`-init-only` ignores the input (it never calls the prescanner)
`-test-io` is similar to `-init-only`, but does read and print the input
without calling the prescanner.
This patch also adds a Driver test to check this action.
Reviewed By: awarzynski, AMDChirag
Differential Revision: https://reviews.llvm.org/D102849
It's possible to specify refer to an undefined derived type as the type of a
component of another derived type and then never define the type of the
component. We were not detecting this situation. To fix this, I
changed the value of isForwardReferenced_ in the symbol's
DerivedTypeDetails and checked for it when performing other derived type
checks.
I also had to record the fact that error messages were previously
emitted for the same problem in some cases so that I could avoid
duplicate messages.
I also added a test.
Differential Revision: https://reviews.llvm.org/D103714
Implement the following semantic check:
"A list item may not appear in a linear clause, unless it is the loop iteration variable."
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D100224
With this patch, the following invocation of the frontend driver will
return an error:
```
flang-new -fc1 input-file.f90 -o
```
Similar logic applies to other options that require arguments.
Similar checks are already available in the compiler driver, flang-new
(that's implemented in clangDriver).
Differential Revision: https://reviews.llvm.org/D103554
This option is supported in `f18`, but not yet available in `flang-new`.
It is required in order to call `flang-new` from the `flang` bash
script.
Differential Revision: https://reviews.llvm.org/D103613
A recent change was made in https://reviews.llvm.org/D101482 to cope
with kind parameters. It had the side effect of generating some type
info symbols inside derived type scopes. Derived type scope symbols
are meant for components, and other/later compilation phases might
choke when finding compiler generated symbols there that are not
components.
This patch preserves the fix from D101482 while still generating the
symbols outside of derived type scopes.
Differential Revision: https://reviews.llvm.org/D103621
When a procedure pointer with no interface is called by a
function reference, complain about the lack.
Differential Revision: https://reviews.llvm.org/D103573
The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.
Differential Revision: https://reviews.llvm.org/D103571
It's possible to specify defined input/output procedures either as a
type-bound procedure of a derived type or as a defined-io-generic-spec. This
means that you can specify the same procedure in both mechanisms, which does
not cause problems. Alternatively, you can specify two different procedures to
be the defined input/output procedure for the same derived type. This is an
error. This change catches this error. The situation is slightly complicated
by parameterized derived types. Types with the same value for a KIND parameter
are treated as the same type while types with different KIND parameters are
treated as different types.
I implemented this check by adding a vector to keep track of which defined
input/output procedures had been seen for which derived types along with the
kind of procedure (read vs write and formatted vs unformatted). I also added
tests for non-parameterized types and types parameterized by KIND and LEN type
parameters.
I also removed an erroneous check from the code that creates runtime type
information.
Differential Revision: https://reviews.llvm.org/D103560
Each var argument to an attach or detach clause must be a
Fortran variable or array with the pointer or allocatable attribute.
This patch enforce this restruction.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D103279
This patch adds the following Fortran specific semantic checks for the OpenMP
Allocate directive.
1) A type parameter inquiry cannot appear in an ALLOCATE directive.
2) List items specified in the ALLOCATE directive must not have the ALLOCATABLE
attribute unless the directive is associated with an ALLOCATE statement.
Co-authored-by: Irina Dobrescu <irina.dobrescu@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D102061
Defined input/output procedures are specified in 12.6.4.8. There are different
versions for read versus write and formatted versus unformatted, but they all
share the same basic set of dummy arguments.
I added several checking functions to check-declarations.cpp along with a test.
In the process of implementing this, I noticed and fixed a typo in
.../lib/Evaluate/characteristics.cpp.
Differential Revision: https://reviews.llvm.org/D103045
Dummy arguments of ENTRY statements in execution parts were
not being created as objects, nor were they being implicitly
typed.
When the symbol corresponding to an alternate ENTRY point
already exists (by that name) due to having been referenced
in an earlier call, name resolution used to delete the extant
symbol. This isn't the right thing to do -- the extant
symbol will be pointed to by parser::Name nodes in the parse
tree while no longer being part of any Scope.
Differential Review: https://reviews.llvm.org/D102948
- Replace class(*) member by a c_ptr member to avoid having to handle
polymorphic components in the type info table generation. Polymorphic
entity handling will require these very tables to be lowered properly.
Note: keep the init as NullPointer/Designators. This is technically
invalid Fortran, the init should have c_ptr type. But wrapping this
in a C_LOC intrinsic call would make runtime generation and lowering
more complex with no real benefits.
- ComponentIterator is crashing when used on the generated derived
types in GetScope. This patch makes GetScope more robust, but it
is not entirely clear to me why this is only happening with the
generated derived types.
- The type of generated character globals was incorrect because
Scope::FindType was matching character types with different
length. Add a CharacterTypeSpec == operator to fix this.
Differential Revision: https://reviews.llvm.org/D102768
This patch implements the following semantic check:
```
A master region may not be closely nested inside a work-sharing, loop, atomic, task, or taskloop region.
```
Adds a test case and also modifies a couple of existing test cases to include the check.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D100228
We sometimes unroll an ac-implied-do of an array constructor into a flat list
of values. We then re-analyze the array constructor that contains the
resulting list of expressions. Such a list may or may not contain errors.
But when processing an array constructor with an unrolled ac-implied-do, the
compiler was building an expression to represent the extent of the resulting
array constructor containing the list of values. The number of operands
in this extent expression was based on the number of elements in the
unrolled list of values. For very large lists, this created an
expression so large that it could not be evaluated by the compiler
without overflowing the stack.
I fixed this by continuously folding the extent expression as each operand is
added to it. I added the test .../flang/test/Semantics/array-constr-big.f90
that will cause the compiler to seg fault without this change.
Also, when the unrolled ac-implied-do expression contains errors, we were
repeating the same error message referencing the same source line for every
instance of the erroneous expression in the unrolled list. This potentially
resulted in a very long list of messages for a single error in the source code.
I fixed this by comparing the message being emitted to the previously emitted
message. If they are the same, I do not emit the message. This change is also
tested by the new test array-constr-big.f90.
Several of the existing tests had duplicate error messages for the same source
line, and this change caused differences in their output. So I adjusted the
tests to match the new message emitting behavior.
Differential Revision: https://reviews.llvm.org/D102210
`%f18` was originally introduced to represent the old Flang driver,
`f18`. With the introduction of the new driver, `flang-new`, we have
been switching to `%flang` (compiler driver) and `%flang_fc1` (frontend
driver) as more generic alternatives.
As most tests have been portend to use the new LIT variables instead of
`%f18`, this is good time to remove it from lit.cfg.py. There's only one
test left that requires the old driver to run. It's updated with:
```
! REQUIRES: old-flang-driver
```
This way we preserve its semantics while reducing the number of
variables in LIT configuration.
Differential Revision: https://reviews.llvm.org/D101281
When producing the runtime type information for a component of a derived type
that had a LEN type parameter, we were not allowing a KIND parameter of the
derived type. This was causing one of the NAG correctness tests to fail
(.../hibiya/d5.f90).
I added a test to our own test suite to check for this.
Also, I fixed a typo in .../module/__fortran_type_info.f90.
I allowed KIND type parameters to be used for the declarations of components
that use LEN parameters by constant folding the value of the LEN parameter. To
make the constant folding work, I had to put the semantics::DerivedTypeSpec of
the associated derived type into the folding context. To get this
semantics::DerivedTypeSpec, I changed the value of the semantics::Scope object
that was passed to DescribeComponent() to be the derived type scope rather than
the containing non-derived type scope.
This scope change, in turn, caused differences in the symbol table output that
is checked in typeinfo01.f90. Most of these differences were in the order that
the symbols appeared in the dump. But one of them changed one of the values
from "CHARACTER(2_8,1)" to "CHARACTER(1_8,1)". I'm not sure if these changes
are significant. Please verify that the results of this test are still valid.
Also, I wonder if there are other situations in this code where we should be
folding constants. For example, what if the field of a component has a
component whose type is a PDT with a LEN type parameter, and the component's
declaration depends on the KIND type parameter of the current PDT. Here's an
example:
type string(stringkind)
integer,kind :: stringkind
character(stringkind) :: value
end type string
type outer(kindparam)
integer,kind :: kindparam
type(string(kindparam)) :: field
end type outer
I don't understand the code or what it's trying to accomplish well enough to
figure out if such cases are correctly handled by my new code.
Differential Revision: https://reviews.llvm.org/D101482
We were not correctly handling structure constructors that had forward
references to parameterized derived types. I harvested the code that checks
for forward references that was used during analysis of function call
expressions and called it from there and also called it during the
analysis of structure constructors.
I also added a test that will produce an internal error without this change.
Differential Revision: https://reviews.llvm.org/D101330
We were not checking that attributes that are supposed to be specific to
dummy arguments were not being used for local entities. I added the checks
along with tests for them.
After implementing these new checks, I found that one of the tests in
separate-mp02.f90 was erroneous, and I fixed it.
Differential Revision: https://reviews.llvm.org/D101126
When generating output for `-fdebug-dump-symbols`, make sure that
BuildRuntimeDerivedTypeTables is also run. This change is needed in
order to make the implementation of `-fdebug-dump-symbols` in
`flang-new` consistent with `f18`. It also allows us to port more tests
to use the new driver whenever it is enabled.
Differential Revision: https://reviews.llvm.org/D100649
This patch updates the final test that can be shared between the old and
the new Flang drivers and that has not been ported yet. %f18 (always
expanded as `f18`) is replaced with %flang_fc1 (expanded as either `f18`
or `flang-new -fc1`, depending on `FLANG_BUILD_NEW_DRIVER`).
This test should've been updated in https://reviews.llvm.org/D100309,
but I missed it then. That's because this test contains non-ascii
characters and `grep -I %f18` (as well as other grep-like tools) skips
it because it's interpreted as a data/binary file. In fact, it's just a
text file with non-ascii chars.
Since this is an obvious omission from D100309 (reviewed, accepted and
merged), I'm sending this without a review to reduce the noise on
Phabricator.
Switching from `%f18` to `%flang_fc1` in LIT tests added in
https://reviews.llvm.org/D91159. This way these tests are run with the
new driver, `flang-new`, when enabled (i.e. when
`FLANG_BUILD_NEW_DRIVER` is set).
Differential Revision: https://reviews.llvm.org/D101078
Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing. This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.
There were two sources of the bogus errors. One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).
The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.
Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.
Differential Revision: https://reviews.llvm.org/D101001
This patch adds semantic checks for the General Restrictions of the
Allocate Directive.
Since the requires directive is not yet implemented in Flang, the
restriction:
```
allocate directives that appear in a target region must
specify an allocator clause unless a requires directive with the
dynamic_allocators clause is present in the same compilation unit
```
will need to be updated at a later time.
A different patch will be made with the Fortran specific restrictions of
this directive.
I have used the code from https://reviews.llvm.org/D89395 for the
CheckObjectListStructure function.
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91159
We were erroneously not taking into account the constant values of LEN type
parameters of parameterized derived types when checking for argument
compatibility. The required checks are identical to those for assignment
compatibility. Since argument compatibility is checked in .../lib/Evaluate and
assignment compatibility is checked in .../lib/Semantics, I moved the common
code into .../lib/Evaluate/tools.cpp and changed the assignment compatibility
checking code to call it.
After implementing these new checks, tests in resolve53.f90 were failing
because the tests were erroneous. I fixed these tests and added new tests
to call03.f90 to test argument passing of parameterized derived types more
completely.
Differential Revision: https://reviews.llvm.org/D100989
This patch adds `-fget-definition` to `flang-new`. The semantics of this
option are identical in both drivers. The error message in the
"throwaway" driver is updated so that it matches the one from
`flang-new` (which is auto-generated and cannot be changed easily).
Tests are updated accordingly. A dedicated test for error handling was
added: get-definition.f90 (for the sake of simplicity,
getdefinition01.f90 no longer tests for errors).
The `ParseFrontendArgs` function is updated so that it can return
errors. This change is required in order to report invalid values
following `-fget-definition`.
The actual implementation of `GetDefinitionAction::ExecuteAction()` was
extracted from f18.cpp (i.e. the bit that deals with
`-fget-definition`).
Depends on: https://reviews.llvm.org/D100556
Differential Revision: https://reviews.llvm.org/D100558
We were erroneously emitting error messages for assignments of derived types
where the associated objects were instantiated with non-constant LEN type
parameters.
I fixed this by adding the member function MightBeAssignmentCompatibleWith() to
the class DerivedTypeSpec and calling it to determine whether it's possible
that objects of parameterized derived types can be assigned to each other. Its
implementation first compares the uninstantiated values of the types. If they
are equal, it then compares the values of the constant instantiated type
parameters.
I added tests to assign04.f90 to exercise this new code.
Differential Revision: https://reviews.llvm.org/D100868
This is similar to https://reviews.llvm.org/D100309, i.e. `%f18` is
replaced with `%flang_new`.
resolve105.f90 wasn't in tree when D100309 was worked on, so it's
updated here instead.
label14.f90 requires `-fsyntax-only`. I didn't notice that when
submitting D100309, hence updating it now instead. `-fsyntax-only` is
required to prevent `%f18` from calling an external compiler (which then
fails and returns a non-zero exit code).
Differential Revision: https://reviews.llvm.org/D100655
This patch updates most of the remaining regression tests (~400) to use
`flang-new` rather then `f18` when `FLANG_BUILD_NEW_DRIVER` is set.
This allows us to share more Flang regression tests between `f18` and
`flang-new`. A handful of tests have not been ported yet - these are
currently either failing or not supported by the new driver.
Summary of changes:
* RUN lines in tests are updated to use `%flang_fc1` instead of `%f18`
* option spellings in tests are updated to forms accepted by both `f18` and
`flang-new`
* variables in Bash scripts are renamed (e.g. F18 --> FLANG_FC1)
The updated tests will now be run with the new driver, `flang-new`,
whenever it is enabled (i.e when `FLANG_BUILD_NEW_DRIVER` is set).
Although this patch touches many files, vast majority of the changes are
automatic:
```
grep -IEZlr "%f18" flang/test/ | xargs -0 -l sed -i 's/%f18/%flang_fc1/g
```
Differential Revision: https://reviews.llvm.org/D100309
We were not instantiating procedure pointer components. If the instantiation
contained errors, we were not reporting them. This resulted in internal errors
in later processing.
I fixed this by adding code in .../lib/Semantics/type.cpp in
InstantiateComponent() to handle a component with ProcEntityDetails. I also
added several tests for various good and bad instantiations of procedure
pointer components.
Differential Revision: https://reviews.llvm.org/D100341
`%flang-new` was introduced in the early days of the new driver to make
a clear distinction between the tests for the current and the new
driver. We have since introduced `%flang` (compiler driver) and
`%flang_fc1` (frontend driver) as the long term solution. This has allowed
us to share tests between `flang-new` and `f18`. This patch replaces
all uses of `%flang-new` with `%flang` and `%flang_fc1`.
Some tests are reformatted so that all tests look uniform and are easier
to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so
that more tests can be shared with `f18`. To facilitate this,
`f{no-}implicit-none` are introduced in `f18` with semantics identical
to `flang-new`.
Two tests are deleted rather than updated:
* flang/test/Frontend/print-preprocess-C-file.f90
* flang/test/Frontend/print-preprocessed-file.f90
Instead, there is plenty of preprocessor tests in
flang/test/Preprocessing/.
Differential Revision: https://reviews.llvm.org/D100174
With the typo ($S instead of %s), the driver was expecting
input from stdin. In such cases, it prints:
```
Enter Fortran source
Use EOF character (^D) to end file
```
This was piped to FileCheck. Together with the available `CHECK-NOT`
statement, this was sufficient for the test to pass (incorrectly).
This patch makes sure that the provided input file is used instead of
stdin.
Differential Revision: https://reviews.llvm.org/D100301
F18 supports the standard intrinsic function SELECTED_REAL_KIND
but not its synonym in the standard module IEEE_ARITHMETIC
named IEEE_SELECTED_REAL_KIND until this patch.
Differential Revision: https://reviews.llvm.org/D100066
Check for two or more symbols that define a data object or entry point
with the same interoperable BIND(C) name.
Differential Revision: https://reviews.llvm.org/D100067
This patch adds two debugging options in the new Flang driver
(flang-new):
*fdebug-unparse-no-sema
*fdebug-dump-parse-tree-no-sema
Each of these options combines two options from the "throwaway" driver
(left: f18, right: flang-new):
* `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema`
* `-fdebug-dump-parse-tree -fdebug-no-semantics` -->
`-fdebug-dump-parse-tree-no-sema`
There are no plans to implement `-fdebug-no-semantics` in the new
driver. Such option would be too powerful. Also, it would only make
sense when combined with specific frontend actions (`-fdebug-unparse`
and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised
options listed above. Each of these is implemented through a dedicated
FrontendAction (also added).
The new frontend actions are implemented in terms of a new abstract base
action: `PrescanAndSemaAction`. This new base class was required so that
we can have finer control over what steps within the frontend are
executed:
* `PrescanAction`: run the _prescanner_
* `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new
in this patch)
* `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the
_semantic checks_
This patch introduces `PrescanAndParseAction::BeginSourceFileAction`.
Apart from the semantic checks removed at the end, it is similar to
`PrescanAndSemaAction::BeginSourceFileAction`.
Differential Revision: https://reviews.llvm.org/D99645
The -fdebug-dump-provenance flag is meant to be used with
needProvenanceRangeToCharBlockMappings set to true. This way, extra
mapping is generated that allows e.g. IDEs to retrieve symbol's scope
(offset into cooked character stream) based on symbol's source code
location. This patch makes sure that this option is set when using
-fdebug-dump-provenance.
With this patch, the implementation of -fdebug-dump-provenance in
`flang-new -fc1` becomes consistent with `f18`. The corresponding LIT
test is updated so that it can be shared with `f18`. I refined it a bit
so that:
* it becomes a frontend-only test
* it's stricter about the expected output
Differential Revision: https://reviews.llvm.org/D98847
This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfortran. In Flang the preprocessor is always run. Instead,
`-cpp/-nocpp` are used to control whether predefined and command-line
preprocessor macro definitions are enabled or not. In practice this is
sufficient to model gfortran`s `-cpp/-nocpp`.
In the absence of `-cpp/-nocpp`, the driver will use the extension of
the input file to decide whether to include the standard macro
predefinitions. gfortran's documentation [1] was used to decide which
file extension to use for this.
The logic mentioned above was added in FrontendAction::BeginSourceFile.
That's relatively late in the driver set-up, but this roughly where the
name of the input file becomes available. The logic for deciding between
fixed and free form works in a similar way and was also moved to
FrontendAction::BeginSourceFile for consistency (and to reduce
code-duplication).
The `-cpp/-nocpp` flags are respected also when the input is read from
stdin. This is different to:
* gfortran (behaves as if `-cpp` was used)
* f18 (behaves as if `-nocpp` was used)
Starting with this patch, file extensions are significant and some test
files had to be renamed to reflect that. Where possible, preprocessor
tests were updated so that they can be shared between `f18` and
`flang-new`. This was implemented on top of adding new test for
`-cpp/-nocpp`.
[1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99292
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D99892
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Differential Revision: https://reviews.llvm.org/D99892
f18 was emitting a bogus error message about the lack of a TARGET
attribute when a pointer was initialized with a component of a
variable that was a legitimate TARGET.
Differential Revision: https://reviews.llvm.org/D99665
When writing tests for a previous problem, I ran across situations where the
compiler was failing calls to CHECK(). In these situations, the compiler had
inconsistent semantic information because the programs were erroneous. This
inconsistent information was causing the calls to CHECK().
I fixed this by avoiding the code that ended up making the failed calls to
CHECK() and making sure that we were only avoiding these situations when the
associated symbols were erroneous.
I also added tests that would cause the calls to CHECK() without these changes.
Differential Revision: https://reviews.llvm.org/D99342
Folding of LOGICAL intrinsic procedure was missing in the front-end causing
crash when using it in parameter expressions.
Simply fold LOGICAL calls to evaluate::Convert<T>.
Differential Revision: https://reviews.llvm.org/D99346
Before the conversion to LLVM-IR dialect and ultimately LLVM IR, FIR is
partially rewritten into a codegen form. This patch adds that pass, the
fircg dialect, and the small set of Ops in the fircg (sub) dialect.
Fircg is not part of the FIR dialect and should never be used outside of
the (closed) conversion to LLVM IR.
Authors: Eric Schweitz, Jean Perier, Rajan Walia, et.al.
Differential Revision: https://reviews.llvm.org/D98063
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
When writing tests for a previous problem, I ran across situations where we
were not producing error messages for declarations of specific procedures of
generic interfaces where every other compiler I tested (except nvfotran) did.
I added a check to CheckExtantExternal() and renamed it since it now checks for
erroneous extant symbols generally.
I also removed a call to this function from processing for ENTRY statements,
since it seemed unnecessary and its presence caused bogus error messages.
I also added some tests for erroneous declarations where we were not producing
error messages.
Differential Revision: https://reviews.llvm.org/D99111
If you specify a specific procedure of a generic interface that has the same
name as both the generic interface and a preceding derived type, the compiler
would fail an internal call to CHECK(). I fixed this by testing for this
situation when processing specific procedures. I also added a test that will
cause the call to CHECK() to fail without this new code.
Differential Revision: https://reviews.llvm.org/D99085
This patch fixes a bug to allow ordered construct within a non-worksharing loop, also adds more sema checks.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D98733
Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-ordered sets must
not be used for Symbols that might be subjected to name
replacement during name resolution, and address-ordered
sets must not be used (without sorting) in circumstances
where the order of their contents affects the output of the
compiler.
All set<> and map<> instances in the compiler that are keyed
by Symbols now have explicit Compare types in their template
instantiations. Symbol::operator< is no more.
Differential Revision: https://reviews.llvm.org/D98878
Adds support for `-fget-symbols-sources` in the new Flang driver. All
relevant tests are updated to use the new driver when
`FLANG_BUILD_NEW_DRIVER` is set.
`RUN` lines in tests are updated so `-fsyntax-only`
comes before `-fget-symbols-sources`. That's because:
* both `-fsyntax-only` and `-fget-symbols-sources` are
action flags, and
* the new driver, flang-new, will only consider the right-most
action flag.
In other words, this change is needed so that the tests work with both
`f18` (requires both flags) and `flang-new` (only considers the last
action flag).
Differential Revision: https://reviews.llvm.org/D98191
In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on std::map::equal_range to map a CharBlock
to its enclosing CookedSource instance.
Add a creation order number to each CookedSource. This allows
AllCookedSources to provide a Precedes(x,y) predicate that is a
true source stream ordering between two CharBlocks -- x is less
than y if it is in an earlier CookedSource, or in the same
CookedSource at an earlier position.
Add a reference to the singleton SemanticsContext to each Scope.
All of this allows operator< to be implemented on Symbols by
means of a true source ordering. From a Symbol, we get to
its Scope, then to the SemanticsContext, and then use its
AllCookedSources reference to call Precedes().
Differential Revision: https://reviews.llvm.org/D98743
Implement INDEX in the runtime, reusing some infrastructure
(with generalization and renaming as needed) put into place
for its cousins SCAN and VERIFY.
I did not implement full Boyer-Moore substring searching
for the forward case, but did accelerate some advancement on
mismatches.
I (re)implemented unit testing for INDEX in the new gtest
framework, combining it with the tests that have recently
been ported to gtest for SCAN and VERIFY.
Differential Revision: https://reviews.llvm.org/D98553
The build was putting .mod files for intrinsic modules in
tools/flang/include/flang but the install puts them in include/flang,
as does the out-of-tree build. This confused things for the driver.
This change makes the build consistent with the install and simplifies
the flang script accordingly.
Also, clean up the cmake commands for building the .mod files.
Differential Revision: https://reviews.llvm.org/D98522
Fortran permits a reference to a function whose result is a pointer
to be used as a definable variable in any context where a
designator could appear. This patch wrings out remaining bugs
with such usage and adds more testing.
The utility predicate IsProcedurePointer(expr) had a misleading
name which has been corrected to IsProcedurePointerTarget(expr).
Differential Revision: https://reviews.llvm.org/D98555
If you specify a type-bound procedure with an alternate return, there
will be no symbol associated with that dummy argument. In such cases,
the compiler's list of dummy arguments will contain a nullptr. In our
analysis of the PASS arguments of type-bound procedures, we were
assuming that all dummy arguments had non-null symbols associated with
them and were using that assumption to get the name of the dummy
argument. This caused the compiler to try to dereference a nullptr.
I fixed this by explicitly checking for a nullptr and, in such cases, emitting
an error message. I also added tests that contain type-bound procedures with
alternate returns in both legal and illegal constructs to ensure that semantic
analysis is working for them.
Differential Revision: https://reviews.llvm.org/D98430
You can define a base type with a type-bound procedure which is erroneously
missing a NOPASS attribute and then define another type that extends the base
type and overrides the erroneous procedure. In this case, when we perform
semantic checking on the overriding procedure, we verify the "pass index" of
the overriding procedure. The attempt to get the procedure's pass index fails
a call to CHECK().
I fixed this by calling SetError() on the symbol of the overridden procedure in
the base type. Then, I check HasError() before executing the code that invokes
the failing call to CHECK(). I also added a test that will cause the compiler
to fail the call to CHECK() without this change.
Differential Revision: https://reviews.llvm.org/D98355
In https://reviews.llvm.org/D98283, the RUN line in pre-fir-tree04.f90
was updated to use `%flang_fc1` instead of `%f18` (so that the test is
shared between the old and the new driver). Unfortunately, the new
driver does not know yet how to find standard intrinsics modules. As a
result, the test fails when `FLANG_BUILD_NEW_DRIVER` is set to On.
I'm restoring the original RUN line. This is rather straightforward, so
sending without a review. This should make Flang builders happy.
The PFT has been updated to support Fortran 77.
clang-tidy cleanup.
Authors: Val Donaldson, Jean Perier, Eric Schweitz, et.al.
Differential Revision: https://reviews.llvm.org/D98283
This patch adds `-fdebug-dump-parsing-log` in the new driver. This option is
semantically identical to `-fdebug-instrumented-parse` in `f18` (the
former is added as an alias in `f18`).
As dumping the parsing log makes only sense for instrumented parses, we
set Fortran::parser::Options::instrumentedParse to `True` when
`-fdebug-dump-parsing-log` is used. This is consistent with `f18`.
To facilitate tweaking the configuration of the frontend based on the
action being requested, `setUpFrontendBasedOnAction` is introduced in
CompilerInvocation.cpp.
Differential Revision: https://reviews.llvm.org/D97457
Until now we've been maintaining 2 test directories for Flang's drivers:
* test/Driver for `f18` (the current driver)
* test/Flang-Driver for `flang-new` (the new driver)
As we have started sharing tests between the drivers, this separation is
no longer required. This patch merges the two test directories. As
suggested in the review, moving forward we'll avoid having tests
specifically for the old driver.
A few notable changes:
* Driver/version-test.f90 and Driver/no-files.f90 are deleted. The
versions for the new driver are more robust, but tricky to share.
* Driver/write-module.f90 is deleted in favour of
Flang-Driver/write-module.f90 (see https://reviews.llvm.org/D97197
for more context)
Differential Revision: https://reviews.llvm.org/D98257
We have a "<" operator defined on the type semantics::Symbol that's based on
the symbols' locations in the cooked character stream. This is potentially
problematic when comparing symbols from .mod files when the cooked character
streams themselves might be allocated to varying memory locations.
This change fixes that by using the order in which symbols are created as the
basis for the "<" operator. Thanks to Tim and Peter for consultation on the
necessity of doing this and the idea for what to use as the basis of the sort.
This change in the "<" operator changed the expected results for three of the
tests. I manually inspected the new results, and they look OK to me. The
differences in data05.f90 and typeinfo01.f90 are entirely the order, offsets,
and sizes of the derived type components. The changes in resolve102.f90 are
due to the new, different "<" operator used for sorting.
Differential Revision: https://reviews.llvm.org/D98225
This patch refactors include-module.f90:
* rename the test file as use-module.f90 to better highlight which
driver feature is being tested
* move tests for diagnostics to use-module-error.f90 (it tests that
`-J/-module-dir` can only be used once)
* make sure that `f18` is tested when `FLANG_BUILD_NEW_DRIVER` is
set to `Off`
* add tests for when all module files are successfully discovered and
loaded
With this patch, there should be a clear separation into 3 scenarios in
use-module.f90:
* Everything is OK
* One module file wasn't found (missing include path for
basictestingmoduletwo.mod)
* Two module files are found, but the test requires
`basictestingmoduleone.mod` from both `Inputs` and `Inputs/module-dir`.
Only the latter is found.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D97197
When we have a subprogram that has been determined to contain errors, we do not
perform name resolution on its execution part. In this case, if the subprogram
contains a NULLIFY statement, the parser::Name of a pointer object in a NULLIFY
statement will not have had name resolution performed on it. Thus, its symbol
will not have been set. Later, however, we do semantic checking on the NULLIFY
statement. The code that did this assumed that the parser::Name of the
pointer object was non-null.
I fixed this by just removing the null pointer check for the "symbol" member of
the "parser::Name" of the pointer object when doing semantic checking for
NULLIFY statements. I also added a test that will make the compiler crash
without this change.
Differential Revision: https://reviews.llvm.org/D98184
Add diagnostic tests with fir-opt for the diagnostics emitted by the ops verifier
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D97996
Add support for the following Fortran dialect options:
- -default*
- -flarge-sizes
It also adds two test cases:
# For checking whether `flang-new` is passing options correctly to `flang-new -fc1`.
# For checking if `fdefault-` arguments are processed properly.
Also moves the Dialect related option parsing to a dedicated function
and adds a member `defaultKinds()` to `CompilerInvocation`
Depends on: D96032
Differential Revision: https://reviews.llvm.org/D96344
We were allowing procedures with the MODULE prefix to be declared at the global
scope. This is prohibited by C1547 and was causing an internal check of the
compiler to fail.
I fixed this by adding a check. I also added a test that would trigger a crash
without this change.
Differential Revision: https://reviews.llvm.org/D97875
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure. But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.
I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function. This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.
I also fixed the error message used when reporting recursively defined
dummy procedure arguments by removing extra apostrophes and sorting the
list of symbols.
I also added tests that will crash the compiler without this change.
Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ... All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.
Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory. But I was unable to create
a test that caused a problem. Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems. Symbols in enclosing or
parallel scopes can have the same name. Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.
This patch supersedes D97749.
Differential Revision: https://reviews.llvm.org/D97774
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure. But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.
I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function. This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.
I also fixed the error message used when reporting recursively defined dummy
procedure arguments.
I also added tests that will crash the compiler without this change.
Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ... All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.
Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory. But I was unable to create
a test that caused a problem. Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems. Symbols in enclosing or
parallel scopes can have the same name. Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.
This change supersedes D97201.
Differential Revision: https://reviews.llvm.org/D97749
Semantic checks for the following OpenMP 4.5 clauses.
1. 2.15.4.2 - Copyprivate clause
2. 2.15.3.4 - Firstprivate clause
3. 2.15.3.5 - Lastprivate clause
Add related test cases and resolve test cases marked as XFAIL.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91920
This reverts commit 07de0846a5.
The original patch has caused 6 out 8 of Flang's public buildbots to
fail. As I'm not sure what the fix should be, I'm reverting this for
now. Please see https://reviews.llvm.org/D97201 for more context and
discussion.
- add ops: rebox, insert_on_range, absent, is_present
- embox, coordinate_of: replace old hand-written parser/pretty-printer with assembly format
- remove dead floating point ops, since buitlins work for all types
- update call op
- update documentation
- misc. NFC to formatting
- add op round trip tests
Authors: Eric Schweitz, Jean Perier, Zachary Selk, Kiran Chandramohan, et.al.
Differential Revision: https://reviews.llvm.org/D97500
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was
defined using the name of the procedure. But the procedure name was
being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous
symbols. I fixed this by making SymbolSet be an ordered set, which does
not use the "<" operator.
I also added tests that will crash the compiler without this change.
And I fixed the formatting on an error message from a previous update.
Differential Revision: https://reviews.llvm.org/D97201
We lower expressions with rank > 0 to a set of high-level array operations.
These operations are then analyzed and refined to more primitve
operations in subsequent pass(es).
This patch upstreams these array operations and some other helper ops.
Authors: Eric Schweitz, Rajan Walia, Kiran Chandramohan, et.al.
https://github.com/flang-compiler/f18-llvm-project/pull/565
Differential Revision: https://reviews.llvm.org/D97421
This patch makes sure that for the following invocation of the new Flang
driver, clangDriver sets the input type to Fortran:
```
flang-new -E -
```
This change does not affect `clang`, i.e. for the following invocation
the input type is set to C:
```
clang -E -
```
This change leverages the fact that for `flang-new` the driver is in
Flang mode.
Differential Revision: https://reviews.llvm.org/D96777
This patch adds the new zero_bits operation and upstrams other changes
including the following:
- update tablegen syntax to newer forms
- update memory effects annotations
- update documentation [NFC]
- other NFC, such as whitespace and formatting
Differential revision: https://reviews.llvm.org/D97331
Originally, when we added the new driver, we created dedicated test
directories for `flang-new`. This way we separated the tests for the
`throwaway` and the new driver.
As we are increasing test coverage and starting to share tests between
the two drivers, it makes sense to share all directories and instead
rely on:
```
! REQUIRES: new-flang-driver
```
to mark tests as exclusively for the new driver.
Differential Revision: https://reviews.llvm.org/D97207
Add -J to the f18 driver for compatibility with gfortran.
Add -module-dir for compatibility with the new flang driver.
They both set the output directory for .mod files and add the
directory to the search list. -module still only does the former.
Clean up the new driver test to match.
Differential Revision: https://reviews.llvm.org/D97164
This patch adds support for `-Xflang` in `flang-new`. The semantics are
identical to `-Xclang`.
With the addition of `-Xflang`, we can modify `-test-io` to be a
compiler-frontend only flag. This makes more sense, this flag is:
* very frontend specific
* to be used for development and testing only
* not to be exposed to the end user
Originally we added it to the compiler driver, `flang-new`, in order to
facilitate testing. With `-Xflang` this is no longer needed. Tests are
updated accordingly.
Differential Revision: https://reviews.llvm.org/D96864
Add the following options:
* -fdebug-measure-parse-tree
* -fdebug-pre-fir-tree
Summary of changes:
- Add 2 new frontend actions: DebugMeasureParseTreeAction and DebugPreFIRTreeAction
- Add MeasurementVisitor to FrontendActions.h
- Make reportFatalSemanticErrors return true if there are any fatal errors
- Port most of the `-fdebug-pre-fir-tree` tests to use the new driver if built, otherwise use f18.
Differential Revision: https://reviews.llvm.org/D96884
Most Fortran compilers accept the following benign extension,
and it appears in some applications:
SUBROUTINE FOO(A,N)
IMPLICIT NONE
REAL A(N) ! N is used before being typed
INTEGER N
END
Allow it in f18 only for default integer scalar dummy arguments.
Differential Revesion: https://reviews.llvm.org/D96982
Add the following options:
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
* -fdebug-dump-provenance
Summary of changes:
- Add 3 new frontend actions: DebugDumpSymbolsAction, DebugDumpParseTreeAction and DebugDumpProvenanceAction
- Add a unique pointer to the Semantics instance created in PrescanAndSemaAction
- Move fatal semantic error reporting to its own method, FrontendActions#reportFatalSemanticErrors
- Port most tests using `-fdebug-dump-symbols` and `-fdebug-dump-parse-tree` to the new driver if built, otherwise default to f18
Differential Revision: https://reviews.llvm.org/D96716
Fortran 2018 explicitly permits an ignored type declaration
for the result of a generic intrinsic function. See the comment
added to Semantics/expression.cpp for an explanation of why this
is somewhat dangerous and worthy of a warning.
Differential Revision: https://reviews.llvm.org/D96879
The intrinsic procedure table properly classify the various
intrinsics, but the PURE and ELEMENTAL attributes that these
classifications imply don't always make it to the utility
predicates that test symbols for them, leading to spurious
error messages in some contexts. So set those attribute flags
as appropriate in name resolution, using a new function to
isolate the tests.
An alternate solution, in which the predicates would query
the intrinsic procedure table for these attributes on demand,
was something I also tried, so that this information could
come directly from an authoritative source; but it would have
required references to the intrinsic table to be passed along
on too many seemingly unrelated APIs and ended up looking messy.
Several symbol table tests needed to have their expected outputs
augmented with the PURE and ELEMENTAL flags. Some bogus messages
that were flagged as such in test/Semantics/doconcurrent01.f90 were
removed, since they are now correctly not emitted.
Differential Revision: https://reviews.llvm.org/D96878
It's possible to define a procedure that has a procedure dummy argument which
names the procedure that contains it. This was causing the compiler to fall
into an infinite loop when characterizing a call to the procedure.
Following a suggestion from Peter, I fixed this be maintaining a set of
procedure symbols that had already been seen while characterizing a procedure.
This required passing a new parameter to the functions that characterized a
Procedure, a DummyArgument, and a DummyProcedure.
I also added several tests that will crash the compiler without this change.
Differential Revision: https://reviews.llvm.org/D96631
This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
Add the following options:
* -fimplicit-none and -fno-implicit-none
* -fbackslash and -fno-backslash
* -flogical-abbreviations and -fno-logical-abbreviations
* -fxor-operator and -fno-xor-operator
* -falternative-parameter-statement
* -finput-charset=<value>
Summary of changes:
- Enable extensions in CompilerInvocation#ParseFrontendArgs
- Add encoding_ to Fortran::frontend::FrontendOptions
- Add encoding to Fortran::parser::Options
Differential Revision: https://reviews.llvm.org/D96407
This patch adds the following compiler frontend driver options:
* -fdebug-unparse (f18 spelling: -funparse)
* -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols)
The new driver will only accept the new spelling. `f18` will accept both
the original and the new spelling.
A new base class for frontend actions is added: `PrescanAndSemaAction`.
This is added to reduce code duplication that otherwise these new
options would lead to. Implementation from
* `ParseSyntaxOnlyAction::ExecutionAction`
is moved to:
* `PrescanAndSemaAction::BeginSourceFileAction`
This implementation is now shared between:
* PrescanAndSemaAction
* ParseSyntaxOnlyAction
* DebugUnparseAction
* DebugUnparseWithSymbolsAction
All tests that don't require other yet unimplemented options are
updated. This way `flang-new -fc1` is used instead of `f18` when
`FLANG_BUILD_NEW_DRIVER` is set to `On`. In order to facilitate this,
`%flang_fc1` is added in the LIT configuration (lit.cfg.py).
`asFortran` from f18.cpp is duplicated as `getBasicAsFortran` in
FrontendOptions.cpp. At this stage it's hard to find a good place to
share this method. I suggest that we revisit this once a switch from
`f18` to `flang-new` is complete.
Differential Revision: https://reviews.llvm.org/D96483
The following _action_ options are always used with `-fsyntax-only`
(also an _action_ option):
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
This patch makes the above options imply `-fsyntax-only`.
From the perspective of `f18` this change saves typing and is otherwise
a non-functional change. But it will simplify things in the new driver,
`flang-new`, in which only the last action option is taken into account
and executed. In other words, the following would only run
`-fsyntax-only`:
```
flang-new -fdebug-dump-symbols -fsyntax-only <input>
```
whereas this would only run `-fdebug-dump-symbols`:
```
flang-new -fsyntax-only -fdebug-dump-symbols <input>
```
Differential Revision: https://reviews.llvm.org/D96528
Implementation of Do loop iteration variable check, Do while loop check, Do loop cycle restrictions.
Also to check whether the ordered clause is present on the loop construct if any ordered region ever
binds to a loop region arising from the loop construct.
Files:
check-omp-structure.h
check-omp-structure.cpp
resolve-directives.cpp
Testcases:
omp-do06-positivecases.f90
omp-do06.f90
omp-do08.f90
omp-do09.f90
omp-do10.f90
omp-do11.f90
omp-do12.f90
omp-do13.f90
omp-do14.f90
omp-do15.f90
omp-do16.f90
omp-do17.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D92732
This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
Instead of using a message attachment with further details,
emit the details as part of a single message.
Differential Revision: https://reviews.llvm.org/D96465
Most components required for this are already there.
Build and Testing clean.
ninja check-flang
Reviewed By: clementval, tskeith
Differential Revision: https://reviews.llvm.org/D96411
Some state in name resolution is stored in the DeclarationVisitor
instance and processed at the end of the specification part.
This state needs to accommodate nested specification parts, namely
the ones that can be nested in a subroutine or function interface
body.
Differential Revision: https://reviews.llvm.org/D96466
Add support for the following options:
* -fopenmp
* -fopenacc
Update OpenMP and OpenACC semantics tests to use the new driver if it is built, otherwise use f18.
OpenMP tests that include `use omp_lib` or run `test_symbols.sh` have not been updated as they require options `-intrinsic-module-directory` and `-funparse-with-symbols` which are currently not implemented in the new driver.
Similarly OpenACC tests that run `test_symbols.sh` have not been updated.
This patch also moves semanticsContext to CompilerInvocation and creates it in CompilerInvocation#setSemanticsOpts so that the semantics context can use Fortran::parser::Options#features.
Summary of changes:
- Move semanticsContext to CompilerInvocation.h
- Update OpenMP and OpenACC semantics tests that do not rely on `-intrinsic-module-directory` and `-funparse-with-symbols` to use %flang
Differential Revision: https://reviews.llvm.org/D96032
This patch adds logic in the InputOutputTestAction frontend action for
reading input from stdin. Without this patch the following fails:
```
flang-new -fc1 -test-io -
```
The implementation of `InputOutputTestAction` is cleaned-up and a test
for reading from stdin is added.
Note that there's a difference between `-test-io` and e.g. `-E` in terms
of file I/O. The frontend action for the former handles all file I/O on
it's own. Conversely, the action corresponding to -E relies on the
prescanner API to handle this.
Currently we can't test reading from stdin for `flang-new -`. In this
case `libclangDriver` assumes `-x -c`. This in turn leads to `flang-new
-cc1`, which is not supported.
Add support for option -J/-module-dir in the new Flang driver. This
will allow for including module files in other directories, as the
default search path is currently the working folder. This also provides
an option of storing the output module in the specified folder.
Differential Revision: https://reviews.llvm.org/D95448
Add support for the following layout options:
* -ffree-form
* -ffixed-form
- -ffixed-line-length=n (alias -ffixed-line-length-n)
Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags.
This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836, these flags are not currently forwarded to gfortran anyway.
The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran.
This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns.
Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files.
Summary of changes:
- Remove -fno-fixed-form and -fno-free-form from Options.td
- Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td
- Create AddFortranDialectOptions method in Flang.cpp
- Create FortranForm enum in FrontendOptions.h
- Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions
- Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing.
Differential Revision: https://reviews.llvm.org/D95460
Constant folding for calls to LBOUND() was not working when the lower bound of
a constant array was not 1.
I fixed this and re-enabled the test in Evaluate/folding16.f90 that previously
was silently failing. I slightly changed the test to parenthesize the first
argument to exercise all of the new code.
Differential Revision: https://reviews.llvm.org/D95894
Now that semantics is working, the standard -fsyntax-only option of
GNU and Clang should be used as the name of the option that causes
f18 to just run the front-end. Support both options in f18, silently
accepting the old option as a synonym for the new one (as
preferred by the code owner), and replace all instances of the
old -fparse-only option with -fsyntax-only throughout the source base.
Differential Revision: https://reviews.llvm.org/D95887
Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic
functions from the intrinsic module IEEE_ARITHMETIC, folding all of
their results to .TRUE.
Differential Revision: https://reviews.llvm.org/D95830
This patch adds a check that verifies that the input file used when
calling the frontend driver (i.e. `flang-new -fc1`) actually exists.
This was not required for the compiler driver, `flang-new`, as that's
already handled in libclangDriver.
Once all input/output file management is moved to the driver, we should
also check that for input from `stdin` the corresponding file descriptor
was successfully acquired.
This patch also makes sure that the default action in the frontend is
`ParseSyntaxOnly`. This is consistent with Clang. Before this change
`flang-new -fc1` would do nothing, which makes testing changes like the
one introduced here a bit tricky.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95127
Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER statement by lacking parentheses, and semantically by
using the type and shape of the initialization expression to define
the attributes of the named constant. (GNU Fortran gets that part
wrong; Intel Fortran and nvfortran have full support.)
This patch disables the old style PARAMETER statement by default, as
it is syntactically ambiguous with conforming assignment statements;
adds a new "-falternative-parameter-statement" option to enable it;
and implements it correctly when enabled.
Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user
tripped over the syntactic ambiguity.
Differential Revision: https://reviews.llvm.org/D95697
There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating the folded array to have lower
bounds of 1 but, we were not re-adjusting their lower bounds to the
declared values. Second, we were not calculating the extents correctly.
Both of these problems led to bogus error messages.
I fixed the first problem by adjusting the lower bounds in
NonPointerInitializationExpr() in Evaluate/check-expression.cpp. I wrote the
class ArrayConstantBoundChanger, which is similar to the existing class
ScalarConstantExpander. In the process of implementing and testing it, I found
a bug that I fixed in ScalarConstantExpander which caused it to infinitely
recurse on parenthesized expressions. I also removed the unrelated class
ScalarExpansionVisitor, which was not used.
I fixed the second problem by changing the formula that calculates upper bounds
in in the function ComputeUpperBound() in Evaluate/shape.cpp.
I added tests that trigger the bogus error messages mentioned above along with
a constant folding tests that uses array operands with shapes that conform but
have different bounds.
In the process of adding tests, I discovered that tests in
Evaluate/folding09.f90 and folding16.f90 were written incorrectly, and I
fixed them. This also revealed a bug in contant folding of the
intrinsic "lbounds" which I plan to fix in a later change.
Differential Revision: https://reviews.llvm.org/D95449
Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files except the original.
Resolve tests.
Differential Revision: https://reviews.llvm.org/D95481
kernels loop and enter data had a too restrictive constraint for the wait clause.
The wait clause is allowed multiple times and not only once. This patch fix this problem.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95469
Restriction on clauses for the EXIT DATA directive were not fully correct.
This patch fixes the situation. The async, if and finalize clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95470
Restriction on clauses for the HOST_DATA directive were not fully correct.
This patch fixes the situation. The if and if_present clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95473
Ensure diagnostics from the prescanner are reported when running `flang-new -fsyntax-only` (i.e. only syntax parsing).
This keeps the diagnostics output of flang-new consistent with `f18 -fparse-only` when running the syntax parsing action, ParseSyntaxOnlyAction.
Summary of changes:
- Modify ParseSyntaxOnlyAction::ExecuteAction to report diagnostics
Differential Revision: https://reviews.llvm.org/D95220
Split the tests from acc-clause-validity.f90 in dedicated files by directives.
The file acc-clause-validity.f90 was getting too big to be correctly maintained.
Tests are identical.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95328
Update the preprocessor regression tests to use the new driver if the new driver is built (FLANG_BUILD_NEW_DRIVER=On), otherwise the tests will still run using f18.
Summary of changes:
- Introduce %flang to the regression tests, which points to the new driver if it is built or otherwise points to f18
- Update all tests in flang/test/Preprocessing/ to use %flang
Differential Revision: https://reviews.llvm.org/D94805
Expressions emitted to module files and error messages
sometimes contain conversions of integer results of inquiry
intrinsics; these are usually not needed, and can conflict
with "int" in the user's namespace. Improve folding so that
these conversions don't appear, and do some other clean-up
in adjacent code.
Differential Revision: https://reviews.llvm.org/D95172
This patch makes sure that diagnostics from the prescanner are reported
when running `flang-new -E` (i.e. only the preprocessor phase is
requested). More specifically, the `PrintPreprocessedAction` action is
updated.
With this patch we make sure that the `f18` and `flang-new` provide
identical output when running the preprocessor and the prescanner
generates diagnostics.
Differential Revision: https://reviews.llvm.org/D94782
It's possible to declare deferred shape array using the POINTER
statement, for example:
POINTER :: var(:)
When analyzing POINTER declarations, we were not capturing the array
specification information, if present. I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList". In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".
I also added a couple of small tests that fail to compile without these
changes.
Differential Revision: https://reviews.llvm.org/D95080
* IsArrayElement() needs another option to control whether it
should ignore trailing component references.
* Add IsObjectPointer().
* Add const Scope& variants of IsFunction() and IsProcedure().
* Make TypeAndShape::Characterize() work with procedure bindings.
* Handle CHARACTER length in MeasureSizeInBytes().
* Fine-tune FindExternallyVisibleObject()'s handling of dummy arguments
to conform with Fortran 2018: only INTENT(IN) and dummy pointers
in pure functions signify; update two tests accordingly.
Also: resolve some stylistic inconsistencies and add a missing
"const" in the expression traversal template framework.
Differential Revision: https://reviews.llvm.org/D95011
F18 Clause 19.4p9 says:
The associate names of an ASSOCIATE construct have the scope of the
block.
Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block:
R1102 associate-construct is: associate-stmt block end-associate-stmt
Associate statement associations are currently fully processed from left
to right, incorrectly interposing associating entities earlier in the
list on same-named entities in the host scope.
1 program p
2 logical :: a = .false.
3 real :: b = 9.73
4 associate (b => a, a => b)
5 print*, a, b
6 end associate
7 print*, a, b
8 end
Associating names 'a' and 'b' at line 4 in this code are now both
aliased to logical host entity 'a' at line 2. This happens because the
reference to 'b' in the second association incorrectly resolves 'b' to
the entity in line 4 (already associated to 'a' at line 2), rather than
the 'b' at line 3. With bridge code to process these associations,
f18 output is:
F F
F 9.73
It should be:
9.73 F
F 9.73
To fix this, names in right-hand side selector variables/expressions
must all be resolved before any left-hand side entities are resolved.
This is done by maintaining a stack of lists of associations, rather
than a stack of associations. Each ASSOCIATE statement's list of
assocations is then visited once for right-hand side processing, and
once for left-hand side processing.
Note that other construct associations do not have this problem.
SELECT RANK and SELECT TYPE each have a single assocation, not a list.
Constraint C1113 prohibits the right-hand side of a CHANGE TEAM
association from referencing any left-hand side entity.
Differential Revision: https://reviews.llvm.org/D95010
The utility routine WhyNotModifiable() needed to become more
aware of the use of pointers in data-refs; the targets of
pointer components are sometimes modifiable even when the
leftmost ("base") symbol of a data-ref is not.
Added a new unit test for WhyNotModifiable() that uses internal
READ statements (mostly), since I/O semantic checking uses
WhyNotModifiable() for all its definability checking.
Differential Revision: https://reviews.llvm.org/D94849
Add Semantic checks for OpenMP 4.5 - 2.7.4 Workshare Construct.
- The structured block in a workshare construct may consist of only
scalar or array assignments, forall or where statements,
forall, where, atomic, critical or parallel constructs.
- All array assignments, scalar assignments, and masked array
assignments must be intrinsic assignments.
- The construct must not contain any user defined function calls unless
the function is ELEMENTAL.
Test cases : omp-workshare03.f90, omp-workshare04.f90, omp-workshare05.f90
Resolve test cases (omp-workshare01.f90 and omp-workshare02.f90) marked as XFAIL
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93091
Add the following standard predefinitions that f18 supports:
* `__flang__`,
* `__flang_major__`,
* `__flang_minor__`,
* `__flang_patchlevel__`
Summary of changes:
- Populate Fortran::parser::Options#predefinitions with the default
supported predefinitions
Differential Revision: https://reviews.llvm.org/D94516
Currently the new flang driver always runs in free form mode. This patch
adds support for fixed form mode detection based on the file extensions.
Like `f18`, `flang-new` will treat files ending with ".f", ".F" and
".ff" as fixed form. Additionally, ".for", ".FOR", ".fpp" and ".FPP"
file extensions are recognised as fixed form files. This is consistent
with gfortran [1]. In summary, files with the following extensions are
treated as fixed-form:
* ".f", ".F", ".ff", ".for", ".FOR", ".fpp", ".FPP"
For consistency with flang/test/lit.cfg.py and f18, this patch also adds
support for the following file extensions:
* ".ff", ".FOR", ".for", ".ff90", ".fpp", ".FPP"
This is added in flang/lib/Frontend/FrontendOptions.cpp. Additionally,
the following extensions are included:
* ".f03", ".F03", ".f08", ".F08"
This is for compatibility with gfortran [1] and other popular Fortran
compilers [2].
NOTE: internally Flang will only differentiate between fixed and free
form files. Currently Flang does not support switching between language
standards, so in this regard file extensions are irrelevant. More
specifically, both `file.f03` and `file.f18` are represented with
`Language::Fortran` (as opposed to e.g. `Language::Fortran03`).
Summary of changes:
- Set Fortran::parser::Options::sFixedForm according to the file type
- Add isFixedFormSuffix and isFreeFormSuffix helper functions to
FrontendTool/Utils.h
- Change FrontendOptions::GetInputKindForExtension to support the missing
file extensions that f18 supports and some additional ones
- FrontendActionTest.cpp is updated to make sure that the test input is
treated as free-form
[1] https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-and-GCC.html
[2] https://github.com/llvm/llvm-project/blob/master/flang/docs/OptionComparison.md#notes
Differential Revision: https://reviews.llvm.org/D94228
Add support for option -I in the new Flang driver. This will allow for
included headers and module files in other directories, as the default
search path is currently the working folder. The behaviour of this is
consistent with the current f18 driver, where the current folder (i.e.
".") has the highest priority followed by the order of '-I's taking
priority from first to last.
Summary of changes:
- Add SearchDirectoriesFromDashI to PreprocessorOptions, to be forwarded
into the parser's searchDirectories
- Add header files and non-functional module files to be used in
regression tests. The module files are just text files and are used to
demonstrated that paths specified with `-I` are taken into account when
searching for .mod files.
Differential Revision: https://reviews.llvm.org/D93453
When a reference to a generic interface occurs in a specification
expression that must be emitted to a module file, we have a problem
when the generic resolves to a function whose name is inaccessible
due to being PRIVATE or due to a conflict with another use of the
same name in the scope. In these cases, construct a new name for
the specific procedure and emit a renaming USE to the module file.
Also, relax enforcement of PRIVATE when analyzing module files.
Differential Revision: https://reviews.llvm.org/D94815
The following driver invocation will generate an output file
in the same directory as the input file:
```
flang-new -fc1 -test-io test-input.f90
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy the
input file into a temporary directory before testing.
This is similar to https://reviews.llvm.org/D94243.
C843 states that "An entity with the INTENT attribute shall be a dummy
data object or a dummy procedure pointer." This change enforces that
and fixes some tests that erroneously violated this rule.
Differential Revision: https://reviews.llvm.org/D94781
Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the 'do' iteration variable is a variable in 'Firstprivate' clause.
Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp
Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D93205
When a use-associated procedure was included in a generic, we weren't
correctly recording that fact. The ultimate symbol was added rather than
the local symbol.
Also, improve the message emitted for the specific procedure by
mentioning the module it came from.
This fixes one of the problems in https://bugs.llvm.org/show_bug.cgi?id=48648.
Differential Revision: https://reviews.llvm.org/D94696
Generic type-bound interfaces for user-defined operators need to be formatted
as "OPERATOR(.op.)", not just ".op."
PRIVATE generics need to be marked as such.
Declaration ordering: when a generic interface shadows a
derived type of the same name, it needs to be emitted to the
module file at the point of definition of the derived type;
otherwise, the derived type's definition may appear after its
first use.
The module symbol for a module read from a module file needs
to be marked as coming from a module file before semantic
processing is performed on the contents of the module so that
any special handling for declarations in module files can be
properly activated.
IMPORT statements were sometimes missing for use-associated
symbols in surrounding scopes; fine-tune NeedImport().
Differential Revision: https://reviews.llvm.org/D94636
It's possible to declare an external procedure and then pass it as an
actual argument to a subprogram expecting a procedure argument. I added
tests for this and added an error message to distinguish passing an
actual argument with an implicit interface from passing an argument with
a mismatched explicit interface.
Differential Revision: https://reviews.llvm.org/D94505
If a module specifies default private accessibility, names that have
been use-associated are private by default. This was not reflected in
.mod files.
Differential Revision: https://reviews.llvm.org/D94602
In some contexts, including the motivating case of determining whether
the expressions that define the shape of a variable are "constant expressions"
in the sense of the Fortran standard, expression rewriting via Fold()
is not necessary, and should not be required. The inquiry intrinsics LBOUND,
UBOUND, and SIZE work correctly now in specification expressions and are
classified correctly as being constant expressions (or not). Getting this right
led to a fair amount of API clean-up as a consequence, including the
folding of shapes and TypeAndShape objects, and new APIs for shapes
that do not fold for those cases where folding isn't needed. Further,
the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any
associations of their symbols and work transparently on use-, host-, and
construct-association symbols; the tools used to resolve those associations have
been defined and documented more precisely, and their clients adjusted as needed.
Differential Revision: https://reviews.llvm.org/D94561
`CheckNoBranching` is currently handling only illegal branching out for constructs
with `Parser::Name` in them.
Extend the same for handling illegal branching out caused by `Parser::Label` based statements.
This patch could possibly solve one of the issues(typically branching out) mentioned in D92735.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93447
Remove duplicated function to check for required clauses on a directive. This was
still there from the merging of OpenACC and OpenMP common semantic checks and it can now be
removed so we use only one function.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93575
The following frontend driver invocation will generate 2 output files
in the same directory as the input files:
```
flang-new -fc1 input-1.f input-2.f
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy test
input files into a temporary directory.
Differential Revision: https://reviews.llvm.org/D94243
Internal subprograms have explicit interfaces. If an internal subprogram has
an alternate return, we check its explicit interface. But we were not
putting the label values of alternate returns into the actual argument.
I fixed this by changing the definition of actual arguments to be able
to contain a common::Label and putting the label for an alternate return
into the actual argument.
I also verified that we were already doing all of the semantic checking
required for alternate returns and removed a "TODO" for this.
I also added the test altreturn06.f90.
Differential Revision: https://reviews.llvm.org/D94017
Add semantic check for most of the restrictions for the declare directive.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D92741
This patch adds a frontend action for emitting object files. While Flang
does not support code-generation, this action remains a placeholder.
This patch simply provides glue-code to connect the compiler driver
with the appropriate frontend action.
The new action is triggered with the `-c` compiler driver flag, i.e.
`flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`,
so `-emit-obj` has to be marked as supported as well.
As code-generation is not available yet, `flang-new -c` results in a
driver error:
```
error: code-generation is not available yet
```
Hopefully this will help communicating the level of available
functionality within Flang.
The definition of `emit-obj` is updated so that it can be shared between
Clang and Flang. As the original definition was enclosed within a
Clang-specific TableGen `let` statement, it is extracted into a new `let`
statement. That felt like the cleanest option.
I also commented out `-triple` in Flang::ConstructJob and updated some
comments there. This is similar to https://reviews.llvm.org/D93027. I
wanted to make sure that it's clear that we can't support `-triple`
until we have code-generation. However, once code-generation is
available we _will need_ `-triple`.
As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and
is deleted. Instead, phases.f90 is added to demonstrate that users can
control compilation phases (indeed, `-c` is a phase control flag).
Reviewed By: SouraVX, clementval
Differential Revision: https://reviews.llvm.org/D93301
This patch adds some positive and failure tests for init and shutdown directives.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90786
Add support for options -D and -U in the new Flang driver.
Summary of changes:
- Create PreprocessorOptions, to be used by the driver then translated
into Fortran::parser::Options
- Create CompilerInvocation::setFortranOpts to pass preprocessor
options into the parser options
- Add a dedicated method, Flang::AddPreprocessingOptions, to extract
preprocessing options from the driver arguments into the preprocessor
command arguments
Macros specified like -DName will default to definition 1.
When defining macros, the new driver will drop anything after an
end-of-line character. This is consistent with gfortran and clang, but
different to what currently f18 does. However, flang (which is a bash
wrapper for f18), also drops everything after an end-of-line character.
So gfortran-like behaviour felt like the natural choice. Test is added
to demonstrate this behaviour.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D93401
As per Flang's coding guidelines
(flang/docs/C++style.md#error-messages):
```
Messages should start with a capital letter.
```
This patch updates error messages in the driver (new and old) so that
they conform with the guideline above.
This change was suggested in one of the recent reviews:
https://reviews.llvm.org/D93712. It felt like this deserved a dedicated
patch, so sending it separately.
If either `Prescan` or `Parse` generate any fatal errors, the new driver
will:
* report it (i.e. issue an error diagnostic)
* exit early
* return non-zero exit code
This behaviour is consistent with f18 (i.e. the old driver).
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93712
See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D93105
Co-authored-by: Valentin Clement <clementval@gmail.com>
When an abstract interface is defined, add the ABSTRACT attribute to
subprogram symbols that define the interface body. Make use of that
when writing .mod files to include "abstract" on the interface statement.
Also, fix a problem with the order of symbols in a .mod file. Sometimes
a name is mentioned before the "real" declaration, e.g. in an access
statement. We want the order to be based on the real definitions. In
these cases we replace the symbol name with an identical name with a
different source location. Then by sorting based on the source location
we get symbols in the right order.
Differential Revision: https://reviews.llvm.org/D93572
OpenMP 4.5 - Variables that appear in expressions for statement function definitions
may not appear in OpenMP Private, Firstprivate or Lastprivate clauses.
Test case : omp-private03.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93213
See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D93105
We were only checking the restrictions of IMPLICIT NONE(EXTERNAL) when a
procedure name is first encountered. But it can also happen with an
existing symbol, e.g. if an external function's return type is declared
before is it called. This change adds a check in that branch too.
Differential Revision: https://reviews.llvm.org/D93552
The behaviour triggered with this flag is consistent with `-fparse-only`
in `flang` (i.e. the throwaway driver). This new spelling is consistent
with Clang and gfortran, and was proposed and agreed on for the new
driver in [1].
This patch also adds some minimal logic to communicate whether the
semantic checks have failed or not. When semantic checks fail, a
frontend driver error is generated. The return code from the frontend
driver is then determined by checking the driver diagnostics - the
presence of driver errors means that the compilation has failed. This
logic is consistent with `clang -cc1`.
[1] http://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html
Differential Revision: https://reviews.llvm.org/D92854
This patch add some checks for the restriction on the routine directive
and fix several issue at the same time.
Validity tests have been added in a separate file than acc-clause-validity.f90 since this one
became quite large. I plan to split the larger file once on-going review are done.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92672
Update the allowed clauses for the SERIAL construct for the new OpenACC 3.1
specification.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92123
Names in EQUIVALENCE statements are only allowed to indicate local
objects as per 19.5.1.4, paragraph 2, item (10). Thus, a name appearing
in an EQUIVALENCE statement with no corresponding declaration in the
same scope is an implicit declaration of the name. If that scope
contains an IMPLICIT NONE, it's an error.
I implemented this by adding a state variable to ScopeHandler to
indicate if we're resolving the names in an EQUIVALENCE statement and
then checked this state when resolving names. I also added a test to
the existing tests for EQUIVALENCE statements.
Differential Revision: https://reviews.llvm.org/D93345
Elemental intrinsic function folding was not taking the lower
bounds of constant array arguments into account; these lower bounds
can be distinct from 1 when named constants appear as arguments.
LLVM bugzilla #48437.
Differential Revision: https://reviews.llvm.org/D93321
Some operators have more than one name, e.g. operator(==), operator(.eq).
That was working correctly in generic definitions but they can also
appear in other contexts: USE statements and access statements, for
example.
This changes FindInScope to always look for each of the names for
a symbol. So an operator may be use-associated under one name but
declared private under another name and it will be the same symbol.
This replaces GenericSpecInfo::FindInScope which was only usable in
some cases.
Add a version of FindInScope() that looks in the current scope to
simplify many of the calls.
Differential Revision: https://reviews.llvm.org/D93344
STORAGE_SIZE() is a standard inquiry intrinsic (size in bits
of an array element of the same type as the argument); SIZEOF()
is a common extension that returns the size in bytes of its
argument; C_SIZEOF() is a renaming of SIZEOF() in module ISO_C_BINDING.
STORAGE_SIZE() and SIZEOF() are implemented via rewrites to
expressions; these expressions will be constant when the necessary
type parameters and bounds are also constant.
Code to calculate the sizes of types (with and without alignment)
was isolated into Evaluate/type.* and /characteristics.*.
Code in Semantics/compute-offsets.* to calculate sizes and alignments
of derived types' scopes was exposed so that it can be called at type
instantiation time (earlier than before) so that these inquiry intrinsics
could be called from specification expressions.
Differential Revision: https://reviews.llvm.org/D93322
When merging use associations into a generic, we weren't handling
the case where the name that was use associated was itself a use
association. This is fixed by following that association to its
ultimate symbol (`useUltimate` in `DoAddUse`).
An example of the bug is `m12d` in `resolve17.f90`. `g` is associated
with `gc` in `m12c` which is associated with `gb` in `m12b`. It was that
last association that we weren't correctly following.
Differential Revision: https://reviews.llvm.org/D93343
Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.
Differential Revision: https://reviews.llvm.org/D93323
From OMP 5.0 [2.17.8]
Restriction:
If memory-order-clause is release,acquire, or acq_rel, list items must not be specified on the flush directive.
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D89879
Patch implements restrictions from 2.17.7 of OpenMP 5.0 standard for atomic Construct. Tests for the same are added.
One of the restriction
`OpenMP constructs may not be encountered during execution of an atomic region.`
Is mentioned in 5.0 standard to be a semantic restriction, but given the stricter nature of parser in F18 it's caught at parsing itself.
This patch is a next patch in series from D88965.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D89583
The semantic analysis of index-names of FORALL statements looks up symbols with
the same name as the index-name. This is needed to exclude symbols that are
not objects. But if the symbol found is host-, use-, or construct-associated
with another entity, the check fails.
I fixed this by getting the root symbol of the symbol found and doing the check
on the root symbol. This required creating a non-const version of
"GetAssociationRoot()".
Differential Revision: https://reviews.llvm.org/D92970
Add restriction on loop construct associated with DO CONCURRENT. Add couple of tests to ensure
clause validity checks.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92533
Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are of relevance to the runtime language support
library. Define a suite of corresponding C++ structure types
for the runtime library to use to interpret instances of the
descriptions.
Create instances of these description types in Semantics as
static initializers for compiler-created objects in the scopes
that define or instantiate user derived types.
Delete obsolete code from earlier attempts to package runtime
type information.
Differential Revision: https://reviews.llvm.org/D92802
Add couple of clause validity tests for the update directive and check for
the restriction where at least self, host or device clause must appear on the directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92447
This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development. We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding. Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.
Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
derived type instantiations so that the user can figure out which
instance caused a problem with a component, have been added as part
of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
is passed as an argument rather than just its intrinsic procedure table;
this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
actually is a single constant value and to validate a non-pointer
variable initializer or object component default value
* shape conformance checking has additional arguments that control
whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
a crash, which might be useful in the future
TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.
Differential Review: https://reviews.llvm.org/D92783
Add clause validity tests for the data construct. The default clause can appear only once
and this was not enforce in the ACC.td.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D91888
Add couple of clause validity tests for the update directive and check for
the restriction where at least self, host or device clause must appear on the directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92447
We were keeping the state of parsed equivalence sets in the class
DeclarationVisitor. A problem happened when analyzing the the specification
part of a declaration that contained an EQUIVALENCE statement followed by an
interface block. The same DeclarationVisitor object that was created for the
outer declaration was being used to analyze the specification part
of a procedure body in the interface block. When analyzing the specification
part of the procedure in the interface block, the names in the outer
declaration's EQUIVALENCE statement were erroneously compared with the names in
the arguments of the interface procedure. This resulted in a bogus error
message.
I fixed this by not checking equivalence sets when we're in an interface
block. I also added a test that will produce an error message without
this change.
Differential Revision: https://reviews.llvm.org/D92501
When the same generic name is use-associated from two modules, the
generics are merged into a single one in the current scope. This change
fixes some bugs in that process.
When a generic is merged, it can have two specific procedures with the
same name as the generic (c.f. module m7c in modfile07.f90). We were
disallowing that by checking for duplicate names in the generic rather
than duplicate symbols. Changing `namesSeen` to `symbolsSeen` in
`ResolveSpecificsInGeneric` fixes that.
We weren't including each USE of those generics in the .mod file so in
some cases they were incorrect. Extend GenericDetails to specify all
use-associated symbols that are merged into the generic. This is used to
write out .mod files correctly.
The distinguishability check for specific procedures of a generic
sometimes have to refer to procedures from a use-associated generic in
error messages. In that case we don't have the source location of the
procedure so adapt the message to say where is was use-associated from.
This requires passing the scope through the checks to make that
determination.
Differential Revision: https://reviews.llvm.org/D92492
Add the semantic checks for the OpenMP 4.5 - 2.15.3.3 Private clause.
1. Pointers with the INTENT(IN) attribute may not appear in a private clause.
2. Variables that appear in namelist statements may not appear in a private clause.
A flag 'InNamelist' is added to the Symbol::Flag to identify the symbols
in Namelist statemnts.
Test cases : omp-private01.f90, omp-private02.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90210
Add semantic check for the cache directive. According to section 2.10 from the specification:
A var in a cache directive must be a single array element or a simple subarray.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90184
Semantic check added to check and restrict the value of the parameter in the COLLAPSE or ORDERED clause
if it is larger than the number of nested loops following the construct.
Test Cases:
omp-do-collapse-positivecases.f90
omp-do-collapse.f90
omp-do-ordered-positivecases.f90
omp-do-ordered.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D89860
Semantic check to restrict the appearance of a variable that is part of another variable
(as an array or structure element) in a PRIVATE or SHARED clause.
Test Cases:
omp-parallel-private01.f90
omp-parallel-private02.f90
omp-parallel-private03.f90
omp-parallel-private04.f90
omp-parallel-shared01.f90
omp-parallel-shared02.f90
omp-parallel-shared03.f90
omp-parallel-shared04.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D89395
This patch introduce the separate parser for the memory-order-clause from the general
OmpClauseList. This parser still creates OmpClause node and therefore can use all the feature
from TableGen and the OmpStructureChecker.
This is applied only for the Flush construct in this patch and it should be applied for
atomic as well.
This is the approach we disscussed several time during the weekly call.
Reviewed By: kiranchandramohan, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D91839
`OmpStructureChecker` has too much boilerplate code in source file.
This patch:
1. Use helpers from `check-directive-structure.h` and reduces the boilerplate.
2. Use TableGen infrastructure as much as possible.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90834
Add some clause validity tests for the host_data directive to avoid future regressions.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91889
Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsic function NULL() with no actual
arguments.
Differential revision: https://reviews.llvm.org/D91657
When comparing LOGICAL operands using ".eq." or ".ne." we were not
guiding users to the ".eqv." and ".neqv." operations.
Differential Revision: https://reviews.llvm.org/D91736
When doing out-of-tree builds, FIR tests were failing. I made a change
similar to the one by @jurahul to fix this.
Differential Revision: https://reviews.llvm.org/D91654
According to section 19.4, paragraph 5, the scope of an ac-implied-do variable
is the enclosing ac-implied-do. But we were not creating new scopes upon
entry to an ac-implied-do. This was causing error messages to be erroneously
emitted.
I fixed, the code, added a test to array-constr-values.f90, added the test
folding15.f90 and corrected the test symbol05.f90.
Differential Revision: https://reviews.llvm.org/D91560
Add the semantic checks for the OpenMP 4.5 - 2.13.9 Depend clause.
1. List items in depend clause should not be zero length array sections.
2. A variable that is part of another variable like structure component
should not be specified on a depend clause.
Test cases : omp-depend01.f90, omp-depend02.f90, omp-depend03.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D89934
When comparing arrays whose shapes do not conform, the contant folding
code ran into problems trying to get the value of an extent that did not
exist. There were actually two problems. First, the routine
"CheckConformance()" was returning "true" when the compiler was unable
to get the extent of an array. Second, the function
"ApplyElementwise()" was calling "CheckConformance()" prior to folding
the elements of two arrays, but it was ignoring the return value.
Differential Revision: https://reviews.llvm.org/D91440
An io-unit that is an internal-file-variable is syntactically identical
to a file-unit-number expression that is a variable reference. An
ambiguous unit is initially parsed as an internal-file-variable. If
semantic analysis determines that the unit is not of character type,
it is rewritten as an internal-file-variable. This modification must
retain source coordinate information.
Differential revision: https://reviews.llvm.org/D91375
Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.
Updated to fix a circular dependence between shared library
binaries that was introduced by the original patch.
Differential revision: https://reviews.llvm.org/D91286
F18 clause 5.3.3 explicitly allows labels on program unit END statements.
Label resolution code accounts for this for singleton program units,
but incorrectly generates an error for host subprograms with internal
subprograms.
subroutine s(n)
call s1(n)
if (n == 0) goto 88 ! incorrect error
print*, 's'
contains
subroutine s1(n)
if (n == 0) goto 77 ! ok
print*, 's1'
77 end subroutine s1
88 end
Label resolution code makes a sequential pass over an entire file to
collect label information for all subprograms, followed by a pass through
that information for semantics checks. The problem is that END statements
may be separated from prior subprogram code by internal subprogram
definitions, so an END label can be associated with the wrong subprogram.
There are several ways to fix this. Labels are always local to a
subprogram. So the two separate passes over the entire file could probably
instead be interleaved to perform analysis on a subprogram as soon as the
end of the subprogram is reached, using a small stack. The stack structure
would account for the "split" code case. This might work.
It is possible that there is some not otherwise apparent advantage to
the current full-file pass design. The parse tree has productions that
provide access to a subprogram END statement "in advance". An alternative
is to access this information to solve the problem. This PR implements
this latter option.
Differential revision: https://reviews.llvm.org/D91217
`-###` has always been supported in the new flang driver. This patch
merely makes sure that it's included when printing the help screen (i.e.
`flang-new -help`).
Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.
Differential revision: https://reviews.llvm.org/D91209
The initial approach was to go with changing parser nodes from `std::list<parser::Name>` to `OmpObjectList`, but that might have lead to illegal programs.
Resolving the symbols inside `OmpAttributeVisitor`.
Fix a couple of `XFAIL` tests.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90538
This patch add some parsing and clause validity tests for the set directive.
It makes use of the possibility introduces in patch D90770 to check the restriction
were one of the default_async, device_num and device_type clauses is required but also
not more than once on the set directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D90771
Add the semantic checks for the OpenMP 4.5 - 2.15.4.1 copyin clause.
Resolve OpenMPThreadprivate directive since the list of items specified
in copyin clause should be threadprivate.
Test cases : omp-copyin01.f90, omp-copyin02.f90, omp-copyin03.f90,
omp-copyin04.f90, omp-copyin05.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D89385
When the bounds of an implied DO loop in an array constructor are
constant, the index variable of that loop is considered a constant
expression and can be used as such in the items in the value list
of the implied DO loop. Since the KIND type parameter values of items
in the value list can depend on the various values taken by such an
index, it is not possible to represent those values with a single
typed expression. So implement such loops by taking multiple passes
over the parse tree of the implied DO loop instead.
Differential revision: https://reviews.llvm.org/D90494
This patch implements the first frontend action for the Flang parser (i.e.
Fortran::parser). This action runs the preprocessor and is invoked with the
`-E` flag. (i.e. `flang-new -E <input-file>). The generated output is printed
to either stdout or the output file (specified with `-` or `-o <output-file>`).
Note that currently there is no mechanism to map options for the
frontend driver (i.e. Fortran::frontend::FrontendOptions) to options for
the parser (i.e. Fortran::parser::Options). Instead,
Frotran::parser::options are hard-coded to:
```
std::vector<std::string> searchDirectories{"."s};
searchDirectories = searchDirectories;
isFixedForm = false;
_encoding(Fortran::parser::Encoding::UTF_8);
```
These default settings are compatible with the current Flang driver. Further
work is required in order for CompilerInvocation to read and map
clang::driver::options to Fortran::parser::options.
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Differential Revision: https://reviews.llvm.org/D88381
Use `--match-full-lines` to make sure that FileCheck doesn't match the
output against the `CHECK` lines (which, like other comments, are also
printed).
More specifically, we want to make sure that the following `check` in the
input file:
```
! CHECK: <some-fortran-input>
```
is matched by FileCheck with `<some-fortran-input>` in the generated
output. Without `--match-full-lines`, that check-line will be matched
with `!CHECK: <some-fortran-input>` instead (which is also
printed together with other contents of the file).
Adding `--match-full-lines` makes the tests stricter and this change
revealed that some `check`s were passing only because that flag was
missing. These are updated accordingly.
Reviewed By: CarolineConcatto, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D90306
Subclause 10.1.12 in F'2018 prohibits forward references from
a specification expression to an object declared later in the
same specification part. Catch this error better and emit
specific error messages about the violation.
Differential revision: https://reviews.llvm.org/D90492
Fortran's FINAL feature is sensitive to object rank.
When an object's rank excludes it from finalization, but
the type has FINAL subroutines for other ranks, emit
a warning. This should be especially helpful in the
case of a scalar FINAL subroutine not being declared
(IMPURE) ELEMENTAL.
Differential revision: https://reviews.llvm.org/D90495
READ(CVAR)[,item-list] with a character variable CVAR
could be parsed as an unformatted READ from an internal
unit or as a formatted READ from the default external unit
with a needlessly parenthesized variable format. We parse
it as the former, but Fortran doesn't have unformatted
internal I/O.
Differential revision: https://reviews.llvm.org/D90493
From below mentioned standard references
OpenACC 3.0 Standards document
840 • A program may not branch into or out of an OpenACC parallel construct
OpenMP 5.0 Standards document
A program that branches into or out of a parallel region is non-conforming.
This patch
Resolves the issue of exit out of a parallel region, other branching out issues like goto statements are not handled with this patch.
Moves code from D87906 to be reused by other OpenMP/OpenACC to check-directive-structure.h.
Adds support in OpenMP parallel construct and a test case to verify.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D88655
Enter data can have the copyin clause and exit data can have the copyout clause.
Both clauses support modifier with other directive but for these two directives no modifier
are supported. This semantic check enforce this rule.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90280
In the OpenACC specification, there are two different self clause. One for the
update directive with a var-list argument. This clause is a synonym of the host clause.
The second self clause is present for most of the compute construct and takes an optional
condition. To solve this ambiguity, the self clause for the update directive is directly
translated to a host clause during the parsing. The self clause in AccClause refers always
to the compute construct clause.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90185
2 Bug fixes:
- Do not resolve procedure as intrinsic if they appeared in an
EXTERNAL attribute statement (one path was not considering this flag)
- Emit an error if a procedure resolved to be an intrinsic function
(resp. subroutine) is used as a subroutine (resp. function).
Lowering was attempted while the evaluate::Expression for the
call was missing without any errors.
1 behavior change:
- Do not implicitly resolve subroutines (resp. functions) as intrinsics
because their name is the name of an intrinsic function (resp.
subroutine). Add justification in documentation.
Reviewed By: klausler, tskeith
Differential Revision: https://reviews.llvm.org/D90049
This patch introduces the dependencies required to read and manage input files
provided by the command line option. It also adds the infrastructure to create
and write to output files. The output is sent to either stdout or a file
(specified with the `-o` flag).
Separately, in order to be able to test the code for file I/O, it adds
infrastructure to create frontend actions. As a basic testable example, it adds
the `InputOutputTest` FrontendAction. The sole purpose of this action is to
read a file from the command line and print it either to stdout or the output
file. This action is run by using the `-test-io` flag also introduced in this
patch (available for `flang-new` and `flang-new -fc1`). With this patch:
```
flang-new -test-io input-file.f90
```
will read input-file.f90 and print it in the output file.
The `InputOutputTest` frontend action has been introduced primarily to
facilitate testing. It is hidden from users (i.e. it's only displayed with
`--help-hidden`). Currently Clang doesn’t have an equivalent action.
`-test-io` is used to trigger the InputOutputTest action in the Flang frontend
driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1"
by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to
“flang-new -fc1” without `-E`. This way we make sure that the preprocessor is
_not_ run in the frontend driver. This is the desired behaviour: `-test-io`
should only read the input file and print it to the output stream.
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Differential Revision: https://reviews.llvm.org/D87989
Remove the assumption that the path separator is `/`. Use functions from `llvm::sys::path` instead.
Reviewed By: isuruf, klausler
Differential Revision: https://reviews.llvm.org/D89369
I added a test to verify that the associated symbol did not have errors before
doing the anaylsis of a call to a component ref along with a test that
triggers the original problem.
Differential Revision: https://reviews.llvm.org/D90074
wait and atomic directives are represented by OpenACCWaitConstruct, OpenACCAtmicConstruct in the parser. Those contrsuct were
not taken into account in the semantic check so far.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88628
In my previous implementation of the semantic checks for ASSOCIATED(), I
had neglected to check the TARGET= argument for objects to ensure that
it has either the POINTER or TARGET attributes.
I added an implementation and a test.
Differential Revision: https://reviews.llvm.org/D89717
When processing declarations in resolve-names.cpp, we were returning a
symbol that had SubprogramName details to PushSubprogramScope(), which
expects a symbol with Subprogram details.
I adjusted the code and added a test.
Differential Revision: https://reviews.llvm.org/D89829
Check INTENT(OUT)/INTENT(INOUT) constraints for actual argument
of intrinsic procedure calls.
- Adding a common::Intent field to the IntrinsicDummyArgument
in the intrinsic table.
- Propagating it to the DummyDataObject intent field so that it can
later be used in CheckExplicitDataArg semantic checks.
- Add related tests.
- Fix regression (C846 false error), C846 INTENT(OUT) rule does
not apply to intrinsic call. Propagate the information that we
are in an intrinsic call up to CheckExplicitDataArg (that is
doing this check). Still enforce C846 on intrinsics other than MOVE_ALLOC (for which
allocatable coarrays are explicitly allowed) since it's not clear it is allowed in all
intrinsics and allowing this would lead to runtime penalties in the intrinsic runtime.
Differential Revision: https://reviews.llvm.org/D89473
From OpenACC 3.0 Standards document
840 • A program may not branch into or out of an OpenACC parallel construct.
Exits are allowed provided it does not cause an exit outside the parallel region.
Test case exits out of the inner do loop, but it is still inside the parallel region.
Patch tries to extract labels from block attached to a construct,
If the exit is to a label not in the collected list then flags an error.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D87906
We had neglected to check for name mismatches for procedure definitions that
appear in interfaces.
I also changed label11.f90 to an error test since I think they're better than
"FileCheck" tests.
Differential Revision: https://reviews.llvm.org/D89611
Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to
fail.
I fixed this by changing the entry for "ASSOCIATED" in the intrinsics table to
accept "AnyPointer" which contains a new "KindCode" of "pointerType". I also
changed the function "FromActual()" to return a typeless intrinsic when called
on a pointer, which duplicates its behavior for BOZ literals. This required
changing the analysis of procedure arguments. While testing processing for
procedure arguments, I found another bad call to `CHECK()` which I fixed.
I made several other changes:
-- I implemented constant folding for ASSOCIATED().
-- I fixed handling of NULL() in relational operations.
-- I implemented semantic analysis for ASSOCIATED().
-- I noticed that the semantics for ASSOCIATED() are similar to those for
pointer assignment. So I extracted the code that pointer assignment uses
for procedure pointer compatibility to a place where it could be used by
the semantic analysis for ASSOCIATED().
-- I couldn't figure out how to make the general semantic analysis for
procedure arguments work with ASSOCIATED()'s second argument, which can
be either a pointer or a target. So I stopped using normal semantic
analysis for arguments for ASSOCIATED().
-- I added tests for all of this.
Differential Revision: https://reviews.llvm.org/D88313
- Rework the host runtime table so that it is constexpr to avoid
having to construct it and to store/propagate it.
- Make the interface simpler (remove many templates and a file)
- Enable 16bits float folding using 32bits float host runtime
- Move StaticMultimapView into its own header to use it for host
folding
Reviewed By: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D88981
The OpenMP 5.0 standard restricts nowait clause to appear only once on sections
directive.
See OpenMP 5.0
- 2.8.1
- point 3 in restrictions.
Added a test with fix.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D88556
`OmpStructureChecker` is supposed to work only with `parser::OmpClause`
after tablegen changes for OpenMP and OpenACC were introduced.
Hence `OmpMemoryOrderClause`, `OmpAtomicMemoryOrderClause` and similar ones were failing
to catch semantic errors, inspite of having code for semantic checks.
This patch tries to change parser for `OmpMemoryOrderClause` and similar dependent ones
and use `OmpClauseList` which resides/comes from common tablegen for OpenMP/OpenACC eventually using `parser::OmpClause`.
This patch also tries to :
1. Change `OmpCriticalDirective` in `openmp-parsers.cpp` to support `OmpClauseList`.
2. Check-flang regresses when changes were introduced due to missing semantic checks in OmpCritical, patch implements them at the minimal level to pass the regression.
3. Change tablegen to support Hint clause.
4. Adds missing source locations `CharBlock Source` in each atomic construct.
5. Remove dead code realted to `memory-order-clauses` after moving to `OmpClauseList`.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88965
The semantics pass currently checks for several constraints
that apply to the use of whole assumed-size arrays in various
contexts, but C1002 wasn't really implemented. This patch
implements C1002 by disallowing the use of whole assumed-size
arrays in expressions and variables unless specifically
allowed by the context. This centralizes the error reporting,
which has been improved with a link to the array's declaration.
Differential revision: https://reviews.llvm.org/D88691
This patch fix the device_num and device_type clauses used in the init clause. device_num was not
spelled correctly in the parser and was to restrictive with scalarIntConstantExpr instead of scalarIntExpr.
device_type is now taking a list of ScalarIntExpr.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88571
Currently Flang uses TextDiagnostic, TextDiagnosticPrinter &
TestDiagnosticBuffer classes from Clang (more specifically, from
libclangFrontend). This patch introduces simplified equivalents of these
classes in Flang (i.e. it removes the dependency on libclangFrontend).
Flang only needs these diagnostics classes for the compiler driver
diagnostics. This is unlike in Clang in which similar diagnostic classes
are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the
implementations introduced here are relatively basic. We can extend them
in the future if this is required.
This patch also enhances how the diagnostics are printed. In particular,
this is the diagnostic that you'd get _before_ the changes introduced here
(no text formatting):
```
$ bin/flang-new
error: no input files
```
This is the diagnostic that you get _after_ the changes introduced here
(in terminals that support it, the text is formatted - bold + red):
```
$ bin/flang-new
flang-new: error: no input files
```
Tests are updated accordingly and options related to enabling/disabling
color diagnostics are flagged as supported by Flang.
Reviewed By: sameeranjoshi, CarolineConcatto
Differential Revision: https://reviews.llvm.org/D87774
Represent FINAL subroutines in the symbol table entries of
derived types. Enforce constraints. Update tests that have
inadvertent violations or modified messages. Added a test.
The specific procedure distinguishability checking code for generics
was used to enforce distinguishability of FINAL procedures.
(Also cleaned up some confusion and redundancy noticed in the
type compatibility infrastructure while digging into that area.)
Differential revision: https://reviews.llvm.org/D88613
SAVE statement, according to 8.6.14, must apply to the same scoping
unit, that excludes nested scoping units. For example, if the SAVE
statement is found in a MODULE, the functions contained in that module
should not inherit the SAVE attribute. I think that the code was doing
this, failing the following source:
```
MODULE pippo
SAVE
CONTAINS
PURE FUNCTION fft_stick_index( )
IMPLICIT NONE
INTEGER :: fft_stick_index
INTEGER :: mc !error: A pure subprogram may not have a variable with the SAVE attribute
END FUNCTION
END MODULE
```
Differential Revision: https://reviews.llvm.org/D88279
1. Section 2.5 : Parallel Construct
2. Section 2.7.1 : Loop Construct
3. Section 2.7.2 : Sections Construct
4. Section 2.7.3 : Single Construct
5. Section 2.7.4 : Workshare Construct
6. Section 2.8.1 : Simd Construct
7. Section 2.8.3 : Loop Simd Construct
8. Section 2.9.1 : Task Construct
9. Section 2.9.2 : Taskloop Construct
10. Section 2.9.3 : Taskloop Simd Construct
Most of the test cases added as part of this change contains semantic errors except few cases which are semantically correct but thrown a semantic error.
Currently flang is not throwing the errors for these cases and throwing semantic errors for the following correct test cases
{omp-do03.f90 , omp-loop-simd01.f90 , omp-simd02.f90 , omp-taskloop01.f90}
Hence, all the test cases are marked as XFAIL.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87908
Hew more closely to the C17 standard; perform macro replacement
of arguments to function-like macros unless they're being stringified
or pasted. Test with a model "assert" macro idiom that exposed
the problem.
Differential Revision: https://reviews.llvm.org/D87650
According to section 9.4.1, paragraph 3,
If the starting point is greater than the ending point, the substring has
length zero
But the compilers code for substring processing was failing a call to `CHECK()`
in this case. I fixed this by just setting the number of items in the
resulting string to 0 for this situation.
Differential Revision: https://reviews.llvm.org/D87799
C-style /*comments*/ are removed during preprocessing directive
tokenization, but Fortran !comments need to be specifically
allowed.
Fixes LLVM bugzilla 47466.
Differential Revision: https://reviews.llvm.org/D87638
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Also, once I corrected the bad dereference, the compiler was putting out
misleading error messages. The underlying error us due to violating section
7.5.10, paragraph 4, which states:
A structure constructor shall not appear before the referenced type is
defined.
I fixed this by testing to see if a type that is used in a structure
constructor is forward referenced.
Differential Revision: https://reviews.llvm.org/D87535
Change the analyzed form of type-bound assignment to match that of call
statements. Resolve the binding name to a specific subprogram when
possible by using `GetBindingResolution`. Otherwise leave it as a
type-bound procedure call.
Differential Revision: https://reviews.llvm.org/D87541
Integer case values were being compared as unsigned by operator<
on evaluate::value::Integer. Change that to signed so that overlap
can be detected correctly.
Explicit CompareUnsigned and BLT are still available if unsigned
comparison is needed.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47309
Differential Revision: https://reviews.llvm.org/D87595
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Differential Revision: https://reviews.llvm.org/D87535
Summary:
This is the first patch implementing the new Flang driver as outlined in [1],
[2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver
(`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the
current Flang throwaway driver, `flang`, can be replaced with `flang-new`.
Currently only 2 options are supported: `-help` and `--version`.
`flang-new` is implemented in terms of libclangDriver, defaulting the driver
mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the
driver runs in Flang mode regardless of the name of the binary inferred from
argv[0].
The design of the new Flang compiler and frontend drivers is inspired by it
counterparts in Clang [3]. Currently, the new Flang compiler and frontend
drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend.
To identify Flang options, this patch adds FlangOption/FC1Option enums.
Driver::printHelp is updated so that `flang-new` prints only Flang options.
The new Flang driver is disabled by default. To enable it, set
`-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to
`LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”).
[1] “RFC: new Flang driver - next steps”
http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
[2] “RFC: Adding a fortran mode to the clang driver for flang”
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
[3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang”
http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: richard.barton.arm, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D86089
When we define a derived type that extends another derived type, we can then
create a structure constructor that contains values for the fields of both the
child type and its parent. The compiler's internal representation of that
value contains the name of the parent type where a component name would
normally appear. This caused an assert during contant folding.
There are three cases for components that appear in structure constructors.
The first is the normal case of a component appearing in a structure
constructor for its type.
The second is a component of the parent (or grandparent) type appearing in a
structure constructor for the child type.
The third is the parent type component, which can appear in the structure
constructor of its child.
There are also cases where the component can be arrays.
I created the test case folding12.f90 that covers all of these cases and
modified the code to handle them.
Most of my changes were to the "Find()" method of the type
"StructureConstructor" where I added code to cover the second and third cases
described above. To handle these cases, I needed to create a
"StructureConstructor" for the parent type component and return it. To handle
returning a newly created "StructureConstructor", I changed the return type of
"Find()" to be "std::optional" rather than an ordinary pointer.
This change supersedes D86172.
Differential Revision: https://reviews.llvm.org/D87151
Change how generic operators and assignments are checked for
distinguishable procedures. Because of how they are invoked, available
type-bound generics and normal generics all have to be considered
together. This is different from how generic names are checked.
Move common part of checking into DistinguishabilityHelper so that it
can be used in both cases after the appropriate procedures have been
added.
Cache result of Procedure::Characterize(Symbol) in a map in
CheckHelper so that we don't have to worry about passing the
characterized Procedures around or the cost of recomputing them.
Add MakeOpName() to construct names for defined operators and assignment
for using in error messages. This eliminates the need for different
messages in those cases.
When the procedures for a defined operator or assignment are undistinguishable,
include the type name in the error message, otherwise it may be ambiguous.
Add missing check that procedures for defined operators are functions
and that their dummy arguments are INTENT(IN) or VALUE.
Differential Revision: https://reviews.llvm.org/D87341
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
The DumpSymbolsSources() routine ordered its output by the addresses
of the names of the symbols, and was susceptible to variation across
environments. Fixed by using a multimap using the values of the names.
Differential Revision: https://reviews.llvm.org/D87035
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Don't use just 128-bit integer as the type for integer
CASE statement constants. Use the actual type of the
literal constants that appeared.
Differential Review: https://reviews.llvm.org/D86875
Conformance checking of the shapes of the operands of
array expressions can't, of course, always be done at
compilation time; but when the shapes are known and
nonconformable, we should catch the errors that we can.
Differential Revision: https://reviews.llvm.org/D86887
Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic representation that results in a SubscriptInteger
that can then be converted.
This is a minor simplification, but it's worth doing because
it is believed to also be a work-around for bugs in the MSVC
compiler with overload resolution that affect the expression
traversal framework.
Differential Revision: https://reviews.llvm.org/D86551
Compilation of the following program currently generates a warning message:
i = 1
if (i .eq. 0) then
write(6, 200) i
200 format (I8)
end if
write(6, 200) i
end
x.f90:6:9: Label '200' is not in scope
write(6, 200) i
^^^^^^^^^^^^^^^
Whereas branch targets must conform to the Clause 11.1.2.1 program
requirement "Transfer of control to the interior of a block from
outside the block is prohibited, ...", this doesn't apply to format
statement references.
This patch fix the prasing for the gang-arg values for the gang clause. It also adds
some clause validity tests for the loop construct.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86584
The tile clause in OpenACC 3.0 imposes some restriction. Element in the tile size list are either * or a
constant positive integer expression. If there are n tile sizes in the list, the loop construct must be immediately
followed by n tightly-nested loops.
This patch implement these restrictions and add some tests.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86655
A number of I/O syntax rules involve variables that will be written to,
and must therefore be definable. This includes internal file variables,
IOSTAT= and IOMSG= specifiers, most INQUIRE statement specifiers, a few
other specifiers, and input variables. This patch checks for
these violations, and implements several additional I/O TODO constraint
checks.
Differential Revision: https://reviews.llvm.org/D86557
When an illegal character appears in Fortran source (after
preprocessing), catch and report it in the prescanning phase
rather than leaving it for the parser to cope with.
Differential Revision: https://reviews.llvm.org/D86553
Accept and represent "global" compiler directives that appear
before and between program units in a source file.
Differential Revision: https://reviews.llvm.org/D86555
If the label field is empty, and macro replacement occurs,
the rescanned text might be misclassified as a comment card
if it happens to begin with a C or a D. Insert a leading
space into these otherwise empty label fields.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47173
A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process specification parts
before execution parts, this may be the first time we encounter the
variable. We were assuming the variable was implicitly declared in the
scope where it was encountered, leading to an error because local
variables may not be referenced in specification expressions.
The fix is to tentatively create the implicit variable in the host
procedure because that is the only way the specification expression can
be valid. We mark it with the flag `ImplicitOrError` to indicate that
either it must be implicitly defined in the host (by being mentioned in
the execution part) or else its use turned out to be an error.
We need to apply the implicit type rules of the host, which requires
some changes to implicit typing.
Variables in common blocks are allowed to appear in specification expressions
(because they are not locals) but the common block definition may not appear
until after their use. To handle this we create common block symbols and object
entities for each common block object during the `PreSpecificationConstruct`
pass. This allows us to remove the corresponding code in the main visitor and
`commonBlockInfo_.curr`. The change in order of processing causes some
different error messages to be emitted.
Some cleanup is included with this change:
- In `ExpressionAnalyzer`, if an unresolved name is encountered but
no error has been reported, emit an internal error.
- Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object
that implements it. Change the interface to pass in names rather
than having to get the first character of the name.
- Change `DeclareObjectEntity` to have the `attrs` argument default
to an empty set; that is the typical case.
- In `Pre(parser::SpecificationPart)` use "structured bindings" to
give names to the pieces that make up a specification-part.
- Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement`
and make use of that in PreSpecificationConstruct.
Differential Revision: https://reviews.llvm.org/D86322
This patch fix the usage of the wait-argument in a clause and add several tests and fix the unparsing of
the wait-argument.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D86325
When we report an error for a bad character kind, don't keep it in the
`DeclTypeSpec`. Otherwise there could be further problems. In this case,
`ComputeOffsets()` got an assertion error because we didn't recognize
`CHARACTER(*,8)` as needing a descriptor because of the bad kind.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47173
Differential Revision: https://reviews.llvm.org/D86357
When a procedure name was used on the RHS of an assignment we were not
reporting the error. When one was used in an expression the error
message wasn't very good (e.g. "Operands of + must be numeric; have
INTEGER(4) and untyped").
Detect these cases in ArgumentAnalyzer and emit better messages,
depending on whether the named procedure is a function or subroutine.
Procedure names may appear as actual arguments to function and
subroutine calls so don't report errors in those cases. That is the same
case where assumed type arguments are allowed, so rename `isAssumedType_`
to `isProcedureCall_` and use that to decide if it is an error.
Differential Revision: https://reviews.llvm.org/D86107
As with use-associated symbols, copy the attributes and flags from the
original symbol onto host-associated symbols when they are created.
This was showing up as an error on a deallocate of a host-associated
name. We reported an error because the symbol didn't have the POINTER
or ALLOCATABLE attribute.
Differential Revision: https://reviews.llvm.org/D85763
This adds a test for D85862 to ensure that preprocessor definitions
passed on command lines don't regress in future.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D85967
OpenACC combined construct can have an optional end directive. This patch handle this
case in the parsing/unparsing with a canonicalization step. Unlike OmpEndLoopDirective,
this doesn't need a special treatment in the pre-fir tree as there is no clause attached to
a AccEndCombinedDirective.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D84481
The shape (esp. the size) of the result of a call to TRANSFER
is implemented according to the definition in the standard.
Differential Revision: https://reviews.llvm.org/D85866
Character literal substrings used as arguments were causing asserts. This
happened when the code was trying to get the DynamicType of the substring. We
were only recording the DynamicType of the Designator on which the substring
was based. For character literal substrings, the Designator was a character
literal, and we weren't handling getting its type.
I fixed this by changing the `GetType()` method for `DynamicType` to check to
see if we were getting the type of a `Substring` and calculating the type of
the substring by getting the number of bytes in an element of the string.
I also changed the test `resolve49.f90` with some tests, one of which causes
the original crash.
Differential Revision: https://reviews.llvm.org/D85908
If an unrestricted specific intrinsic function name is first encountered
as an actual argument, it should be interpreted as an object entity,
not a procedure entity.
Fix some tests that depended on the previous interpretation by adding
explicit INTRINSIC statements.
Differential Revision: https://reviews.llvm.org/D85792
Allow compiler directives in the implicit-part and before USE statements
in the specification-part.
Differential Revision: https://reviews.llvm.org/D85693
If a bound of a subscript triplet is present but fails to analyze
due to an error, return nullopt rather than returning a Triplet with
that bound missing. This is so we can distinguish an absent bound from
an erroneous one and avoid spurious errors.
Differential Revision: https://reviews.llvm.org/D85672
To prevent mistokenization of CHARACTER*2HXY as a Hollerith
literal constant while allowing it in DATA A/2*2HXY/, there's
a little state that tracks whether a / has been seen earlier
in the same statement. But it was being reset on each line,
not statement, so Hollerith in a DATA statement continuation
line was incorrectly tokenized. Fixed.
Differential Revision: https://reviews.llvm.org/D85571
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: sscalpone, AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Objects that are storage associated by EQUIVALENCE and
initialized with DATA are initialized by creating a
compiler temporary data object in the same scope,
assigning it an offset, type, and size that covers the
transitive closure of the associated initialized original
symbols, and combining their initializers into one common
initializer for the temporary.
Some problems with offset assignment of EQUIVALENCE'd objects
in COMMON were exposed and corrected, and some more error
cases are checked.
Remove obsolete function.
Small bugfix (nested implied dos).
Add a test.
Fix struct/class warning.
Differential Revision: https://reviews.llvm.org/D85560
In the example below we were producing the error message
"Assignment to constant 'f' is not allowed":
```
function f() result(r)
f = 1.0
end
```
This changes it to a more helpful message when the LHS is a subprogram
name and also mentions the function result name when it's a function.
Differential Revision: https://reviews.llvm.org/D85483
Add `-fimplicit-none-type-always` to treat each specification-part
like it has `IMPLICIT NONE`. This is helpful for enforcing good Fortran
programming practices. We might consider something similar for
`IMPLICIT NONE(EXTERNAL)` as well.
Add `-fimplicit-none-type-never` to ignore occurrences of `IMPLICIT NONE`
and `IMPLICIT NONE(TYPE)`. This is to handle cases like the one below,
which violates the standard but it accepted by some compilers:
```
subroutine s(a, n)
implicit none
real :: a(n)
integer :: n
end
```
Differential Revision: https://reviews.llvm.org/D85363
This patch remove duplicated code between the check-omp-structure and the check-acc-structure
and unify it into a check-directive-structure templated class.
Reviewed By: kiranchandramohan, sscalpone, ichoyjx
Differential Revision: https://reviews.llvm.org/D85104
Based on https://reviews.llvm.org/D84022 with additional changes to
maintain out-of-tree builds.
Original commit message:
Currently the binaries are output directly into the bin subdirectory of
the build directory. This doesn't work correctly with multi-config
generators which should output the binaries into <CONFIG_NAME>/bin
instead.
The original patch was implemented by David Truby and the additional
changes added here were also proposed by David Truby.
Differential Revision: https://reviews.llvm.org/D85078/
Co-authored-by: David Truby <david.truby@arm.com>
1. Annotate the sources with constraint numbers.
2. Add tests for
*C7107 (R765) digit shall have one of the values 0 or 1.
*C7108 (R766) digit shall have one of the values 0 through 7.
*C7109 (R764) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where explicitly allowed in 16.9 as an actual argument of an intrinsic procedure.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D84504
Add a usage string and a defaults section that clarifies:
* If no input files are given, f18 reads from stdin
* If no input files are given, f18 dumps the parse tree.
* The default behaviour is to exec F18_FC.
* The fefault F18_FC setting is 'gfortran'
Adds a simple regression test which tests the top and tail of the help
screen and the exit status.
Depends on D84855
Differential Revision: https://reviews.llvm.org/D84856
When flang is invoked with no files it waits for input on stdin. Make it
print a message saying this to prevent the user being surprised.
Differential Revision: https://reviews.llvm.org/D84855
CMPLX folding was expecting only one arguments in case X argument
is complex. This is wrong since there is also the optional KIND
argument.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D84936
I fixed an assert caused by passing an empty array as the source= argument to
RESHAPE(). In the process, I noticed that there were no tests for RESHAPE(),
so I wrote a test that covers all the description in 16.9.163. In the process,
I made the error messages more consistent and descriptive. I also changed the
test to see if a reference to an intrinsic function was a constant to say that
it is a constant if it's a refererence to an invalid intrinsic. This avoids
emitting multiple messages for the same erroneous source.
Differential Revision: https://reviews.llvm.org/D84904
When declaring the same variable twice with an initialization, we were failing
an internal check. I fixed this by checking to see if the associated symbol
already had an error.
I added tests for pointer and non-pointer initialization of duplicate names.
Differential Revision: https://reviews.llvm.org/D84969
To make it easier for lowering to identify which symbols from the host
are captured by internal subprograms, create HostAssocDetails for them.
In particular, if a symbol is referenced and it is contained in a
subprogram or main program that is not the same as the containing
program unit of the reference, a HostAssocDetails symbol is created
in the current scope.
Differential Revision: https://reviews.llvm.org/D84889
Summary:
Currently the binaries are output directly into the bin subdirectory of the
build directory. This doesn't work correctly with multi-config generators which
should output the binaries into <CONFIG_NAME>/bin instead.
Reviewers: sscalpone, richard.barton.arm
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84022
When an instrinsic function is declared in a type declaration statement
we need to set the INTRINSIC attribute and (per 8.2(3)) ignore the
specified type.
To simplify the check, add IsIntrinsic utility to BaseVisitor.
Also, intrinsics and external procedures were getting assigned a size
and offset and they shouldn't be.
Differential Revision: https://reviews.llvm.org/D84702
Move `ResolveAccParts` and `ResolveOmpParts` from resolve-names.cpp to
resolve-directives.{h,cpp}. Move the implementation in the classes
`DirectiveAttributeVisitor`, `AccAttributeVisitor`, and
`OmpAttributeVisitor` to resolve-directives.cpp as well.
To allow this to happen, move `EvaluateIntExpr` and introduce
`EvaluateInt64` to resolve-names-utils.h. The latter is also useful
elsewhere in resolve-names.cpp for converting an Expr to std::int64_t.
The other problem was that `ResolveDesignator` was called from the code
that was moved. At the moment it doesn't seem to be doing anything so I
removed the calls (and no tests failed). If it proves to be needed, we
can either resolve those designators in resolve-names.cpp or pass the
`ResolveDesignator` function in to the code that needs to call it.
Differential Revision: https://reviews.llvm.org/D84768
If a symbol (that is not a dummy argument) is implicitly declared inside
a statement function, don't create it in the statement function's scope.
Instead, treat statement functions like blocks when finding the inclusive
scope and create the symbol there.
Add a new flag, StmtFunction, to symbols that represent statement functions.
Differential Revision: https://reviews.llvm.org/D84588
Summary:
As a corrollary, these tests are now run as part of the check-flang
target.
Reviewers: sscalpone
Subscribers: mgorny, delcypher, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83946
Summary:
Expressions like `iVar==z'fe'` were causing an assertion error because
the `Relate()` function in `Evaluate/tools.cpp` that processes
relational operators didn't deal with BOZ literals, which are typeless.
I fixed this by checking to see if the operands are BOZ literals. If
so, if the other operand is REAL, I convert them to REAL. Otherwise, I convert
them to integers with default kind.
I also added a test to resolve63.f90 that triggers the problem.
Reviewers: tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83917
Summary:
When a constant array of empty strings goes through contant folding, the result
is something that contains no bytes. If this array is passed to the intrinsic
function `RESHAPE()`, we were not handling things correctly. I fixed this by
checking for an empty destination when calling the function `CopyFrom()` on an
array of strings.
I also added a test with a couple of different examples that trigger the
problem.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84352
The prescanner looks for implicit continuation lines when
there are unclosed parentheses at the end of a line, so that
source preprocessing macro references with arguments that span
lines are recognized. The condition that determines this
implicit continuation has been put into a predicate member
function and corrected to apply only when the following line
is source (not a preprocessing directive, comment, &c.).
Fixes bugzilla #46768.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84280
In fixed form source, complain when a label digit appears
outside the label field & when a non-digit appears in the label
field.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84283
Old-style C /*comments*/ are omitted from preprocessor directive
token sequences by the prescanner, but line-ending C++ and Fortran
free-form comments are not since their handling might depend on
the directive. Add code to skip these line-ending comments as
appropriate in place of existing code that just skipped blanks.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84061
Summary:
This patch enhances parser support for taskwait construct to OpenMP 5.0.
2.17.5 taskwait Construct
!$omp taskwait [clause[ [,] clause] ... ]
where clause is one of the following:
depend([depend-modifier,]dependence-type : locator-list)
The patch includes code changes and testcase modifications.
Reviewed By: Valentin Clement, Kiran Chandramohan
Differential Revision: https://reviews.llvm.org/D82255
When an intrinsic is referenced in a module scope, a symbol for it is
added. When that module is USEd, the intrinsic should not be included.
Otherwise we can get ambiguous reference errors with the same intrinsic
coming from two difference modules.
Differential Revision: https://reviews.llvm.org/D83905
A SAVE statement with no entity list applies the SAVE attribute only to
the entities that it is allowed on. We were applying it to automatic
data objects and reporting an error that they can't have SAVE.
The fix is to change `DeclarationVisitor::CheckSaveAttr` to check for
automatic objects. That controls both checking and setting the
attribute. This allows us to remove the check from `CheckSpecExpr`
(along with `symbolBeingChecked_`). Also, it was only called on constant
objects so the non-const overload can be eliminated.
The check in `CheckSpecExpr` is replaced by an explicit check for
automatic objects in modules. This caught an error in modfile03.f90 so
that part of the test was eliminated.
Differential Revision: https://reviews.llvm.org/D83899
Summary:
C7113 States that "An ac-value shall not be unlimited polymorphic." We failed
to detect this situation which resulted in a crash when trying to get the
underlying derived type specification of the unlimited polymorphic value.
I added code to avoid the crash, code to emit an error message, and a test.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83793
Summary:
This patch is enabling the generation of clauses enum sets for semantics check in Flang through
tablegen. Enum sets and directive - sets map is generated by the new tablegen infrsatructure for OpenMP
and other directive languages.
The semantic checks for OpenMP are modified to use this newly generated map.
Reviewers: DavidTruby, sscalpone, kiranchandramohan, ichoyjx, jdoerfert
Reviewed By: DavidTruby, ichoyjx
Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83326
Summary:
When a program unit creates a generic based on one defined in a module, the
function `CopyFrom()` is called to create the `GenericDetails`. This function
copied the `specificProcs_` but failed to copy the `bindingNames_`. If the
function `CheckGeneric()` then gets called, it tries to index into the empty
binding names and causes the crash.
I fixed this by adding code to `CopyFrom()` to copy the binding names.
I also added a test that causes the crash.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D83491
Summary:
When there are errors in the evaluation of every cosubscript expression in a
coindexed object, the compiler would crash. I fixed this by just checking to
see if there were errors in the evaluation of the cosubscripts before
constructing the `DataRef` for the coindexed object.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83410
Summary:
This change implements support for image selectors and image selector
specifications as described in section 9.6.
In check-coarray[.h,cpp] I changed the `Leave()` function for
`parser::ImageSelectorSpec` to take a `parser::ImageSelector`, which
contains a list of image selector specifications. This allows us to
detect when the same specification is used more than once. I also added
code to analyze the expressions for the image selector specifications to
expression.cpp and a test for all of the conditions to check at
compile-time.
Note that we do not check at compile-time to see if the value of the
cosubscripts are within the specified cobounds. We also do not check anything
related to selecting a valid team. We also do not check that the denotation of
the `stat-variable` is not dependent on the evaluation of an entity in the
same statement.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D83336
I added 'num_images()' to the list of functions that are evaluated as intrinsic. I also added a test file in flang/test/Semantics to test calls to 'num_images()'. There was a call to 'num_images()' in flang/test/Semantics/call10.f90 that expected an error, now it no longer produces an error. So I edited that file accordingly. I also edited the intrinsics unit test to add further testing of 'num_images()'.
Differential Revision: https://reviews.llvm.org/D83142
Summary:
This patch enhances parser support for flush construct to OpenMP 5.0 by including memory-order-clause.
2.18.8 flush Construct
!$omp flush [memory-order-clause] [(list)]
where memory-order-clause is
acq_rel
release
acquire
The patch includes code changes and testcase modifications.
Reviewed By: klausler, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D82177
Summary:
A program may erroneously reference the same name as both a data object
and as a function. Some of these references were causing an internal
error in expression analysis.
It was already the case that a symbol referenced in a parse tree for a
call was changed from an `Entity` to a `ProcEntity`. I added code to
detect when a symbol was referenced in a parse tree as an array element
gets changed from an `Entity` to an `ObjectEntity`. Then, if an
`ObjectEntity` gets called as a function or a `ProcEntity` gets
referenced as a data object, errors get emitted.
This analysis was previously confined to the name resolution of the
specification part of a `ProgramTree`. I added a pass to the execution
part of a `ProgramTree` to catch names declared in blocks.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D82903
Add `hasAlternateReturns` to `evaluate::ProcedureRef`.
Add `HasAlternateReturns` to test subprogram symbols.
Fix `label01.F90` test: It was checking that "error: " didn't appear in
the output. But that was erroneously matching a warning that ends
"would be in error:". So change it to check for ": error: " instead.
Differential Revision: https://reviews.llvm.org/D83007
Implement cross-set EQUIVALENCE impossibility checking; fixes
an infinite loop on an erroneous test. Also fix substring
reference offset calculations in EQUIVALENCE discovered to
be incorrect during testing.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D82993
Port the remaining tests which only require mechanical changes and delete
test_any.sh.
* Delete old RUN lines
* Replace:
EXEC: ${F18} ... | ${FileCheck} ...
with
RUN: %f18 .. | FileCheck ...
* Prepend RUN line with not when it is expected to fail
Also reinstate a de-activated EXEC line and port it in the same way.
Differential Revision: https://reviews.llvm.org/D82168
These tests checked for stdout and stderr in the same pipe, which does not
come out in a guaranteed order. test_any.sh's FileCheck accepts CHECK lines in
any order while FileCheck checks must match in order.
Hand port these to pipe stdout to a temp file which is checked with a separate
FileCheck RUN line to test it.
Differential Revision: https://reviews.llvm.org/D82167
test_any.sh's FileCheck accepts the CHECK line matches in any order while
FileCheck checks in strict order. Re-order the CHECK lines to source code
order - they come from an ordered datastructure.
Some CHECK lines are sensitive to line number which are fixed up manually.
getsymbols02 had multiple test inputs which had their own EXEC lines.
Consolidate these together in one file.
Differential Revision: https://reviews.llvm.org/D82166
These tests are sensitive to line numbers in the input and check output.
They also successively write to a temporary file then check that.
Fix the line number issues and replace the temporary file use with successive
calls to FileCheck with different check-prefixes.
Differential Revision: https://reviews.llvm.org/D82165
The regex syntax used by test_any.sh's FileCheck is sometimes incompatible with
real FileCheck.
Hand port these tests to use FileCheck and it's regex format.
Also remove FIXME from label01 that no longer applies.
Also add second run-line that enables all tests.
Add some new FIXMEs for issues in original tests
Differential Revision: https://reviews.llvm.org/D82164
Treat function result like dummy argument: a SAVE statement without an
entity-list does not make it saved.
Differential Revision: https://reviews.llvm.org/D82309
Summary:
Fix individual check tests with lit when building out-of-tree
`ninja check-flang-<folder>` was not working.
The CMakeLists.txt was looking for the lit tests in the source directory
instead of the build directory.
This commit extends @CarolineConcatto previous patch[D81002]
Reviewers: DavidTruby, sscalpone, tskeith, CarolineConcatto, jdoerfert
Reviewed By: DavidTruby
Subscribers: flang-commits, llvm-commits, CarolineConcatto
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D82120
Summary:
This patch enhances parser support for flush construct to OpenMP 5.0 by including memory-order-clause.
2.18.8 flush Construct
!$omp flush [memory-order-clause] [(list)]
where memory-order-clause is
acq_rel
release
acquire
The patch includes code changes and testcase modifications.
Reviewed By: klausler, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D82177
Implement rest of DATA statement semantics and conversion of
DATA statement initializations into static initializers of
objects in their symbol table entries.
Reviewed By: tskeith, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82207
Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing
via conversion to initializers.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82137
Summary:
We weren't handling the case of subroutines with alternate returns that
are contained in modules. I changed the code to add an `*` as the name
of the parameter when creating the `.mod` file.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82096
Summary:
This patch changes speficic extremum functions rewrite to generic MIN/MAX.
It applies to AMAX0, AMIN0, AMAX1, AMIN1, MAX0, MIN0, MAX1, MIN1, DMAX1,
and DMIN1.
- Do not re-write specific extremums to MAX/MIN in intrinsic Probe and let
folding rewrite it and introduc the conversion on the MIN/MAX result.
- Also make operand promotion explicit in MIN/MAX folding.
For instance, after this patch:
AMAX0(int8, int4) is rewritten to REAL(MAX(int8, INT(int4, 8)))
All this care is to avoid rewritting it to MAX(REAL(int8), REAL(int4))
that may not always be numerically equivalent to the first rewrite.
Reviewers: klausler, schweitz, sscalpone, jdoerfert, DavidTruby
Reviewed By: klausler, schweitz
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D81940
I added a test the exercises all of the cases instances of specification expressions as defined in section 10.1.11.
Summary: [flang] Added test for specification expressions
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81759
When we encountered a type name in a derived type definition, we were
sometimes finding a component of that name rather than the type from
the enclosing scope. Fix this by introducing `NonDerivedTypeScope()` to
start the search in the right scope.
Differential Revision: https://reviews.llvm.org/D81493
Summary:
If you create an expression with parse errors, the `parser::Expr.typedExpr`
will be empty, which causes a compiler crash. The crash is caused by the
check in check-do-forall.cpp that scans all expresssions to see if `DO`
variables are being modified.
It turned out that the problem was that I was fetching subexpressions of type
`parser::Expr`, which are not guaranteed to have a non-null `typedExpr`. I
fixed this by only grabbing the top-level expression from which to gather
arguments as part of the DO loop analysis. This, in turn, exposed a problem
where I wasn't collecting all of the actual arguments in an expression. This
was caused by the fact that I wasn't recursing through the rest of the
expression after finding an argument. I fixed this by recursing through the
argument in the member function in `CollectActualArgumentsHelper`.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81101
Summary:
Using a forward reference to define a `len` parameter causes a crash.
The underlying cause was that a previously declared type had an
erroneous expression for its `LEN` param value. When this expression
was referenced to evaluate a subsequent expression, bad things happened.
I fixed this by putting in code to detect this case.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80593
Summary:
Fortran::evaluate::IsConstantExpr did not check that the numerator
was a constant expression. This patch fixes the issue.
Reviewers: DavidTruby, klausler, schweitz, PeteSteinfeld, jdoerfert, sscalpone
Reviewed By: klausler, PeteSteinfeld, sscalpone
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D81096
Summary
- Implemented C876, C877
- Fixed IsConstantExpr to check C879
- Fixed bugs in few test cases - data01.f90, block-data01.f90,
pre-fir-tree02.f90
- Modified implementation of C8106 to identify all automatic objects
and modified equivalence01.f90 to reflect the changes
Differential Revision: https://reviews.llvm.org/D78424
structure for upstreaming to llvm-project.
These files have had many changes since they were originally upstreamed.
Some of the changes are cosmetic. Most of the functional changes were
done to support the lowering of control-flow syntax from the front-end
parse trees to the FIR dialect.
This patch is meant to be a reviewable size. The functionality it
provides will be used by code yet to be upstreamed in lowering.
review comments:
[review D80449][NFC] make PFT ParentVariant a ReferenceVariant
ReferenceVariant had to be slightly updated to also support
non constant references (which is required for ParentType).
[review D80449] extend Variable implementation beyond a comment
Summary:
We were not detecting declaring multiple interfaces to the same procedure.
Also, we were not handling the initialization of entitiies where the associated
Symbol had previously had errors.
I added the function `IsInterfaceSet()` to ProcEntityDetails to see if
the value of `interface_` had been previously set. I then checked this
function before calling set_interface() and emitted an error message if
the interface was already set.
Also, in situations where we were emitting error messages for symbols, I
set the Error flag on the Symbol. Then when performing initialization
on the Symbol, I first check to see if the Symbol had an error.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80453
Summary:
Many of these were already implemented, and I just annotated the tests and/or
the code.
C752 was a simple check to verify that CONTIGUOUS components are arrays with
C754 proved to be virtually identical to C750 that I implemented previously.
This caused me to remove the distinction between specification expressions for
type parameters and bounds expressions that I'd previously created.
the POINTER attribute.
I also changed the error messages to specify that errors in specification
expressions could arise from either bad derived type components or type
parameters.
In cases where we detect a type param that was not declared, I created a symbol
marked as erroneous. That avoids subsequent semantic process for expressions
containing the symbol. This change caused me to adjust tests resolve33.f90 and
resolve34.f90. Also, I avoided putting out error messages for erroneous type
param symbols in `OkToAddComponent()` in resolve-names.cpp and in
`EvaluateParameters()`, type.cpp.
C756 checks that procedure components have the POINTER attribute.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D79798
Summary:
If the value in the collapse close is negative f18 abort without the correct error message. This PR change the size_t in name resolution to a int64_t and check appropriately for negative or zero before the privatization of induction variable.
The correct error is then catch by the OpenMP structure check.
This diff is migrated from the GitHub pull request https://github.com/flang-compiler/f18/pull/1098
Reviewers: ichoyjx, jdoerfert, sscalpone, DavidTruby
Reviewed By: ichoyjx, sscalpone, DavidTruby
Subscribers: sscalpone, klausler, yaxunl, guansong, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D77821
When a module contained an import of a use-association of a
use-association, we weren't recognizing that the symbols was needed.
The fix is the follow all of the use-associations using `GetUltimate()`.
Differential Revision: https://reviews.llvm.org/D79737
There were several different ways of handling the option to f18 to
find predefined modules:
- test_errors.sh was created by cmake substituting
FLANG_INTRINSIC_MODULES_DIR into test_errors.sh.in
- some tests used the flang script which has the option built it
- some tests used %f18_with_includes which was replaced by the path
to f18 plus the -I option
- some included -I../../include/flang in their run command
To make this more consistent, change %f18 to include the
-intrinsic-module-directory option and use it everywhere, including
to replace %flang and %f18_with_includes. This requires changing all
of the invocations of the test scripts to put %f18 at the end so that
it can expand to more than one argument.
This eliminates the need to generate test_errors.sh which means we
don't need flang/test/Semantics/CMakeLists.txt or the %B substitution.
That makes the test_errors.sh command like the others, replacing
%B/test/Semantics/test_errors.sh with %S/test_errors.sh.
Also remove the OPTIONS: functionality as custom options can be included
in the RUN: command. And remove -I/../../include/flang as that is now
always included.
Differential Revision: https://reviews.llvm.org/D79634
Summary:
Initially on github I worked on semantic checks.Then I tried some compile-time
test of the rank value, they were failing as there were no symbols
generated for them inside SELECT RANK's scope.So I went further to
add new symbol in each scope, also added the respective 'rank: '
field for a symbol when we dump the symboltable. I added a field to
keep track of the rank in AssocEntityDetails class.This caused shape
analysis framework to become inconsistent. So shape analysis framework
was updated to handle this new representation.
* I added more tests for above changes.
* On phabricator I addressed some minor changes.
* Lastly I worked on review comments.
Reviewers: klausler,sscalpone,DavidTruby,kiranchandramohan,tskeith,anchu-rajendran,kiranktp
Reviewed By:klausler, DavidTruby, tskeith
Subscribers:#flang-commits, #llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78623
IsDescriptor was returning false for a component whose shape depended
on a length parameter. Change it to return true for any array with
non-constant bounds.
Differential Revision: https://reviews.llvm.org/D79349
Summary: I updated the code that produces the message and the associated test.
Reviewers: sscalpone, DavidTruby, kiranchandramohan
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79514
Summary: I updated the code that produces the message and the associated test.
Reviewers: sscalpone, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79514
Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are processed
first. Add alignment to CommonBlockDetails to record the required
alignment of the common block.
For equivalence sets, each object depends on the one that is forced to
occur first in memory. The rest are recorded in the dependents_ map and
have offsets assigned after the other symbols are done.
Differential Revision: https://reviews.llvm.org/D79347
When doing a standalone build of flang against an LLVM that contains a
built flang, the tests were run on the flang from LLVM rather than on
the one that was just built.
The problem was in the lit configuration for finding %flang etc.
Fix it to look only in the directory where it was built.
Differential Revision: https://reviews.llvm.org/D79327
Summary:
Most of these checks were already implemented, and I just added references to
them to the code and tests. Also, much of this code was already
reviewed in the old flang/f18 GitHub repository, but I didn't get to
merge it before we switched repositories.
I implemented the check for C747 to not allow coarray components in derived
types that are of type C_PTR, C_FUNPTR, or type TEAM_TYPE.
I implemented the check for C748 that requires a data component whose type has
a coarray ultimate component to be a nonpointer, nonallocatable scalar and not
be a coarray.
I implemented the check for C750 that adds additional restrictions to the
bounds expressions of a derived type component that's an array.
These bounds expressions are sepcification expressions as defined in
10.1.11. There was already code in lib/Evaluate/check-expression.cpp to
check semantics for specification expressions, but it did not check for
the extra requirements of C750.
C750 prohibits specification functions, the intrinsic functions
ALLOCATED, ASSOCIATED, EXTENDS_TYPE_OF, PRESENT, and SAME_TYPE_AS. It
also requires every specification inquiry reference to be a constant
expression, and requires that the value of the bound not depend on the
value of a variable.
To implement these additional checks, I added code to the intrinsic proc
table to get the intrinsic class of a procedure. I also added an
enumeration to distinguish between specification expressions for
derived type component bounds versus for type parameters. I then
changed the code to pass an enumeration value to
"CheckSpecificationExpr()" to indicate that the expression was a bounds
expression and used this value to determine whether to emit an error
message when violations of C750 are found.
I changed the implementation of IsPureProcedure() to handle statement
functions and changed some references in the code that tested for the
PURE attribute to call IsPureProcedure().
I also fixed some unrelated tests that got new errors when I implemented these
new checks.
Reviewers: tskeith, DavidTruby, sscalpone
Subscribers: jfb, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D79263
Summary:
I found a small test case that caused a crash when derived type
definitions have parameters without definitions.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79282
Summary:
This includes a refactor of the existing combined construct checks
that were present, as well as adding the remaining combined constructs
that had not been implemented yet.
Reviewers: jdoerfert
Subscribers: yaxunl, guansong, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77812
Summary:
Updates recent work on DATA statement semantic checking in
flang/lib/Semantics/check-data.{h,cpp} to use the compiler's
internal representation for typed expressions rather than working
on the raw parse tree. Saves the analyzed expressions for DATA
statement values as parse tree decorations because they'll soon be
needed in lowering. Corrects wording of some error messages.
Fixes a bug in constant expression checking: structure constructors
are not constant expressions if they set an allocatable component
to anything other than NULL.
Includes infrastructure changes to make this work, some renaming
to reflect the fact that the implied DO loop indices tracked by
expression analysis are not (just) from array constructors, remove
some dead code, and improve some comments.
Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby, anchu-rajendran, schweitz
Reviewed By: tskeith, anchu-rajendran, schweitz
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78834
Summary:
Add size and offset properties to symbols, representing their byte size
and offset within their enclosing scope.
Add size and align properties to scopes so that they are available for
scopes representing derived types.
Add ComputeOffsets pass over the symbol table to fill in those fields.
Compute descriptor size based on rank and length parameters. Extract
DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor
to share the code.
Add Scope::GetSymbols to get symbols in canonical order.
compute-offsets.cpp and mod-file.cpp both need to process symbols in the
order in which they are declared. Move the collecting of those symbols
into Scope so that it can be shared.
Add symbol size and offset to output of `-fdebug-dump-symbols` and use
that in some tests.
Still to do:
- make size and alignment rules configurable based on target
- use offsets to check EQUIVALENCE statements
Differential Revision: https://reviews.llvm.org/D78680
Currently, many `Flang :: Semantics` tests FAIL on Solaris. The failure
mode is always the same:
actual at 67: Name in ALLOCATE statement must be a variable name
expect at 67: ERROR: Name in ALLOCATE statement must be a variable name
It turns out the issue is twofold here:
- The awk script embedded in `flang/test/Semantics/common.sh` uses a string
value for `FS`, which isn't supported by traditional awk as documented in
the GNU autoconf manual.
- Even though /usr/gnu/bin (with gawk installed as awk) is in my build
environment's `PATH`, still /bin/awk is used
Although the proper fix would probably be to avoid the unportability, it's
easy to work around it for now. `common.sh` above is the only script in
the whole tree that for unknown reasons overrides `PATH` to
`/usr/bin:/bin`, unnecessarily creating this mess in the first place. Just
removing that setting easily avoids the issue.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D78550
Without this, the LLVM utilities (FileCheck) aren't built when running
`ninja check-flang` and it fails with:
llvm-project/llvm/utils/lit/lit/llvm/subst.py:134: fatal: Did not find FileCheck in...
Also the modules aren't built without depending on `module_files`, which
makes multiple tests failing.
Differential Revision: https://reviews.llvm.org/D78036
In most cases, I just added the contraint names to the code and tests.
I implemented the following checks:
- C736 A child type with a coarray ultimate component must have a parent with
a coarray ultimate component.
- C737 A child type with and EVENT_TYPE or LOCK_TYPE component must have a
parent either which is EVENT_TYPE or LOCK_TYPE or a type with an EVENT_TYPE
or LOCK_TYPE component.
- C740 Sequence types must contain at least on component
- C740 Data components of sequence types must either be of an intrinsic type
or a sequenced derived type.
After implementing these checks, some tests had new errors unrelated to their
original purpose, so I fixed them.
Original-commit: flang-compiler/f18@098f01bc47
Reviewed-on: https://github.com/flang-compiler/f18/pull/1097
In general all the basic functionality seems to work and removes some redundancy
and more complicated features in favor of borrowing infrastructure from LLVM
build configurations. Here's a quick summary of details and remaining issues:
* Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and
MacOS/darwin. Architectures include x86_64 and Arm. Without
access to Window nothing has been tested there yet.
* As we change file and directory naming schemes (i.e.,
capitalization) some odd things can occur on MacOS systems with
case preserving but not case senstive file system configurations.
Can be painful and certainly something to watch out for as any
any such changes continue.
* Testing infrastructure still needs to be tuned up and worked on.
Note that there do appear to be cases of some tests hanging (on
MacOS in particular). They appear unrelated to the build
process.
* Shared library configurations need testing (and probably fixing).
* Tested both standalone and 'in-mono repo' builds. Changes for
supporting the mono repo builds will require LLVM-level changes that
are straightforward when the time comes.
* The configuration contains a work-around for LLVM's C++ standard mode
passing down into Flang/F18 builds (i.e., LLVM CMake configuration would
force a -std=c++11 flag to show up in command line arguments. The
current configuration removes that automatically and is more strict in
following new CMake guidelines for enforcing C++17 mode across all the
CMake files.
* Cleaned up a lot of repetition in the command line arguments. It
is likely that more work is still needed to both allow for
customization and working around CMake defailts (or those
inherited from LLVM's configuration files). On some platforms agressive
optimization flags (e.g. -O3) can actually break builds due to the inlining
of templates in .cpp source files that then no longer are available for use
cases outside those source files (shows up as link errors). Sticking at -O2
appears to fix this. Currently this CMake configuration forces this in
release mode but at the cost of stomping on any CMake, or user customized,
settings for the release flags.
* Made the lit tests non-source directory dependent where appropriate. This is
done by configuring certain test shell files to refer to the correct paths
whether an in or out of tree build is being performed. These configured
files are output in the build directory. A %B substitution is introduced in
lit to refer to the build directory, mirroring the %S substitution for the
source directory, so that the tests can refer to the configured shell scripts.
Co-authored-by: David Truby <david.truby@arm.com>
Original-commit: flang-compiler/f18@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
The full list of constraints is C727, C728, C729, C730, C743, C755, C759, C778,
and C1543.
I added a function to tools.cpp to check to see if a symbol name is the name
of an intrinsic type.
The biggest change was to resolve-names.cpp to check to see if attributes were
either duplicated or in conflict with each other. I changed all locations
where attributes were set to check for duplicates or conflicts.
I also added tests for all checks and annotated the tests and code with the
numbers of the constraints being tested/checked.
Original-commit: flang-compiler/f18@3f30e8a61e
Reviewed-on: https://github.com/flang-compiler/f18/pull/1084
The previous code had handling for cases when too many file descriptors may be
opened; this is not necessary with MemoryBuffer as the file descriptors are
closed after the mapping occurs. MemoryBuffer also internally handles the case
where a file is small and therefore an mmap is bad for performance; such files
are simply copied to memory after being opened.
Many places elsewhere in the code assume that the buffer is not empty, and the
old file opening code handles this by replacing an empty file with a buffer
containing a single newline. That behavior is now kept in the new MemoryBuffer
based code.
Original-commit: flang-compiler/f18@d34df84351
Reviewed-on: https://github.com/flang-compiler/f18/pull/1032
When a module subprogram has the MODULE prefix the following must match
with the corresponding separate module procedure interface body:
- C1549: characteristics and dummy argument names
- C1550: binding label
- C1551: NON_RECURSIVE prefix
SubprogramMatchHelper performs all of these checks.
Rename separate-module-procs.f90 to separate-mp01.f90 so we can have
separate-mp02.f90 (etc).
Make ShapesAreCompatible public in characteristics.h.
Add Scope::IsSubmodule.
Original-commit: flang-compiler/f18@d121578af1
Reviewed-on: https://github.com/flang-compiler/f18/pull/1080
A separate-module-subprogram is declared as `module procedure ...`
and gets its characteristics from the declaration of that name as
a separate module procedure. When we encounter one, we need to create
symbols in the new subprogram scope for the dummy arguments and
function return (if any).
The failure to create these symbols led to the bug in issue flang-compiler/f18#1054:
when a dummy argument was referenced, the compiler interpreted it as
an implicit declaration because there was no symbol for the argument.
Fixesflang-compiler/f18#1054.
Original-commit: flang-compiler/f18@4d3c4bac84
Reviewed-on: https://github.com/flang-compiler/f18/pull/1080
Tree-same-pre-rewrite: false
When we encounter a ProcDecl and a symbol for it has already been
created, replace the CharBlock for the name with the one in the ProcDecl
as it is the "main" declaration of that name. This matches what is done
for an EntityDecl.
This moves the location of some error messages to a better source
location so update the affected tests.
Original-commit: flang-compiler/f18@514c0f2c94
Reviewed-on: https://github.com/flang-compiler/f18/pull/1080
Tree-same-pre-rewrite: false
Fix omp-nested01.f90 so that it is not an expected failure. The test was
never enabled but I'm guessing this is what it's supposed to do.
Fix the instructions to include "make test" as part of running tests.
Original-commit: flang-compiler/f18@c351181cab
Reviewed-on: https://github.com/flang-compiler/f18/pull/1075
We have re-classified a subset of the regression tests as unit tests and
now we are porting the remaining ones.
Test discovery and running is now performed by lit rather than ctest.
The tests continue to use their original scripts with minor
modifications. Most of the changes were mechanical and so scripted.
A few changes were made by hand. Details
Manual:
* modfile09-*.f90 tests depend on being run together as some tests have
dependencies on modules created by other tests. This will need
separating out when porting away from test_modfile.sh, but for now,
added modfile09-*.f90 to the Inputs directory and added a single
tests modfile09.f90 to hold the run line.
* getdefinition03-a.f90 includes a non-test file getdefinition03-b.f90.
Manually edited the former to find the latter in Inputs so as to add
only one test.
* Same pattern for getsymbols03-{a,b}.f90
Auto:
* Remaining tests have a lit RUN line added to them based on the type
of test they are.
* Failing tests also have an XFAIL line added to them.
* Generic tests have their pre-existing RUN lines replaced with the
word "EXEC" to avoid conflict with the added lit RUN line.
Original-commit: flang-compiler/f18@63ec0af9f4
Reviewed-on: https://github.com/flang-compiler/f18/pull/1027
Tree-same-pre-rewrite: false
Some of the regression tests are C programs that act as test harnesses
for the compiler internals as opposed to being Fortran inputs to test
the compiler in action. The former style of tests are analog to LLVM's
unittests and will not use the lit framework.
Change-Id: I0ff10e23f66ff843e8fff4c35cfb6559b9dab762
Original-commit: flang-compiler/f18@2bfddbe8f8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1027
Tree-same-pre-rewrite: false
These tests were disabled due to https://github.com/flang-compiler/f18/issues/407.
Previously these tests caused F18 to crash as the feature was not fully
implemented.
The altreturn feature is now implemented, so these tests can be
re-enabled. altreturn03 tested some negative cases which F18 correctly
diagnoses. Modified that test to expect these new error messages. Also
make the later cases in the test reachable.
These tests can now be ported by the script to lit-style tests.
Change-Id: Ib336c10d55068d9a26fc2deb43ad052e74e73456
Original-commit: flang-compiler/f18@4de19d7ba2
Reviewed-on: https://github.com/flang-compiler/f18/pull/1027
Tree-same-pre-rewrite: false
Scan FORMAT strings locally to avoid C++ binary runtime dependence when computing deepest parenthesis nesting
Remove a dependency on ostream from runtime
Remove remaining direct external references from runtime to C++ library binaries
Remove runtime dependences on lib/common
SetPos() and SetRec()
Instantiate templates for input
Begin input; rearrange locking, deal with CLOSE races
View()
Update error message in test to agree with compiler change
First cut at real input
More robust I/O runtime error handling
Debugging of REAL input
Add iostat.{h,cpp}
Rename runtime/numeric-* to runtime/edit-*
Move templates around, templatize integer output editing
Move LOGICAL and CHARACTER output from io-api.cpp to edit-output.cpp
Change pointer argument to reference
More list-directed input
Complex list-directed input
Use enum class Direction rather than bool for templates
Catch up with changes to master
Undo reformatting of Lower code
Use record number instead of subscripts for internal unit
Unformatted sequential backspace
Testing and debugging
Dodge bogus GCC warning
Add <cstddef> for std::size_t to fix CI build
Address review comments
Original-commit: flang-compiler/f18@50406b3496
Reviewed-on: https://github.com/flang-compiler/f18/pull/1053
The check for whether a private component is accessible was depending on
determining whether the source range of the current scope was within the
source range of the module that the component was declared in. This
could fail if the current scope was of kind `ImpliedDos` and had no
source range.
The fix is to add `Scope::Contains` to check the relationship by
traversing the parent links. These are created when the Scope is so are
always reliable. The source range of a scope is built up over time.
Original-commit: flang-compiler/f18@d787108637
Reviewed-on: https://github.com/flang-compiler/f18/pull/1060
If the pure context check succeeds, call `WhyNotModifiable` to verify
the LHS can be modified.
Detect assignment to whole assumed-size array.
Change `IsVariable` to return false for a parameter or a component or
array reference whose base it a parameter.
When analyzing an assignment statement, report an error if the LHS is
a constant expression. Otherwise it might get folded and when we detect
the problem later the error will be confusing.
Handle Substring on LHS of assignment. Change ExtractDataRef and IsVariable
to work on a Substring.
Fix IsImpliedShape and IsAssumedSize predicates in ArraySpec.
Fix C709 check in check-declarations.cpp.
Original-commit: flang-compiler/f18@f2d2657aab
Reviewed-on: https://github.com/flang-compiler/f18/pull/1050
When a misparsed FunctionReference was converted to a StructureConstructor,
the components accessed were not checked for accessibility.
The conversion happens in expression analysis so that where the accessibity
must be checked. So move `CheckAccessibleComponent` to `tools.h` so that it
can be shared by `resolve-names.cpp` and `expression.cpp`.
Add FindModuleContaining to help implement this and use it other places.
Check that an access-spec can only appear in a module.
Remove some unnecessary "semantics::" qualifiers.
Original-commit: flang-compiler/f18@99ce156e49
Reviewed-on: https://github.com/flang-compiler/f18/pull/1046
When something is parsed as an array element it was sometimes intended
to be a function call or structure constructor. So if the base name is
not found the errors can be confusing. This is an attempt to improve
them.
When the subscript list is empty, it was probably meant to be a function
call, so report that the name is not a function.
If the base is a scalar but there are subscripts, report that it is not
an array.
Original-commit: flang-compiler/f18@e2fd5333ff
Reviewed-on: https://github.com/flang-compiler/f18/pull/1039
Data statements contains expressions but they are not wrapped in one of
the kinds of parse tree nodes that are analyzed, like `parser::Expr`.
So potential errors were not discovered.
Change `ExprChecker` to handle `DataStmtConstant` and analyze any
expressions that are contained in it. Note that the analyzed form of
the expression is not yet saved in the parse tree.
Original-commit: flang-compiler/f18@8bdaf0a521
Reviewed-on: https://github.com/flang-compiler/f18/pull/1044
I've updated the compiler and test source with references to the contraints at
the points where they were enforced and tested. Many of these were already
implemented and required no code change. A few constraint checks were both
implemented and tested, and I only added references to the constraint
numbers in the compiler source and tests. Here are the things I had to
implement:
Constraint C716 states that, in a REAL constant, if both a kind-param and an
exponent letter appear, the exponent letter must be 'E'.
Constraints C715 and C719 require that a KIND value be actually implemented.
Constraint C722 requires that functions that return assumed-length character
types are external.
Constraint C726 disallows assumed lenght charater types for dummy arguments and
return types.
Original-commit: flang-compiler/f18@45998741e5
Reviewed-on: https://github.com/flang-compiler/f18/pull/1031
Tree-same-pre-rewrite: false
In a data statement like `data x / a(1) /`, `a(1)` may be an array
element or a structure constructor. It is parsed as an array element
so if it turns out `a` is a derived type it must be rewritten as a
strucutre constructor.
Original-commit: flang-compiler/f18@a2b2a330e7
Reviewed-on: https://github.com/flang-compiler/f18/pull/1024
`data x /a(1)/` is ambiguous. The data value may be an array element
or a structure constructor. We need to parse it as one of these and
then fix up the parse tree when it should have been the other one.
My PR 1012 changed the parser to identify this as an array element.
That makes this test invalid until we have the right parse tree fixup,
so I am disabling it for now.
Original-commit: flang-compiler/f18@72aa278f03
Reviewed-on: https://github.com/flang-compiler/f18/pull/1013
Check that masks and LHS of assignments in WHERE statements and
constructs have consistent shapes. They must all have the same rank and
any extents that are compile-time constants must match.
Emit a warning for assignments in FORALL statements and constructs where
the LHS does not reference each of the index variables.
Original-commit: flang-compiler/f18@8b04dbebcf
Reviewed-on: https://github.com/flang-compiler/f18/pull/1009
This commit covers Semantic Constraints C882 - C887
C882 : It was partially Implemented. Finished the implementation
and added test case
C884 : Implemented and added test case
C883 : Implementation was there already. Added test case
C885, C886, C887 : Implementation was there already. Added test case for
data-repeat.
Original-commit: flang-compiler/f18@822129736b
Reviewed-on: https://github.com/flang-compiler/f18/pull/992
FORALL statements and constructs require a lot of the same checking
as DO CONCURRENT, so do the checks in DoChecker so that code can be
shared where possible. This requires some reorganization there.
Remove code from AssignmentChecker that did some of these checks.
Change names that contain `DoVar` or `DoVariable` to `IndexVar` to
reflect the fact that they may be DO or FORALL index variables.
Distinguish between the two when necessary with enum `IndexVarKind`.
Change some messages that referred to "concurrent-header" or
"concurrent-control" to specifically say "DO CONCURRENT" or "FORALL".
Original-commit: flang-compiler/f18@84752c492e
Reviewed-on: https://github.com/flang-compiler/f18/pull/989
Tree-same-pre-rewrite: false
C709 An assumed-type entity shall be a dummy data object that does not
have the ALLOCATABLE, CODIMENSION, INTENT (OUT), POINTER, or VALUE
attribute and is not an explicit-shape array.
C710 An assumed-type variable name shall not appear in a designator or
expression except as an actual argument corresponding to a dummy
argument that is assumed-type, or as the first argument to the intrinsic
function IS_CONTIGUOUS, LBOUND, PRESENT, RANK, SHAPE, SIZE, or UBOUND,
or the function C_LOC from the intrinsic module ISO_C_BINDING.
C711 An assumed-type actual argument that corresponds to an assumed-rank
dummy argument shall be assumed-shape or assumed-rank.
For C709 I added code to check-declarations.cpp. For this, I had to
distinguish between polymorphic types and assumed-type types to
eliminate multiple messages on the same line.
C710 was already checked, but I added a notation in the source.
For C711 I added code to check-call.cpp and the test call15.f90.
Original-commit: flang-compiler/f18@4a703f2b5a
Reviewed-on: https://github.com/flang-compiler/f18/pull/985
This commit implements rule:
A loop iteration variable for a sequential loop in a parallel or
task generating construct is private in the innermost such construct
that encloses the loop.
A Simple example:
```
i = -1 <== Scope 0
j = -1
!$omp parallel <== Scope 1
print *,i,j <-- both are shared (Scope 0)
!$omp parallel <== Scope 2
print *,i,j <-- a) i is shared (Scope 0), j is private (Scope 2)
!$omp do <== Scope 3
do i=1, 10 <-- i is private (Scope 3)
do j=1, 10 <-- b) j is private (Scope 2, not 3!)
enddo
enddo
print *,i,j <-- c) i is shared (Scope 0), j is private (Scope 2)
!$omp end parallel
print *,i,j <-- both are shared (Scope 0)
!$omp end parallel
print *,i,j <-- both are shared (Scope 0)
end
```
Ideally the above rule solves a), b), and c) but a) is left as a TODO
because it is better to handle the data-sharing attribute conflicts
along with the rules for "Predetermined DSA on Clauses".
The basic idea is when visiting the `DoConstruct` node within an OpenMP
construct, if the do-loop is not associated (like `i` loop is associated
with `!$omp do`) AND the do-loop is in the parallel/task generating
construct, resolve the loop index to be private to that innermost construct.
In the above example, `j` loop is not associated (then it is sequential) and
the innermost parallel/task generating construct that encloses the `j` loop
is the `parallel` construct marked with `<== Scope 2`, so `j` is private
to that construct. To do that, I also need to change the prototype of those
`ResolveOmp*` functions to allow specifiying the `scope` because the new
symbol for `j` should be created in Scope 2 and all the `symbol` field of
`Name j` in that `parallel` construct should be fixed, such as c).
Original-commit: flang-compiler/f18@69a845283b
Reviewed-on: https://github.com/flang-compiler/f18/pull/976
An entity declared with the CLASS keyword shall be a dummy argument or
have the ALLOCATABLE or POINTER attribute.
Implementing this check revealed a problem in the test resolve44.cpp.
It also showed that we were doing semantic checking on the entities
created by the compiler for LOCAL and LOCAL_INIT locality-specs. So I
changed the creation of symbols associated with LOCAL and LOCAL_INIT
locality-specs to be host associated with the outer symbol rather than
new object entities. In the process, I also changed things so that the
`parser::Name` associated with the newly created symbols was set to the
symbol rather than being set to nullptr.
Original-commit: flang-compiler/f18@5dd0b0bbe8
Reviewed-on: https://github.com/flang-compiler/f18/pull/981
Use internal units for internal I/O state
Replace use of virtual functions
reference_wrapper
Internal formatted output to array descriptor
Delete dead code
Begin list-directed internal output
Refactorings and renamings for clarity
List-directed external I/O (character)
COMPLEX list-directed output
Control list items
First cut at unformatted I/O
More OPEN statement work; rename class to ExternalFileUnit
Complete OPEN (exc. for POSITION=), add CLOSE()
OPEN(POSITION=)
Flush buffers on crash and for terminal output; clean up
Documentation
Fix backquote in documentation
Fix typo in comment
Begin implementation of input
Refactor binary floating-point properties to a new header, simplify numeric output editing
Dodge spurious GCC 7.2 build warning
Address review comments
Original-commit: flang-compiler/f18@9c4bba11cf
Reviewed-on: https://github.com/flang-compiler/f18/pull/982
I implemented and added tests for constraints C703, C704, C705, C706,
and C796. In some cases, the code and/or test already existed, and all
I did was add a notation indicating the associated constraint.
Original-commit: flang-compiler/f18@49a64c4c23
Reviewed-on: https://github.com/flang-compiler/f18/pull/978
C702 (R701) A colon shall not be used as a type-param-value except in the
declaration of an entity that has the POINTER or ALLOCATABLE attribute.
I added code to the visitor for a TypeDeclarationStmt to check for the
'LEN' type parameter for strings and to loop over the type parameters
for derived types.
I also ran into a few situations where previous tests had erroneously
used a colon for type parameters without either the POINTER or
ALLOCATABLE attribute and fixed them up.
Original-commit: flang-compiler/f18@a1a95bfcd1
Reviewed-on: https://github.com/flang-compiler/f18/pull/973
This refers to three rules in OpenMP 4.5 Spec 2.15.1.1:
* The loop iteration variable(s) in the associated do-loop(s) of a do,
parallel do, taskloop, or distribute construct is (are) private.
* The loop iteration variable in the associated do-loop of a simd
construct with just one associated do-loop is linear with a linear-step
that is the increment of the associated do-loop.
* The loop iteration variables in the associated do-loops of a simd
construct with multiple associated do-loops are lastprivate.
A simple example:
```
implicit none
integer :: N = 1024
integer i, j, k
!$omp parallel do collapse(3)
do i=1, N <- i is private
do j=1, N <- j is private
do k=1, N <- k is private
enddo
enddo
enddo
end
```
If `collapse` clause is not present, the associated do-loop for construct
`parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are
all associated do-loops and the loop index variables are private to the
OpenMP construct:
```
implicit none
!DEF: /MainProgram1/n ObjectEntity INTEGER(4)
integer :: n = 1024
!DEF: /MainProgram1/i ObjectEntity INTEGER(4)
!DEF: /MainProgram1/j ObjectEntity INTEGER(4)
!DEF: /MainProgram1/k ObjectEntity INTEGER(4)
integer i, j, k
!$omp parallel do collapse(3)
!DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do i=1,n
!DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do j=1,n
!DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do k=1,n
end do
end do
end do
end program
```
This implementation assumes that the structural checks for do-loops
are done at this point, for example the `n` in `collapse(n)` should
be no more than the number of actual perfectly nested do-loops, etc..
Original-commit: flang-compiler/f18@572a57d3d0
Reviewed-on: https://github.com/flang-compiler/f18/pull/962
Address review comments
Integer output data editing (I,B,O,Z)
Full integer output formatting
Stub out some work in progress
Progress on E output data editing
E, D, EN, and ES output editing done
Fw.d output editing
Real G output editing
G output editing for reals
Make environment a distinct module
CHARACTER and LOGICAL output editing
Minimal decimal representations for E0, F0, G0 editing
Move real output editing code into its own file
Fix/dodge some GCC build problems
Prep work for external I/O statement state
External HELLO, WORLD
Fix build problem with GCC
Add virtual destructors where needed
Add new test
Original-commit: flang-compiler/f18@c3f1774f8e
Reviewed-on: https://github.com/flang-compiler/f18/pull/950
The test still wasn't correct for structure components. If the last
part-ref is a non-array or a single array element, but the whole
ArrayRef has non-zero rank, it is not contiguous. Otherwise, if there
are subscripts on the last part-ref they can be checked normally.
Add some tests for cases that were previously failing, and also for
cases with vector subscripts.
Original-commit: flang-compiler/f18@aa0a088732
Reviewed-on: https://github.com/flang-compiler/f18/pull/961
You cannot call an IMPURE procedure in a DO CONCURRENT construct. One
way that can happen is if an entity with an IMPURE FINAL procedure gets
deallocated. Similar to the checks for deallocating coarrays, there are
three ways that an entity can get deallocated that are applicable to DO
CONCURRENT constructs -- an actual DEALLOCATE statement, block exit, and
assignment.
This change depends on the utility function `HasImpureFinal()` in tools.h to
determine if an entity has a derived type with an IMPURE FINAL
procedure. In the course of testing this change, I realized that this
check is incorrect, but the code specific to DO CONCURRENT is
independent of the check, so I might as well implement it.
Original-commit: flang-compiler/f18@d2294ff511
Reviewed-on: https://github.com/flang-compiler/f18/pull/954
This is an extended framework based on the previous work that addresses
the NR on OpenMP directives/clauses (b2ea520). In this change:
* New `OmpVisitor` is created (ResolveNamesVisitor derives from it) to
create necessary scopes for certain OpenMP constructs. This is along
with the regular Fortran NR process.
* Old `OmpVisitor` is adjusted and converted to a standalone visitor--
`OmpAttributeVisitor`. This is used to walk through the OpenMP constructs
and do the NR for variables on the OpenMP directives or data references
within the OpenMP constructs. "Do the NR" here means that based on the NR
results of the regular Fortran NR, fix the symbols of `Names` related
to the OpenMP constructs. Note that there is an `OmpContext` in this
visitor (similar to the one in `OmpStructureChecker`), this is necessary
when dealing with the nested OpenMP constructs in the future.
Given an OpenMP code:
```
real*8 a, b
a = 1.
b = 2.
!$omp parallel private(a)
a = 3.
b = 4.
!$omp end parallel
print *, a, b
end
```
w/o -fopenmp:
```
real*8 a, b
!REF: /MainProgram1/a
a = 1.
!REF: /MainProgram1/b
b = 2.
!!!! OMP parallel
!REF: /MainProgram1/a
a = 3.
!REF: /MainProgram1/b
b = 4.
!!!! OMP end parallel
!REF: /MainProgram1/a
!REF: /MainProgram1/b
print *, a, b
end
```
w/ -fopenmp:
```
real*8 a, b
!REF: /MainProgram1/a
a = 1.
!REF: /MainProgram1/b
b = 2.
!$omp parallel private(a) <-- new Symbol for 'a' created
!DEF: /MainProgram1/Block1/a (OmpPrivate) HostAssoc REAL(8)
a = 3. <-- fix the old symbol with new Symbol in parallel scope
!REF: /MainProgram1/b
b = 4. <-- do nothing because by default it is shared in this scope
!$omp end parallel
!REF: /MainProgram1/a
!REF: /MainProgram1/b
print *, a, b
end
```
Please note that this is a framework update, there are still many
things on the TODO list for finishing the NR for OpenMP (based on
the `OpenMP-semantics.md` design doc), which will be on top of this
framework.
Some TODO items:
- Create a generic function to go through all the rules for deciding
`predetermined`, `explicitly determined`, and `implicitly determined`
data-sharing attributes. (This is the next biggest part)
- Handle `Array Sections` and `Array or Structure Element`.
- Take association into consideration for example Pointer association,
`ASSOCIATE` construct, and etc.
- Handle all the name resolution for directives/clauses that have
`parser::Name`.
* N.B. Extend `AddSourceRange` to apply to current and parent scopes
- motivated by a few cases that need to call `AddSourceRange`
for current & parent scopes; the extension should be safe
- global scope is not included
Original-commit: flang-compiler/f18@0c3c39d30e
Reviewed-on: https://github.com/flang-compiler/f18/pull/940
Updated CMake files accordingly, using better regex
Updated license headers to match new extension and fit within 80 columns
Updated other comments within files that referred to the old extension
Original-commit: flang-compiler/f18@ae7721e611
Reviewed-on: https://github.com/flang-compiler/f18/pull/958
Change Traverse to visit the actual arguments of structure constructors.
Change FindImpureCallHelper to visit the actual arguments of a call to a
pure procedure in case one of them makes a call to an impure function.
Original-commit: flang-compiler/f18@81a5488ee6
Reviewed-on: https://github.com/flang-compiler/f18/pull/951
We were always return false when testing a component for simple
contiguity. Change to check that the component is an array that is
simply continguous. Also treat a scalar component of scalar as simply
contiguous.
A pointer with bounds remapping to a complex part is a similar case
so add a test for that too.
Original-commit: flang-compiler/f18@27d76da2a4
Reviewed-on: https://github.com/flang-compiler/f18/pull/952
internal formatted WRITE with no data list items.
Improve argument names in io-api.h
Bump up error number to not conflict with errno values
Use Fortran::runtime::io namespace
Add wrapper around malloc/free, allow use of unique_ptr with wrapper
IoErrorHandler
Revamp FormatContext, use virtual member functions
Update comment syntax, allow for old C
12HHELLO, WORLD
Remove files not yet ready for review
Use std::forward
Fix gcc build warnings
Fix redundant filename in license boilerplate
Reduce runtime dependence on compiler binary libraries, fixing shared lib builds
Original-commit: flang-compiler/f18@839a91f1d6
Reviewed-on: https://github.com/flang-compiler/f18/pull/946
Perform checks on bounds-spec and bounds-remapping in a pointer
assignment statement:
- check that the rank of the bounds specified matches the rank of the
pointer
- for bounds-spec, check that the pointer rank matches the target rank
- for bounds-remapping:
- check that the target is rank 1 or simply contiguous
- check that there are sufficient elements on the RHS for the bounds
specified, when it can be determined at compile time
Move more of the pointer-specific checking from `assignment.cc`
to `pointer-assignment.cc`.
Original-commit: flang-compiler/f18@7489b35392
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
This is easier to use when including an expression in an error message
and also useful when debugging for dumping expressions.
Fix up several places that no longer need to use a temporary
std::stringstream.
Also change some references to `operator<<` in `formatting.cc` and
`symbol.cc` that became ambiguous with this change.
Original-commit: flang-compiler/f18@25dc49b6e9
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
When checking if the target of a pointer assignment is valid, we
weren't following associations. E.g. we complained about the assignment
below if `b` had the TARGET attribute but `c` did not:
```
associate(a => b%c)
p => a
end associate
```
The fix is to change `GetSymbolVector()` to follow associations in
creating the chain of symbols from a designator.
Add tests for this, and also some other cases where TARGET is on the
derived type variable rather than the component (which worked but didn't
have tests).
Original-commit: flang-compiler/f18@c81c6baedd
Reviewed-on: https://github.com/flang-compiler/f18/pull/937
Call `CheckPointerAssignment()` when analyzing a pointer assignment
statement. NOTE: the cases with bounds-spec and bounds-remapping are
still to be done.
Perform checks on pointer symbols in `check-declarations.cc`.
Check for pointer to generic intrinsic in `semantics/expression.cc`.
Add the other required pointer assignment checks to `pointer-assignment.cc`.
Original-commit: flang-compiler/f18@3dc5fd6d9e
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
This replaces IsUnrestrictedSpecificIntrinsicFunction and returns
information that allows the caller to distinguish between restricted
and unrestricted intrinsics.
The new case in `resolve46.f90` used to get an internal error.
Original-commit: flang-compiler/f18@4cb1ee10b9
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
Tree-same-pre-rewrite: false
`DynamicType::AsFortran` was using mixed case for intrinic type names.
Make it upper case for consistency with TYPE(...) and CHARACTER when a
length is present and other error messages.
Original-commit: flang-compiler/f18@e16909d67f
Reviewed-on: https://github.com/flang-compiler/f18/pull/928
Tree-same-pre-rewrite: false
At the time we finish processing an array-spec in `resolve-names.cc`,
we don't know if the entity is going to be declared ALLOCATABLE later
so we can't check for validity there. In the new test in `resolve58.f90`
(based on issue flang-compiler/f18#930) we were reporting an error on `b` and not on `a`
when it should be the reverse.
The fix is to move array-spec checking to `check-declarations.cc`,
after name resolution is complete.
Fixesflang-compiler/f18#930.
Original-commit: flang-compiler/f18@c596d2fef7
Reviewed-on: https://github.com/flang-compiler/f18/pull/933
I added a traveral framework to find actual arguments in expressions.
For arguments that are DO variables being passed to dummy arguments with
INTENT(OUT), I emit an error message. For INTENT(INOUT), I emit a
warning.
Original-commit: flang-compiler/f18@815dbed75c
Reviewed-on: https://github.com/flang-compiler/f18/pull/918
Assumed-type dummy arguments can only be used as actual arguments. If
they are used in other contexts it is an error. Change argument analysis
to handle these differently depending on the context. `allowAssumedType`
is set when the argument can be assumed-type. These expressions now all
get `typedExpr` set to `nullopt`.
Change `AnalyzeSectionSubscripts` to analyze all of the subscripts
even if one has an error. This ensures they all get analyzed expressions
(or `nullopt` in case of error).
Fix a bug analyzing `BoundsRemapping`: the lower bound was analyzed
twice and the upper bound not at all.
These change mean that `typedExpr` is set in all known cases.
Fixesflang-compiler/f18#915.
Original-commit: flang-compiler/f18@679ef69905
Reviewed-on: https://github.com/flang-compiler/f18/pull/923
back out -Mnolargearray default temporarily
Fix C_F_POINTER(SHAPE=) argument check, it can be any kind of integer
Revert default result kind of SIZE() & al. to standard by default
Remove needless usage of -fdebug-semantics
Original-commit: flang-compiler/f18@57058a5b16
Reviewed-on: https://github.com/flang-compiler/f18/pull/907
The commit includes the following,
-> The name field in DoConcurrent*Enforce classes are not used anymore.
Removing the field and its collection and retrieval from
DoConcurrentBodyEnforce and its usage in DoConcurrentLabelEnforce.
-> DoConcurrentLabelEnforce is useful for checking that there
are no branches escaping from other constructs also. For enabling
use in other constructs (like critical) moving this to tools.h
and renaming it as LabelEnforce.
-> Checks for the constraints.
-> Tests for the constaints.
Original-commit: flang-compiler/f18@4b7a007ff3
Reviewed-on: https://github.com/flang-compiler/f18/pull/897
Add `typedAssignment` to `PointerAssignmentStmt` parse tree node and
extend `evaluate::Assignment` to include pointer assignment, including
analyzed bounds. Analyze pointer assignments and fill those in.
Emit them in unparsed output and parse tree dump when present.
Change assignment checking to use analyzed expressions and assignments
rather than calling AnalyzeExpr. Check bounds in pointer assignments
for impure function calls in FORALL context.
Add `Fold` convenience function to `ExpressionAnalyzer`.
Original-commit: flang-compiler/f18@140c983423
Reviewed-on: https://github.com/flang-compiler/f18/pull/904
As it was implemented we weren't detecting non-constant kind parameters
in the integer-type-spec. The fix is just to walk the integer-type-spec
like was do any other one.
Also, there is not need for ResolveControlExpressions -- all it does is
walk that part of the parse tree.
Original-commit: flang-compiler/f18@8c0d890eb8
Reviewed-on: https://github.com/flang-compiler/f18/pull/904
Tree-same-pre-rewrite: false
I added code to save the INTENT of a dummy argument in the checked expression
of the actual argument. When processing a CallStmt, I then retrieve the
ProcedureRef, which contains a list of the checked ActualArguments. I then
traverse this list looking for actual arguments that are active DO variable
that are being passed to dummy arguments whose INTENT is either OUT or INOUT.
For OUT dummies, I put out an error message and warn for INOUT dummies.
Original-commit: flang-compiler/f18@0ff1d26428
Reviewed-on: https://github.com/flang-compiler/f18/pull/902
Make compilation of other predefined module files depend on
__fortran_builtins.mod. Currently only iso_c_binding.f90 and
iso_fortran_env.f90 depend on it but others could in the future.
Create the .f18.mod files by copying from the .mod files so that
we don't have to worry about dependencies for those.
Original-commit: flang-compiler/f18@8209ad3d32
Reviewed-on: https://github.com/flang-compiler/f18/pull/899
I added infrastructure to SemanticsContext to track active DO variables
and the source locations where they appear in DO statements. I also
added code to semantics.[h,cc] to check to see if a DO variable is
already defined, and, if so, to emit an error message along with a
reference to the relevant DO construct. I also added calls to several
places where variables are defined to determine if the definitions are
happening in the context of an active DO construct.
I have not yet added the checks for DO variables being redefined when passing
them as actual arguments to dummy arguments with INTENT(OUT) or INTENT(INOUT).
I wanted to get these changes merged first and catch up with the other changes
in master.
Original-commit: flang-compiler/f18@1bbfcca61b
Reviewed-on: https://github.com/flang-compiler/f18/pull/860
This changes the license information in many of the flang source files.
- Renamed LICENSE to LICENSE.txt.
- NVIDIA Copyright lines have been removed.
- Initial lines for files follow the LLVM coding convention (file name on the first line; Emacs mode information on the first line).
- License references have been replaced with the abridged LLVM text.
- License information was removed from the test files.
- No file header was placed on test files (these weren't in most LLVM test files).
- License information was added to documentation files where it was missing.
We did not add brief file summaries to the initial line.
See http://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
for a description of the new license.
See http://llvm.org/docs/CodingStandards.html#file-headers
for a description of the new LLVM standard file header.
Original-commit: flang-compiler/f18@add6cde724
Reviewed-on: https://github.com/flang-compiler/f18/pull/887
Add `ArgumentAnalyzer::FindBoundOp` to look for an operator or
assignment definition in the type of each operand. Then `TryBoundOp`
checks if it is actually applicable.
Change ResolveGeneric to handle type-bound operators: the `adjustActuals`
function passed in handles the difference between these and normal
type-bound procedures. For operators, either operand may be the passed-
object argument. For procedures we know which one it is.
Extract `GetDerivedTypeSpec`, `GetBindingResolution`, and
`OkLogicalIntegerAssignment` into separate functions to simplify the
logic of the calling functions.
Original-commit: flang-compiler/f18@1f7ff22145
Reviewed-on: https://github.com/flang-compiler/f18/pull/872
Tree-same-pre-rewrite: false
Extend `ResolveGeneric` to handle calls to procedure components by
passing in the data-ref that is used as the passed-object argument.
`AddPassArg` takes care of adding a placeholder for the passed object.
This is shared by the generic and non-generic cases of calls to
procedure components.
Original-commit: flang-compiler/f18@be83590183
Reviewed-on: https://github.com/flang-compiler/f18/pull/863
The real operand was always converted to the complex operand type.
The highest precison should be used instead. This fix converts the
real to a complex of the same kind before applying the promotion
rules for complex operands.
Reference to Fortran 2018 standard 10.9.1.3 that rules this added
in comments.
Original-commit: flang-compiler/f18@0d6b9c33aa
Reviewed-on: https://github.com/flang-compiler/f18/pull/858
identification of their index in the dummy argument list,
simplifying their representation, completing the representation
of their actual arguments, and (while I'm here) resolving
calls to type-bound procedures whose bindings are known at
compilation time.
Button up class ActualArgument by making remaining data
members private and adding accessors & mutators.
Original-commit: flang-compiler/f18@5eb60ec419
Reviewed-on: https://github.com/flang-compiler/f18/pull/855
1. Dump negative parts in complex constants without parentheses
(-1., 0.) was dumped as ((-1.), 0.) from f18 expression format.
The latter format is only valid with the complex constructor extension
that is not supported by all compilers.
This commit ensure the former fromat is used in dumps so that dumps can
be used by all fortran compilers. It turns out the parenthesis added
by REAL::AsFortran are not required because operation lowering is
already taking care of this.
2. Dump evaluate::ComplexComponent with REAL/IMAG instead of %RE/%IM
f18 was failing to reparse its own dump in some cases involving
complex expressions like `-z**i`.
The reason was %RE and %IM were used to dump ComplexComponents.
%RE and %IM can only be used on designators but ComplexComponent can
contain arbitrary complex expressions.
Hence, %RE and %IM cannot be used to dump ComplexComponent.
This commit replace them with call to intrinsic function
REAL/IMAG.
Note that this may unfortunatly be unsafe if the user
shadowed REAL or IMAG but I do not see an easy way to solve
this... The current dump is not correct.
Original-commit: flang-compiler/f18@4550a23d0b
Reviewed-on: https://github.com/flang-compiler/f18/pull/851
A symbol that represents a procedure binding is PURE if the procedure
it is bound to is PURE. Fix `IsPureProcedure` to check that.
Make use of `IsPureProcedure` in `CheckSpecificationExprHelper`.
Original-commit: flang-compiler/f18@c95f2eb4fb
Reviewed-on: https://github.com/flang-compiler/f18/pull/849
This is prohibited by Section 11.1.7.4.1, paragraph 1.
Note also that we allow for REAL step expressions. But the check I
added only works for INTEGER step expressions.
I added a function to tools.cc to test to see if an expression is zero,
and I added calls to check-do.cc for regular and CONCURRENT DO
statements to this function. I made the regular DO a warning and the DO
CONCURRENT message an error. I added tests for the DO CONCURRENT case,
including a test that uses an integer constant.
Original-commit: flang-compiler/f18@8c4fadfe00
Reviewed-on: https://github.com/flang-compiler/f18/pull/834
Section 15.4.3.4.2 specifies restrictions on functions that may be used
to implement an "extended-intrinsic-op". These checkw are implemented in
`CheckHelper::CheckDefinedOperator`.
Move `IsIntrinsicRelational` et al. to `semantics/tools.h` so that
the same logic is used to check both dummy and actual arguments.
Fix up tests that had errors that are now detected.
Original-commit: flang-compiler/f18@b900762eed
Reviewed-on: https://github.com/flang-compiler/f18/pull/846
Change expression analysis to do assignment statements as it currently
does call statements. Check there for defined assignment and set
`typedAssignment` in the `AssignmentStmt` node to contain the analyzed
assignment, either intrinsic or user-defined.
When `var = expr` is implemented by subroutine `sub`, the analyzed
assignment contains a procedure reference to `sub(var, (expr))`.
Add `IsDefinedAssignment` to decide based on types and ranks of lhs
and rhs whether is can be a defined assignment. The result is
tri-state because when they are both the same derived type it can
be either intrinsic or defined. Use this where a similar decision
is made in `check-declarations.cc`.
Change "Procedure referenced in PURE subprogram" error message to
contain the name of the procedure. If the reference is from a defined
assignment that name won't appear on the highlighted source line.
Original-commit: flang-compiler/f18@5c87071210
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Perform the checks from 15.4.3.4.3 to determine what procedures are
valid to implement defined assignment. This requires characterizing
procedures, so share the result of that with
`CheckSpecificsAreDistinguishable`.
Original-commit: flang-compiler/f18@9e0d79f173
Reviewed-on: https://github.com/flang-compiler/f18/pull/841
Tree-same-pre-rewrite: false
This constraint prohibits deallocation of polymorphic entities in a DO
CONCURRENT.
Section 9.7.3.2 specifies the situations that might cause deallocation
of a polymorphic entity. The ones that are applicable to a DO CONCURRENT
are exiting from a block that declares such variables, intrinsic
assignment, and an actual DEALLOCATE statement. This section also
specifies (paragraph 8) that deallocation of a derived type causes
deallocation of all of its allocatable subobjects.
Section 10.2.1.3 specifies what happens during intrinsic assignment.
Paragraph 3 states If the variable is an allocated allocatable variable,
it is deallocated if expr is an array of different shape, any
corresponding length type parameter values of the variable and expr
differ, or the variable is polymorphic and the dynamic type or any
corresponding kind type parameter values of the variable and expr
differ." Thus, an allocatable polymorphic variable on the left hand side
of an assignment statement gets deallocated. Paragraph 13 states that
"For a noncoarray allocatable component the following sequence of
operations is applied.
(1) If the component of the variable is allocated, it is deallocated."
Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated.
Deallocation can be caused by exiting from a block where the entity is
declared, from an assignment, and from direct deallocation.
Original-commit: flang-compiler/f18@7d1932d344
Reviewed-on: https://github.com/flang-compiler/f18/pull/814
Update the grammar to handle logical abbreviations (e.g. `.A.` for `.AND.`)
when the feature is enabled. Only support `.X.` when both XOR and
logical abbreviations are enabled.
Fix the driver to enable logical abbreviations with the
`-flogical-abbreviations` option. This was already documented in
`documentation/Extensions.md`.
Remove `parser::Expr::XOR` from the parse tree and immediately map
`.XOR.` to `.NEQV.` if that feature is enabled. This was already being
done during expression analysis anyway.
Add `LanguageFeatureControl::GetNames` to return all of the names of
a logical or relational operator, depending on which features are
enabled. Use these in both name resolution and expression analysis.
Add `Not` to `LogicalOperator` to help in those cases.
Fix handling of BOZ literals: A numeric operation with one real or
integer operand and the other a BOZ literal is intrinsic.
Also, unary plus with a BOZ literal operand is also intrinsic.
Original-commit: flang-compiler/f18@956bd50bc7
Reviewed-on: https://github.com/flang-compiler/f18/pull/815
* Use Extremum<T> FoldOperation to fold MIN and MAX
* Fix Extremum<T> FolOperation
* For character, the length is the one of the longest argument.
Define and use `CharacterUtils<Kind>::Resize` helper to do this.
* For array of all types, Extremum<T> with Ordering::Less was
behaving like Ordering::Greater. This is because the default
`ApplyElementwise` for `Operation` was selected and it then
called the Extremum<T> constructor without the ordering
argument (which was an optional defaulted to Greater).
Define a specific handler for Extremum<T> and make the ordering
argument mandatory to prevent this kind of bug to pass
f18 compilation in the futur.
* Fix intrinsic.cc for MIN and MAX
* When provided with two arguments, `Match` was adding an empty
3rd optional actual argument. Later code working on min and
max was not expecting this and failing. The fix prevent this
empty argument to be created by changing the initial size of
`actualForDummy` to actually be the number of dummies that do
not have `Optionality::Repeats`
This commit fixes issue flang-compiler/f18#677.
Original-commit: flang-compiler/f18@acb62f240b
Reviewed-on: https://github.com/flang-compiler/f18/pull/803
Change `AllFortranNames()` to return a `std::vector` rather than a
`std::initialization_list`. The latter doesn't own its underlying
storage and so can't be returned as a value. clang detects this and
issues a warning.
Two tests in `resolve63.f90` behave differently with clang and require
further investigation.
Original-commit: flang-compiler/f18@1ed3a3cfee
Reviewed-on: https://github.com/flang-compiler/f18/pull/810
Enhance `ArgumentAnalyzer` to do most of the work for this.
For each kind of operator that might have a user-defined form we follow
this process:
- analyze the arguments
- if the types and shapes match the intrinsic operator do the usual
processing
- otherwise attempt to interpret it as a user-defined operator with
`TryDefinedOp`
When we fail to resolve an operator, produce different errors depending
on whether there is a user-defined operator available or not.
If there is, report that neither user-defined nor intrinsic operator
worked. If there is not, describe the rules for the intrinsic operator.
In either case, include the type(s) of the operand(s).
Most of the uses of `ArgumentAnalyzer` are in helper functions that
apply to classes of operators.
For consistency, rename `BinaryOperationHelper` to `NumericBinaryOperator`
and `LogicalHelper` to `LogicalBinaryHelper` and introduce `NumericUnaryHelper`
for unary `+` and `-`. `.NOT.` and `//` are not implemented in helpers.
Replace `success_` with `fatalErrors_` in `ArgumentAnalyzer` for
consistency with `ExpressionAnalyzer`.
Add `NumericOperator` and `LogicalOperator` enums to `Fortran.h` to go
with `RelationalOperator`. Add `AddFortran` functions to each to convert
to a Fortran source string. `RelationalOperator` also has `AllFortranNames`
because there are multiple names for each operator. This replaces
`LogicalOperator` in `expression.h` and the string representation of
the operators in `formatting.cc`.
Original-commit: flang-compiler/f18@3bb9d664e8
Reviewed-on: https://github.com/flang-compiler/f18/pull/807
Relax checking when irrelevant due to INTENT(IN)
Add and pass call14.f90 test on VALUE
Allow ASYNCHRONOUS/VOLATILE to apply to host/USE associated entities, add tests
Pass call06
Check C827 & C828, fix tests
Original-commit: flang-compiler/f18@df6cb83794
Reviewed-on: https://github.com/flang-compiler/f18/pull/801
During the symbol tests, OpenMP directives (start with "!$omp")
line needs to be saved for 1.f90 and 2.f90. Also moved "OPTIONS:"
detection to common.sh as "$USER_OPTIONS"
Original-commit: flang-compiler/f18@7d4e8e8ad5
The major changes are:
1) changed the non-nullptr type to reference
2) changed ResolveOmpObject to use std::visit
3) the rest of the changes are about positions and naming
Original-commit: flang-compiler/f18@93debe59f3
DSA stands for Data-Sharing Attribute. This work is part of the
Name Resolution for OpenMP framework (data-refs on clauses part)
Based on 2.15.3: A list item that specifies a given variable may
not appear in more than one clause on the same directive, except that
a variable may be specified in both firstprivate and lastprivate clauses.
Through a temporary `std::set` of `const Symbol *` to keep track of
all the symbols on a certain OpenMP directive, we can determine whether
a variable `Name` (or `Symbol`, more accurately) has already appeared on
another DSA clause already, with the exception of FIRSTPRIVATE clause
and LASTPRIVATE clause. This rule applies to `/COMMON block/` also and
the source provenance shows on error message points to the `Name` between
slashes.
Added two more tests and changed some existing tests to accommodate
this commit. I intend to keep the `omp-clause-validity01.f90` test to
do the validity checks only.
Original-commit: flang-compiler/f18@0d7828c21e
This is a preliminary framework to do the name resolution for
data references on the OpenMP clauses. Unlike data references
in the OpenMP region, clauses determining the data-sharing or
data-mapping attributes are straightforward and the resolution
process could be extended to do the name resolution in the OpenMP
region. It is hard to determine what kind of checks can be done
in this visitor and what checks should be done later after name
resolution. But the guide line is that `After the completion of
this phase, every Name corresponds to a Symbol with proper OpenMP
attribute(s) determined unless an error occurred.`
1. Take data-sharing clauses as example, create new symbol for
variable that require private access within the OpenMP region.
Declare the entity implicitly if necessary. The new symbol has
`HostAssocDetails`, which is mentioned in the `OpenMP-semantics.md`.
2. For `Shared` or `ThreadPrivate`, no symbol needs to be created.
OpenMP attribute Flag `OmpThreadprivate` needs to be marked for
`Threadprivate` because the `threadprivate` attribute remains the
same whenever these variables are referenced in the program.
`Names` in `Shared` clause need to be resolved to associate the
symbols in the clause enclosing scope (contains the OpenMP directive)
but `OmpShared` does not need to be marked. Declare the entity
implicitly if necessary.
3. For `COMMON block`, when a named common block appears in a list,
it has the same meaning as if every explicit member of the common
block appeared in the list. Also, a common block name specified in
a data-sharing attribute clause must be declared to be a common
block in the same scoping unit in which the data-sharing attribute
clause appears. So, if a named common block appears on a `PRIVATE`
clause, all its members should have new symbols created within the
OpenMP region (scope). For later Semantic checks and CG, a new
symbol is also created for common block name with `HostAssocDetails`.
There are many things are still on the TODO list:
- Better error/warning messages with directive/clause source provenance
- Resolve variables referenced in the OpenMP region, for example,
`private(tt%a)` is not allowed but `tt%a = 1` is allowed in the
OpenMP region and a private version of `tt` maybe created for
the region. The functions created in the `OmpVisitor` should be
able to handle the name resolution on the statement too (more
data structures may be introduced). This is a big portion and may
require some interface changes to distinguish a reference is on
`OpenMP directive/clause` or `statements within OpenMP region`.
- Same data reference appears on multiple data-sharing clauses.
- Take association into consideration for example Pointer association,
`ASSOCIATE` construct, and etc.
- Handle `Array Sections` and `Array or Structure Element`.
- Handle all the name resolution for directives/clauses that have
`parser::Name`.
- More tests
Original-commit: flang-compiler/f18@b2ea520885
This addresses issue flang-compiler/f18#781. I changed my test to create a PURE procedure
component by using an interface as suggested by Peter and Jean. I then
enhanced the function IsPureProcedure() in tools.cc to cover this case
and updated the code in check-do.cc to perform the test.
Original-commit: flang-compiler/f18@5df56a217d
Reviewed-on: https://github.com/flang-compiler/f18/pull/789
# This is the 1st commit message:
Changes to disallow image control statements in DO CONCURRENT
Most of these changes were already implemented. The last remaining part was to check for calls to move_alloc with coarray arguments. This set of changes implements that. I also bundled other changes. Specifically:
All of the code to detect image control statements was moved from check-do.cc to tools.cc so that it could be used by other semantic checking functions.
I added location information to the error messages for all DO semantics checks to highlight either the DO loop associated with the error or other relevant source locations.
I cleaned up the error messages associated with DO semantics so that they have more consistent grammar and punctuation.
I eliminated redundant checks for IEEE_GET_FLAG and IEEE_HALTING_MODE.
I removed the redundant test doconcurrent08.f90.
Responses to pull request comments
I changed the interface to determine whether a statement is an image control
statement to use an ExecutableConstruct as its input. Since
ExecutableConstruct contains types that do not have source location information
(ChangeTeamConstruct and CriticalConstruct), I also created a function to get
the source location of an ExecutableConstruct. Also, some ExecutableConstructs
are image control statements because they reference coarrays. I wanted to tell
users that the reason that an ALLOCATE statement (for example) is an image
control statement because it references a coarray. To make this happen, I
added another function to return a message for image control statements that
reference coarrays.
I also cleaned up the references to the standard in comments in check-do.cc to
briefly describe the contents of those constraints.
I also added messages that refer to the enclosing DO CONCURRENT statement for
error messages where appropriate.
Responses to pull request comments
The biggest change was to redo the implementation of "IsImageControlStmt()" to
use a custom visitor that strips off the "common::Indirection<...>" prefix of
most of the image control statement types and also takes advantage of
"common::HasMember<...>" to determine if a variant contains a specific type.
Spelling error.
# This is the commit message flang-compiler/f18#2:
More refactoring in response to comments on the pull request.
Original-commit: flang-compiler/f18@3f0a0155b3
Reviewed-on: https://github.com/flang-compiler/f18/pull/780
Most of these changes involve moving code around so that it case be
used for `DefinedUnary` and `DefinedBinary`. The functional changes are
in the `Analyze` member functions for those cases where the arguments
are now analyzed, the generic is resolved, and a `FunctionRef` is
created.
Add `ArgumentAnalyzer` to handling building of the `ActualArguments`
of a call. This allows the code to be shared with the defined unary
and defined binary cases. Move `AnalyzeActualArgument` and
`AnalyzeActualArgument` into that class (renaming both to `Analyze`).
Create an overload of `GetCalleeAndArguments` for the `Name` case so it
can be used for defined ops where we don't have a `ProcedureDesignator`.
Move `IsGenericDefinedOp` to `tools.h` to make it available to the
new code.
We were using `semantics::CheckExplicitInterface` to resolve a generic
interface to a specific procedure based on actual arguments. The problem
with that is that it performs too many checks. We just want to get the
right specific; there may be errors reported later during call analysis.
To fix this, add a new function, `CheckInterfaceForGeneric`, to perform
this check. It shares code with `CheckExplicitInterface`, but it passes
in a null scope to indicate that the full set of checks aren't
necessary in `CheckExplicitInterfaceArg`. Instead we lift the call to
`TypeAndShape::IsCompatibleWith` out of `CheckExplicitDataArg`, and skip
the latter when there is no scope.
Original-commit: flang-compiler/f18@fff2d1580f
Reviewed-on: https://github.com/flang-compiler/f18/pull/786
Implement the basics of resolving generic names in expressions.
`ExpressionAnalyzer::ResolveGeneric` maps the symbol for a generic
name to the specific procedure appropriate for the actual arguments.
Extract `CheckExplicitInterface` out of `CheckArguments` so that it
can be tried for each specific procedure of the generic as part of
the test to see which is compatible.
Note that it may be there is an elemental and non-elemental specific
procedure that is compatible with the actual arguments. In that case
the generic is resolved to the non-elemental one.
Test this by using generic functions in specification expressions
that must be written to module files. Verify how the generics were
resolved by looking at the generated `.mod` files.
There is more work to be done in this area: the passed-object dummy
argument is not considered and in some cases generated module files
are not correct.
Original-commit: flang-compiler/f18@50e458045a
Reviewed-on: https://github.com/flang-compiler/f18/pull/778
Extend documentation on preprocessing
IsSimplyContiguous
basic skeleton
Apply suggested improvements to mod-file.cc
Checks for new call13.f90 (15.4.2.2 explicit interfaces)
Implement checking for procedures that can be called via an implicit interface
Argument checking, test fixing
Better argument checking
Better derived type compatibility checking
Treat externals as if implicitly interfaced
Extend IEEE_EXCEPTIONS module so tests still pass with argument checking
SAME_TYPE_AS and EXTENDS_TYPE_OF intrinsic inquiry functions
Define interfaces for most intrinsic subroutines
Better PASS arguments
More with PASS() argument
Prep for review
address comments
fix comment
Remove formatted expression from specification expression error message per review
more review comments
Original-commit: flang-compiler/f18@3cca775da9
Reviewed-on: https://github.com/flang-compiler/f18/pull/776
This time I'm adding to the checks for constraint C1137, which states
that image control statements cannot appear in a DO CONCURRENT. The
checks I added test to see if the DO CONCURRENT contains an ALLOCATE or
DEALLOCATE that references a coarray.
Original-commit: flang-compiler/f18@c16b883db3
Reviewed-on: https://github.com/flang-compiler/f18/pull/769
peter klausler