Problem with compiler option

Now you are confusing me!

/alt_kinds should be working correctly from version 5.40 of FTN95.

selected_x_kind gives the default values (i.e. it does not respond to /alt_kinds).

I can make selected_x_kind sensitive to /alt_kinds and this would seem sensible although it may never be used in this context.

Hi:

/ALT_KINDS work correctly now in v 5.40, at least with real declarations (but see below). Probably selected_real_kinds should reflect that option too, so as kind = selected_real_kind() works always the same, but I agree that is an uncommon case to find that construct together with /ALT_KINDS

Now, I discovered one problem with v 5.40, at least that downloaded from Mediafire: It works OK on 32 bits WinXP, but on 64 bits XP crashes at the end of compilation leaving a 0 bytes .obj file, with the following messages (from Plato):

Compiling file: DEMO95.F90 Access violation: The instruction at address 00538dfe attempted to write to location 7fff0000 00538da8 allocate_constant_entity(<ptr>structￄconstant_entity) [+0056]

005355e6 inst_memref(void) [+0373]

00535f3b send_instruction(<ptr>structￄpending_instruction) [+1a9b]

0053500f complete_emit(void) [+0250]

00534bb5 emitr(enumￄmachine_instruction,enumￄcpu_register) [+002a]

0047a60d do_function_top(<ptr>structￄtree_record) [+0603]

0051e1aa code_generator(<ref>structￄtree_ptr) [+2022]

00416e11 end_function(int) [+10f0]

eax=7fff0000 ebx=005c1bd4 ecx=00000004 edx=00000000 esi=08ad6080 edi=7fff0000 ebp=0384f2d0 esp=0384f2ac IOPL=0 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210206 [NC EP NZ SN DN NV] 0360/5820 TSTK=3 [ ] 00538dfe rep

00538dff movsb

Note that this happened compiling DEMOF95.F90, all default options. This is strange, because 5.30 worked well in both platforms.

Paul,

Sorry about the confusion. We previously discussed /alt_kind in Feb-07. At that time I was finding problems with it's use. I am yet to download Ver 5.40, but have recently noted that Ver 5.30 does not work. ( I always wait a while to see what others find. I've only just stoped running Ver 4.9 as a backup check of Ver 5.3 )

My apologies as I should have read the Ver 5.40 release notes that mentions /alt_kind.

Based on my post last night, could you consider an extension to FTN95 to support an extended set of kind values; for Real and Complex, always include 4, 8 and 10 as valid values for Integer, include 8 for Logical, include 4

The only problem came about when INTEGER8 was introduced, which I recall as recent ! For Integers, when kind=4, or nn_4 is used, then the compiler should issue a warning about ambiguity or non-portability. I must admit that this could get messy, as '1234_n' is valid and when n=4 can be a 64 bit or 32 bit value, depending on /alt_kind. Infortunately, I think the only way to provide an integer8 constant is using this number format. If n has been derived from selected_int_kind then a warning would be misleading.

Back on the introduction of KIND Back in the 70's and 80's I did a lot of work on converting programs of unknown origin to Prime, Vax and PC. Control Data was fairly common to me, but there were a few English computers with wierd precision which always caused a lot of problems. Does anyone remember IBM fortran? What a nightmare! Practical Fortran 4 and Fortran 77 programs always mixed integer, real and character/hollerith in the same memory locations. It was increadibly frustrating that realn and integer4 was not enforced, as this was the clearest and most concise way of describing the precision of variable declarations, especially reals. I wonder how much experience in fortran programming some of the members of the standards comittee had. They certainly keep introducing program constructs that I, as a fortran programmer, do not use!

John

Regarding SELECTED_REAL_KIND, I only know of one package (Ronald Cools' cubpack.f90) which uses it. We use the numerical recipies in Fortran and even here SELECTED_REAL_KIND is not used. Instead the following is used: INTEGER, PARAMETER :: SP = KIND(1.0) REAL(SP) :: a

John

Sorry but I will not be able to provide support for both kinds simultaneously although with the present compiler you can do it on a file by file basis.

There are three reasons for this

1. We need to keep things simple (the KISS principle) for everyones sake.
2. Programming the compiler for this would not be straight forward.
3. There is already an overlap and this may increase with future developments.

Paul

John C,

Those English computers with wierd precisions, always used 24 bit words, which meant that a REAL was 48 bits. UK programmers could get FE software to work in single precision. Equivalent US computers (except for CDC) got to 30, 32 or 36 bit REALs - nowhere near good enough for much FE work, and much more variable than machines of UK origin!

e.g. Elliot/NCR 4120/4130 - 24 bit ICL 1900 series - 24 bit ICL 2900 series - same Ferranti Atlas? (48-bit single precision)

ICL 1900 Fortran (66) had an interesting couple of concepts: Statement No zero (meaning the next executable statement) and used in Arithmetic IF, together with zero length fields in input formats (e.g. I0, F0.0 etc) with similar functionality to Fortran-77 'formatless' list-directed input. The minute you started using those features, however, you were locked into that compiler.

I used IBM 1130 with 16-bit words (32 bit REAL) and Univac 1100 computers with 36 bit REAL.

Eddie

Thanks Eddie, I think you may have explained why after migrating from an ICL 1900 to a VAX we could never exactly replicate the old computers output :idea:

I very quickly learnt to only use double precision on the VAX.

Eddie,

When I first started work, I refused to use the IBM 1130, but insisted on using a Prime. I remember there were no logical if statements.

In mid 80's, I once had to transfer code onto an IBM mainframe (forgotten the number). I learnt how backward IBM was in comparison to then Prime/Vax for engineering computing. The IBM Fortran imposed a lot of constraints on what could be assumed from the Fortran 77 standard, with anything good that was vender dependant was not in their compiler, especially for I/O errors. I'm sure IBM had considerable influence on what capabilities were partially excluded from the F77 standard. Interactive graphics also gave particular problems for easy implementation.

I never used 'double precision', I always used real8. I'm not so confident about 48-bit precision as I would have a few finite element shell examples where 48-bit:'real6' would have problems, although I could do with that in a project I am working on now. Who would have thought that 2gb would have been a memory limit ! Lately I've become accustomed to instant computing, with minimal I/O delays.

John

For the next release I have improved the compiler's response to the option ALT_KINDS so that the following code will work as expected.

options(alt_kinds)
integer,parameter::ik=selected_int_kind(12)
integer,parameter::xk=selected_real_kind(17)
integer,parameter::jk=kind(42_4)
integer(kind=ik)::i
real(kind=xk)::x
integer(kind=jk)::j
print*,ik,xk,jk
end

This change affects PARAMETER declarations where the evaluation takes place at compile time. Runtime calls to external intrinsic functions will remain unchanged and so will still give the compiler default values even when ALT_KINDS is applied. However, these intrinsics are usually exaluated inline at compile time even when they appear to be in runtime code.

I have done some further work on this so that even dynamic calls to selected_int_kind etc (i.e. calls to the library at run time) will be sensitive to ALT_KINDS. This rarely happens. When the arguments are constant the compiler evaluates these calls at compile time.