This is an archive of the discontinued LLVM Phabricator instance.

[flang] Allow `to` argument of move_alloc to be class(*)
ClosedPublic

Authored by DavidTruby on Feb 8 2023, 3:29 AM.

Details

Summary

This patch expands the runtime check in move_alloc to allow the
destination to be unlimited polymorphic.

Diff Detail

Event Timeline

DavidTruby created this revision.Feb 8 2023, 3:29 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 8 2023, 3:29 AM
Herald added a subscriber: sunshaoce. · View Herald Transcript
DavidTruby requested review of this revision.Feb 8 2023, 3:29 AM
clementval added inline comments.Feb 8 2023, 3:41 AM
flang/runtime/allocatable.cpp
48

If allocated the type of the unlimited polymorphic descriptor will not be CFI_type_other.

DavidTruby added inline comments.Feb 8 2023, 4:17 AM
flang/runtime/allocatable.cpp
48

Oh, is it then set to the concrete type?
How do you determine if the variable is unlimited polymorphic then? Perhaps it's not possible here in which case we should just remove this whole check?

clementval added inline comments.Feb 8 2023, 5:02 AM
flang/runtime/allocatable.cpp
48

There is no way to directly check if a descriptor is for a polymorphic/unlimited polymorphic entity. We could either pass a boolean value in the lowering or just perform the check inline when it is needed before calling the runtime. So in both case the current check should not be preserved in this form.

Remove check entirely

I think we just want to get rid of this. Is there an additional check that needs doing somewhere in Semantic analysis or anything? I couldn't find a case that shouldn't be allowed that is when I tried.

luporl added a subscriber: luporl.Feb 17 2023, 11:28 AM

It seems to me it's ok to just remove the runtime checks, as you did.
Semantic analysis already checks if both arguments are allocatable and type compatible, except for polymorphic types.
For these, I currently get a not yet implemented error.

But given the spec of move_alloc (16.9.137), it's possible to verify all cases in compile time (as gfortran does). These should be the possible cases involving (unlimited) polymorphic types:

  • from isn't polymorphic but to is: invalid, unless to is unlimited polymorphic.
  • from is polymorphic but to isn't: invalid, not type compatible.
  • from and to are polymorphic: from must have the same declared type of to or any of its extensions (7.3.2.3).
  • from is unlimited polymorphic but to isn't: invalid.
  • to is unlimited polymorphic: from may have any declared type.

None of the cases above depend on runtime type information.

It seems to me it's ok to just remove the runtime checks, as you did.
Semantic analysis already checks if both arguments are allocatable and type compatible, except for polymorphic types.
For these, I currently get a not yet implemented error.

But given the spec of move_alloc (16.9.137), it's possible to verify all cases in compile time (as gfortran does). These should be the possible cases involving (unlimited) polymorphic types:

  • from isn't polymorphic but to is: invalid, unless to is unlimited polymorphic.

This is not invalid if from as a compatible type with to. monomorphic derived-type to a polymorphic with the same declared type.

  • from is polymorphic but to isn't: invalid, not type compatible.
  • from and to are polymorphic: from must have the same declared type of to or any of its extensions (7.3.2.3).
  • from is unlimited polymorphic but to isn't: invalid.
  • to is unlimited polymorphic: from may have any declared type.

None of the cases above depend on runtime type information.

clementval accepted this revision.Feb 27 2023, 1:51 AM

I'm fine to remove the check.

This revision is now accepted and ready to land.Feb 27 2023, 1:51 AM
luporl added a comment.EditedFeb 27 2023, 4:44 AM

But given the spec of move_alloc (16.9.137), it's possible to verify all cases in compile time (as gfortran does). These should be the possible cases involving (unlimited) polymorphic types:

  • from isn't polymorphic but to is: invalid, unless to is unlimited polymorphic.

This is not invalid if from as a compatible type with to. monomorphic derived-type to a polymorphic with the same declared type.

It really makes sense to allow from to be a monomorphic derived-type and to a polymorphic with the same declared (base) type. gfortran allows this.

However, the F2018 standard (16.9.137 MOVE_ALLOC) states this about the TO argument:

It shall be polymorphic if FROM is polymorphic.

Then I guess it doesn't imply that TO shall not be polymorphic if FROM isn't.