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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 ? |
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. |
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. |
flang/runtime/derived-api.cpp | ||
---|---|---|
95 |
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. |
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 |
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. |
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.