| View previous topic :: View next topic |
| Author |
Message |
acw
Joined: 04 Nov 2005
Posts: 165
Location: Darkest Devon
|
 Posted: Thu Apr 30, 2009 3:01 pm Post subject: 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
| Code: | ! 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 |
|
|
| Back to top |
|
 |
acw
Joined: 04 Nov 2005
Posts: 165
Location: Darkest Devon
|
| Posted: Tue May 12, 2009 10:44 am Post subject: |
|
|
Has anyone looked into this apparent regression yet?
Thanks,
Alan |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed May 13, 2009 8:26 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
acw
Joined: 04 Nov 2005
Posts: 165
Location: Darkest Devon
|
| Posted: Wed May 13, 2009 8:31 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed May 13, 2009 11:24 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Wed May 13, 2009 12:56 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed May 13, 2009 3:03 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Thu May 14, 2009 3:33 am Post subject: |
|
|
Removing CONTAINS appears to fix the problem.
| Code: |
! 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
|
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Mon May 18, 2009 1:01 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
