[flang][RFC] Add lowering design for procedure pointers

[peixin]

Summary

This document aims to give insights at the representation of procedure
pointers in FIR.

[unterumarmung]

Thanks for adding me.
NFC comment: you have a typo in the title - procdure -> procedure

[jeanPerier]

Thanks for writing this up !

I think there are few additional things you may need to cover here about Procedure pointers:

1. What will happen for procedure pointers pointing to internal procedures.

Currently, the flang-procedure-pointer pass (see lib/Optimizer/CodeGen/BoxedProcedure.cpp) rewrites fir.boxproc<T> and deals with emboxproc, the idea behind is that function address in Fortran can point to internal procedures, and there are several ways this could be dealt with. For instance, procedure pointers could carry a pointer to the host stack if it points to an internal procedure, and calls made to it would need to retrieve and hoist this as an extra arguments. For procedure dummy, the chosen design was to create thunks (which has the drawback or requiring the stack to be executable). Some solutions with runtime managed trampolines defined outside of the stack could also be imagined.

2. Procedure pointers to functions returning characters

For dummy procedures, the length of the function may be assumed in the procedure making the call. Given the length is required to make the call, it must be provided as an extra argument (see https://github.com/llvm/llvm-project/blob/ffc7f9d542370eb72ad1f4bf79f763ca685bab8b/flang/include/flang/Optimizer/Builder/Character.h#L198). Is it also possible for a dummy procedure pointer to have a function type with an assumed length ? If so, something might need to be done to carry the length information (as an extra argument ?).

3. Is it possible to pass procedure pointers in BIND(C) procedure ? (If yes, what is the related C type).

flang/docs/ProcedurePointer.md

171

I get that you are following the local object POINTER lowering here where we both have a fir.box<> and a fir.ptr<> being allocated on the stack and do sync operations. I am thinking this may away with HLFIR, at least when lowering, and that a pass would instead simplify local fir.box into a set of address allocations.

I would if possible stay away from it for procedure pointers and just start with a single fir.alloca !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>.

193

Lack Fortran input illustration ?

229

Note that you may need to relax T to be () -> () in this case to account for the fact that function types are being rewritten by certain pass (e.g: https://github.com/llvm/llvm-project/blob/main/flang/lib/Optimizer/CodeGen/TargetRewrite.cpp and https://github.com/llvm/llvm-project/blob/main/flang/lib/Optimizer/Transforms/AbstractResult.cpp).

The issue I see there with having a type !fir.boxproc<T> inside a fir.type is that if T function type needs to be rewritten, so must the fir.type, and currently, I do not think there is a way to change the types of the fir.type members after it was created without creating a new type with a different name. See this TODO: https://github.com/llvm/llvm-project/blob/67d0d7ac0acb0665d6a09f61278fbcf51f0114c2/flang/lib/Optimizer/CodeGen/BoxedProcedure.cpp#L128.

The same issue will probably happens with fir.global of procedure pointers, where the fir.global might type needs to be changed if the interface is transformed.

[klausler]

In D136840#3892253, @jeanPerier wrote:

1. What will happen for procedure pointers pointing to internal procedures.

Currently, the flang-procedure-pointer pass (see lib/Optimizer/CodeGen/BoxedProcedure.cpp) rewrites fir.boxproc<T> and deals with emboxproc, the idea behind is that function address in Fortran can point to internal procedures, and there are several ways this could be dealt with. For instance, procedure pointers could carry a pointer to the host stack if it points to an internal procedure, and calls made to it would need to retrieve and hoist this as an extra arguments. For procedure dummy, the chosen design was to create thunks (which has the drawback or requiring the stack to be executable). Some solutions with runtime managed trampolines defined outside of the stack could also be imagined.

An extra argument doesn't work for internal procedures passed as actual arguments to F'77 procedures unless you want to break ABI compatibility.

A stack thunk is a security hole. Please don't require an executable stack segment for Fortran.

I don't think that there's any alternative to having heap-resident thunks for internal procedures when they are used as procedure pointer targets and/or actual arguments. These impose a clean-up burden on lowering but are otherwise straightforward.

[peixin]

1. Add more related sections and constraints.
2. Address the comments.

[peixin]

Thanks @jeanPerier and @klausler a lot for the detailed comments and explanations.

Note that you may need to relax T to be () -> () in this case to account for the fact that function types are being rewritten by certain pass (e.g: https://github.com/llvm/llvm-project/blob/main/flang/lib/Optimizer/CodeGen/TargetRewrite.cpp and https://github.com/llvm/llvm-project/blob/main/flang/lib/Optimizer/Transforms/AbstractResult.cpp).

The issue I see there with having a type !fir.boxproc<T> inside a fir.type is that if T function type needs to be rewritten, so must the fir.type, and currently, I do not think there is a way to change the types of the fir.type members after it was created without creating a new type with a different name. See this TODO: https://github.com/llvm/llvm-project/blob/67d0d7ac0acb0665d6a09f61278fbcf51f0114c2/flang/lib/Optimizer/CodeGen/BoxedProcedure.cpp#L128.

Fixed.

The same issue will probably happens with fir.global of procedure pointers, where the fir.global might type needs to be changed if the interface is transformed.

Right, I hit this previously. Add it in TODO lists.

1. What will happen for procedure pointers pointing to internal procedures.

Add explanations in doc.

Is it also possible for a dummy procedure pointer to have a function type with an assumed length ? If so, something might need to be done to carry the length information (as an extra argument ?).

Yes. Add explanations in doc.

3. Is it possible to pass procedure pointers in BIND(C) procedure ? (If yes, what is the related C type).

Yes. Add Case 4 and Case 5. Please check that.

An extra argument doesn't work for internal procedures passed as actual arguments to F'77 procedures unless you want to break ABI compatibility.
A stack thunk is a security hole. Please don't require an executable stack segment for Fortran.
I don't think that there's any alternative to having heap-resident thunks for internal procedures when they are used as procedure pointer targets and/or actual arguments. These impose a clean-up burden on lowering but are otherwise straightforward.

Thanks for these explanations. Added in doc.

flang/docs/ProcedurePointer.md

171

Got it. Thanks. Fixed.

[jeanPerier]

flang/docs/ProcedurePointer.md

267

274

Do you mean tuple<fir.ref<!fir.boxproc<T>>, i64> or fir.ref<!fir.boxproc<T>>, i64> ? (The latter probably only makes sense it it is possible to change the length of the procedure pointer dummy, which I am not sure is possible).

[peixin]

flang/docs/ProcedurePointer.md

267

Fixed.

274

Sorry, my bad. I meant to use tuple<!fir.ref<!fir.boxproc<T>>, i64>.

[PeteSteinfeld]

Thanks for doing this!

I'd like to see information on how you're going to test this. There should be executable tests, which, unfortunately, we don't have much support for. It would be good to list all of the areas that need to be tested -- functions, subroutines, internal procedures, component procedure pointers, interfacing with C, varying types for arguments and function returns, ...

flang/docs/ProcedurePointer.md

81

"intrinsic NULL" should read "the NULL() intrinsic"

208–211

I didn't understand this section. I assume that the sentence that starts with "With the explicit interface ..." should read something like "If the C function has an explicit interface and a dummy argument that is a procedure pointer, the code passes a C function pointer as the actual argument". But I'm not sure what happens for the case where the interface is not explicit. Can you please clarify?

270

Should read "to a function returning a character type"

272–274

Is this section specific to functions that return a character type with an assumed length? Is so the section title should mention the fact that the character type is assumed length. Also the section does not actually mention characters. Best to be as specific as possible.

278–283

I don't understand the reference to Fortran 77. Internal procedures first appeared in Fortran 2008. But that doesn't seem relevant, either. I suggest just getting rid of references to the standard here.

I assume that you want this paragraph to read something like: "Initially the current plan is to implement pointers to internal procedures using the LLVM Trampoline intrinsics. This has the drawback of requiring the stack to be executable, which is a security hole. To avoid this, we will need improve the implementation to use heap-resident thunks.

291

Should read "that of an external ..."

376

Should read "components"

378–379

Should read "Having procedure pointers in derived types permits methods to be dynamically bound to objects. Such procedure pointer components will have the type !fir.boxproc<T>.

438

Should read "... possible implementations." That is, don't have the final "possible".

[peixin]

Address the comments.

[peixin]

I'd like to see information on how you're going to test this. There should be executable tests, which, unfortunately, we don't have much support for. It would be good to list all of the areas that need to be tested -- functions, subroutines, internal procedures, component procedure pointers, interfacing with C, varying types for arguments and function returns, ...

I agree that execution test is important for this feature. Usually, I test end-to-end with some fortran examples locally. For this feature, I think LLVM IR check is the first round. Regarding to execution tests, is it OK to attach the issue created in llvm-project to the future lowering/codegen patch, or can I upload the Fortran/C test examples somewhere?

flang/docs/ProcedurePointer.md

208–211

I changed the description. The added testing part can clarify it more clearly.

A C function pointer is semantically equivalent to a Fortran procedure in LLVM IR level, and a pointer to a C function pointer is semantically equivalent to a Fortran procedure pointer in LLVM IR level. That is, a Fortran procedure will be converted to a opaque pointer in LLVM IR level, which is the same for a C function pointer; a Fortran procedure pointer will be converted to a opaque pointer pointing to a opaque pointer, which is the same for a pointer to a C function pointer.

272–274

Remove the case of assumed length character.

Is it also possible for a dummy procedure pointer to have a function type with an assumed length ?

@jeanPerier I was wrong for your question. It cannot be that case. C721 does not allow it. Check the following:

  interface
    character(*) function func()
    end
  end interface
  procedure(), pointer :: p=>func
  call bar(p)
contains
  subroutine bar(proc)
    procedure(func), pointer :: proc
    character(10) :: a! = "aaaa"
    a = proc()
    print *, a
  end
end
character(*) function func()
  func = "abc"
end

gfortran can compile it, but the running result is wrong. LLVM Flang reports the semantic error, which is expected.

278–283

Thanks a lot. English is not my mother language, so I really appreciate you make it more clear.

438

Sorry, it was one typo. Fixed.

[PeteSteinfeld]

Thanks for all of the updates, @peixin. I only had one small nit, which was my fault.

I like your idea of creating an issue in llvm-project to cover the execution testing of the implementation. Please do so.

I'm approving this patch since it has all of the changes I've requested. But I recommend waiting for @jeanPerier to approve since he has had so many comments.

flang/docs/ProcedurePointer.md

280–281

"need improve" should read "need to improve". My mistake!

[jeanPerier]

flang/docs/ProcedurePointer.md

272–274

C721 makes your example illegal, but I am not sure it makes it illegal to have dummy procedure pointers with assumed length.

Here is an example that shows an usage of assumed length character function with pointers that is, I think, legal. I wrote it in a way that neither the procedure pointer call site, nor the called target know about the result length at compile time. The only way to get the result length is for it to be propagated alongside the procedure pointer argument when calling "foo":

gfortran and ifort compile and print the expected:

ab
abcd

module test
contains
subroutine foo(proc_pointer)
  character(*), external, pointer :: proc_pointer
  print *, proc_pointer()
end subroutine

subroutine as_length2()
 character(2), external :: assumed_length
 character(2), external, pointer :: p
 p => assumed_length
 call foo(p)
end subroutine

subroutine as_length4()
 character(4), external :: assumed_length
 character(4), external, pointer :: p
 p => assumed_length
 call foo(p)
end subroutine
end module

character(*) function assumed_length()
 assumed_length = "abcdefghi"
end function

 use test
 call as_length2()
 call as_length4()
end

Given nvfortran, xlf, and nag seem to have various issues with this program, I would not prioritize this feature, but adding a clean todo seems the minimum to me.

[jeanPerier]

flang/docs/ProcedurePointer.md

272–274

Mmh, never mind. Reading the fine prints of C723 I read "A function name declared with an asterisk type-param-value shall not be [...], a pointer, [...]", so it might just be illegal to have procedure pointers with assumed length. But flang still lacks a semantic check to enforce this.

[peixin]

Address the comment from @PeteSteinfeld . need -> need to

[peixin]

Add C723 in the description. C721 -> C721 and C723.

flang/docs/ProcedurePointer.md

272–274

Thanks for finding this. I filed one ticket for it. https://github.com/llvm/llvm-project/issues/58757

[jeanPerier]

LGTM

[kiranchandramohan]

The conversion to LLVM of the procedure-pointer-related operations (emboxproc, hostboxproc,unboxproc) are marked as TODO. The examples only show the usage of emboxproc. Does that mean hostboxproc and unboxproc are not going to be used? Could you discuss their conversions to LLVM as well?
https://github.com/llvm/llvm-project/blob/d839f654586a4f3a84b334fcc2c986343a1d7f98/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L631
https://github.com/llvm/llvm-project/blob/d839f654586a4f3a84b334fcc2c986343a1d7f98/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L2085
https://github.com/llvm/llvm-project/blob/d839f654586a4f3a84b334fcc2c986343a1d7f98/flang/lib/Optimizer/CodeGen/CodeGen.cpp#L3171

flang/docs/ProcedurePointer.md

276

Could you clarify that this will not be part of the initial implementation?

[peixin]

In D136840#3902033, @kiranchandramohan wrote:

The conversion to LLVM of the procedure-pointer-related operations (emboxproc, hostboxproc,unboxproc) are marked as TODO. The examples only show the usage of emboxproc. Does that mean hostboxproc and unboxproc are not going to be used? Could you discuss their conversions to LLVM as well?

As I mentioned in the NOTE after Current list of TODOs in code generation, there are any number of possible implementations of the conversion to LLVM for procedure pointer. Actually, using BoxedProcedure pass has already supported most of usage scenarios of procedure pointers, but there are several implementations not finished as I listed there (BoxProcType type conversion, record type with a boxproc type, and fir.global).

My current plan is to use BoxedProcedure pass to complete procedure pointer. But it is free to anyone who want to try to implement it using the conversion of EmboxProc, BoxProc_Host, Len_Param_Index, UnboxProc operations without the need of BoxedProcedure pass.

flang/docs/ProcedurePointer.md

276

I don't get it. This will be implemented, but following the method of processing internal procedure. I may not describe it clearly during the meeting.

The final implementation for both procedure pointer to internal procedure and internal procedure should use heap-resident thunks. That's what the following description says.

[kiranchandramohan]

In D136840#3902232, @peixin wrote:

In D136840#3902033, @kiranchandramohan wrote:

The conversion to LLVM of the procedure-pointer-related operations (emboxproc, hostboxproc,unboxproc) are marked as TODO. The examples only show the usage of emboxproc. Does that mean hostboxproc and unboxproc are not going to be used? Could you discuss their conversions to LLVM as well?

As I mentioned in the NOTE after Current list of TODOs in code generation, there are any number of possible implementations of the conversion to LLVM for procedure pointer. Actually, using BoxedProcedure pass has already supported most of usage scenarios of procedure pointers, but there are several implementations not finished as I listed there (BoxProcType type conversion, record type with a boxproc type, and fir.global).

My current plan is to use BoxedProcedure pass to complete procedure pointer. But it is free to anyone who want to try to implement it using the conversion of EmboxProc, BoxProc_Host, Len_Param_Index, UnboxProc operations without the need of BoxedProcedure pass.

Thanks @peixin for the explanation. Could you explicitly state in the beginning of the document that you will use/extend the BoxedProcedure pass and thus will not be lowering the procedure-pointer-related options to LLVM?

[peixin]

Thanks @kiranchandramohan. Good point. It's more clear for readers. Add the descriptions as suggested.

flang/docs/ProcedurePointer.md

+<!--===- docs/ProcedurePointer.md
+
+   Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+   See https://llvm.org/LICENSE.txt for license information.
+   SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+
+-->
+
+# Procedure Pointer
+
+A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes.
+
+This document summarizes what of context the procedure pointers should appear,
+and how they are lowered to FIR.
+
+The current plan is to use/extend the `BoxedProcedure` pass for the conversion
+to LLVM IR, and thus will not be lowering the procedure-pointer-related
+operations to LLVM IR in `CodeGen.cpp`.
+
+## Fortran standard
+
+Here is a list of the sections and constraints of the Fortran standard involved
+for procedure pointers.
+
+- 8.5.4 Components
+  - C757
+  - C758
+  - C759
+- 8.5.9: EXTERNAL attribute
+- 8.5.14: POINTER attribute
+  - C853
+  - A procedure pointer shall not be referenced unless it is pointer associated
+    with a target procedure.
+- 8.5.15 PROTECTED attribute
+  - C855
+- 8.5.16 SAVE attribute
+  - (4) A procedure pointer declared in the scoping unit of a main program,
+        module, or submodule implicitly has the SAVE attribute.
+- 8.10.2.1 COMMON statement
+  - C8119
+- 10.2.2.2 Pointer assignment statement
+  - C1028
+  - C1029
+- 10.2.2.4 Procedure pointer assignment
+- 11.1.3 ASSOCIATE construct
+  - C1005
+- 12.6.3 Data transfer input/output list
+  - C1233
+- 15.2.2.4 Procedure pointers
+  - A procedure pointer may be pointer associated with an external procedure, an
+    internal procedure, an intrinsic procedure, a module procedure, or a dummy
+    procedure that is not a procedure pointer.
+- 15.4.3.6 Procedure declaration statement
+- 15.5.2.9(5) Actual arguments associated with dummy procedure entities
+- 16.9.16 ASSOCIATED(POINTER [, TARGET])
+  - POINTER may be a procedure pointer, and TARGET may be proc-target in a
+    pointer assignment statement (10.2.2).
+- 16.9.144 NULL([MOLD])
+  - MOLD may be a procedure pointer.
+- 18.2.3.4 C_F_PROCPOINTER(CPTR, FPTR)
+  - FPTR shall be a procedure pointer, and not be a component of a coindexed
+    object.
+- C.1.1 A procedure that is not a procedure pointer can be an actual argument
+  that corresponds to a procedure pointer dummy argument with the INTENT(IN)
+  attribute.
+
+---
+
+## Representation in FIR
+
+### Procedure pointer `!fir.ref<!fir.boxproc<T>>`
+
+A procedure pointer may have an explicit or implicit interface. T in
+`!fir.ref<!fir.boxproc<T>>` is the function type, which is `() -> ()` if the
+procedure pointer has the implicit interface declared as
+`procedure(), pointer :: p`.
+
+A procedure declaration statement specifies EXTERNAL attribute (8.5.9) for all
+entities for all entities in the procedure declaration list.
+
+### Actual arguments associated with dummy procedure entities
+
+The actual argument may be a procedure pointer, a valid target for the dummy
+pointer, a reference to the NULL() intrinsic, or a reference to a function that
+returns a procedure pointer.
+
+If the interface is explicit, and the dummy argument is procedure pointer, the
+reference is resolved as the pointer to the procedure; otherwise, the reference
+is resolved as the pointer target.
+
+**Fortran case 1**
+```fortran
+subroutine proc_pointer_dummy_argument(p)
+  interface
+    function func(x)
+      integer :: x
+    end function func
+  end interface
+  procedure(func), pointer :: p
+  call foo1(p)
+  call foo2(p)
+contains
+  subroutine foo2(q)
+    interface
+      function func(x)
+        integer :: x
+      end function func
+    end interface
+    procedure(func), pointer :: q
+  end subroutine foo2
+end subroutine proc_pointer_dummy_argument
+```
+
+**FIR for case 1**
+```
+func.func private @foo1(!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>)
+func.func private @foo2(!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>)
+
+func.func @proc_pointer_dummy_argument(%0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>) {
+  %1 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  fir.call @foo1(%1) : ((!fir.ref<i32>) -> !fir.ref<f32>) -> ()
+  fir.call @foo2(%0) : (!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>) -> ()
+  return
+}
+```
+
+**Fortran case 2**
+```fortran
+subroutine proc_pointer_global()
+  interface
+    function func(x)
+      integer :: x
+    end function func
+  end interface
+  procedure(func), pointer, save :: p
+  call foo1(p)
+  call foo2(p)
+contains
+  subroutine foo2(q)
+    interface
+      function func(x)
+        integer :: x
+      end function func
+    end interface
+    procedure(func), pointer :: q
+  end subroutine foo2
+end subroutine proc_pointer_global
+```
+
+**FIR for case 2**
+```
+func.func private @foo1(!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>)
+func.func private @foo2(!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>)
+
+fir.global internal @ProcedurePointer : !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>> {
+  %0 = fir.zero_bits (!fir.ref<i32>) -> !fir.ref<f32>
+  %1 = fir.emboxproc %0 : ((!fir.ref<i32>) -> !fir.ref<f32>) -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  fir.has_value %1 : !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+}
+
+func.func @proc_pointer_global() {
+  %0 = fir.address_of(@ProcedurePointer) : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  %1 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  fir.call @foo1(%1) : (!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>) -> ()
+  fir.call @foo2(%0) : (!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>) -> ()
+  return
+}
+```
+
+**Fortran case 3**
+```fortran
+subroutine proc_pointer_local()
+  interface
+    function func(x)
+      integer :: x
+    end function func
+  end interface
+  procedure(func), pointer :: p
+  call foo1(p)
+  call foo2(p)
+contains
+  subroutine foo2(q)
+    interface
+      function func(x)
+        integer :: x
+      end function func
+    end interface
+    procedure(func), pointer :: q
+  end subroutine foo2
+end subroutine proc_pointer_local
+```
+
+**FIR for case 3**
+```
+func.func private @foo1(!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>)
+func.func private @foo2(!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>)
+
+func.func @proc_pointer_local() {
+  %0 = fir.alloca !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  %1 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  %2 = fir.box_addr %1 : (!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>) -> ((!fir.ref<i32>) -> !fir.ref<f32>)
+  %3 = fir.zero_bits (!fir.ref<i32>) -> !fir.ref<f32>
+  fir.store %3 to %2 : !fir.ref<(!fir.ref<i32>) -> !fir.ref<f32>>
+  %4 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  fir.call @foo1(%4) : (!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>) -> ()
+  fir.call @foo2(%0) : (!fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>) -> ()
+  return
+}
+```
+
+It is possible to pass procedure pointers to a C function. If the C function has
+an explicit interface in fortran code, and the dummy argument is a procedure
+pointer, the code passes a pointer to the procedure as the actual argument
+(see Case 5); Otherwise, the code passes the procedure pointer target as the
+actual argument (see Case 4).
+
+**Case 4**
+```c
+void func_(void (*foo)(int *)) {
+  int *x, y = 1;
+  x = &y;
+  foo(x);
+}
+```
+```fortran
+program main
+  procedure(), pointer :: pp
+  pp=>print_x
+  call func(pp)
+contains
+  subroutine print_x(x)
+    integer :: x
+    print *, x
+  end
+end
+```
+
+Note that the internal procedure is not one good usage, but it works in
+implementation. It is better to use BIND(C) external or module procedure as
+right-hand side proc-target.
+
+**Case 5**
+```c
+void func_(void (**foo)(int *)) {
+  int *x, y = 1;
+  x = &y;
+  (*foo)(x);
+}
+```
+```fortran
+program main
+  interface
+    subroutine func(p)
+      procedure(), pointer :: p
+    end
+  end interface
+  procedure(), pointer :: pp
+  pp=>print_x
+  call func(pp)
+contains
+  subroutine print_x(x)
+    integer :: x
+    print *, x
+  end
+end
+```
+
+Case 4 and Case 5 are not recommended from Fortran 2003 standard, which provides
+the feature of interoperability with C to handle this. Specifically,
+C_F_PROCPOINTER is used to associate a procedure pointer with the target of a C
+function pointer. C_FUNPTR is also designed for interoperability with any C
+function pointer type.
+
+### Procedure pointer to function returning a character type
+
+The dummy procedure pointer may not have a function type with an assumed length
+due to C721 and C723.
+
+### Procedure pointer to internal procedure
+
+Initially the current plan is to implement pointers to internal procedures
+using the LLVM Trampoline intrinsics. This has the drawback of requiring the
+stack to be executable, which is a security hole. To avoid this, we will need
+improve the implementation to use heap-resident thunks.
+
+### Procedure pointer assignment `p => proc`
+
+The right-hand side may be a procedure, a procedure pointer, or a function whose
+result is a procedure pointer.
+
+The procedure could be a BIND(C) procedure. The lowering of it is the same as
+that of an external or module procedure. The case of internal procedure has been
+discussed above.
+
+```c
+#include<stdio.h>
+void func_(int *x) {
+  printf("%d\n", *x);
+}
+```
+```fortran
+program main
+  interface
+    subroutine func(x) bind(C)
+      integer :: x
+    end
+  end interface
+  procedure(func), bind(C, name="func_") :: proc
+  procedure(func), pointer :: pp
+  integer :: x = 5
+  pp=>proc
+  call pp(x)
+end
+```
+
+**Fortran case**
+```fortran
+subroutine proc_pointer_assignment(arg0, arg1)
+  interface
+    function func(x)
+      integer :: x
+    end
+  end interface
+  procedure(func), pointer :: arg0, arg1
+  real, external, bind(C, name="Procedure") :: proc
+  arg0=>proc    ! case 1
+  arg0=>arg1    ! case 2
+  arg0=>reffunc ! case 3
+contains
+  function reffunc() result(pp)
+    interface
+      function func(x)
+        integer :: x
+      end
+    end interface
+    procedure(func), pointer :: pp
+  end
+end
+function proc(x) bind(C, name="Procedure")
+  integer :: x
+  proc = real(x)
+end
+```
+
+**FIR**
+```
+func.func @Procedure(%arg0 : !fir.ref<i32>) -> !fir.ref<f32> {
+  %1 = fir.load %arg0 : !fir.ref<i32>
+  %2 = fir.convert %1 : (i32) -> f32
+  return %2 : f32
+}
+
+func.func @Reference2Function() -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>> {
+  %0 = fir.alloca !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  %1 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  return %1 : !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+}
+
+func.func @proc_pointer_assignment(%arg0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>, %arg1 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>) {
+  %0 = fir.alloca !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>> {bindc_name = ".result"}
+  // case 1: assignment from external procedure
+  %1 = fir.address_of(@Procedure) : (!fir.ref<i32>) -> !fir.ref<f32>
+  %2 = fir.emboxproc %1 : ((!fir.ref<i32>) -> !fir.ref<f32>) -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  fir.store %2 to %arg0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  // case2: assignment from procdure pointer
+  %3 = fir.load %arg1 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  fir.store %3 to %arg0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  // case3: assignment from a reference to a function whose result is a procedure pointer
+  %4 = fir.call @Reference2Function() : () -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  fir.store %4 to %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  %5 = fir.load %0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  fir.store %5 to %arg0 : !fir.ref<!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>>
+  return
+}
+```
+
+### Procedure pointer components
+
+Having procedure pointers in derived types permits `methods` to be dynamically
+bound to objects. Such procedure pointer components will have the type
+!fir.boxproc<T>.
+
+**Fortran**
+```fortran
+subroutine proc_pointer_component(a, i, f)
+  interface
+    function func(x)
+      integer :: x
+    end
+  end interface
+  type matrix
+    real :: element(2,2)
+    procedure(func), pointer, nopass :: solve
+  end type
+  integer :: i
+  procedure(func) :: f
+  type(matrix) :: a
+  a%solve=>f
+  r = a%solve(i)
+end subroutine proc_pointer_component
+```
+
+**FIR**
+```
+func.func @proc_pointer_component(%arg0 : (!fir.ref<i32>) -> !fir.ref<f32>, %arg1: !fir.ref<i32>) {
+  %0 = fir.alloca !fir.type<_QFtestTmatrix{element:!fir.array<2x2xf32>,solve:!fir.boxproc<() -> ()>}>
+  %1 = fir.field_index solve, !fir.type<_QFtestTmatrix{element:!fir.array<2x2xf32>,solve:!fir.boxproc<() -> ()>}>
+  %2 = fir.coordinate_of %0, %1 : (!fir.ref<!fir.type<_QFtestTmatrix{element:!fir.array<2x2xf32>,solve:!fir.boxproc<() -> ()>}>>, !fir.field) -> !fir.ref<!fir.boxproc<() -> ()>>
+  %3 = fir.emboxproc %arg0 : ((!fir.ref<i32>) -> !fir.ref<f32>) -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  %4 = fir.convert %3 : (!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>) ->  !fir.boxproc<() -> ()>
+  fir.store %4 to %2 : !fir.ref<!fir.boxproc<() -> ()>>
+  %4 = fir.field_index solve, !fir.type<_QFtestTmatrix{element:!fir.array<2x2xf32>,solve:!fir.boxproc<() -> ()>}>
+  %5 = fir.coordinate_of %0, %4 : (!fir.ref<!fir.type<_QFtestTmatrix{element:!fir.array<2x2xf32>,solve:!fir.boxproc<() -> ()>}>>, !fir.field) -> !fir.ref<!fir.boxproc<() -> ()>>
+  %6 = fir.load %5 : !fir.ref<!fir.boxproc<() -> ()>>
+  %7 = fir.convert %6 : (!fir.boxproc<() -> ()>) -> !fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>
+  %8 = fir.box_addr %7 : (!fir.boxproc<(!fir.ref<i32>) -> !fir.ref<f32>>) -> ((!fir.ref<i32>) -> !fir.ref<f32>)
+  %9 = fir.call %8(%arg1) : (!fir.ref<i32>) -> !fir.ref<f32>
+  return
+}
+```
+
+---
+
+# Testing
+
+The lowering part is tested with LIT tests in tree, but the execution tests are
+useful for full testing.
+
+LLVM IR testing is also helpful with the initial check. A C function pointer is
+semantically equivalent to a Fortran procedure in LLVM IR level, and a pointer
+to a C function pointer is semantically equivalent to a Fortran procedure
+pointer in LLVM IR level. That is, a Fortran procedure will be converted to a
+opaque pointer in LLVM IR level, which is the same for a C function pointer;
+a Fortran procedure pointer will be converted to a opaque pointer pointing to
+a opaque pointer, which is the same for a pointer to a C function pointer.
+
+The tests should include the following
+- function result, subroutine/function arguments with varying types
+  - non-character scalar
+  - character (assumed-length and non-assumed-length)
+  - array (static and dynamic)
+  - character array
+  - derived type
+  - ... (polymorphic?)
+- internal/external/module procedure or a C function as the target
+  - procedure pointer initialization
+  - procedure pointer assignment
+- procedure pointer, procedure pointer target passed to a C function
+- procedure pointer, procedure pointer target passed to a Fortran procedure
+- procedure pointer component in derived types
+
+---
+
+# Current TODOs
+Current list of TODOs in lowering:
+- `flang/lib/Lower/CallInterface.cpp:708`: not yet implemented: procedure pointer result not yet handled
+- `flang/lib/Lower/CallInterface.cpp:961`: not yet implemented: procedure pointer arguments
+- `flang/lib/Lower/CallInterface.cpp:993`: not yet implemented: procedure pointer results
+- `flang/lib/Lower/ConvertExpr.cpp:1119`: not yet implemented: procedure pointer component in derived type assignment
+- `flang/lib/Lower/ConvertType.cpp:228`: not yet implemented: procedure pointers
+- `flang/lib/Lower/Bridge.cpp:2438`: not yet implemented: procedure pointer assignment
+- `flang/lib/Lower/ConvertVariable.cpp:348`: not yet implemented: procedure pointer component default initialization
+- `flang/lib/Lower/ConvertVariable.cpp:416`: not yet implemented: procedure pointer globals
+- `flang/lib/Lower/ConvertVariable.cpp:1459`: not yet implemented: procedure pointers
+- `flang/lib/Lower/HostAssociations.cpp:162`: not yet implemented: capture procedure pointer in internal procedure
+- lowering of procedure pointers in ASSOCIATED, NULL, and C_F_PROCPOINTER
+
+Current list of TODOs in code generation:
+
+NOTE: There are any number of possible implementations.
+
+- `flang/lib/Optimizer/CodeGen/TypeConverter.h:64` TODO: BoxProcType type conversion
+- `flang/lib/Optimizer/CodeGen/BoxedProcedure.cpp:136` not yet implemented: record type with a boxproc type
+- fir.global for procedure pointers
+
+or
+
+- `flang/lib/Optimizer/CodeGen/CodeGen.cpp:2080` not yet implemented: fir.emboxproc codegen
+- `flang/lib/Optimizer/CodeGen/CodeGen.cpp:629` not yet implemented: fir.boxproc_host codegen
+- `flang/lib/Optimizer/CodeGen/CodeGen.cpp:1078` not yet implemented: fir.len_param_index codegen
+- `flang/lib/Optimizer/CodeGen/CodeGen.cpp:3166` not yet implemented: fir.unboxproc codegen
+
+---
+
+Resources:
+- [1] Fortran standard