Structure constructor for extended types

[ender01]

[plain]
Hello all,

I have a hunk of code that worked last year but now will not compile.  When I try to compile it I get an error with the (unenlightening) compiler message "Compilation Aborted (Code 1)".  The code will compile if I comment out the assignment to a variable of extended type (symbolNode).  Can someone tell me what I've missed?

Thanks,

Rich


module fooMod
	implicit none
	
	integer, parameter:: I_LO=selected_int_kind(4)
	
	!  Define node object
	type node
      integer(kind=I_LO) :: name
      type(node), pointer :: node_Ptr
		!class(*), pointer :: storage
		integer(kind=I_LO), pointer :: storage_Ptr  !  Place holder
	end type node
	
	!  Define symbol object
	type symbol
      integer(kind=I_LO) :: size
		character(len=1), dimension(:), allocatable :: token
	   !procedure(charStr_func), pointer :: getToken
	end type symbol
	
	!  Define node object for linked list
	type, extends(node) :: symbolNode
	   type(symbol) :: nodeSymbol
	   type(symbolNode), pointer :: sibling_Ptr => null()
	   type(symbolNode), pointer :: parent_Ptr => null()
	end type symbolNode
	
	!  Declare test fixture variables
	integer(kind=I_LO) :: test_Storage1
	integer(kind=I_LO), target :: test_Storage1_ptr
	character(len=1),dimension(3) :: test_token
	type(symbol) :: test_Symbol1
	type(node) :: test_Node1
	type(symbolNode) :: test_symbolNode1
	type(node) :: test_NodePtr1
	type(symbolNode) :: test_SiblingPtr1, test_ParentPtr1
	type(node), pointer :: test_Node1_Ptr
	type(symbolNode), pointer :: test_Sibling1_Ptr, test_Parent1_Ptr
	
	contains
	   !  setup_testFixture: Contstruct and initialize test fixture.  Run once
      !                     before all unit tests are performed
      subroutine setup_testFixture()
         implicit none
         
         !  Set up test fixture nodes
         test_Storage1 = 5
         test_Storage1_ptr = test_Storage1
         test_Node1_Ptr => null()
         test_Parent1_Ptr => null()
         test_Sibling1_Ptr => null()
         test_token = (/"1","2","3"/)
         
         !  Set up symbol with default structure constructor
         test_Symbol1 = symbol(3_I_LO,test_token)
         
         !  Set up node with default structure constructor
         test_Node1 = node(4_I_LO,test_Node1_Ptr,test_Storage1_ptr)
         
         !  Set up symbolNode with default structure constructor
         !test_symbolNode1 = symbolNode(test_Node1,test_Symbol1, &
         !                              test_Sibling1_Ptr,test_Parent1_Ptr)
         
         !test_symbolNode1 = symbolNode(4_I_LO,test_Node1_Ptr,test_Storage1_ptr, &
         !                      test_Symbol1, test_Sibling1_Ptr,test_Parent1_Ptr) 
         
         return
      end subroutine setup_testFixture
end module fooMod[/plain]

[Steven_L_Intel1]

I can reproduce an internal compiler error for all 11.1 versions - is that what you are seeing? In which version did you successfully compile this? I get a different error with 11.0.

The example constructors you have are incorrect in that they do not have the right number or type of elements. However, I can't get the compiler to accept the proper number and type. I will pass this on to the developers.

[ender01]

Quoting - Steve Lionel (Intel)

I can reproduce an internal compiler error for all 11.1 versions - is that what you are seeing? In which version did you successfully compile this? I get a different error with 11.0.

The example constructors you have are incorrect in that they do not have the right number or type of elements. However, I can't get the compiler to accept the proper number and type. I will pass this on to the developers.

Hi Steve,

I don't know off hand which version of the compiler I was using was (it's on a different machine than the one I'm using now). I can tell you that it was an evaluation copy that I was using almost exactly 1 year ago. The error that I'm seeing from the log is:

fortcom: Fatal: There has been an internal compiler error (C00000FD)

Could you be a little more specific on the problem with the number and types of arguments that I'm using?

Thanks,

Rich

[Steven_L_Intel1 · Accepted solution]

Yes, internal compiler error is what I see in 11.1. That's definitely a bug and I'll report it.

A structure constructor, without use of keywords for the component names, relies on what the standard calls "Component order". For an extended type, this is:

