[flang-commits] [flang] [flang] Don't crash on bad inherited implied DO type (PR #91073)
Peter Klausler via flang-commits
flang-commits at lists.llvm.org
Sat May 4 10:20:39 PDT 2024
https://github.com/klausler created https://github.com/llvm/llvm-project/pull/91073
Fortran has an ambiguously defined rule about the typing of index variables of implied DO loops in DATA statements and array constructors that omit an explicit type specification. Such indices have the type that they would have "if they were variables" in the innermost enclosing scope. Although this could, and perhaps should, be read to mean that implicit typing rules active in that innermost enclosing scope should be applied, every other Fortran compiler interprets that language to mean that if there is a type declaration for that name that is visible from the enclosing scope, it is applied, and it is an error if that type is not integer.
Fixes https://github.com/llvm/llvm-project/issues/91053.
>From 97fc051a52b1027e48dcf7057de5513badd0b05d Mon Sep 17 00:00:00 2001
From: Peter Klausler <pklausler at nvidia.com>
Date: Sat, 4 May 2024 10:03:49 -0700
Subject: [PATCH] [flang] Don't crash on bad inherited implied DO type
Fortran has an ambiguously defined rule about the typing of index variables
of implied DO loops in DATA statements and array constructors that
omit an explicit type specification. Such indices have the type that
they would have "if they were variables" in the innermost enclosing scope.
Although this could, and perhaps should, be read to mean that implicit
typing rules active in that innermost enclosing scope should be applied,
every other Fortran compiler interprets that language to mean that if
there is a type declaration for that name that is visible from the
enclosing scope, it is applied, and it is an error if that type
is not integer.
Fixes https://github.com/llvm/llvm-project/issues/91053.
---
flang/docs/Extensions.md | 23 ++++++++++++++-----
flang/lib/Evaluate/formatting.cpp | 4 ++--
flang/lib/Semantics/expression.cpp | 9 +++++---
flang/lib/Semantics/resolve-names.cpp | 5 ++--
flang/test/Semantics/array-constr-index01.f90 | 8 +++++++
5 files changed, 35 insertions(+), 14 deletions(-)
create mode 100644 flang/test/Semantics/array-constr-index01.f90
diff --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 9030207d9bda5d..0a5bcdc6ff3f4f 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -107,12 +107,6 @@ end
These definitions yield fairly poor results due to floating-point
cancellation, and every Fortran compiler (including this one)
uses better algorithms.
-* When an index variable of a `FORALL` or `DO CONCURRENT` is present
- in the enclosing scope, and the construct does not have an explicit
- type specification for its index variables, some weird restrictions
- in F'2023 subclause 19.4 paragraphs 6 & 8 should apply. Since this
- compiler properly scopes these names, violations of these restrictions
- elicit only portability warnings by default.
* The rules for pairwise distinguishing the specific procedures of a
generic interface are inadequate, as admitted in note C.11.6 of F'2023.
Generic interfaces whose specific procedures can be easily proven by
@@ -728,6 +722,23 @@ end
array and structure constructors not to be finalized, so it also makes sense
not to finalize their allocatable components when releasing their storage).
+* F'2023 19.4 paragraph 5: "If integer-type-spec appears in data-implied-do or
+ ac-implied-do-control it has the specified type and type parameters; otherwise
+ it has the type and type parameters that it would have if it were the name of
+ a variable in the innermost executable construct or scoping unit that includes
+ the DATA statement or array constructor, and this type shall be integer type."
+ Reading "would have if it were" as being the subjunctive, this would mean that
+ an untyped implied DO index variable should be implicitly typed according to
+ the rules active in the enclosing scope. But all other Fortran compilers interpret
+ the "would have if it were" as meaning "has if it is" -- i.e., if the name
+ is visible in the enclosing scope, the type of that name is used as the
+ type of the implied DO index. So this is an error, not a simple application
+ of the default implicit typing rule:
+```
+character j
+print *, [(j,j=1,10)]
+```
+
## De Facto Standard Features
* `EXTENDS_TYPE_OF()` returns `.TRUE.` if both of its arguments have the
diff --git a/flang/lib/Evaluate/formatting.cpp b/flang/lib/Evaluate/formatting.cpp
index 5f822bbcbb04f4..20193b006bf2fd 100644
--- a/flang/lib/Evaluate/formatting.cpp
+++ b/flang/lib/Evaluate/formatting.cpp
@@ -539,10 +539,10 @@ std::string DynamicType::AsFortran() const {
result += length->AsFortran();
}
return result + ')';
- } else if (IsUnlimitedPolymorphic()) {
- return "CLASS(*)";
} else if (IsAssumedType()) {
return "TYPE(*)";
+ } else if (IsUnlimitedPolymorphic()) {
+ return "CLASS(*)";
} else if (IsTypelessIntrinsicArgument()) {
return "(typeless intrinsic function argument)";
} else {
diff --git a/flang/lib/Semantics/expression.cpp b/flang/lib/Semantics/expression.cpp
index f677973ca2753b..cb0174043ca1a7 100644
--- a/flang/lib/Semantics/expression.cpp
+++ b/flang/lib/Semantics/expression.cpp
@@ -1805,10 +1805,13 @@ void ArrayConstructorContext::Add(const parser::AcImpliedDo &impliedDo) {
const auto &bounds{std::get<parser::AcImpliedDoControl::Bounds>(control.t)};
exprAnalyzer_.Analyze(bounds.name);
parser::CharBlock name{bounds.name.thing.thing.source};
- const Symbol *symbol{bounds.name.thing.thing.symbol};
int kind{ImpliedDoIntType::kind};
- if (const auto dynamicType{DynamicType::From(symbol)}) {
- kind = dynamicType->kind();
+ if (const Symbol * symbol{bounds.name.thing.thing.symbol}) {
+ if (auto dynamicType{DynamicType::From(symbol)}) {
+ if (dynamicType->category() == TypeCategory::Integer) {
+ kind = dynamicType->kind();
+ }
+ }
}
std::optional<Expr<ImpliedDoIntType>> lower{
GetSpecificIntExpr<ImpliedDoIntType::kind>(bounds.lower)};
diff --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index 61394b0f41de75..deccd4ea2ced41 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -6556,6 +6556,7 @@ Symbol *DeclarationVisitor::DeclareStatementEntity(
return nullptr;
}
name.symbol = nullptr;
+ // F'2023 19.4 p5 ambiguous rule about outer declarations
declTypeSpec = prev->GetType();
}
Symbol &symbol{DeclareEntity<ObjectEntityDetails>(name, {})};
@@ -6574,9 +6575,7 @@ Symbol *DeclarationVisitor::DeclareStatementEntity(
} else {
ApplyImplicitRules(symbol);
}
- Symbol *result{Resolve(name, &symbol)};
- AnalyzeExpr(context(), doVar); // enforce INTEGER type
- return result;
+ return Resolve(name, &symbol);
}
// Set the type of an entity or report an error.
diff --git a/flang/test/Semantics/array-constr-index01.f90 b/flang/test/Semantics/array-constr-index01.f90
new file mode 100644
index 00000000000000..560b6be8313958
--- /dev/null
+++ b/flang/test/Semantics/array-constr-index01.f90
@@ -0,0 +1,8 @@
+!RUN: %python %S/test_errors.py %s %flang_fc1
+subroutine s(i)
+ type(*) :: i
+ !ERROR: TYPE(*) dummy argument may only be used as an actual argument
+ !ERROR: Assumed-type entity 'i' must be a dummy argument
+ !ERROR: Must have INTEGER type, but is TYPE(*)
+ print *, [(i, i = 1,1)]
+end
More information about the flang-commits
mailing list