Bug in 8.3 64bit using Strict Iso /ISO

Unfortunately use of /ISO in the 64 bit compile also changes the default integer kind to 4 (it is 3 without /ISO).

This means the following code won't compile even though it is standard (ISO/ANSI) conforming:

program main
   integer istatus
   print *, 'default integer kind is =', kind(istatus)
   open(10,file='test.txt', iostat=istatus)
   write(10,'('Hello World')')
   close(10)
end program main

You get the following error, even though istatus is a scaler, default-kind integer:

error 259 - Scalar, default-kind, INTEGER variable expected for the IOSTAT keyword

Thank you for the feedback. This was totally unexpected. It relates to very old code in FTN95 (the code is present in v4.9). The change to kind=4 for /iso has now been removed and the false error report for IOSTAT has also been fixed. These changes will be in the next release of FTN95.

Thanks Paul.

I never really understood why you wanted to change the default integer kind to 4 in 64 bit mode. Perhaps it was to support non-standard wider pointers but users who need this could just have declared using kind=4 explicitly.

Use of iostat=i should work when i is a default integer (declared as integer i). Ideally the compiler should also cope with cases where the user changes the default integer type to 4 (or any integer kind which is large enough to store the codes). I am happy that it works with a default integer kind of 3.

But I am digressing.

I have found some more issues with v 8.3, which refuses to run my ISO compliant codes (unlike 7.2, 8.05 which will run). However, I am struggling to put together a simple illustration. I will post again when I know more.

Quoted from davidb I never really understood why you wanted to change the default integer kind to 4 in 64 bit mode.

I am of the opposite view. Shouldn't the default integer kind be able to address the memory being used. We had integer2 for 16-bit, integer4 for 32-bit so integer8 for 64-bit. Admittedly, if the default integer was changed, it would have caused a lot more problems for moving between 32 and 64-bit versions of code, but more general use of integer8 is coming. Certainly the Fortran Standard requirement for default integer, real and double precision needs more thought. Should we insist on having 16-byte reals in a 64-bit compiler. I think SIZE is a good example of being on both sides of the fence. There is definitely a conflict between useability and code compliance. I think the standard syntax for SIZE in a 64-bit environment needs rethinking. There is certainly a greater need for checking the kind of integer being selected/used in 64-bit code.

John