genRecordAssignment is emitting code to call Assign in the runtime for some cases.
In these cases, the finalization is done by the runtime so we do not need to do it in
a separate cal to avoid multiple finalization..
Also refactor the code in Bridge so the actual finalization of allocatable
is done before any reallocation. We might need to push this into ReallocIfNeeded.
It is not clear if the allocatable lhs needs to be finalized in any cases or only if it is
reallocated.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Other than my question, LGTM.
flang/lib/Lower/Bridge.cpp | ||
---|---|---|
2819 | Why ruling out the left hand side function result case? |
flang/lib/Lower/Bridge.cpp | ||
---|---|---|
2819 | I guess this is debatable. In this case you would have the f finalized type :: t integer :: a contains final :: finalize end type type(t) function f(n) integer, intent(in) :: n f = t(n) end function and if you write it like that you don't obviously type(t) function f(n) integer, intent(in) :: n f%a = n end function Is the func result part of 7.5.6.3 point 1. I guess since there is mention of func result we should treat it as any other variable. What do you think? |
flang/lib/Lower/Bridge.cpp | ||
---|---|---|
2819 | Thanks for the explanation. Reading at the standard, I would expect f to be finalized before the assignment. It fits in the point 1 (it's a normal variable that can be read/written several times inside the function). I think this would happen anyway if t is a type with allocatable components where we always use genAssign to deal with the assignment. Then the finalizer would be called in genAssign. |
Keep finalizing function result
flang/lib/Lower/Bridge.cpp | ||
---|---|---|
2819 | Let's keep finalization for function result. We can revise this in case it should not. |
Why ruling out the left hand side function result case?