Straightforward check for Begin and End directive of:
1. Block related constructs
2. Loop related constructs (End directive is optional)
3. Sections related constructs
Original-commit: flang-compiler/f18@d0436f13ee
Because now we set the flag for `End` directives that accept clauses,
no need to check the specific directives anymore.
Original-commit: flang-compiler/f18@a5cdc4b035
During enumerator name resolution, instead of keeping the current
enumerator value inside an expression, fold it to an int and keep
it as an int. This is clearer and will be easier if one wants to
provide some enum type size optimization.
Original-commit: flang-compiler/f18@4e49d5396c
Reviewed-on: https://github.com/flang-compiler/f18/pull/689
Tree-same-pre-rewrite: false
Split omp_lib.F90 into two files: a Fortran file used to
create the omp_lib module and a .h file that can be used
directly, which apparently some codes do. Because of the
split, and wanting to avoid forcing use isc_c_binding,
use int_ptr_kind() instead of c_intptr_t.
Original-commit: flang-compiler/f18@ce6a9fb173
Reviewed-on: https://github.com/flang-compiler/f18/pull/690
Tree-same-pre-rewrite: false
When the name of a statement function was previously declared, we
weren't correctly recognizing it as a statement function. E.g.
```
integer :: f, i
f(i) = i + 1
```
`f` was entered in the symbol table with `EntityDetails` and the
`parser::Name` on the first line was resolved to that symbol.
On the second line we replaced the symbol for `f` in the scope
with a subprogram symbol, but that didn't change the symbol in
the first `parser::Name`.
The fix requires:
1. don't erase the original symbol for `f`, just replace its details
2. when we erase the symbol for `f` in the subprogram scope, don't
unresolve it
Original-commit: flang-compiler/f18@31212686ea
Fix issue flang-compiler/f18#676
The issue was that the 'DEFAULT' case was handled
directly in fold.cc which did not lowercase/trim trailing
space of the argument befaore comparing to "default".
Modify the `Selected_char_kind` function to accept the default
char kind as argument and to return it if the processed argument
matches "default".
Original-commit: flang-compiler/f18@14222ae914
Reviewed-on: https://github.com/flang-compiler/f18/pull/679
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
so makefiles with "rm *.mod" will still work. Add a
new option to f18, -intrinsic-module-directory, which
supplies a directory in which f18 searches for standard
intrinsic modules. Neither the option nor the path is passed to F18_FC.
Original-commit: flang-compiler/f18@0bbda4c39e
Reviewed-on: https://github.com/flang-compiler/f18/pull/653
Add a script called flang to the bin directory that calls
f18 with the -I option pointing to the module files for the
predefined modules. The wrapper also sets the module suffix
to .fmf to avoid naming conflicts with module files generated
by other compilers. Now, the build creates and installs both
.mod and .fmf files for the predefined module files to
accommodate the flang script.
Original-commit: flang-compiler/f18@b6c30284e7
Reviewed-on: https://github.com/flang-compiler/f18/pull/653
Tree-same-pre-rewrite: false
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
- doconcurrent01.f90: I removed the custom versions of ieee_exceptions and
iso_fortran_env. I also fixed a typo in a comment. Also, the use of the real
standare interface caused one of the error messages to go away, so I fixed
that.
Original-commit: flang-compiler/f18@a8b310a968
Reviewed-on: https://github.com/flang-compiler/f18/pull/637
* [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
1. make the parse tree nodes more conform with OpenMP spec
2. isolate the memory related clauses to make the parse tree nodes
extendable for OpenMP 5.0
3. source provenance is saved for each atomic-clause (read, write, update,
and capture); for atomic-clause that is not present, source location
is saved for "ATOMIC" directive name itself
More tests will be added during Semantics.
Original-commit: flang-compiler/f18@8e2db2f868
Reviewed-on: https://github.com/flang-compiler/f18/pull/636
If a generic interface had a specific procedure with the same name that
is specified by an interface body, it was not handled correctly.
We were replacing the generic symbol with the symbol for the specific
procedure. Instead, leave the generic symbol in the scope and just
insert the new symbol for the specific into the generic.
Also, don't do distinguishability checks when one of the specific
procedures already has an error.
Fixesflang-compiler/f18#587.
Original-commit: flang-compiler/f18@2e90565675
Reviewed-on: https://github.com/flang-compiler/f18/pull/640
+ Fix issue 589.
+ Catch empty subscript list in array reference
In name resolution, when skimming through the execution statement of a
function, calls to the result symbol should not trigger the conversion
of this symbol to a function symbol. The result is a data object and
cannot be called unless it was explictly declared to be a procedure
pointer.
Notably, recursive function calls cannot be made if RESULT was not used.
The symbol is prevented from being transformed into a function
symbol by transforming it into an object before skimming through the
executable statement. This is done after processing all the
specifications so that if the result actually is a procedure pointer,
the call to `ConvertToObjectEntity` introduced by this commit will
not convert it to an object by mistake.
This commit also introduce a check when fixing misparsed function
reference into array reference to verify the array reference has
array subscripts. Currently this went uncaught. It is not possible
to complain later in expressions because the subscript list of
expression might be empty for unrelated error recovery reasons
(e.g. if an entity of the wrong type appeared as susbcript).
Add related tests.
Original-commit: flang-compiler/f18@2fd8b65f58
Reviewed-on: https://github.com/flang-compiler/f18/pull/631
Tree-same-pre-rewrite: false
After fixing 594, it appears there were issues in
FindUltimateComponent that was considering type bound
procedure as components.
This commit fixes and beef-up the component visitation by making a visitor
class for it. The main advantage of making it an class vs functions is that
it is possible to get the component chain to the result component for better
feedback for the user.
The framework allow a single place to define/handle what ultimate, direct and
potential components are.
Original-commit: flang-compiler/f18@d84821a1d6
Reviewed-on: https://github.com/flang-compiler/f18/pull/607
Tree-same-pre-rewrite: false
There were many places in tests and predefined modules that had
incorrect code that we weren't detecting until now.
Most of the problems were deferred-shape arrays that should have
been implied-shape. For example:
`real, parameter :: a(:) = [1.0, 2.0]`
should have `(*)` rather than `(:)`.
There were also a few places with deferred-shape arrays that were
not allocatable/pointer or explicit-shape ones that were.
Original-commit: flang-compiler/f18@0a959ce1d8
Reviewed-on: https://github.com/flang-compiler/f18/pull/630
There are many constraints on what kind of array-specs can appear
in what contexts. Add `CheckArraySpec()` to perform most of them.
When the check fails, don't set the shape of the symbol being
declared and instead set the Error flag so we can avoid cascading
errors.
Fixesflang-compiler/f18#609.
Original-commit: flang-compiler/f18@f159d97f1f
Reviewed-on: https://github.com/flang-compiler/f18/pull/630
Tree-same-pre-rewrite: false
This allows it to have member functions `Rank()`, `IsExplicitShape()`,
`IsAssumedShape()`, etc. Make use of those new functions and remove
`isExplicit()` and `isDeferred()` from `ShapeSpec` as they are no
longer needed.
Original-commit: flang-compiler/f18@7ef7ad6359
Reviewed-on: https://github.com/flang-compiler/f18/pull/630
Tree-same-pre-rewrite: false
An array-spec like `(:,:)` (with one or more colons) is either a
deferred-shape-spec-list or an assumed-shape-spec-list and they
can only be distinguished by context that the parser doesn't have.
We were parsing these as assumed-shape-spec-list but they are easier
to deal with if we parse them as deferred-shape-spec-list because
anything that is the latter is also one of the former.
Original-commit: flang-compiler/f18@78c3f3b96f
Reviewed-on: https://github.com/flang-compiler/f18/pull/630
Tree-same-pre-rewrite: false
- make `TypaParamAttr` a `ParamValue` argument. Modify
`GetParamValue` to also take this as an argument.
- remove `GetLenParamValue` that is now useless and
modify constructor/`GetParamValue` calls
- get it the `TypeParamAttr` right from the begining
when visiting `parser::DerivedTypeSpec` in resolve-names.cc.
It was set to `Kind` by default and it was hard to ensure the
attribute would not be checked until set properly.
Original-commit: flang-compiler/f18@bcc300e714
Reviewed-on: https://github.com/flang-compiler/f18/pull/615
While testing fix for issue 581 it appeared that 'ParamValue`
implicit len parameters had incorrect attribute kind.
This commit:
+ Set correct attribute when creating `ParamValue` for implicit
type parameter.
+ Also set the correct attribute foe charachter lenght `ParamValue`
though it is currently not used anywhere.
+ Change some std::int64_t to common::ConstantSubscript on the way.
Original-commit: flang-compiler/f18@57a344b256
Reviewed-on: https://github.com/flang-compiler/f18/pull/615
Tree-same-pre-rewrite: false
`HaveCompatibleKindParameters` was not considering the kind
parameters of the parent types leading to false answers.
This change fixes this by directly looking into the map of `ParamValue`
of the `DeclTypeSpec` instead of going through the symbols of the derived
type scope. This map contains all the parent and implicit type parameters.
Original-commit: flang-compiler/f18@cd5b976fc9
Reviewed-on: https://github.com/flang-compiler/f18/pull/615
Tree-same-pre-rewrite: false
* [OpenMP] parse tree changes for standalone directives
1. Put all standalone directives except FLUSH, CANCEL, and CANCELLATION POINT
into one `OpenMPSimpleStandaloneConstruct` (for no-clause directive,
validity checks will be deferred to Semantics). A top-level class will
include all the standalone directive nodes. This simplies the logic a lot.
2. All the standalone directives now have their own source provenance for
directive name itself.
3. Change check-omp-structure.* to avoid assertions
4. Add basic tests for standalone directives, more will be added during
the clause validity checks in Semantics
* Resolve !$OMP ORDERED ambiguity by attempting block construct first - Peter
Original-commit: flang-compiler/f18@a77aa7ed84
Reviewed-on: https://github.com/flang-compiler/f18/pull/627
- dosemantics05.f90: Added tests for ASSOCIATE, BLOCK and SELECT TYPE statements and changed the error messages.
- check-do.cc: Changed things so that FindScope() is only called once when DoConcurrentVariableEnforce is instantiated. I changed the error message. I changed the type and name of CS to be an std::set and be called SymbolContainer.
- resolve-names.cc: I changed the Pre() function for parser::Statement to add the source range of a statement to both the current scope and all of its parents. This fixed a problem with finding the current scope based on the source position.
Original-commit: flang-compiler/f18@085b2c18f3
Reviewed-on: https://github.com/flang-compiler/f18/pull/612
The constraint states that "If the locality-spec DEFAULT ( NONE ) appears in a DO CONCURRENT statement; a variable that is a local or construct entity of a scope containing the DO CONCURRENT construct; and that appears in the block of the construct; shall have its locality explicitly specified by that statement."
Here's a summary of the changes:
- In check-do.cc: Implemented the function
CheckDefaultNoneImpliesExplicitLocality() to do the checking. This involved
adding the class DoConcurrentVariableEnforce to walk the DO loop's block
looking for variable names. I also cleaned up the code a little in
CheckDoExpression() and EnforceConcurrentLoopControl().
- Added the test dosemantics05.f90
Original-commit: flang-compiler/f18@2369aa805e
Reviewed-on: https://github.com/flang-compiler/f18/pull/612
Tree-same-pre-rewrite: false
1. Changes are to save provenance for directive names
2. check-omp-structure.* is updated to avoid assertion errors
3. Tests added now are only for the basic usages for the declarative directives,
more complete examples will be added once we start implementing the semantics
checks for declarative directives
Original-commit: flang-compiler/f18@433e274f68
Reviewed-on: https://github.com/flang-compiler/f18/pull/620
* [OpenMP] Add Sections and Single Construct check
Parse tree for OmpEndSingle needs to be modified to save the provenance
of END SINGLE directive and check its own clauses
* Update on reviews
1. PushContext is created to push new context with source provenance
2. Tweak the logic for SECTION nesting, treak Orphaned or wrong nesting
as the same error type
3. Make sure the check for NOWAIT clause only applies to the ones that
are not handled by parser.
Note that the case for DO or DO_SIMD will take effect after the
loop association work (parse tree change) is done. But I still list
them there for completeness.
4. Happen to find that NOWAIT is not accepted by PARALLEL SECTIONS,
fixed it in the parser.
Original-commit: flang-compiler/f18@236cf1efea
Reviewed-on: https://github.com/flang-compiler/f18/pull/585
When we use-associate a generic interface name and then add more
procedures to the generic, we create a new symbol for the merged
generic. That symbol has to include a pointer to the derived type
or procedure with the same name, just as the original generic did.
To achieve that, change `AddSpecificProcsFrom` to also copy those
fields from the original symbol and change its name to `CopyFrom`
to reflect its new purpose. Also, change it to take `GenericDetails`
instead of `Symbol` as its argument so we can't call it on the wrong
kind of symbol.
Original-commit: flang-compiler/f18@1e22970e43
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
When a generic interface had no specific procedures, we were writing
it the `.mod` file as `generic::g=>`, which is not valid Fortran.
Change to writing generics as interface blocks rather than generic
statements so that this case is handled. Include an access stmt if it
was declared private.
Also fix a bug in `test_errors.sh` where the expected/actual error
messages weren't sorted by line number correctly.
Original-commit: flang-compiler/f18@1c32a289b5
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
Tree-same-pre-rewrite: false
Create symbols for generics in a pre-pass over the specification part so
it is easier to handle cases when they have the same name as a derived
type or subprogram. This is done by calling `PreSpecificationConstruct`
on each `SpecificationConstruct` of a specification part before we
continue walking it. The generics symbols are created there and the same
mechanism will be used to handle forward references to derived types.
Report an error when the same name is used for a generic interface,
derived type, and subprogram.
Improve the error message issued when a procedure and generic interface
have the same name but the procedure is not a specific of the generic.
Change `SayAlreadyDeclared` to report the error on the second occurence
of the name when possible. This can arise for declarations the are
processed out of order, e.g. contained subprograms and generic interfaces.
Avoid multiple "already declared" errors for the case when a contained
subprogram has the same name as a declared entity. We first create the
symbol with SubprogramNameDetails, then replace it with the entity (and
report the error), then replace it with the real subprogram (and get the
error again). By setting and checking the error flag we avoid the second
error.
Original-commit: flang-compiler/f18@48fc076783
Reviewed-on: https://github.com/flang-compiler/f18/pull/614
Tree-same-pre-rewrite: false
It is common to get a pointer, check it is not null, and dereference it.
Sometimes that requires a named temporary just to be able to do the check.
The macro `DEREF(p)` provides this capability: it asserts that `p` is not null
and returns `*p`. This is analagous to `.value()` on an `std::optional`.
We might want to add a way to disable `CHECK` and the check in `DEREF` together.
This change also includes some examples of making use of `DEREF`.
Original-commit: flang-compiler/f18@d7aa90e55a
Reviewed-on: https://github.com/flang-compiler/f18/pull/608
- resolve-names.cc: I reworded the message when a name appears in a
locality-spec when a name is used that cannot appear in a variable
definition context.
- tools.cc: I removed the unused functions ```IsValueDummy()``` and
```IsModifiable()```. I made the function ```GetAssociatedVariable()```
static. I cleaned up the code in ```GetAssociationRoot()```. I cleaned up
the code in ```IsOrContainsEventOrLockComponent()```. I added a TODO to
```WhyNotModifiable()``` and made some other improvements to it.
- tools.h: Removed some deleted and unnecessary functions.
- I fixed up a couple of tests related to the changes in error messages.
Original-commit: flang-compiler/f18@47da8ff9c8
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
- expression.cc - fixed an error message. This required changing the tests
structconst0[3,4].f90
- tools.[h,cc] - Added a new function called ```WhyNotModifiable()``` to see
if a name can be modified. This function returns a string that describes why
the name cannot be modified. I changed the existing function
```IsModifiable()``` to call ```WhyNotModifiable()```. I fixed and
restructured the code for ```GetAssociationRoot()```. This involved creating
the mutually recursive function ```GetAssociatedVariable()```. I added a
check to see if a name is an INTENT(IN) dummy argument to the function
```IsVariableName()```.
- resolve-names.cc - Wrote the function ```SayWithReason()``` that allows an
arbitrary message to be added to an existing message. I changed the code in
```PassesLocalityChecks()``` to call the new function ```WhyNotModifiable()```
to get the specifics of why a variable name cannot be used in a variable
modification context and then call the new function ```SayWithReason()``` to
report the error. I also cleaned up the code as per Jean's suggestion.
Original-commit: flang-compiler/f18@8a2f4bdfd2
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
Tree-same-pre-rewrite: false
Specifically, these changes enforce the last sentence of the constraint, which
prohibits names that cannot appear in a variable definition context from
appearing in a locality-spec. Here are the details.
- Created the function "IsModifiableName" to return "true" when its parameter
is the name of a variable that can appear in a variable definition context.
- Created the function "GetAssociationRoot" to follow construct associations
to potentially get to an underlying variable. This function is similar to
the existing "GetUltimate" function that follows use associations and host
associations. One difference is that "GetAssociationRoot" requires access
to the types "MaybeExpr" and "SomeExpr", which makes is inappropriate to put
into symbol.cc, which is where "GetUltimate" lives. Perhaps we should move
"GetUltimate" to tools.[h,cc].
- Generalized the functions "IsPureFunction" to "IsPureProcedure" since either
a pure function or subroutine can provide a context for variables that
cannot be modified. Changed "FindPureFunctionContaining" to
"FindPureProcedueContaining" to go along with this.
- Added the function "IsExternalInPureContext" to detect the case where a
nominally pure procedure potentially modifies a variable.
- Created the function "IsOrContainsEventOrLockComponent" to detect variables
that either are of EVENT_TYPE or LOCK_TYPE or contain components of these
types. Such variables cannot appear in variable definition contexts.
- Added the test resolve56.f90 to test most of these conditions. Note that I
only tested the new code from the perspective of locality-specs.
Original-commit: flang-compiler/f18@c9d2507b74
Reviewed-on: https://github.com/flang-compiler/f18/pull/596
Tree-same-pre-rewrite: false
When the same generic is use-associated from two different modules,
they must be merged together into a symbol with GenericDetails.
After that merger, if there is a use association of the same name
with a non-generic we have to report an error. So save the UseDetails
from the original USE in GenericDetails so we can create the
appropriate UseErrorDetails.
Fixesflang-compiler/f18#586.
Original-commit: flang-compiler/f18@5067345f70
Reviewed-on: https://github.com/flang-compiler/f18/pull/591
Fix issue 598 and related issues.
Transform resolve-names.cc ConstructVisitor association_ member into a
stack so that different association construct (select-type, select-rank,
change-team, associate) imbrication/succession do not interfere with each
other leading to wrong erronous symbol resolution.
Original-commit: flang-compiler/f18@5781f29ed6
Reviewed-on: https://github.com/flang-compiler/f18/pull/600
Tree-same-pre-rewrite: false
Type-bound generic statements can have binding names that refer to
bindings that occur later in the type. So save a map of generic to
binding names and process them when we get to the end of the
type-bound procedure part. This is similar to how specific procedures
of generic identifiers are handled.
Also detect duplicate binding names for a type-bound generic.
Fixes issue flang-compiler/f18#572.
Original-commit: flang-compiler/f18@d58bb77cfa
Reviewed-on: https://github.com/flang-compiler/f18/pull/577
* The warning was already here, this commit only refactors things so that
it can be controled with -Mstandard.
* Also makes the warning point to the do-stmt and adds a note to the warning
pointing to the statements where it ends.
Original-commit: flang-compiler/f18@11e1eb6edd
Reviewed-on: https://github.com/flang-compiler/f18/pull/552
Tree-same-pre-rewrite: false
- Only allow out-of-scope label target for label-do-stmt
when the label is on an end-stmt of a scope directly nested
into the one of the label-do-stmt.
- Also transform label-do-stmt into non-label-do constructs
so that later phases do not have to handle label-do-stmt.
Original-commit: flang-compiler/f18@91cff2f296
Reviewed-on: https://github.com/flang-compiler/f18/pull/552
Tree-same-pre-rewrite: false
Change test scripts so that cmake passes in the path to the `f18`
that it just built. They no longer have to use relative paths.
Simplify argument passing in test scripts by sharing it in `common.sh`.
Move `if_arith01.f90`, `if_construct01.f90`, `if_stmt01.f90` to `ERROR_TESTS`.
As it was, nothing was being tested on them.
For `test_error.sh`, find the include directory relative to `f18` and
pass that in with a `-I` option. Eliminate the temporary definitions of
`iso_fortran_env`, `iso_c_binding`, `ieee_exceptions` in the tests
because the "real" ones are now available.
The tests that are run with `test_any.sh` could probably have similar
changes, but they are not part of this commit.
Original-commit: flang-compiler/f18@b62fe489be
Reviewed-on: https://github.com/flang-compiler/f18/pull/568
Generic operators and assignment have different rules than generic
names for their procedures being distinguishable.
Implement those rules in `DistinguishableOpOrAssign`. The rules are
considerably simpler: they must have the name number of dummy arguments
and at least one pair in the same position must be distinguishable.
Fixes issue flang-compiler/f18#563.
Original-commit: flang-compiler/f18@276bb08206
Reviewed-on: https://github.com/flang-compiler/f18/pull/576
Complete the checks for distinguishable specifics procedure in a generic
by considering any passed-object dummy arguments.
C1514 rule 3 is implemented and the checks for the other rules are
extended to consider the PASS attribute, including the concept of the
"effective" position of an argument in an argument list, computed by
ignoring passed-object arguments.
Add `pass` to `characteristics::DummyArgument` to mark each
passed-object dummy argument.
Change symbols to store the index of the passed-object dummy argument
rather than its symbol.
Check that specifics of a type-bound generic are distinguishable only
after all of the procedure bindings have been processed. They don't have
to be before the generic.
Original-commit: flang-compiler/f18@2751490f95
Reviewed-on: https://github.com/flang-compiler/f18/pull/567
* Examples of Composite and Combined constructs
2.8.3 Loop SIMD Construct
2.11.1 Parallel Loop Construct
2.11.3 Parallel Loop SIMD Construct
Not in the implementation:
2.8.3 DO SIMD: A list item may appear in a linear or firstprivate clause but not both
Original-commit: flang-compiler/f18@75d9c1a081
Reviewed-on: https://github.com/flang-compiler/f18/pull/558
In `OrderParameterNames` and `OrderParameterDeclarations` it was
always true that `this == &type.get<DerivedTypeDetails>()` which
meant that `this` was redundant.
So convert them to non-member functions in `tools.h` that get the
details from the symbol passed in. This makes life simpler for the
callers.
Original-commit: flang-compiler/f18@81710d4e6e
Reviewed-on: https://github.com/flang-compiler/f18/pull/559
Move these functions from scope.cc, symbol.cc, type.cc into tools.cc:
Scope::FindOrInstantiateDerivedType
Scope::InstantiateDerivedType
Scope::InstantiateIntrinsicType
Symbol::Instantiate
DerivedTypeSpec::ProcessParameterExpressions
DerivedTypeSpec::Instantiate
This eliminates some dependencies in these files on SemanticsContext,
FoldingContext, etc.
It also allows three of the functions to be private to tools.cc
because they are only called from the others.
Original-commit: flang-compiler/f18@48c6efbf95
Reviewed-on: https://github.com/flang-compiler/f18/pull/559
Tree-same-pre-rewrite: false
- Changed the name a a function to FindOrDeclareEnclosingEntity
- Changed that function to return a reference rather than a pointer
- Polished the setting of the IMPLICIT flag on a declared entity in a
locality-spec
- Changed a test to remove an unreported error
Original-commit: flang-compiler/f18@0c1a00d7c2
Reviewed-on: https://github.com/flang-compiler/f18/pull/551
Tree-same-pre-rewrite: false
Prior to this change, the compiler issued an error message when a name in a
SHARED locality-spec had not been declared explicitly in an enclosing scope.
Presumably, this was done to enforce constraint C1124. This constraint states
that "A variable-name in a locality-spec shall be the name of a variable in the
innermost executable construct or scoping unit that includes the DO CONCURRENT
statement". For LOCAL and LOCAL_INIT locality-spec's, we were automatically
creating a local variable in the situation where one had not been explicitly
declared rather than issuing an error message.
The only compiler I could find that implements the SHARED locality-spec was the
PGI compiler, which automatically creates a variable and does not emit an error
message. Also, @vdonaldson said that he had consulted with a member of the
Fortran standards committee who said that the correct thing was to create a
variable if necessary.
This change has the compiler creating a variable in the enclosing scope of a DO
CONCURRENT statement if necessary. I also changed a test to adapt to the new
behavior. I also consolidated the semantic checking for the constraints
associated with all of the locality-spec's.
Original-commit: flang-compiler/f18@d9253a76fc
Reviewed-on: https://github.com/flang-compiler/f18/pull/551
Tree-same-pre-rewrite: false
Straightforward implementation but not including:
* list-item on aligned clause
* nesting check with the ordered construct (parse tree changes needed!)
* list-item attributes check on aligned clause
Original-commit: flang-compiler/f18@cf04d8ad26
Reviewed-on: https://github.com/flang-compiler/f18/pull/554
These changes implement most of the requirements for C1128, which says: "A
variable-name that appears in a LOCAL or LOCAL_INIT locality-spec shall not
have the ALLOCATABLE; INTENT (IN); or OPTIONAL attribute; shall not be of
finalizable type; shall not be a nonpointer polymorphic dummy argument; and
shall not be a coarray or an assumed-size array. A variable-name that is not
permitted to appear in a variable definition context shall not appear in a
LOCAL or LOCAL_INIT locality-spec."
The changes do not implement the checking required to determine whether a
variable can appear in a "variable definition context".
Here's a summary of the changes:
- I created the function 'PassesLocalityChecks()' to enforce C1128 along with
C1124, C1125, and C1126.
- I cleaned up the code to check if a type or symbol is a coarray.
- I added functions to tools.[h,cc] to test if a symbol is OPTIONAL, INTENT
IN, finalizable, a coarray, or an assumed size array. Should these be
member functions of the type "Symbol"?
- Since I changed one of the locality related error messages, I needed to
change the test resolve35.f90.
- I added the test resolve55.f90 to test all of the checks implemented in this
update.
Original-commit: flang-compiler/f18@4ca5d090b9
Reviewed-on: https://github.com/flang-compiler/f18/pull/542
Tree-same-pre-rewrite: false
Most restrictions in 2.7.1 Loop construct, nesting checks are still on TODO list.
seenClauses (EnumSet) is dropped. A multimap clauseInfo is added to save the encountering clause and its parser tree node pointer (parser::OmpClause) and to do the checks after walking through all the clauses.
Original-commit: flang-compiler/f18@f797357682
Reviewed-on: https://github.com/flang-compiler/f18/pull/536
