View previous topic :: View next topic |
Author |
Message |
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Thu Oct 06, 2016 12:37 pm Post subject: Severe Bug with EQUIVALENCE |
|
|
The following code is working fine if compiled with 32-bit FTN95 version.
Code: | MODULE XXX
:
INTEGER, PARAMETER :: LENAMBUF = 50000
:
REAL*8 APF (LENAMBUF/2-1) and indices
INTEGER IPF (2,LENAMBUF/2-1)
EQUIVALENCE (APF(1), IPF(1,1))
:
END MODULE XXX
!------------------------------------------------------
Subroutine YYY
USE XXX
:
IPF (1,IPI+1) = iType
IPF (2,IPI+1) = No1
IPF (1,IPI+2) = No2
IPF (2,IPI+2) = No3
IPF (1,IPI+3) = No4
IPF (2,IPI+3) = nCoefficients
APF (IPI+4) = ObservationL
APF (IPI+5) = ObservLzero
APF (IPI+6) = WeightP
:
Write APF to disk
:
END Subroutine YYY
!------------------------------------------------------
Subroutine ZZZ
USE XXX
:
Read APF from disk
:
iObservType = IPF (1,IPI+1)
No1 = IPF (2,IPI+1)
No2 = IPF (1,IPI+2)
No3 = IPF (2,IPI+2)
No4 = IPF (1,IPI+3)
nCoefficients = IPF (2,IPI+3)
ObservationL = APF (IPI+4)
ObservLzero = APF (IPI+5)
WeightP = APF (IPI+6)
:
END Subroutine ZZZ
|
Copiling with /64 option it goes completele wrong. I cannot get my data back.
If I remove the APF / IPF part from Module XXX and introduce the following COMMON in all related Subroutines, everything is working correct in 32-bit and in 64-bit versions.
Code: | REAL*8 APF (50000/2-1)
INTEGER IPF (2,50000/2-1)
EQUIVALENCE (APF(1), IPF(1,1))
COMMON /AMBUF/ APF
|
My only explanation is that EQUIVALENCE is not working.
Please see as well my last post in section General. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Thu Oct 06, 2016 1:36 pm Post subject: |
|
|
Thank you for the feedback. I have logged this as needing attention. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Thu Oct 06, 2016 2:10 pm Post subject: |
|
|
Unfortunately I cannot continue development with FTN95 /64 as long as there is this bug.
Is there a perspective to get this solved soon? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Thu Oct 06, 2016 2:30 pm Post subject: |
|
|
Erwin,
I thought EQUIVALENCE is not allowed in a MODULE in F90 or F95 ?
It is a structure for local or COMMON arrays only.
The Lahey F95 manual I have also requires:
"If an equivalence-object is of an intrinsic type other than default INTEGER, default REAL, double precision REAL, default COMPLEX, default LOGICAL, or default CHARACTER, all of the objects in equivalence-set must be of the same type with the same kind value."
This sounds a bit restrictive, as I have certainly mixed kind values for non default types.
I typically EQUIVALENCE real*8 and integer*4 arrays in COMMON, without any problems for 32-bit or 64-bit. I am not sure of the example you have provided.
John
Last edited by JohnCampbell on Thu Oct 06, 2016 2:44 pm; edited 1 time in total |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Thu Oct 06, 2016 2:43 pm Post subject: |
|
|
John,
do you know any documentation about this?
I'm using this since long time.
Erwin |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Thu Oct 06, 2016 3:06 pm Post subject: |
|
|
Section 5.5.1 of F95 standard excludes "an automatic object" and "a structure component".
An earlier example you gave was an automatic object.
I am not sure if a structure component excludes a component of a MODULE ?
Note 11.8 in Section 11.3.2 excludes the use of a local name in a USE statement from appearing in EQUIVALENCE.
You are wanting to equivalence two specification statements in a MODULE. I can't find a comment on this, although in general you can't assume any order in a MODULE, or if the specified components are ordered.
I have never used EQUIVALENCE in a MODULE.
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Thu Oct 06, 2016 3:43 pm Post subject: |
|
|
Erwin
I am not able to promise a quick fix but it would be a great help if you could post a short working program that works in 32 bit mode and illustrates the problem. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Fri Oct 07, 2016 12:37 am Post subject: |
|
|
Paul,
I reproduced a test which I thought failed years ago with /32, but it now appears to work ? ( ftn95 test.f90 /link /map ) The .exe is huge.
It does however fail with /64 ( ftn95 test.f90 /64 /link /map ) Code: | ! Last change: JDC 11 Feb 2002 10:18 pm
! INCLUDE 'sapmem.ins' working storage definition
!
module sapmem
integer*4, parameter :: one_mb_8 = 1024*1024/8
!z INTEGER*4, PARAMETER :: MXTOT = 1300*one_mb_8 ! working storage size R*8
INTEGER*4, PARAMETER :: MXTOT = 130*one_mb_8 ! working storage size R*8
INTEGER*4, PARAMETER :: M4TOT = MXTOT*2 ! working storage size I*4
!
!z COMMON /SAPCM1/ MTOT, P_END
INTEGER*4 MTOT, P_END
!
!z COMMON /SAPCM9/ AABASE
REAL*8 AABASE(MXTOT)
INTEGER*4 IIBASE(M4TOT)
EQUIVALENCE (AABASE,IIBASE)
!
end module sapmem
use sapmem
integer*4 ii
!
write (*,*) 'aabase at',loc (aabase)
write (*,*) 'iibase at',loc (iibase)
do ii = 1,mxtot
aabase(ii) = ii
end do
end |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Fri Oct 07, 2016 7:51 am Post subject: |
|
|
Thanks John.
A preliminary investigation may lead to a work-around.
Any fix would probably require a full release or a full intermediate release. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Fri Oct 07, 2016 7:53 am Post subject: |
|
|
Paul,
I have isolated the problem, but I cannot place it in the forum.
May I send it to your personnel email address?
John,
using COMMON areas in combination with EQUIVALENCE I have correct results in 32- and in 64-bit versions.
However, I do not use COMMON at all anymore, because it cannot hold dynamic arrays and cannot be included in DLLs. I am not sure about the memory usage; stack ...
Erwin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Oct 10, 2016 8:21 am Post subject: |
|
|
Erwin
This bug appears to arise when LENAMBUF/2-1 is an odd number.
So a temporary work-around would be to use:
Code: | INTEGER, PARAMETER :: LENAMBUF = 50000
REAL*8 APF (LENAMBUF/2)
INTEGER IPF (2,LENAMBUF/2) |
I will report this as a bug that needs fixing.
The results for 32 bit and 64 bit mode diverge at a late point in the calculations but I am assuming that this is a different issue. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Mon Oct 17, 2016 10:33 am Post subject: |
|
|
Paul,
back in the office I tested the program with a even number. However, I cannot see any difference !?
Erwin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Oct 17, 2016 1:02 pm Post subject: |
|
|
Erwin
It failed for me with an odd value and worked OK with an even value.
This makes some sense if it is an alignment issue but there may still be a random element.
Are you sure that the code that you sent to me fails with an even value for N in IPF (2,N)? |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Mon Oct 17, 2016 3:10 pm Post subject: |
|
|
Paul,
I tried again and I am really sure that the even number did not make any difference.
As well I don't understand why in 64-bit version only the last record will be read.
Erwin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Thu Jan 26, 2017 12:52 pm Post subject: |
|
|
Erwin
My test program for this issue now works correctly.
After the next full release, please let me know if this problem remains. |
|
Back to top |
|
|
|