-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
! RUN: flang -fc1 -emit-hlfir %s -o - | FileCheck %s | ||
|
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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 ahlfir.region_assign
.