This is an archive of the discontinued LLVM Phabricator instance.

[flang] Allow KIND type parameters to be used as LEN parameters of components
ClosedPublic

Authored by PeteSteinfeld on Apr 28 2021, 1:06 PM.

Details

Summary

When producing the runtime type information for a component of a derived type
that had a LEN type parameter, we were not allowing a KIND parameter of the
derived type. This was causing one of the NAG correctness tests to fail
(.../hibiya/d5.f90).

I added a test to our own test suite to check for this.

Also, I fixed a typo in .../module/__fortran_type_info.f90.

I allowed KIND type parameters to be used for the declarations of components
that use LEN parameters by constant folding the value of the LEN parameter. To
make the constant folding work, I had to put the semantics::DerivedTypeSpec of
the associated derived type into the folding context. To get this
semantics::DerivedTypeSpec, I changed the value of the semantics::Scope object
that was passed to DescribeComponent() to be the derived type scope rather than
the containing non-derived type scope.

This scope change, in turn, caused differences in the symbol table output that
is checked in typeinfo01.f90. Most of these differences were in the order that
the symbols appeared in the dump. But one of them changed one of the values
from CHARACTER(2_8,1) to CHARACTER(1_8,1). I'm not sure if these changes
are significant. Please verify that the results of this test are still valid.

Also, I wonder if there are other situations in this code where we should be
folding constants. For example, what if the field of a component has a
component whose type is a PDT with a LEN type parameter, and the component's
declaration depends on the KIND type parameter of the current PDT. Here's an
example:

type string(stringkind)
  integer,kind :: stringkind
  character(stringkind) :: value
end type string

type outer(kindparam)
  integer,kind :: kindparam
  type(string(kindparam)) :: field
end type outer

I don't understand the code or what it's trying to accomplish well enough to
figure out if such cases are correctly handled by my new code.

Diff Detail

Event Timeline

PeteSteinfeld requested review of this revision.Apr 28 2021, 1:06 PM
PeteSteinfeld created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2021, 1:06 PM
PeteSteinfeld added a project: Restricted Project.Apr 28 2021, 1:07 PM
klausler added inline comments.Apr 28 2021, 1:14 PM
flang/lib/Semantics/runtime-type-info.cpp
98

FindLenParameterIndex() isn't going to return a meaningful result for a KIND type parameter.

I think the solution to this bug may have to be found at a higher level. KIND type parameters should have been replaced with their constant values in each instantiation of a parameterized derived type. The runtime type information tables should be generated only for derived type instantiations. So a KIND type parameter shouldn't make it here in the first place.

Responding to Peter's comments. I totally changed my implementation to be as
described in the current commit description.

PeteSteinfeld edited the summary of this revision. (Show Details)Apr 29 2021, 3:34 PM
klausler added inline comments.Apr 29 2021, 3:45 PM
flang/lib/Semantics/runtime-type-info.cpp
103–104

KIND type parameters are necessarily constant in derived type instantiations so this message change may mislead a programmer into thinking that a specification expression in a component has to be a "bare" KIND type parameter and not a more general constant expression that can involve KIND type parameters.

PeteSteinfeld added inline comments.Apr 29 2021, 7:11 PM
flang/lib/Semantics/runtime-type-info.cpp
103–104

Good point. I'll revert this message to its previous value.

PeteSteinfeld edited the summary of this revision. (Show Details)

Responding to Peter's comments.

Responding to Peter's comments.

klausler accepted this revision.Apr 30 2021, 8:24 AM
This revision is now accepted and ready to land.Apr 30 2021, 8:24 AM