This is an archive of the discontinued LLVM Phabricator instance.

[flang] Fix semantic analysis for PDT component init
AbandonedPublic

Authored by peixin on May 26 2022, 7:27 AM.

Details

Summary

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.

Diff Detail

Event Timeline

peixin created this revision.May 26 2022, 7:27 AM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: jdoerfert. · View Herald Transcript
peixin requested review of this revision.May 26 2022, 7:27 AM
klausler requested changes to this revision.May 26 2022, 9:56 AM
klausler added inline comments.
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.

This revision now requires changes to proceed.May 26 2022, 9:56 AM
peixin updated this revision to Diff 432726.May 28 2022, 7:41 AM
peixin retitled this revision from [flang] Fix semantic analysis for PDT component init with constant kind/len to [flang] Fix semantic analysis for PDT component init.
peixin edited the summary of this revision. (Show Details)

Address all the comments.

@klausler Is there any possibility that these init can be folded elsewhere to skip these complicated checks?

flang/lib/Evaluate/tools.cpp
1564

Thanks. Fixed.

1575

Got it. Thanks.

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.

What is the motivation of this folding: is it required for semantics check, or does it lead to better code ?

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

Going through a string version of the expression is a bit unusual...

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

peixin abandoned this revision.Jun 14 2022, 4:08 AM

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

Got it. Thanks for the fix.