If a symbol (derived type, for example) was use-associated into a scope
and then imported into a nested interface block, we were not including
the correct IMPORT statement in the .mod file.
This fixes refines the test for when the IMPORT is needed.
Fixesflang-compiler/f18#657.
Original-commit: flang-compiler/f18@8383de47ec
Reviewed-on: https://github.com/flang-compiler/f18/pull/675
Tree-same-pre-rewrite: false
Some attributes for subprograms can be in the subprogram prefix but
others cannot. For the latter, emit a separate attribute statement
to specify them. We were already doing that for PRIVATE but not for
OPTIONAL. Those may be the only two attributes this can apply to.
Fixesflang-compiler/f18#659.
Original-commit: flang-compiler/f18@ae67e08780
Reviewed-on: https://github.com/flang-compiler/f18/pull/675
Tree-same-pre-rewrite: false
When defined operators were written to .mod files in USE statement
they did not come out correctly. They have to be emitted with
`PutGenericName()` so that `operator` is included.
Original-commit: flang-compiler/f18@d40e65a2f9
Reviewed-on: https://github.com/flang-compiler/f18/pull/675
Tree-same-pre-rewrite: false
1. Big chunk: update comments in parse-tree.h and openmp-grammar.h
with Spec chapter/section info, simple explanation, or productions.
2. Update `To`, `Link`, and `From` clauses with `OmpObjectList` to allow
`/Common Block/`. Spec does not mention whether `Common Block name`
should be accepted or not, so we should assume that these clauses
accept normal `list-item`, which is `Variable`, `Array Section`, or
`Common Block name`.
Original-commit: flang-compiler/f18@140315cb62
Reviewed-on: https://github.com/flang-compiler/f18/pull/673
Address comments. Not all scopes are related to
a name. This change makes this more visible to compiler
programers by changing `scope:name()` into `Scope::GetName()`
that returns an optional `SourceName` instead of always
returning a `SourceName` and dying when it cannot.
Original-commit: flang-compiler/f18@0addb79919
Reviewed-on: https://github.com/flang-compiler/f18/pull/634
Tree-same-pre-rewrite: false
Change all SourceName* to std::optional<SourceName> because
SourceName is small enough (16 bytes) to be passed and stored
by value which avoid having to worry about life-time, storage and
value constance issues that comes with pointers.
Original-commit: flang-compiler/f18@73fc08d7bd
Reviewed-on: https://github.com/flang-compiler/f18/pull/634
Tree-same-pre-rewrite: false
* [OpenMP] Canonicalization framework
This is mainly designed for loop association work but can be used for others,
and `CanonicalizeOmp` must be after `CanonicalizeDo`.
At the `Block` level, recognize legal sequence of `OpenMPLoopConstruct`,
`DoConstruct`, and `OmpEndLoopDirective`. Move available `DoConstruct`
and optional `OmpEndLoopDirective` into `OpenMPLoopConstruct`. Throw error
messages if:
1. `DoConstruct` is not following `OpenMPLoopConstruct`
2. `OmpEndLoopDirective` is not following associated do-loop
Once this pass this done, Semantics will not proceed if error exists.
* Update on reviews
1. extract matching and move part into its own function (once `DoConstruct`
is moved, see whether `OpenMPEndLoopDirective` is available)
2. Use a template function to access construct from ExecutionPartConstruct.
3. Move this code into namespace semantics
Original-commit: flang-compiler/f18@52979f1e93
Reviewed-on: https://github.com/flang-compiler/f18/pull/599
Fix issue flang-compiler/f18#574.
Array references can be mistaken for function references during
parsing. This is handled and fixed by semantics. however, if the
symbol in the misparsed array reference was construct associated,
then semantics was not handling the case correctly because
semantics was only expecting `ObjectEntityDetails`.
It was not possible to change the related `GetUltimate` into
`GetAssociationRoot` because associated symbols are not always
associated to another symbol (variable) but may be assoicated to
an expression. Hence, this change allow `AssocEntityDetails` to
be also accepted when dealing with array references misparsed as
function references.
Original-commit: flang-compiler/f18@b6a8b5f42b
Reviewed-on: https://github.com/flang-compiler/f18/pull/672
Tree-same-pre-rewrite: false
- I removed the redundant test s3() from dosemantics90.f90
- I changed the error messages to state "LOCAL locality-spec" rather than just
"locality-spec"
- I changed the names of a couple of variables/parameters in check-do.cc to
make the code more understandable.
Original-commit: flang-compiler/f18@bcc6291e83
Reviewed-on: https://github.com/flang-compiler/f18/pull/663
"C1129 A variable that is referenced by the scalar-mask-expr of a concurrent-header or by any concurrent-limit or concurrent-step in that concurrent-header shall not appear in a LOCAL locality-spec in the same DO CONCURRENT statement."
In the process of implementing these checks, I found and fixed some other problems. I also cleaned up some of the code in check-do.cc. I ran into two notable difficulties in implementing these checks. First, the symbols associated with the names in a locality spec get created when the locality specs are process during name resolution. Thus, they're different from the symbols associated with names that appear in the control expressions. At Tim's suggestion, I dealt with this by looking up the symbols from the names in the locality spec starting with the closest enclosing scope containing the DO construct. Second, the symbols can be hidden behind host- use- and construct-associations.
Original-commit: flang-compiler/f18@055788c2f0
Reviewed-on: https://github.com/flang-compiler/f18/pull/663
Tree-same-pre-rewrite: false
I got rid of duplicate functions that test for a procedure being PURE, renamed
the type SymbolContainer to SymbolSet, and moved some functions into the class
where they're referenced.
Original-commit: flang-compiler/f18@e48bfdf573
Reviewed-on: https://github.com/flang-compiler/f18/pull/663
Tree-same-pre-rewrite: false
The original implementation will throw parsing error for multiple
clauses on `declare target` directive, for example:
```
!$omp declare target to(Q) link(R)
```
Based on the OpenMP Spec, we only need two types for the specifier:
```
!$omp declare target (extended-list)
```
or
```
!$omp declare target [clause[ [,] clause] ... ]
```
This fix makes `declare target` accepts either the `list` or `clauses`,
which is more general and better for error messages.
Adjusted existing test for checking the parse tree changes. More tests
will be added during Semantics.
Original-commit: flang-compiler/f18@60f47fc1a1
Reviewed-on: https://github.com/flang-compiler/f18/pull/670
The VOLATILE and ASYNCHRONOUS attributes are special in two ways:
- they can be applied to use-associated variables
- if they are applied to a host-associated variable in a block, that
variable has the attribute only within the scope of the block
The latter is implemented by making a new `HostAssocDetails` symbol
within the block where the attribute can be set without affecting the
variable in the outer scope. This is similar to how the SHARED locality
spec is implemented.
Fixesflang-compiler/f18#649.
Original-commit: flang-compiler/f18@471aba4513
Reviewed-on: https://github.com/flang-compiler/f18/pull/655
So far, in `ImplicitRules` class, `isImplicitNoneType_` is a ternary
unset -> nothing about implicit in this scope, look into parents
set true -> There is an IMPLICIT NONE for types in this scope.
set to false -> There is an IMPLICIT statement mapping types in
this false.
However, it was never set to false, so the IMPORT NONE of parent scopes
was "leaking" when it should not.
Set `isImplicitNoneType_` to false if an IMPLICIT statement is met to
fix the issue.
However, this change made the current name-resolution to then completly
disregard parent scope IMPLICIT NONE even for letters for which no
mapping were defined in the current scope. To fix this `GetType` was
modified to check for implicit none.
This led to `ApplyImplicitRules` to do redudant check, so it was
reorganised to querry for a type and complain if gets a nuulptr.
`GetImplicitType` was modified to avoid redundant error message.
Original-commit: flang-compiler/f18@962dbf3d8b
Reviewed-on: https://github.com/flang-compiler/f18/pull/635
Tree-same-pre-rewrite: false
1. Following Block and Sections constructs, re-structure loop related
constructs into `{Begin, Loop, End}`. Being part of the work in
PR flang-compiler/f18#599, the `Loop` and `End` nodes are optional during parser. They
should be filled in during the phase of `CanonicalizationOfOmp`. This
commit is solely for the parse tree change. So, after this commit,
PR flang-compiler/f18#599 needs to be changed accordingly.
2. Removed parse tree nodes for `END DO` and `END DO SIMD`. Similar to
Block and Sections constructs, `End` node now accepts clauses too,
the validity checks are deferred into Semantics. This is more genernal
and error message could be better.
3. With this commit alone, assertion error would occur when `End` directive
is present, for example `!$OMP END DO` because the `End` node is not
moved into `OpenMPLoopConstruct` yet. Again, PR flang-compiler/f18#599 will handle that.
More tests will be added in PR flang-compiler/f18#599 and during the future Semantics work.
Original-commit: flang-compiler/f18@8cd1932fd6
Reviewed-on: https://github.com/flang-compiler/f18/pull/656
```
!$omp sections [clause[ [,] clause] ... ]
[!$omp section]
structured-block
[!$omp section
structured-block]
...
!$omp end sections [nowait]
```
1. Following parse tree node changes for Block constructs, changing the
Sections/Parallel Sections to `{Begin, Section-Blocks, End}`
2. Handles `!$omp section` in the parser, do not create parse tree node
for this directive because basically it is a delimiter to split the
code into different `Block`s within the Sections/Parallel Sections
constructs. So, the `Section-Blocks` here is a `std::list` of `Block`s.
(thanks to Tim's suggestion)
3. Modify check-omp-structure.* to avoid breaking existing tests
More tests will be added during Semantics. Also, similar to Block constructs,
the `Begin` and `End` directive matching will be done in future PR.
This commit also contains Peter's important fix for allowing "!$OMP END SECTION"
as a legal statement following `Block` (daf5630: Modify execution part error
recovery to not consume !$OMP SECTION).
Original-commit: flang-compiler/f18@75d016f6d2
Reviewed-on: https://github.com/flang-compiler/f18/pull/652
Character literals in an array constructor were always written
with no kind prefix, so if kind was not 1 they were incorrect.
`c4a` in `modfile28.f90` was an example of this.
Change it to always include the kind as is done with non-array
character literals.
Original-commit: flang-compiler/f18@4f4caa7006
Reviewed-on: https://github.com/flang-compiler/f18/pull/650
Symbols can be declared across multiple statements. The CharBlock
that is used for the symbol name is from the first of these.
Sometimes that is not the best choice. If a name appears in a
type-declaration-stmt or a derived-type-stmt, that occurrence is a
better choice. Errors referencing that symbol should normally point
at that name (not its appearance in an earlier PUBLIC statement,
for example).
Also, the order of symbols in .mod files is based on the order of
their names in the cooked source. Here is an example where it is
necessary to sort `a` based on where its type-declaration-stmt
occurs rather than the first occurrence of `a`:
```
public :: a
type t
end type
type(t), parameter :: a = t()
```
The fix is to add `Symbol::ReplaceName()` so that we can update the
CharBlock for a symbol name when a better one is found, without
changing the actual characters that make up the name.
Original-commit: flang-compiler/f18@5544f16348
Reviewed-on: https://github.com/flang-compiler/f18/pull/650
Tree-same-pre-rewrite: false
The function result can depend on the declaration of the dummy
arguments so it should be written to the .mod file after them.
For example:
```
function f(x)
integer :: x(:)
integer :: f(size(x))
end
```
Original-commit: flang-compiler/f18@f6c8c58c24
Reviewed-on: https://github.com/flang-compiler/f18/pull/650
Tree-same-pre-rewrite: false
* [OpenMP] parse tree changes for `OpenMPBlockConstruct`
1. merge `Workshare` and `Single` into `OpenMPBlockConstruct` because
they both accept structured-block and syntax is similar to other block
directives.
2. `OpenMPBlockConstruct` changes to structure like `{Begin, Block, End}`,
where `Begin` and `End` are tuple of `{Directive, ClauseList}`.
3. Updated the check-omp-structure.* for necessary parts. Added all the END
directive enumeration types that may have clauses.
More tests will be added during Semantics.
* [OpenMP] Update on Tim's suggestion
1. Fix unspecified enumeration for `OmpDirective` in the `OmpContext`.
This is through getting rid of `PushContext(source)` function to
make sure whenever it is about to push a NEW context, directive
source location and enumeration are available. To do that, I moved
around all the switches for directive into high level `Construct`'s
`Enter` node. Besides fixing the issue, the side benefit is that
whenever we call `GetContext().directive`, we are sure that the
`directive` here was set already.
2. When `Enter` the `OmpEndBlockDirective` node, partial context
information, such as directive source location or legal clause lists,
needs to be reset. The new directive source location should be
`OmpEndBlockDirective`'s `source`. The enumeration `directive`
should not be reset for the END directives that do not accept
clauses because nothing needs to be checked (for example any clause
that is on `END PARALLEL` is illegal).
Original-commit: flang-compiler/f18@e5bd6b7ba0
Reviewed-on: https://github.com/flang-compiler/f18/pull/632
