This is an archive of the discontinued LLVM Phabricator instance.

[flang] Lowering and implementation for same_type_as
ClosedPublic

Authored by clementval on Jan 10 2023, 2:12 AM.

Details

Summary

The test performed by same_type_as does not consider kind type
parameters. If an exact match is not found, the name of the
derived type is compared. The name in the runtime info does not include
the kind type parameters as it does in the mangled name.

Diff Detail

Event Timeline

clementval created this revision.Jan 10 2023, 2:12 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
Herald added a subscriber: mehdi_amini. · View Herald Transcript
clementval requested review of this revision.Jan 10 2023, 2:12 AM

Remove blank line

clang-format

Brace initialization

jeanPerier added inline comments.
flang/runtime/derived-api.cpp
88

As I understand, the standard is leaving processor dependent the case where both entities are unlimited polymorphic and their dynamic types are intrinsic types ("If neither A nor B has extensible dynamic type, the result is processor dependent.") and the code here choses to return false in that case.

I do not have motivations to chose one or the other, but I would rather @klausler to weight in and the processor dependent behavior to be documented in Extensions.md.

95

On the one hand the note 16.29 is pretty clear and your code is in line with this. On the other hand, it breaks my understanding of Fortran. I do not understand how "the dynamic type of A is the same as the dynamic type of B" in the requirement implies that they can have different kind parameters... @klausler is the note 16.29 really in line what is in actual requirements ?

jeanPerier added inline comments.Jan 10 2023, 6:25 AM
flang/runtime/derived-api.cpp
95

It looks like folding is indeed ignoring type and length parameters when it can fold SAME_TYPE_AS (https://github.com/llvm/llvm-project/blob/94896994386d2a6a9e7bc310de83ee1491f194ef/flang/lib/Evaluate/fold-logical.cpp#L212-L213).

So there is not doubt about what needs to be done, but I do not understand how the Note can be deduced from the requirement.

PeteSteinfeld accepted this revision.Jan 10 2023, 6:27 AM

Aside from checking about unlimited polymorphic type comparisons, all builds and tests correctly and looks good.

flang/runtime/derived-api.cpp
88

Section 7.3.2.2, paragraph 3 states

An entity that is declared using the TYPE(*) type specifier is assumed-type and is an unlimited polymorphic entity. It is not declared to have a type, and is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity.

This seems to me to state that any two unlimited polymorphic types are different.

Still, I agree with Jean that it would be good to consult with @klausler.

This revision is now accepted and ready to land.Jan 10 2023, 6:27 AM
clementval added inline comments.Jan 10 2023, 6:30 AM
flang/runtime/derived-api.cpp
95

On the one hand the note 16.29 is pretty clear and your code is in line with this. On the other hand, it breaks my understanding of Fortran. I do not understand how "the dynamic type of A is the same as the dynamic type of B" in the requirement implies that they can have different kind parameters... @klausler is the note 16.29 really in line what is in actual requirements ?

I think the confusion comes from the fact that we are folding the kind type parameter in the derived type directly. This is an implementation detail of flang and we could imagine the dynamic type to be the same if we do not fold the kind parameters. Therefore if we ignore the kind parameters the dynamic type would be the same. At least that is my understanding.

klausler added inline comments.Jan 10 2023, 1:45 PM
flang/runtime/derived-api.cpp
88

TYPE(*) dummy arguments don't have (declared) types, so they're like NaNs in tests for equality.

CLASS(*) objects also don't have declared types, so they should also compare unequal.

I don't see a good reason for SAME_TYPE_AS() to ever return .true. unless its arguments really do have the same dynamic declared type, ignoring all parameters.

95

is the note 16.29 really in line what is in actual requirements ?

I can't find a "note 16.29" in my copy of the standard. Do you mean "note 2" in section 16.9.165? If so, yes, I think same_type_as ignores kind type parameters entirely. Which seems silly to me, but that's what somebody wanted.

This revision was automatically updated to reflect the committed changes.