forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

/alt_kind does not work as intended for COMPLEX(4) type

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 673

PostPosted: Sat Sep 03, 2016 1:00 pm    Post subject: /alt_kind does not work as intended for COMPLEX(4) type Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4819
Location: Salford, UK

PostPosted: Mon Sep 05, 2016 8:59 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 673

PostPosted: Mon Sep 05, 2016 12:57 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4819
Location: Salford, UK

PostPosted: Mon Sep 05, 2016 1:42 pm    Post subject: Reply with quote

Thank you for the clarification. I will make a note that it needs to be fixed.
If anyone has used COMPLEX(Cool in their existing code then the fix will given them more precision and so should not be a problem.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 503

PostPosted: Tue Sep 06, 2016 5:26 pm    Post subject: Reply with quote

What did you mean by 'non-traditional' here mecej4 ?

Quote:
the compiler accepts but with a non-traditional meaning the type COMPLEX(Cool.



Edit:- Ooooh !!!! I see now why Paul's comment had the 'cool' look LOL
COMPLEX(8 )
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 673

PostPosted: Tue Sep 06, 2016 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 503

PostPosted: Thu Sep 08, 2016 4:21 am    Post subject: Reply with quote

Ah-ha now I see, you were ribbing Paul Smile
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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4819
Location: Salford, UK

PostPosted: Mon Jan 30, 2017 11:48 am    Post subject: Reply with quote

This has now been fixed for the next release.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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