* 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
During the symbol tests, OpenMP directives (start with "!$omp")
line needs to be saved for 1.f90 and 2.f90. Also moved "OPTIONS:"
detection to common.sh as "$USER_OPTIONS"
Original-commit: flang-compiler/f18@7d4e8e8ad5
The major changes are:
1) changed the non-nullptr type to reference
2) changed ResolveOmpObject to use std::visit
3) the rest of the changes are about positions and naming
Original-commit: flang-compiler/f18@93debe59f3
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
vdonaldson