Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#74 closed defect (wontfix)

flib doesn't support 64-bit

Reported by: Dave Offiler Owned by: Dave Offiler
Priority: normal Milestone: 1.0
Component: ropp_utils Version: 0.8
Keywords: Cc:

Description

flib doesn't support true 64-bit compilation (e.g. efc with -i8 switch)

1) there is no named kind for 8-byte integers. In many places, named 4-byte integers are freely mixed with default kinds - e.g. across subroutine calls. Fine when the default is 4-byte, but causes compile-time errors when the default is 8-byte.

2) the kind for 4-byte reals is set up as 'KIND(1.0)' and this is then used in the kind setup for 8-byte reals (the R8K setup is literally double-precision). Again, this will only work when the default kind is 4-byte. On the TX, when the default is 8-byte, R4K is actually 8-byte and R8K is 16-byte. This also causes compile-time erros relating to inconsistent subroutine arguments.

This issue is related to Ticket #67

Change history (2)

comment:1 by Dave Offiler, 18 years ago

Resolution: wontfix
Status: newclosed

1) could be fixed in principle by adding a named kind type (e.g. I8K) in the NUMERIC_KINDS module in flib.f90. In addition, all default integers, including constants, would need to be given a specific kind type.

2) the kind type could be (and should have been) explicitly set to a 4-byte kind, e.g. with SELECTED_REAL_KIND(6) instead of KIND(1.0).

In both cases, this modifies the 3rd party code in flib, which is probably against the usage conditions (especially if the modified code is bundled with ROPP). It is not for us, but the author, to properly support 64-bit compilation.

For ROPP, other work-arounds will have to be found. (See Ticket #67)

comment:2 by Dave Offiler, 18 years ago

Version: 0.8
Note: See TracTickets for help on using tickets.