Skip to content
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

Merged
merged 1 commit into from
Sep 12, 2024

Conversation

klausler
Copy link
Contributor

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.

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.
@llvmbot llvmbot added flang Flang issues not falling into any other category flang:semantics labels Sep 11, 2024
@llvmbot
Copy link
Member

llvmbot commented Sep 11, 2024

@llvm/pr-subscribers-flang-semantics

Author: Peter Klausler (klausler)

Changes

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.


Full diff: https://github.com/llvm/llvm-project/pull/108222.diff

2 Files Affected:

  • (modified) flang/lib/Evaluate/intrinsics.cpp (+3-1)
  • (added) flang/test/Semantics/kinds06.f90 (+4)
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

Copy link
Contributor

@DanielCChen DanielCChen left a 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!

Copy link
Contributor

@tblah tblah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@klausler klausler merged commit 1d3bcf9 into llvm:main Sep 12, 2024
11 checks passed
@klausler klausler deleted the dchen branch September 12, 2024 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flang:semantics flang Flang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants