Compiler bug: With /alt option, 1.0_dp in PARAMETER

The 7.1 compiler has a bug that causes the compiler to disallow the use of a _dp kind prefix appended to a real constant in a double precision parameter declaration when the /alt option is used to compile. A reproducer:

MODULE knd_mod
IMPLICIT NONE
integer, parameter :: dp=kind(1d0)
END MODULE knd_mod

PROGRAM test_knd

USE knd_mod
IMPLICIT NONE
REAL (dp), PARAMETER :: one = 1.0_dp

write(*,*)' dp = ',dp, ',  One = ',one

END program

If the /alt compiler option is used, the compiler objects to the _dp kind suffix in the line containing 'REAL (dp), PARAMETER':

[FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
    PROCESSING MODULE  [<KND_MOD> FTN95/Win32 v7.10.0]
    NO ERRORS  [<KND_MOD> FTN95/Win32 v7.10.0]
0010) REAL (dp), PARAMETER :: one = 1.0_dp
*** KIND parameter out of range, permitted KINDs are 1, 2, or 3
    1 ERROR  [<TEST_KND> FTN95/Win32 v7.10.0]
*** Compilation failed

The error does not occur if the /alt option is not used.

[P.S., 15 June 2015: This bug is not present in FTN95-7.20]

I confirm this behaviour when using /ALT_KINDS needs to be fixed.

Apparently, literal constants like 1.0_8, 1.0_4 work properly but not parameters like 1.0_dp.

See here in the help documentation where this issue is acknowledged (though its rather cryptic).

http://www.silverfrost.com/ftn95-help/options/default_kind_values_for_intrinsic_types.aspx

Can this be fixed please 😃

[u:f1852bf04c]Edit[/u:f1852bf04c] I find that setting the option to ignoring the error message (/IGNORE 636) makes the example above compile and run correctly. So you just need to change how the check is made when /ALT_KINDS is turned on.

This bug has been fixed for the next release.

My mistake. This one is still outstanding.

OK. Now it is fixed.

Paul,

Thanks for fixing this as it is a useful change for FTN95 to be more compatible with most other compilers in the default KIND values. I know that the use of explicit values of KIND is advised against, but the simplicity of 1_8 as a long integer is often convenient. The support of 1_dp is a useful addition and supports the preferred use of KIND values.

John