|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Mon Nov 14, 2016 4:47 pm Post subject: Compiler bug with /64 and /defint_kind 4 |
|
|
My modular program system (about 600 routines) works fine with the 32-bit version of FTN95.
In case of the 64-bit version (FTN95 compiler options: /64 /defint_kind 4) the results are completely wrong! An erroneous 64-bit execution could be localized and extracted in a small test program:
Silverfrost FTN95/WIN32 Ver 8.05.0 test-error.F90 Mon Nov 14 13:22:11 2016
Compiler Options in Effect:
64 COLOUR DEBUG DEFINT_KIND 4 DEFREAL_KIND 2 DELETE_OBJ_ON_ERROR LINK LIST
MINIMISE_REBUILD NO_QUIT NON_STANDARD SINGLE_THREADED
0001 program test
0002 integer, allocatable, dimension(:,:) :: iplate ! array for special plate type
0003 mxplate = 19
0004 ntypm = 4
0005 allocate(iplate(mxplate,0:ntypm))
0006 iplate = 0
0007
0008 iplate(10,2) = 2
0009
0010 write (6,*) 'Result: '
0011 write (6,*) 'Array iplate:'
0012 do j=0,ntypm
0013 write(6,'(20I3)') (iplate(i,j),i=1,mxplate)
0014 end do
0015
0016 write (6,*) 'Bit-size of iplate:', bit_size(iplate)
0017 write (6,*) ' '
0018 end
Result of test:
Array iplate:
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
Bit-size of iplate: 64
Instead of a single value at position (10,2), the entire column is filled with 2. In my opinion a compiler bug!
Remark: These small test program works fine with the 32-bit version and the 64-bit version with "integer*8, allocatable, dimension(:,:) :: iplate" (at line 2 of the code) instead of the compiler option /defint_kind 4.
Thanks
Wolfgang |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Nov 14, 2016 5:12 pm Post subject: |
|
|
Wolfgang
The problem with "/defint_kind 4" is a known issue that has not yet been fixed.
For the time being, it is necessary to avoid this option and to use integer(7) or integer(4) locally where necessary.
In other words, don't change all integers to 64 bits but only change those that have to be changed. |
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Thu Dec 28, 2017 6:34 pm Post subject: |
|
|
Is the /DEFINT_KIND 4 issue still outstanding? I have been trying to use UBOUND and LEN as subroutine arguments, and I saw from another post somewhere that some intrinsic functions are still defaulting to KIND=3 rather than 4, which would explain a compilation error message about wrong KIND. I can use UBOUND with a specified KIND parameter as a work-around, but that does not appear to be an option for LEN. I could use Int(Len(c), Kind=4), I suppose, but I was wondering what was the status of these two issues. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Thu Dec 28, 2017 10:02 pm Post subject: |
|
|
Some of the problems with /DEFINT_KIND 4 have been fixed but it is probably not a good idea to use it anyway. Why use 64 bit integers globally? Why not just use them where needed?
Having said that, if you are able to report problems one at a time, illuatrated by a few lines of sample code, then we can progress through any remaining issues. In particular, do you have a few lines of code that illustrates the problem with UBOUND? Also what version of FTN95 are you using? |
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Fri Dec 29, 2017 5:32 am Post subject: |
|
|
Here's some examples that generate a compile-time error using CheckMate x64:
Code: | Winapp
Program p1
Integer :: iw
Character(Len=16) :: c = 'ABCDEFGHIJKLMNOP'
! Len
iw = winio$('%*ws', Len(c), c)
End Program p1 |
and
Code: | Program p2
Integer, Dimension(2) :: a
! Ubound
Call s (Ubound(a))
!
Contains
!
Subroutine s (i)
Integer, Intent(In) :: i
End Subroutine s
!
End Program p2 |
I am using version 8.20. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Fri Dec 29, 2017 4:47 pm Post subject: |
|
|
“Why use 64 bit integers globally? Why not just use them where needed? “
Apart from the obvious riposte: “Why not?”, there is a traditional precedent,
which was that INTEGERs and the default REAL both had the same length. From the perspective of a programmer for whom programming is a sideline, not a main business, it is helpful if all integers have the same length, and you don’t need to check a range of overflow conditions.
On the other hand, INTEGER*8 is extremely wasteful of space for many purposes, and INTEGER*4 not much better. Take for example WINIO@. This function probably never returns other than 0, 1 or 2. Why does it have to be an INTEGER*4 function?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Dec 29, 2017 6:07 pm Post subject: |
|
|
Simon
Code: | iw = winio$('%*ws', Len(c), c) |
There are a number of different issues here that we need to fix.
In the meantime you will need to convert the KIND of LEN(c) as, for example, INT(LEN(c),3). |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Dec 29, 2017 6:22 pm Post subject: |
|
|
Simon
Again there are a number of issues here that need fixing.
In both these samples the problems are not primarily related to /DEFINT_KIND.
A work-around is to use s(int(Ubound(a),3)). |
|
Back to top |
|
|
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Thu Apr 05, 2018 2:23 pm Post subject: |
|
|
„Compiler problems with 64 bit integers (here globally and non-globally)“
I have got some of old programs with integer arrays containing characters. The program system works fine with 32 bit integers.
In case of 64 bit integers (globally and non-globally), the printouts are incorrectly (no characters in both printouts). Using compiler options: /64 & /DEFINT_KIND 4 (original program, test code (see below)) or only /64 (test code; here code with “integer*8”). I am using version 8.10.
Wolfgang
Code: |
program test
implicit none
integer :: ifeld
character*4 :: ct='U235'
!
read (ct,'(a4)') ifeld
! print should be:U235
write(*,'(a4)') ifeld
!
end |
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Apr 07, 2018 3:34 am Post subject: |
|
|
It looks to be a problem writing an I*8 using A4. See the further test: Code: | program test
implicit none
integer*8 :: ifeld
integer*4 :: iostat
character*4 :: ct='U235'
!
read (ct,'(a4)',iostat=iostat) ifeld
write (*,*) 'read test :',ifeld, ' iostat=',iostat
! print should be:U235
write(*,'(a,a4)') 'a4 test :',ifeld
write(*,'(a,a8)') 'a8 test :',ifeld
call test_i4 (ifeld)
!
end
subroutine test_i4 (i4)
integer*4 i4(2)
write (*,*) 'write as 2 x A4'
write (*,'(a4)') i4(1)
write (*,'(a4)') i4(2)
end |
|
|
Back to top |
|
|
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Sun Apr 08, 2018 9:04 am Post subject: |
|
|
John,
thanks for your support!
It is not a question of using A4! Integer*8 in combination with A8 for read & write is also incorrect (at least with version 8.10PE). |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Apr 08, 2018 9:17 am Post subject: |
|
|
This is the principal problem with your code: Reading or writing a variable using a format specification that is meant for use with another type. The F95 standard says:
Quote: | 10.5.3 Character editing
The A[w] edit descriptor is used with an input/output list item of type character. |
Your code uses I/O list items of type integer with the Aw format.
This is not allowed in Standard Fortran, and the behavior of non-conforming code is "undefined" unless a vendor defines and implements the behavior of such code as an extension. In your case, some compilers may have given you results that you liked, but you cannot count on future versions of the compiler or other compilers to continue to behave in a certain way. Your program, with INTEGER*4 or INTEGER*8, when run with the NAG compiler, gives this error:
Quote: | Runtime Error: Invalid edit descriptor for integer i/o-list item
Program terminated by I/O error on internal file
wfg.f90, line 6: Error occurred in TEST |
Compilers are not required by the standard to catch errors of this type, but a compiler can win popularity by doing so.
I appreciate the need for extensions when there is something to be done that cannot be done (or done conveniently) by using only means provided by the standard. In the present instance, I do not see that necessity.
I also appreciate that with a large old program the work of fixing the code can involve much effort. Knowing that there is a need for fixing and not taking steps to do so is, in US English, "kicking the can down the road". |
|
Back to top |
|
|
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Sun Apr 08, 2018 1:27 pm Post subject: |
|
|
I can accept your comments if the compiler strictly adheres to the F95 standard. But that's not the case, the 32 bit version works correctly with 32 bit integer in combination with "a4" format for in- and output. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Apr 08, 2018 1:57 pm Post subject: |
|
|
The standard can be hard to read and, until one gets used to "standardese", the terminology can be confusing -- I know, I ran into the same problems years ago.
We can group the rules of the standard into two classes. A small number, called "constraints", specify actions that a "processor", i.e., a compiler+runtime, is required to satisfy. All other requirements are the responsibility of the programmer. Except for those aspects that are covered by "constraints", a compiler is not required to do anything regarding programs that are not standard-conforming.
The mismatch of format data editing specifications (such as A4) to items in the I/O list is not subject to any constraints. A compiler is not required to catch such errors or issue warnings for such mismatches. Not doing these things does not make the compiler "non-95 compliant".
We can certainly ask Silverfrost to consider modifying their compiler to catch these errors in the way that, e.g., the NAG compiler did. That is a "quality of implementation" issue, not a standards-compliance issue.
Quote: | the 32 bit version works correctly with 32 bit integer in combination with "a4" format for in- and output |
The notion "works correctly" is not defined in this case. You and I could have different expectations of "works correctly". If you assume that variables in the I/O list are simply individual addresses of boxes from which bytes are taken, formatted and output, your position is correct. However, there are many other ways of doing I/O and, in some of them, the output would be different or the program would crash.
The Lahey ELF90 compiler outputs 235 with your program, leaving out the "U". |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Apr 09, 2018 11:05 am Post subject: |
|
|
This failure has now been fixed and is available in a new set of DLLs found here...
http://forums.silverfrost.com/viewtopic.php?p=24467#24467
These are for v8.30 but may work for v8.10 and v8.20. Please create a backup of the DLLs before installing. |
|
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
|