32bit compiler error

Internal compiler error in regular 32bit mode but OK with /64. Compiled as shown below

!!! ftn95 a.f95  /link /debug /undef /check >result
module AllSubs
integer n
character (Len=1)  :: bufRead (88) 
equivalence (x,bufRead(1:8))

contains
integer function ReadingCurrDir ()
  n = 1
ReadingCurrDir = 2
end function

end module AllSubs
!.....................................
Program h5toText
use AllSubs
  aaa = 1
end

You can get around this problem by explicitly declaring x as DOUBLE PRECISION. If it is declared implicitly as single precision then it will not occupy the same space as bufRead(1:8).

I don't know if this equivalence is valid Fortran. gFortran doesn't like it.

I will make a note that this needs investigating.

This bug has now been fixed for the next release of FTN95 but at the moment only for 32 bit code.

The same bug occurs for 64 bit code but in this case there is also another bug that remains outstanding.

This equivalence runs very fast converting binary data from any other sources into also binary but the ones FTN95 can read and understand. You just read some file instead of this standard (but incompatible) and slow way

open(unit=19,file=filetoread, STATUS='old', FORM='UNFORMATTED', err=900) read (19) x,y,z,a,b,c,d,e,f,g,i close(19)

this way

real*8 x,y,z,a,b,c,d,e,f,g equivalence (x,bufRead(1:eight)) equivalence (y,bufRead(9:16)) equivalence (z,bufRead(17:24)) .................... equivalence (i,bufRead(81:84))

call openr@(filetoread, ihndl, ierrcode) call readf@(bufRead, ihndl, nbytes, nread, ierrcode) call closef@(ihndl, ierrcode)

where bufRead(84) is character*1 in my case nbytes=84 bytes long or many megabytes long. And the equivalence statement converts all read data automatically. This way with large nbytes the read speed can reach the limit the OS and file system can provide 4 GB/s on the RAMdrives.

By the way HDF5 works similar way (in the cached by OS file system space which often is in the RAM) why it is so fast. Some Fortran compilers and of course MARLAB provide binding to HDF5 library. Reading from any place, writing and appending to large GB size files in this case resembles bullet speed - literally in no time, like 0.1 second and all is done. Some other C and Fortran compilers, including the ones HDF Group compiled its own tools for HDF5 (h5dump for example) do ASCII input/output 500x and binary 100x slower (only 2 and 8 megabytes per second) ! I just registered in their forums to laugh on them and suggested to change the compilers. May be they will help to make HDF5 library available specifically for FTN95

The 64 bit bug that was outstanding on this thread has now been fixed for the next release of FTN95.