Different behavior concerning READF@

Hi all,

I'm trying to port an old Salford code from 32-bit to 64-bit. I encountered a problem with READF@. In the 32-bit version, READF@ also reads ASCII data correctly. In the 64-bit version, however, I get an error code 998.

I know I could change it to READFA@, but I want to understand why the same code works differently.

Currently I'm using FTN95/x64 Ver. 8.90.0

dgurok

Can you post or send me a sample program that illustrates the difference?

      PROGRAM TEST
C      
      CHARACTER TXTDUM*32000
      CHARACTER*256 TXTFIL
      INTEGER*2 HWND, IERR
      INTEGER*4 NB, NBR
C      
      NB=80
      TXTFIL='MOD.txt'
      CALL OPENR@(TXTFIL,HWND,IERR)
      WRITE(*,*) 'OPENR, IERR ', IERR
C      
      CALL READF@(TXTDUM,HWND,NB,NBR,IERR)
      WRITE(*,*) 'READF, IERR ', IERR
      WRITE(*,*) 'TXTDUM(1:80): ', TXTDUM(1:NB)
C      
      CALL CLOSEF@(HWND,IERR)
      WRITE(*,*) 'CLOSEF, IERR ', IERR
C      
      END

Result

 32-bit
 OPENR, IERR            0
 READF, IERR            0
 TXTDUM(1:80): #001     0.000     0.000  1024.187  1000.000     1000.    0.0    0.0    0.0   Li
 CLOSEF, IERR            0
 
 64-bit
 OPENR, IERR            0
 READF, IERR          998
 TXTDUM(1:80):
 CLOSEF, IERR            0 

I took the line of data from your 32-bit example to generate MOD.txt ( as a text file )

Using PLATO with x64, (/64) I can reproduce your error with 'Release' or 'Debug', with error 998.

However with 'CheckMate', I get error 0, as for 32-bit.

For Win32, all compile options show no error.

I am not sure what error number 998 refers to ? ( can't find it in FTN95.chm)

The documentation for READF@ does say 'This routine should be used on binary data.'

998 translates to 'Invalid access to memory location'.

The failure can be fixed in our build for clearwin64.dll by downgrading the Microsoft optimisation of the code for the file containing this routine.

I can provide a replacement DLL but it will be post v9.00 of FTN95 so that might be problematic.

Thanks Paul,

That would certainly help us if we push forward with our Salford 64-bit port next year, as there are other internal technical problems that need to be solved too 😃

dgurok

Would you like me to send you new DLLs?

They will probably be compatible with your current FTN95 but you will need to proceed carefully and re-instate these new DLLs after upgrading to FTN95 v9.0.

That sounds great. You can send me the download link via PM if you like.

I will then report how the change affects our port.

Thanks Paul for the new DLLs.

I did a quick test and so far I'm not having any problems reading and writing files in the way we process our data.

Quoted from PaulLaidler The failure can be fixed in our build for clearwin64.dll by downgrading the Microsoft optimisation of the code for the file containing this routine.

Interesting problem ! Is this an error in a Microsoft compiler due to inappropriate optimision ?

John

I don't know why changing the level of optimisation fixes the problem. I guess that I could have changed the code line by line in an attempt to localise the fault but it's only one file and a small number of routines so there is unlikely to be a significant change in performance.