forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Severe Bug with EQUIVALENCE

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Thu Oct 06, 2016 12:37 pm    Post subject: Severe Bug with EQUIVALENCE Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Oct 06, 2016 1:36 pm    Post subject: Reply with quote

Thank you for the feedback. I have logged this as needing attention.
Back to top
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Thu Oct 06, 2016 2:10 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Oct 06, 2016 2:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Thu Oct 06, 2016 2:43 pm    Post subject: Reply with quote

John,
do you know any documentation about this?
I'm using this since long time.
Erwin
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Oct 06, 2016 3:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Oct 06, 2016 3:43 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Oct 07, 2016 12:37 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Oct 07, 2016 7:51 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Fri Oct 07, 2016 7:53 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Oct 10, 2016 8:21 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Mon Oct 17, 2016 10:33 am    Post subject: Reply with quote

Paul,
back in the office I tested the program with a even number. However, I cannot see any difference !?
Erwin
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Oct 17, 2016 1:02 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
EKruck



Joined: 09 Jan 2010
Posts: 224
Location: Aalen, Germany

PostPosted: Mon Oct 17, 2016 3:10 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Jan 26, 2017 12:52 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group