[PATCH] D99892: [flang] Improve constant folding for type parameter inquiries

Peter Klausler via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 5 13:35:42 PDT 2021


klausler added a comment.

In D99892#2669498 <https://reviews.llvm.org/D99892#2669498>, @PeteSteinfeld wrote:

> Yes, the value of the type parameter is derived from the associated object at the time that the object is instantiated.  I believe that the current code is folding the value of the type parameter from the instantiated value.  Here's a modified version of your example that illustrates that:
>
>   subroutine foo(n)
>     type :: t(len)
>     integer, len :: len
>     end type t
>   
>     type(t(n)) :: x1
>     real(x1%len) :: r1 ! Error since the KIND of r1 isn't constant
>     type(t(4)) :: x2
>     real(x2%len) :: r2
>   
>     block
>       real(x2%len) :: r3 ! OK, the KIND of r3 is x2%len, which is folded to 4
>     end block
>     n = 99
>     block
>       real(x2%len) :: r4 ! Still OK, because the x2%len gets folded to 4
>     end block
>   end

You're using non-constant expressions to define the LEN type parameter and then catching the error in the outer context, which requires a constant expression.  But what about cases where a non-constant expression is used to define a LEN type parameter that is referenced in a context that does not require a constant expression?  If the type parameter inquiry is replaced with the actual parameter expression, we'll produce bad results.

  subroutine foo(n)
    type :: t(len)
      integer, len :: len
    end type
    type(t(n)) :: x
    print *, x%len
    n = n + 1
    print *, x%len   ! <--- must not be changed due to modification to 'n'
  end subroutine


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99892/new/

https://reviews.llvm.org/D99892



More information about the llvm-commits mailing list