|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Tue Oct 29, 2019 11:16 am Post subject: 32bit compiler error |
|
|
Internal compiler error in regular 32bit mode but OK with /64. Compiled as shown below
Code: | !!! 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 |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Oct 29, 2019 5:45 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Oct 31, 2019 8:07 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 31, 2019 11:48 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Nov 07, 2019 11:49 am Post subject: |
|
|
The 64 bit bug that was outstanding on this thread has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
|
|
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
|