The PDT component init should be folded during semantic analysis when
the component init has constant kind/lan and does not have derived type
parameter in shape and constant expression.
Details
Diff Detail
Event Timeline
flang/lib/Evaluate/tools.cpp | ||
---|---|---|
1564 | return evaluate::IsActuallyConstant(type->numericTypeSpec().kind()); | |
1575 | IsConstantExpr will return true for a type parameter (see 10.1.12 (10)) whether it is constant or not. Use IsActuallyConstant() instead, as suggested above. | |
flang/lib/Semantics/resolve-names.cpp | ||
6693 | This doesn't make sense to me. Even if the kind and length of the component are constant, the default initialization of the component may still depend on type parameters. | |
flang/test/Semantics/init01.f90 | ||
64 | This error message is now wrong. |
What is the motivation of this folding: is it required for semantics check, or does it lead to better code ?
flang/lib/Semantics/resolve-names.cpp | ||
---|---|---|
6695 | Going through a string version of the expression is a bit unusual... Maybe you could achieve something similar by collecting the symbols in the init expressions (CollectSymbols) and checking if any of the symbols have the TypeParamDetails. |
It will result in fatal internal error when collecting host association variables if not folded. Here is the example:
program m integer :: i call sub() contains subroutine sub() type my_type (k, l) integer, KIND :: k = 4 integer, LEN :: l = 2 integer :: x = 10 real :: y = 20 end type end end
$ flang-new test.f90 fatal internal error: node has not been analyzed: Expr -> LiteralConstant -> IntLiteralConstant = '10'
flang/lib/Semantics/resolve-names.cpp | ||
---|---|---|
6695 |
Agree. This is only the initial try and it definitely needs better solution. I will take a deeper dive for PDT init semantic analysis and also try as you suggested later. |
It will result in fatal internal error when collecting host association variables if not folded. Here is the example: ....
Ah, thanks. In that case, the issue is with the lowering code, it should not unconditionally expect an expression when visiting the parse tree symbols. Your fix is workaring around the issue for the cases where the init expressions does not depends on the kind parameters, but the crash will still occur for types like:
subroutine sub() type my_type (k) integer, KIND :: k integer :: x = k end type end
I do not think anything really need to fold the init expression of un-instantiated PDTs. The lowering visit that is looking for symbols in internal procedure should just ignore if the expression is not analyzed.
I went ahead a pushed a lowering fix for review: https://reviews.llvm.org/D127735
return evaluate::IsActuallyConstant(type->numericTypeSpec().kind());