-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[flang] Better error recovery for REAL(x, [KIND=]bad) #108222
Conversation
There's two entries in the intrinsic table for REAL; the first handles the REAL(z) case of a COMPLEX argument, and the second handles the data type/kind conversion case. In the case of REAL(x,bad) with a bad or unsupported kind of REAL, neither table entry was matching. In the event of an unrecognized intrinsic function, the compiler emits the first error message that resulted, which was confusing here because it was a complaint about having too many arguments. Reversing the order of the intrinsic table entries would fix the error message, but would also have broken REAL(z) with a complex argument, since it would then be treated as REAL(z,KIND=KIND(0.)) rather than REAL(z,KIND=KIND(z)). The fix is to let the second entry "hit" with improved error recovery.
@llvm/pr-subscribers-flang-semantics Author: Peter Klausler (klausler) ChangesThere's two entries in the intrinsic table for REAL; the first handles the REAL(z) case of a COMPLEX argument, and the second handles the data type/kind conversion case. In the case of REAL(x,bad) with a bad or unsupported kind of REAL, neither table entry was matching. In the event of an unrecognized intrinsic function, the compiler emits the first error message that resulted, which was confusing here because it was a complaint about having too many arguments. Reversing the order of the intrinsic table entries would fix the error message, but would also have broken REAL(z) with a complex argument, since it would then be treated as REAL(z,KIND=KIND(0.)) rather than REAL(z,KIND=KIND(z)). The fix is to let the second entry "hit" with improved error recovery. Full diff: https://github.com/llvm/llvm-project/pull/108222.diff 2 Files Affected:
diff --git a/flang/lib/Evaluate/intrinsics.cpp b/flang/lib/Evaluate/intrinsics.cpp
index 876c2aed4ffd69..166dae93178c51 100644
--- a/flang/lib/Evaluate/intrinsics.cpp
+++ b/flang/lib/Evaluate/intrinsics.cpp
@@ -2264,7 +2264,7 @@ std::optional<SpecificCall> IntrinsicInterface::Match(
messages.Say("'kind=' argument must be a constant scalar integer "
"whose value is a supported kind for the "
"intrinsic result type"_err_en_US);
- return std::nullopt;
+ // use default kind below for error recovery
} else if (kindDummyArg->flags.test(ArgFlag::defaultsToSameKind)) {
CHECK(sameArg);
resultType = *sameArg->GetType();
@@ -2274,6 +2274,8 @@ std::optional<SpecificCall> IntrinsicInterface::Match(
DynamicType{TypeCategory::Integer, defaults.sizeIntegerKind()};
} else {
CHECK(kindDummyArg->flags.test(ArgFlag::defaultsToDefaultForResult));
+ }
+ if (!resultType) {
int kind{defaults.GetDefaultKind(*category)};
if (*category == TypeCategory::Character) { // ACHAR & CHAR
resultType = DynamicType{kind, 1};
diff --git a/flang/test/Semantics/kinds06.f90 b/flang/test/Semantics/kinds06.f90
new file mode 100644
index 00000000000000..f5b488ebc71496
--- /dev/null
+++ b/flang/test/Semantics/kinds06.f90
@@ -0,0 +1,4 @@
+!RUN: %python %S/test_errors.py %s %flang_fc1
+!ERROR: 'kind=' argument must be a constant scalar integer whose value is a supported kind for the intrinsic result type
+print *, real(1.,666)
+end
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code now has
./a.f:2:35: error: 'kind=' argument must be a constant scalar integer whose value is a supported kind for the intrinsic result type
doubleArrAlloc = RESHAPE([ (((REAL(j, 16) / REAL(i, 16)),&
^^^^^^^^^^^
./a.f:2:49: error: 'kind=' argument must be a constant scalar integer whose value is a supported kind for the intrinsic result type
doubleArrAlloc = RESHAPE([ (((REAL(j, 16) / REAL(i, 16)),&
^^^^^^^^^^^
It looks good to me. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There's two entries in the intrinsic table for REAL; the first handles the REAL(z) case of a COMPLEX argument, and the second handles the data type/kind conversion case.
In the case of REAL(x,bad) with a bad or unsupported kind of REAL, neither table entry was matching. In the event of an unrecognized intrinsic function, the compiler emits the first error message that resulted, which was confusing here because it was a complaint about having too many arguments.
Reversing the order of the intrinsic table entries would fix the error message, but would also have broken REAL(z) with a complex argument, since it would then be treated as REAL(z,KIND=KIND(0.)) rather than REAL(z,KIND=KIND(z)).
The fix is to let the second entry "hit" with improved error recovery.