| View previous topic :: View next topic |
| Author |
Message |
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
 Posted: Sat Jan 31, 2015 7:07 pm Post subject: 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:
| Code: | 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":
| Code: | [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]
Last edited by mecej4 on Mon Jun 15, 2015 11:56 pm; edited 1 time in total |
|
| Back to top |
|
 |
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Sat Jan 31, 2015 9:38 pm Post subject: |
|
|
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 
Edit
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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Feb 02, 2015 10:08 am Post subject: |
|
|
| This bug has been fixed for the next release. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Feb 02, 2015 5:20 pm Post subject: |
|
|
| My mistake. This one is still outstanding. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Tue Feb 03, 2015 11:13 am Post subject: |
|
|
| OK. Now it is fixed. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Tue Feb 03, 2015 11:17 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
