Default data type of Holleriths when passing to functions/subroutines

[orgabit]

Hi,

I have the following test program to test passing holleriths to functions/subroutines. ifort is terminating with the following error message:

testholleriths.f(21): error #6285: There is no matching specific subroutine for this generic subroutine call. [TESTH]
CALL TESTH (2H12, IBUF, 1)
-----------^

The question is: what data type is the compiler assuming in this case for the hollerith 2H12?


PROGRAM TESTHOLLERITHS

C INCLUDE 'RTE-UX.h'

INTERFACE TESTH
SUBROUTINE TESTH_01 (A,B,C)
INTEGER(2), INTENT(IN) :: A
INTEGER(2), INTENT(IN) :: B(*)
INTEGER(2), INTENT(IN) :: C
END SUBROUTINE TESTH_01

SUBROUTINE TESTH_02 (A,B,C)
INTEGER(4), INTENT(IN) :: A
INTEGER(2), INTENT(IN) :: B(*)
INTEGER(4), INTENT(IN) :: C
END SUBROUTINE TESTH_02
END INTERFACE TESTH

INTEGER*2 iI, IBUF(3)

CALL TESTH (2H12, IBUF, 1)

END


SUBROUTINE TESTH (I1, I2, I3)
ENTRY TESTH_01 (I1, I2, I3)
ENTRY TESTH_02 (I1, I2, I3)

INTEGER*2 I1(*), I2(*), I3(*)
INTEGER*2 I1L(3), I2L(3), I3L(3)
INTEGER*2 iI
CHARACTER C1L*6, C2L*6, C3L*6

EQUIVALENCE (I1L , C1L), (I2L , C2L) , (I3L , C3L)

WRITE (6, '("I1 = 0x", Z4, " / I2 = 0x", 3Z4, " / I3 = 0x", Z4)')
> I1(1), (I2(iI), iI = 1,3), I3(1)

CALL MOVEWORDS (I1, I1L, 1)
CALL MOVEWORDS (I2, I2L, 3)
CALL MOVEWORDS (I3, I3L, 1)

WRITE (6, '("C1 = ", A2, " / C2 = ", A6, " / C3 = ", A2)')
> C1L, C2L, C3L

END

Any ideas / explanations for this behaviour?

Thanks,

Andy

[mecej4]

Hollerith constants are obsolete. They do not have a default type. To issue a compatible call, you could use

CALL TESTH (int(2H12,2), IBUF, 1_2)

The first argument will have the value 12849 (decimal). Unless you want to obfuscate your code, why do you want to use Hollerith constants?

Integer*2 is not necessarily the same as Integer(2).

[orgabit]

Hi, thx for your reply. I am currently porting an application from an old HP computer architecture to Linux. On that HP platform (HP1000), Holleriths were used heavily (we are talking about code which was started in the late 70'ties). I know about the workaround (let int() do the thing) but I thought (and from what I read in the manuals) the holleriths are interpreted by the compiler and assigned to a data type based on their length.

Andy

[mecej4]

The problems are caused by, shall I say, trying to time-travel?

You are trying to use overloaded module procedures which are USEd in the caller and full interfaces are needed for the compiler to resolve generic names in terms of specific names. These features were completely unknown in Fortran 66 and 77, and require strict type matching or explicit coercion, and are not compatible with the lax use of Hollerith constants in old code.

You will probably have no problems if you keep all your code in conformity with F66 style. Or, at least, keep Holleriths out of new code. Spend your valuable time on bringing old code into the present century.

[Steven_L_Intel1]

There are several pages in the compiler documentation about the datatype of non-decimal constants, including Hollerith. The datatype assumed depends on the context. In the specific case of Hollerith constants as actual arguments, "no data type is assumed", so these cannot ever match a generic.

[TimP]

This usage of Hollerith appears to go well outside the limits of Fortran 66, into what always would have been platform dependent territory. As I recall, Hollerith usage was well defined only in limited contexts, such as DATA, where variable typing had to be given (at least by implicit data typing), as well as FORMAT. In none of those cases would there be reliance on the compiler giving a data type to the Hollerith string.
The f77 and subsequent standards deleted even the limited definition of Hollerith of the f66 standard. I'm not at all confident of being able to accomplish in 2011 what the Fortran committee decided couldn't be accomplished in 1977, in terms of supporting earlier Hollerith usage.