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
We weren't handling MainProgram with no ProgramStmt correctly in
ProgramTree. When building it we were dereferencing an empty optional.
And in ResolveSpecificationParts we were dereferencing a null pointer.
Original-commit: flang-compiler/f18@1bda90d005
Reviewed-on: https://github.com/flang-compiler/f18/pull/827
Using debug build of f18, `omp-resolve01.f90` sometimes crashed in
`OmpVisitor::ResolveOmpObject`. This was because when the designator was
analyzed it could be rewritten from an `ArrayElement` to a `Substring`.
That made the reference to the `Name` inside the designator no longer
valid so the crash happened when it was referenced later. The fix is to
return when the substring is detected so the name is not referenced.
Also, the name returned from `ResolveDesignator` can but null so it must
be checked.
The crash in `RewriteOpenMPLoopConstruct` happened intermittently on
`omp-loop-association.f90`. It happened when the DO construct was the
last element of the block. In that case `block.erase()` returns an
iterator pointing to `block.end()` which must not be dereferenced.
Original-commit: flang-compiler/f18@3299972d04
Reviewed-on: https://github.com/flang-compiler/f18/pull/824
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
Convert some CharBlock references to values
Replace more pointers with reference wrappers
Restore object references that were converted to value semantics in an earlier commit
Use Reference<> in Scope
Fix new component iterator
Document pitfall that bit me
final tweaks before rebasing and merging
Rebasing
Original-commit: flang-compiler/f18@87874af934
Reviewed-on: https://github.com/flang-compiler/f18/pull/788
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
PR#753 changed the `OmpObject` to be:
```
struct OmpObject {
UNION_CLASS_BOILERPLATE(OmpObject);
std::variant<Designator, /*common block*/ Name> u;
};
```
This commit adjust the logic flow for `ResolveOmpObject` based on
the above parse tree change.
For an `OmpObject`,
```
if (Designator) {
if (DataRef.Name) {
// Resolve Names
} else {
// ResolveDesignator
// AnalyzeExpr
if (Designator.Substring) {
// Error
}
// other checks like StructureComponent, ArrayElement, etc.
}
} else if (Name) {
// Resolve COMMON block
}
```
Original-commit: flang-compiler/f18@e5c1b92c15
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
There was already code in check-do.cc to test for the presence of a
variety of different image control statements, but several of them did
not have associated tests. This change adds tests for most of them.
Also, I removed the check for the END PROGRAM statement, since its
presence causes a syntax error which prevents the semantic check from
ever being reached.
Original-commit: flang-compiler/f18@9cc6f5bd40
Reviewed-on: https://github.com/flang-compiler/f18/pull/764
Fix problems with writing a mod file while another compilation is
reading or writing. Write to a temp and then rename it:
- compute the new contents of the .mod file
- if it already exists, check if it is already correct
- if not, write new contents to a temp file
- rename the temp to the final destination
`mkstemps()` seems to be the best way to create the temp file.
It returns a file descriptor, so change the rest of the mod file
writing to use POSIX open/read/write/close. This seems to set
errno more reliably too.
There is some extra work around creating the temp to make it have
the same directory and suffix as the final file (so that if one gets
left behind by a crash, "rm *.mod" still cleans it up).
`mkstemps()` creates file with 0600 permissions so try to change it
to what it would have been if we just wrote the file.
Change module file reading to only read the file once; we used to
read it to verify the checksum and then again to parse it.
Instead, change `Parsing` so that we can get the file contents
after `Prescan()` and use that to verify the checksum. Also, it has
a mechanism for searching directories for files, so make use of that
instead of duplicating that functionality in `ModFileReader`.
This requires some changes to how errors are returned so they can
be reported in the right place.
Original-commit: flang-compiler/f18@d0d54971a5
Reviewed-on: https://github.com/flang-compiler/f18/pull/758
Tree-same-pre-rewrite: false
implement an enum class to indicate whether the statement being checked
is a CYCLE or EXIT statement. This change rippled through a few
interfaces, resulting in cleaner, more readable code. Thanks for the
tip, Tim!
Original-commit: flang-compiler/f18@e167c3d39f
Reviewed-on: https://github.com/flang-compiler/f18/pull/756
Tree-same-pre-rewrite: false
These constraints state that CYCLE and EXIT statements should not leave DO
CONCURRENT, CRITICAL, or CHANGE TEAM constructs.
I added checking code to check-do.cc and removed some superseded code from
check-do.cc and semantics.cc. The new code uses the construct stack
implemented in my previous pull request.
I also added a new test -- dosemantics11.f90 and modified the tests
dosemantics10.f90, doconcurrent05.f90, and doconcurrent06.f90 to adapt to
the new error messages. I converted these latter two tests to use
test_error.sh since they only reported errors.
Original-commit: flang-compiler/f18@b0bea7da64
Reviewed-on: https://github.com/flang-compiler/f18/pull/756
Tree-same-pre-rewrite: false
Fixflang-compiler/f18#724.
Allow all type kinds for arguments in restricted specific conversion
intrinisc (no warning, this is ubiquitous).
Allow MAX/MIN restricted intrinsic (AMAX0...) to be replaced by the
related generic foolowed by a type conversion to the expected result
type of the specific. Emit a warning because xlf and ifort are doing so
but pgfortran is converting the arguments instead.
Original-commit: flang-compiler/f18@c07adb94ed
Reviewed-on: https://github.com/flang-compiler/f18/pull/749
Tree-same-pre-rewrite: false
10.1.6.2 says:
> The operators <, <=, >, >=, ==, and /= always have the same interpretations
> as the operators .LT., .LE., .GT., .GE., .EQ., and .NE., respectively.
That means we have to treat `operator(<)` like `operator(.lt.)`,
for example. `<>` is a third alias for `.NE.`.
We can't just choose always to use one form (e.g. replacing `operator(.lt.)`
with `operator(<)`). This is because all symbols names are `CharBlock`s
referring to the cooked character stream so that they have proper source
provenance. Also, if a user prefers one style and uses it consistently,
that's the form they should see in messages.
So the fix is to use whatever form is found in the source, but also to
look up symbols by the other names when necessary. To assist this, add
`GenericSpecInfo::GetAllNames()` to return all of the names of a generic
spec. Each place a generic spec can occur we have to use these to look
for the symbol.
Also reorganize the `AddUse()` overloads to work with this change.
Fixesflang-compiler/f18#746.
Original-commit: flang-compiler/f18@7f06f175d5
Reviewed-on: https://github.com/flang-compiler/f18/pull/752
Instead of using an `ENUM_CLASS Kind` to distinguish a `Designator`
or common-block name, change it to `std::variant`. If the `Name`
is available, then it is common-block name.
Original-commit: flang-compiler/f18@abf5db6171
When a derived type is use-associated with a rename, like
`use m, only: t2 => t1`
we need to record in the `DerivedTypeSpec` both the local-name in this
scope and the symbol for the derived type.
In most cases we need to work the the type symbol and its
`DerivedTypeDetails`, but when writing the type to the module file
we need the local-name. The name of the type symbol may be hidden
or not use-associated.
When analyzing a `parser::Name` we don't want to follow use-associations
because we could end up with the wrong name in a `DataRef` (i.e. the
use-name rather than the local-name). But that means that
`GetNamedConstantValue()` does have to follow them or named constants
won't always be folded.
Fixesflang-compiler/f18#729.
Original-commit: flang-compiler/f18@50d8921c69
Reviewed-on: https://github.com/flang-compiler/f18/pull/740
When a module contains a use-association with rename, we have to be
careful to use the correct name (i.e. the local-name, not the use-name)
when writing out its `.mod` file.
When analyzing a `Name` in an expression, follow the use-association
for details, attributes, and constant values; but if we need to make a
`Designator` or `ProcedureDesignator`, use the local name.
Original-commit: flang-compiler/f18@8f07b803e1
Reviewed-on: https://github.com/flang-compiler/f18/pull/740
Tree-same-pre-rewrite: false
Eliminate two of the three overloadings of `Scope::MakeDerivedType()`.
Keep the one that has `Category` first because that's the order the
constructor of `DeclTypeSpec` uses.
In `mod-file.cc`, eliminate some calls to `PutLower()`. Symbols and
names are already lower case so they don't need to be converted.
In `modfile03.f90`, move the expected `.mod` file comments to right
after the corresponding modules. That makes it easier to work with.
Original-commit: flang-compiler/f18@86874d9bf8
Reviewed-on: https://github.com/flang-compiler/f18/pull/740
Tree-same-pre-rewrite: false
If a generic name is use-associated from two different modules and they
both have a specific procedure or both have a derived type with the same
name, report it as an error.
Original-commit: flang-compiler/f18@42369af96d
Reviewed-on: https://github.com/flang-compiler/f18/pull/741
Tree-same-pre-rewrite: false
When we use-associate the same generic name from two different modules
they are merged together. If the same specific procedure occurs in both
generics it should only occur once in the merged one.
Similarly, it's not an error if they both have a derived type or
specific procedure named the same as the generic, as long as they are
the same symbol.
Fixesflang-compiler/f18#733.
Original-commit: flang-compiler/f18@d37db07691
Reviewed-on: https://github.com/flang-compiler/f18/pull/741
Tree-same-pre-rewrite: false
- -fget-definitions finds the definition of the symbol under specified source
position.
- -fget-all-symbols finds definition locations of all symbols in a document. For
symbols found in other modules, shows which module the symbol came from.
- Tests.
- New structure SourcePosition with file, line, column information.
Original-commit: flang-compiler/f18@e0099b0900
Reviewed-on: https://github.com/flang-compiler/f18/pull/698
Tree-same-pre-rewrite: false
I changed the interface of ```PushConstruct()``` to take an rvalue reference as its only parameter and made the construction of the ```ConstructNode```s explicit in all of the ```Pre()``` functions for the various construct types.
Original-commit: flang-compiler/f18@f8be813874
Reviewed-on: https://github.com/flang-compiler/f18/pull/686
Tree-same-pre-rewrite: false
The most significant change is that I replaced the stack of
ExecutableConstruct's with a stack composed of ConstructNode's, each of which
is a variant of the constructs that made up the type ExecutableConstruct. This
change allows the nodes of the stack to be extended to include the types needed
for OMP semantic checking.
I also extended the existing test to include some correct DO loops with CYCLE
and EXIT statements to test the code more completely.
Original-commit: flang-compiler/f18@d26f34e3a4
Reviewed-on: https://github.com/flang-compiler/f18/pull/686
Tree-same-pre-rewrite: false
I added a stack of ExecutableConstruct's to SemanticsContext along with
functions to push and pop constructs. I added code to the SemanticsVisitor
to use these new functions. I also added functions Pre and Post functions
for UnlabeledStatement's so that we could isolate the source positions for
statements embedded in "if" statements to improve error messages.
I also added code to check-do.[h,cc] to use this new infrastructure to check
for CYCLE and EXIT statements that are not contained within DO constructs
along with a test.
Original-commit: flang-compiler/f18@b8370bdeb8
Reviewed-on: https://github.com/flang-compiler/f18/pull/686
Tree-same-pre-rewrite: false
OpenMP 4.5 only accepts `defaultmap(tofrom:scalar)`. The original implementation
only parses the entire `tofrom:scalar` string and does nothing else. This commit
makes it treat `tofrom` (`ImplicitBehavior`) and `scalar` (`VariableCategory`)
separately, which is clear and extendable for OpenMP 5.0 Spec.
Original-commit: flang-compiler/f18@12074dcd2c
Resolve the pointer and pointee names in a `BasedPointerStmt` and
enforce some of the constraints on them. There are still some
constraints to be implemented, mainly about what kind of attributes
the pointers and pointees can have.
The rules for these are a little vague. I mostly followed
- Cray Fortran Reference Manual section 9.3.2
- https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html
- VSI Fortran for OpenVMS Language Reference Manual section B.11
Note that the first two use the term "Cray pointer" but the last does
not. That is confusing because you have to know from context whether
it is referring to Cray pointers or Fortran pointers, so I used
"Cray pointer" and "Cray pointee" in error messages to refer to the
two names in the pointer statement.
Original-commit: flang-compiler/f18@cabb112be2
Reviewed-on: https://github.com/flang-compiler/f18/pull/697
Names of subprograms declared with MODULE PROCEDURE in a submodule
were not found correctly. The fix is to separate the handling of
these from other subprograms. The subprogram being defined must have
been declared in the same module or an ancestor module/submodule.
Fixesflang-compiler/f18#709
Original-commit: flang-compiler/f18@80b635d343
Reviewed-on: https://github.com/flang-compiler/f18/pull/710
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
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
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 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
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
peter klausler