Skip to content

[Flang] Fix handling of unlimited polymorphic arrays #159624

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.

Sign up for GitHub

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

Closed
wants to merge 2 commits into from
Closed

[Flang] Fix handling of unlimited polymorphic arrays #159624

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7fe645d
[Flang] Fix handling of unlimited polymorphic arrays
ceseo Sep 18, 2025
b982f6f
Simplified condition and updated comments in AssignOpConversion
ceseo Sep 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion flang/lib/Optimizer/HLFIR/Transforms/ConvertToFIR.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,8 @@ class AssignOpConversion : public mlir::OpRewritePattern<hlfir::AssignOp> {
// types of the LHS and the RHS must match already. We use the
// runtime in this case so that the polymorphic (including
// unlimited) content is copied properly.
(lhs.isPolymorphic() && assignOp.isTemporaryLHS())) {
(lhs.isPolymorphic() && assignOp.isTemporaryLHS()) ||
lhs.isPolymorphic() || rhs.isPolymorphic()) {
// Use the runtime for simplicity. An optimization pass will be added to
// inline array assignment when profitable.
mlir::Value from = emboxRHS(rhsExv);
Expand Down
25 changes: 25 additions & 0 deletions flang/test/HLFIR/unlimited-polymorphic-where-construct.f90
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
! RUN: flang -fc1 -emit-hlfir %s -o - | FileCheck %s
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this test testing the fix? Since the fix in the patch happens at the HLFIR to FIR level, I do not think -emit-hlfir exercises it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it is because if the polymorphic assignment was going through the scalar assignment path as before, we would see a fir.store instead of a hlfir.region_assign.


module m1
type x
end type x
logical,parameter::t=.true.,f=.false.
logical::mask(3)=[t,f,t]
end module m1

subroutine s1
use m1
class(*),allocatable::v(:),u(:)
allocate(x::v(3))
allocate(x::u(3))
where(mask)
u=v
Copy link
Contributor

Choose a reason for hiding this comment

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

Tricky case. Your fix implies that the LHS and RHS dynamic type is the same at runtime to work properly. I do not know what is the standard required behavior here....

In, assignment-stmt polymorphic LHS are required to be allocatable in F2023 10.2.1.2 (1) so that the LHS can be reallocated to the RHS dynamic type if it is not the same.

But here, inside a masked assignment, the reallocation logic is not really specified. Lowering is not generating it because the LHS/RHS shapes are supposed to match already.

I do think it would be cleaner to forbid assignments to whole polymorphic allocatables inside WHERE statements.

Section 10.2.3 does not really say anything about it allocatable assignements inside WHERE statements, and especially in the case of polymorphic LHS, this opens the doors to many interpretation/behaviors.

@klausler, what do you think? Should this case be clarified with the J3?

end where
! CHECK: hlfir.region_assign
! CHECK: !fir.ref<!fir.class<!fir.heap<!fir.array<?xnone>>>>
end subroutine s1

program main
call s1
print *,'pass'
end program main