|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Sep 03, 2016 1:00 pm Post subject: /alt_kind does not work as intended for COMPLEX(4) type |
|
|
Many legacy Fortran codes contain declarations of the type REAL*4, INTEGER*2, etc., with the expectation that the suffix number is the byte size of the variable (for COMPLEX, the suffix number is the byte size of each part, real and imaginary).
The alternative syntax, REAL(4), etc., is slightly less common, but FTN95 supports this syntax (and the *n type syntax) with the /alt_kinds option. This support does not work as expected for COMPLEX(4), which is rejected by FTN95 /alt_kind; the compiler accepts but with a non-traditional meaning the type COMPLEX(8).
The following program illustrates the inconsistency. Please see, for example, https://gcc.gnu.org/onlinedocs/gfortran/KIND-Type-Parameters.html#KIND-Type-Parameters , for a description of the traditional meaning of COMPLEX(4) and COMPLEX(8).
Code: | program tst
complex(4) x
complex(8) y
complex z
complex*16 w
write(*,10)'COMPLEX(4) : ',kind(x),range(x),precision(x)
write(*,10)'COMPLEX(8) : ',kind(y),range(y),precision(y)
write(*,10)'COMPLEX : ',kind(z),range(z),precision(z)
write(*,10)'COMPLEX*16 : ',kind(w),range(w),precision(w)
10 format(A13,3i5)
end program
| The two lines that pertain to x are rejected by FTN95 with the /alt_kinds option. Furthermore, FTN95 regards the complex variable y as a pair of 4-byte reals, whereas y is expected to be a pair of 8-byte reals.
The results from GFortran and Intel Fortran:
Code: | COMPLEX(4) : 4 37 6
COMPLEX(8) : 8 307 15
COMPLEX : 4 37 6
COMPLEX*16 : 8 307 15
|
With the lines containing the variable x commented out, FTN95 /alt_kinds gives:
Code: | COMPLEX(8) : 4 37 6
COMPLEX : 4 37 6
COMPLEX*16 : 8 307 15
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Sep 05, 2016 8:59 am Post subject: |
|
|
Thank you for the feedback.
FTN77, FTN90 and FTN95 have always used COMPLEX*8 and COMPLEX*16 so it is unfortunate that this is different from other compilers.
It is not obvious to me how this can be resolved other than by adding another compiler option to FTN95 in order to allow the new alternative kinds. In view of the existing complexity of alternatives within FTN95, this could be quite tricky.
Do you have any thoughts on how to resolve this issue either by adapting your code or by our changing FTN95? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Sep 05, 2016 12:57 pm Post subject: |
|
|
Paul, there is no issue with COMPLEX*8 and COMPLEX*16, and declarations of this type, though not specified in the Fortran standard, are allowed by all Fortran compilers (F77 and later, at least).
The issue is with specifying a variable to be COMPLEX(n), where n is a literal constant. The Fortran 95 standard (draft version at http://j3-fortran.org/doc/standing/archive/007/97-007r2/pdf/97-007r2.pdf ) says in 4.3.1.3, second paragraph:
Quote: | A kind type parameter may be specified for a complex entity and selects for both parts the real approximation method characterized by this kind type parameter value. |
The standard does not specify the kind numbers to be used, but does constrain their choice. Therefore, when a vendor allows COMPLEX(8), either natively or optionally through a switch such as /ALT_KINDS, the kind number 8 must be the value returned by the KIND intrinsic function for the complex variable, its real part and its imaginary part. FTN95 with /ALT_KINDS, however, returns the kind number 4 for all three. I think that the constraint in the standard is violated.
I strongly think that /ALT_KINDS should be fixed. Creating a new compiler option is not indicated -- I doubt that any user of FTN95 uses COMPLEX(8) with the expectation that such variables are made up of a pair of 32-bit floats. Perhaps the question could be posed to the forum members.
Last edited by mecej4 on Mon Sep 05, 2016 2:10 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Sep 05, 2016 1:42 pm Post subject: |
|
|
Thank you for the clarification. I will make a note that it needs to be fixed.
If anyone has used COMPLEX( in their existing code then the fix will given them more precision and so should not be a problem. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Sep 06, 2016 5:26 pm Post subject: |
|
|
What did you mean by 'non-traditional' here mecej4 ?
Quote: | the compiler accepts but with a non-traditional meaning the type COMPLEX(. |
Edit:- Ooooh !!!! I see now why Paul's comment had the 'cool' look LOL
COMPLEX(8 ) |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Sep 06, 2016 5:51 pm Post subject: |
|
|
I hope that you will concede that having smilies in Fortran source code is non-traditional!
One of the user preferences/settings of these forums allows you to choose if smilies are displayed with emoticons. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Sep 08, 2016 4:21 am Post subject: |
|
|
Ah-ha now I see, you were ribbing Paul
I knew about the smilies but don't have all the options in memory so didn't twig the 8 ) being the shades . |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Jan 30, 2017 11:48 am Post subject: |
|
|
This has now been fixed for the next release. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|