"The component order of an extended type consists of the component order of its parent type followed by any additional components in the order of their declarations in the extended derived-type definition."

So let's look at what we have here. SymbolNode extends node, so the components of the extended type are first the components of node, followed by the added components of SymbolNode. In order, this would be:

integer(kind=I_LO) :: name
type(node), pointer :: node_Ptr
integer(kind=I_LO), pointer :: storage_Ptr
type(symbol) :: nodeSymbol
type(symbolNode), pointer :: sibling_Ptr => null()
type(symbolNode), pointer :: parent_Ptr => null()

That's six components. Your first assignment to test_SymbolNode1 has only five components, so that's wrong. The second one has six but the types are wrong. Looking at that more closely:

symbolNode(4_I_LO, ! Ok - this is integer(I_LO)
test_Node1_Ptr, ! Ok - this is a pointer to type(node)
test_Storage1_ptr, ! Oops - this is an integer(I_LO), not a pointer to one
test_Symbol1, ! Ok - this is type(symbol)
test_Sibling1_Ptr, ! Ok - this is pointer to type(symbolNode)
test_Parent1_Ptr) ! Ok - this is pointer to type(symbolNode)

But even if I change the declarations to match the type, the 11.0 compiler still complains that the number of expressions is wrong. My guess is that it wants the parent type name (symbol) to be in here too, but the standard explicitly excludes that in the component order. Even if I use keywords, the 11.0 compiler complains. No matter what I do here, I can't get the 11.0 compiler to be happy.

So I don't see how you got this to work before.

[ender01]

Quoting - Steve Lionel (Intel)

Yes, internal compiler error is what I see in 11.1. That's definitely a bug and I'll report it.

A structure constructor, without use of keywords for the component names, relies on what the standard calls "Component order". For an extended type, this is:

"The component order of an extended type consists of the component order of its parent type followed by any additional components in the order of their declarations in the extended derived-type definition."

So let's look at what we have here. SymbolNode extends node, so the components of the extended type are first the components of node, followed by the added components of SymbolNode. In order, this would be:

integer(kind=I_LO) :: name
type(node), pointer :: node_Ptr
integer(kind=I_LO), pointer :: storage_Ptr
type(symbol) :: nodeSymbol
type(symbolNode), pointer :: sibling_Ptr => null()
type(symbolNode), pointer :: parent_Ptr => null()

That's six components. Your first assignment to test_SymbolNode1 has only five components, so that's wrong. The second one has six but the types are wrong. Looking at that more closely:

symbolNode(4_I_LO, ! Ok - this is integer(I_LO)
test_Node1_Ptr, ! Ok - this is a pointer to type(node)
test_Storage1_ptr, ! Oops - this is an integer(I_LO), not a pointer to one
test_Symbol1, ! Ok - this is type(symbol)
test_Sibling1_Ptr, ! Ok - this is pointer to type(symbolNode)
test_Parent1_Ptr) ! Ok - this is pointer to type(symbolNode)

But even if I change the declarations to match the type, the 11.0 compiler still complains that the number of expressions is wrong. My guess is that it wants the parent type name (symbol) to be in here too, but the standard explicitly excludes that in the component order. Even if I use keywords, the 11.0 compiler complains. No matter what I do here, I can't get the 11.0 compiler to be happy.

So I don't see how you got this to work before.

Thanks Steve,

The original declaration of test_Storage1_Ptr was:

integer(kind=I_LO), target :: test_Storage1_ptr

I lost the target spec in the process of monkeying around trying to get the compiler to take it. The first version (with 4 arguments - the parent object followed by the three new fields) is what I had working (at least compiling). Then again, maybe I'm misremembering and an earlier version was working...

Thanks again!

Rich

[Steven_L_Intel1]

The version with four components is wrong as the parent type "does not participate" in component ordering.

There must be something peculiar going on here as a straightforward example I tried worked fine. I will report this. Issue ID is DPD200141852.

[Steven_L_Intel1]

If the program is corrected so that all the types match, it compiles ok in 11.1 Update 6. However, I can still trigger an internal error with other mismatches and will report that separately. DPD200154112

Enabling standards checking reveals another problem with the example code - the variables test_SymbolNode1, test_SiblingPtr1, and test_ParentPtr1 are all required to have the SAVE attribute specified because they have component initialization and are in the specification part of a module.