5.30 problem with duplication of variable within a module

Hi,

I've found an apparent problem in 5.30 that wasn't there before (at least not in 5.10). If I declare a type containing an array (integers in my case) that used to declare a variable within a module, I appear to get two copies of the variable - one version for within the module, another when accessed outside the module.

The problem occurs if the array within the type has >= 256 entries - set it to 255 and it works as expected. It's only a problem in Win32 release and debug builds - it works as expected in checkmate and .NET builds.

The example below shows the problem - when run in win32 debug and I get different results depending on how I access tester%nchains. Also if you look at loc(tester) it's different inside and outside the TestMod module.

Any insight or a fix would be greatly appreciated.

Alan

! Demonstrates multiple instantiation of type within module
module TestMod
  type TestType
    integer:: nchains = 0
    integer:: holes(256)     ! we get two testers if array size >= 256
  end type
  type(TestType):: tester
contains

  ! Setup a test value in tester
  subroutine SetupTest()
    tester%nchains = 42
  end subroutine SetupTest

  ! Return location of tester as seen by TestMod
  integer function GetTest()
    GetTest = tester%nchains
  end function GetTest
end module TestMod

program Test
  use TestMod
  integer:: l1, l2
  
  ! Setup tester - nchains set to 42
  call SetupTest()

  ! Get nchains from tester - can also comes LOC(tester)
  l1 = GetTest()             ! returns 42
  l2 = tester%nchains        ! returns 0 if holes array size >= 256

  ! Output the values - THEY DON'T MATCH IF HOLES ARRAY SIZE >= 256
  print *, l1, l2
  if (l1 /= l2) print *, 'testers are not the same !!'
end program

Has anyone looked into this apparent regression yet? Thanks, Alan

I have now located the regression as from version 5.20. It only occurs if you use an initial value within the TYPE declaration. We will aim to fix this for the next release.

Paul,

Are there any other implications of this? Does it only happen with statically sized arrays - not allocatable or any other non-array types, or is it down to the size of the type itself. I've noticed in my main program the size has to be smaller than 256 so I guess it appears on a limit on the size of the adt when using initialisers ?

Is there likely to be an interim 5.31 release soonish?

Thanks.

Alan

I have not fixed the bug yet. Only located it. On its own it probably would not warrant a new general release but I may be able to get a special build to you.

I do not know all of the implications. However, the problem is limited to MODULEs, where the size of the TYPE is greater than 1024 and the TYPE contains initial values.

Paul

Paul,

I have a lot of type structures in a module which match all those attributes, so I would be interested in how general this bug might be. Please let us know the extent of this problem when you know more.

John

I don't think that one can be more specific than saying all of these apply....

1. Checking mode off (/CHECK, and anything that implies it, not used)
2. TYPE definition is in a MODULE
3. TYPE definition contains initialisers.
4. An instance of the TYPE has size greater than 1024.

If you have all of these then you will get the regression.

Hence a work-around is to avoid initialisers or use /check for now.

Removing CONTAINS appears to fix the problem.

! Demonstrates multiple instantiation of type within module 
module TestMod 
  type TestType 
    integer:: nchains = 0 
    integer:: holes(22256)     ! we get two testers if array size >= 256 
  end type 
  type(TestType):: tester 
end module TestMod 

program Test 
  use TestMod 
  integer:: l1, l2 , GetTest
  external GetTest
  
! Setup tester - nchains set to 42 
  call SetupTest() 

! Get nchains from tester - can also comes LOC(tester) 
  l1 = GetTest()             ! returns 42 
  l2 = tester%nchains        ! returns 0 if holes array size >= 256 

! Output the values - THEY DON'T MATCH IF HOLES ARRAY SIZE >= 256 
  print *, l1, l2 
  if (l1 /= l2) print *, 'testers are not the same !!' 
end program

! Setup a test value in tester 
  subroutine SetupTest() 
  use TestMod 
!    tester%nchains = 42 
    tester%nchains = size (tester%holes)
  end subroutine SetupTest 

! Return location of tester as seen by TestMod 
  integer function GetTest() 
  use TestMod 
    GetTest = tester%nchains 
  end function GetTest 

This bug has now been fixed. It turned out that it was not a regression in the sense that the initialisation was not working anyway. A previous bug fix simply highlighted the current bug and this has now been fixed for the next release.