CODEWITHSUNDEEP
fortran
ftiaronsem
ftiaronsem

Reputation: 1584

unexpected behavior in ifort 15

I just encountered the following in ifort (IFORT) 15.0.0 2014072

program integerkinds
  use iso_fortran_env
  implicit none

  integer(kind=selected_int_kind(15)):: j15

  print *,'Selected Integer Kind 15:'
  print *, huge(j15)
  print *, int(huge(j15))
  print *, int(huge(j15),kind=selected_int_kind(15))

end program integerkinds

for which the output is

 Selected Integer Kind 15:
   9223372036854775807
          -1
   9223372036854775807

shouldn't the compiler automatically choose the correct return type based on int()'s argument? This unexpected behavior has just cost me about 2500 hours of computing time on our cluster :(

The documentation states (http://nf.nci.org.au/facilities/software/intel_fortran_reference.pdf at page 9-80):

Argument Type                                        Result Type
INTEGER(1), INTEGER(2), INTEGER(4)                   INTEGER(4) 
INTEGER(1), INTEGER(2), INTEGER(4), INTEGER(8)       INTEGER(8)

According to this table Integer(8) as argument should give Integer(8) as result type, but the output gives -1. Looks like a bug to me, but I wanted to get a second pair of eyes on this before I go and bug the intel developers. Is there something in the standard that I am overlooking that mandates a -1 as return value here?

Upvotes: 1

Views: 2240

Answers (1)

IanH
IanH

Reputation: 21431

No. That table is wrong or misleading (the multiple rows, which otherwise make no sense, may possibly reflect variation in behaviour given some compatibility option, but if so I'm not aware of what option it is). In standard Fortran, the kind of the result of the INT generic intrinsic only depends on the presence and value of the KIND argument. If the KIND argument is not present then the result has default integer kind, otherwise the KIND argument specifies the KIND of the result.

The value of the argument to the second invocation of INT in your example program cannot be represented in a default integer for that compiler, in the absence of compile options that change the default integer kind. Your code is non-conforming.

While the text has not changed materially (apart from perhaps becoming more confusing) I note that the documentation that you link to is ancient.

Upvotes: 5

Related Questions