soccer jersey forums.silverfrost.com :: View topic - Compiler capability
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 

Compiler capability
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1896
PostPosted: Mon Jan 14, 2019 2:49 pm    Post subject: Reply with quote
Paul,

I am not sure if I interpret the Fortran 95 standard correctly, but the following excerpt, particularly in the last two sentences, seems to say that if SEQUENCE is not present, the types defined by two separate but otherwise identical TYPE definitions are not the same.
Quote:
4.4.2 Determination of derived types

A particular type name shall be defined at most once in a scoping unit. Derived-type definitions with the same type name may appear in different scoping units, in which case they may be independent and describe different derived types or they may describe the same type.

Two data entities have the same type if they are declared with reference to the same derived-type definition. The definition may be accessed from a module or from a host scoping unit. Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that have the same name, have the SEQUENCE property, and have components that do not have PRIVATE accessibility and agree in order, name, and attributes. Otherwise, they are of different derived types.

Interpreting these rules is something that I found to be difficult because a derived type definition is said to constitute a separate "scoping unit", in this part of F95 Art. 2.2:
Quote:
2.2 Program unit concepts
...
A program unit consists of a set of nonoverlapping scoping units. A scoping unit is

(1) A derived-type definition (4.4.1),

(2) A procedure interface body, excluding any derived-type definitions and procedure
interface bodies in it (12.3.2.1), or

(3) A program unit or subprogram, excluding derived-type definitions, procedure
interface bodies, and subprograms in it.

A scoping unit that immediately surrounds another scoping unit is called the host scoping unit.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK
PostPosted: Mon Jan 14, 2019 4:59 pm    Post subject: Reply with quote
mecej4

Thank you for the clarification.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1225
Location: Morrison, CO, USA
PostPosted: Fri Jan 18, 2019 12:01 am    Post subject: Reply with quote
One things that I found by accident is: If you have a TYPE as an argument to a function call, but that function call expects an intrinsic type (i.e. REAL), then the compiler will flag that as an error (certainly it should).

Another thing I found: For FTN95 intrinsic functions (i.e. FEXISTS@), I can specify the second argument (should be KIND=3) as KIND=2 and there is no compiler error/warning about this. Even if I put these two incarnations next to each other.

Code:

    ABCD = FEXISTS@('THIS IS A TEST',I4)
    ABCD = FEXISTS@('THIS IS A TEST',I2)


I found this because I had a failure at run-time where the I*4 result was stored in an I*2 variable. I'm having to go back to all my code to check since the FTN95 intrinsic functions take either KIND=2 or KIND=3 depending on the function.

And, I cannot define an INTERFACE to force the check because the functions are intrinsic, and the compiler quits with that as the error.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK
PostPosted: Fri Jan 18, 2019 9:34 am    Post subject: Reply with quote
Bill

I think that FTN95 probably needs to be changed to allow users to provide interfaces for routines ending in @. In the meantime you can override the error message by using /IGNORE 1094 on the FTN95 command line.

Code:
program main
logical L
integer ercode
interface
logical function fexist@(path, error_code)
character(LEN=*) path
integer error_code
end function
end interface
L = fexists@("buildlog",ercode)
end


Correction:
This fragment of code does not currently work as expected for routines ending with the @ symbol. I have added this topic to the wish list.

Last edited by PaulLaidler on Thu Jan 24, 2019 9:33 am; edited 1 time in total
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1896
PostPosted: Fri Jan 18, 2019 2:15 pm    Post subject: Reply with quote
Being able to specify interfaces would be quite helpful.

Some (all, perhaps?) of the FTN95 non-standard intrinsics appear to allow '$' at the end of their names instead of '@', but there are some inconsistencies. The documentation should clarify this matter.

The following program works fine with /64, but linking fails in 32-bit mode, saying that FEXISTS$ is a missing symbol.
Code:
program xintrin
implicit none
logical :: fex, fexists$
integer :: e1, e3
!
fex=fexists@('xin.f90',e3)
print '(1x,L1,1x,I10)',fex,e3

fex=fexists$('xin.*',e1)
print '(1x,L1,1x,I10)',fex,e1
end
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK
PostPosted: Fri Jan 18, 2019 4:37 pm    Post subject: Reply with quote
mecej4

Thank you for the feedback.

The $ symbol is intended for third party compiler (e.g. gFortran) users who want to access ClearWin+.

It should not appear in the documentation except for the notes on using ClearWin+ with third party compilers.

I have fixed the documentation (in this respect) in one or two places in the latest release. If there are other places that need fixing then please let me know.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK
PostPosted: Thu Jan 24, 2019 9:36 am    Post subject: Reply with quote
Bill

Please note my correction to the post above. If you use /ignore then the given code compiles and runs but, at the moment, the interface is not used (when the routine name contains the @ symbol).
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1225
Location: Morrison, CO, USA
PostPosted: Thu Jan 24, 2019 2:49 pm    Post subject: Reply with quote
Thanks, Paul.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
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