[Flang] Update the fix of PR 80738 to cover generic interface inside modules

[DanielCChen]

The following test cases crashes. The problem is that the fix for PR #80738 is not quite complete. It should GetUltimate() of the interface_ before check if it is generic.

  MODULE M

    CONTAINS

    FUNCTION Int(Arg)
    INTEGER :: Int, Arg
      Int = Arg
    END FUNCTION

    FUNCTION Int8(Arg)
    INTEGER(8) :: Int8, Arg
      Int8 = 8_8
    END FUNCTION

  END MODULE

  MODULE M1
  USE M

    INTERFACE Int8
      MODULE PROCEDURE  Int
      MODULE PROCEDURE  Int8
    END INTERFACE

  END MODULE

  PROGRAM PtrAssignGen
  USE M
  USE M1
  IMPLICIT NONE

  INTERFACE Int
    MODULE PROCEDURE  Int
    MODULE PROCEDURE  Int8
  END INTERFACE

  PROCEDURE(Int8),   POINTER :: PtrInt8

  PtrInt8 => Int8
  IF ( PtrInt8(100_8) .NE. 8_8 ) ERROR STOP 12

  END

[llvmbot]

@llvm/pr-subscribers-flang-semantics

Author: Daniel Chen (DanielCChen)

Changes

The following test cases crashes. The problem is that the fix for PR #80738 is not quite complete. It should GetUltimate() of the interface_ before check if it is generic.

  MODULE M

    CONTAINS

    FUNCTION Int(Arg)
    INTEGER :: Int, Arg
      Int = Arg
    END FUNCTION

    FUNCTION Int8(Arg)
    INTEGER(8) :: Int8, Arg
      Int8 = 8_8
    END FUNCTION

  END MODULE

  MODULE M1
  USE M

    INTERFACE Int8
      MODULE PROCEDURE  Int
      MODULE PROCEDURE  Int8
    END INTERFACE

  END MODULE

  PROGRAM PtrAssignGen
  USE M
  USE M1
  IMPLICIT NONE

  INTERFACE Int
    MODULE PROCEDURE  Int
    MODULE PROCEDURE  Int8
  END INTERFACE

  PROCEDURE(Int8),   POINTER :: PtrInt8

  PtrInt8 => Int8
  IF ( PtrInt8(100_8) .NE. 8_8 ) ERROR STOP 12

  END

---

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

1 Files Affected:

• (modified) flang/lib/Semantics/resolve-names.cpp (+4-3)

diff --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index 36deab969456d0..2a42c79161468a 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -5648,9 +5648,10 @@ void DeclarationVisitor::Post(const parser::ProcDecl &x) {
   const auto &name{std::get<parser::Name>(x.t)};
   const Symbol *procInterface{nullptr};
   if (interfaceName_) {
-    procInterface = interfaceName_->symbol->has<GenericDetails>()
-        ? interfaceName_->symbol->get<GenericDetails>().specific()
-        : interfaceName_->symbol;
+    Symbol *ultimate{&interfaceName_->symbol->GetUltimate()};
+    procInterface = ultimate->has<GenericDetails>()
+        ? ultimate->get<GenericDetails>().specific()
+        : ultimate;
   }
   auto attrs{HandleSaveName(name.source, GetAttrs())};
   DerivedTypeDetails *dtDetails{nullptr};

[jeanPerier]

LGTM

[psteinfeld]

This change is causing some of our tests to fail. Here's an example. I have two files that are compiled separately. Here's the first file:

module fmod
contains
  subroutine inner(n)
    print *, n
  end subroutine
end module
module fmod1
  use fmod,proc1=>inner
  procedure(proc1),pointer :: p1
end module

I then compile this file with flang-new -c first.f90. Here's the second file:

Program test
  Use fmod1
  p1 => proc1
  Call p1(343)
End Program

I then compile this file with flang-new main.f90 first.o. I expect this to not produce errors. But I get the following output:

error: Semantic errors in main.f90
./main.f90:3:3: error: 'inner' is not a procedure
    p1 => proc1
    ^^^^^^^^^^^
./main.f90:3:3: error: In assignment to object pointer 'p1', the target 'inner' is a procedure designator
    p1 => proc1
    ^^^^^^^^^^^
./fmod1.mod:4:27: Declaration of 'p1'
  procedure(inner),pointer::p1
                            ^^
./main.f90:4:3: error: 'inner' is not a procedure
    Call p1(343)
    ^^^^^^^^^^^^
./fmod1.mod:4:11: error: 'inner' must be an abstract interface or a procedure with an explicit interface
  procedure(inner),pointer::p1
            ^^^^^

Weirdly, if I concatenate these two files, everything works.

I'm planning to revert this change. Stay tuned for that.

[DanielCChen]

@psteinfeld Thanks for the notification. I will take a another look of the fix and your test case.

[DanielCChen]

#81544 is created to handle both the original case in this PR and the regressions.