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 

Compiler bug with /64 and /defint_kind 4
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
wfgybgl



Joined: 28 Oct 2016
Posts: 8
Location: Bergisch Gladbach

PostPosted: Mon Nov 14, 2016 4:47 pm    Post subject: Compiler bug with /64 and /defint_kind 4 Reply with quote

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


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

PostPosted: Mon Nov 14, 2016 5:12 pm    Post subject: Reply with quote

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



Joined: 05 Jul 2006
Posts: 268

PostPosted: Thu Dec 28, 2017 6:34 pm    Post subject: Reply with quote

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


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

PostPosted: Thu Dec 28, 2017 10:02 pm    Post subject: Reply with quote

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



Joined: 05 Jul 2006
Posts: 268

PostPosted: Fri Dec 29, 2017 5:32 am    Post subject: Reply with quote

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



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Dec 29, 2017 4:47 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Dec 29, 2017 6:07 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Dec 29, 2017 6:22 pm    Post subject: Reply with quote

Simon

Code:
Call s (Ubound(a))


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



Joined: 28 Oct 2016
Posts: 8
Location: Bergisch Gladbach

PostPosted: Thu Apr 05, 2018 2:23 pm    Post subject: Reply with quote

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



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat Apr 07, 2018 3:34 am    Post subject: Reply with quote

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



Joined: 28 Oct 2016
Posts: 8
Location: Bergisch Gladbach

PostPosted: Sun Apr 08, 2018 9:04 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sun Apr 08, 2018 9:17 am    Post subject: Reply with quote

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



Joined: 28 Oct 2016
Posts: 8
Location: Bergisch Gladbach

PostPosted: Sun Apr 08, 2018 1:27 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sun Apr 08, 2018 1:57 pm    Post subject: Reply with quote

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


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

PostPosted: Mon Apr 09, 2018 11:05 am    Post subject: Reply with quote

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
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
Goto page 1, 2  Next
Page 1 of 2

 
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