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 

Please check if this crashes in your case
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Nov 23, 2019 5:26 pm    Post subject: Reply with quote

This is what the Fortran 95 Standard says about intrinsic functions:

Quote:
2.5.7 Intrinsic
The qualifier intrinsic signifies that the term to which it is applied is defined in this standard. Intrinsic applies to data types, procedures, assignment statements, and operators. All intrinsic data types, procedures, and operators may be used in any scoping unit without further definition or specification.


Please note the last sentence. Intrinsic entities are already defined at the beginning of compilation. The properties of intrinsics are stated with different wording at https://www.obliquity.com/computer/fortran/intrinsic.html :

Quote:
FORTRAN 77 provides a variety of intrinsic functions which may be used in any program unit. They are subject neither to type declarations nor IMPLICIT statements. Their names are not reserved keywords but to avoid confusion, it is inadvisable to use these names as arrays, constants, variables or user-defined external subprograms.


You wrote, "Do you now see my stance on that?"

I see it and I disagree strongly. If you don't care about the Fortran standard, and the Silverfrost documentation does not define and describe non-conforming behaviour that is to your satisfaction, you and I no longer have any basis for continuing this discussion. Make up your own language, get somebody to write a compiler for it, and try to recruit users for your new language.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Nov 24, 2019 1:52 am    Post subject: Reply with quote

Relax, mecej4. All reasonably follow standard with one hand and do something extra which is non-standard but could be in the future with another. You are too late by 3 decades with your advise to "make your own language, get somebody to write a compiler for it, and try to recruit users for your new language". This language is Ftn77-Ftn95. Very Happy Very Happy Very Happy Very Happy Smile The more developers violated standard the more successful they were. Fortran-like Matlab is an example.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Nov 25, 2019 9:04 am    Post subject: Reply with quote

For all who did not get the essence of our discussion here is the summary.

I had the code which periodically worked and not worked when it was necessary to give the code additional instructions via adding some parameters after the EXE name when you start the EXE. It's like when you for example add parameters

C:> PKZIP -a file.zip DATAfil.dat or
C:> FTN95.EXE /LINK /DEBUG

These parameters FTN77/95 recognizes from ancient ages when other Fortran compilers were just little babies and Fortran Standard was telling them : NO, anathema to you, do not do that, this will be non-standard!

The problem as it appears is in the inexplainable behavior of FTN95 which i find totally unacceptable and confusing to the extent that you for sure will not find the bug in decades as i did.

First, this is a side note: how we started programming after FTN77 using Fortran-90 modules. We put all subroutines into the modules and then USE them where needed and the program works OK. Before we placed all subroutines as independent subprograms before/after/aside the MAIN program and declared them REAL/INTEGER and EXTERNAL where we used them.

Now take the chair because you will fall when you get the point we discuss: when you expect that any subroutine you declared in the module will work if you USE this module you get that some Silverfrost-specific subroutine does not work because compiler "forgets" or "gets confused" with the "mangled" name reserved for this subroutine or function (Don't worry, it is not 100% reserved because you still can take this name but you will lose Silverfrost-specific functionality of course. You will shoot yourself into the leg but it's up to you )

Compiler forgets this subroutine name not because the user wrote "i like this name no matter what and will use it even if this name is LOG or WINIO@" but just "because" it got prefix, for example, MO! in front of its name (because the module above we called MO). This is called "mangles". But that's exactly like almost all other subroutines get mangled when declared inside the modules but things always worked OK (this is internal thing for the compiler and user even does not even need to know that). Can you imagine that? The own compiler left hand does not know what its right hand is doing. Why ? Possibly because Standard is requiring that modules mangle the names (but all do that, and it's ok). Should compiler be confused forgetting the name of subroutine specifically its own intrinsic functions (?!!!) Of course no way, that's not OK until some wounded into the head user will intentionally grab and overwrite the intrinsic name usually having the @ at the end). What is all this? This is either a design defect but also possibly just the trivial bug.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 25, 2019 10:21 am    Post subject: Reply with quote

Dan

It is true that the person who wrote this part of FTN95 did not anticipate that you would make this mistake.

FTN95 has already been improved (for the next release) so that it will no longer be necessary to declare the return type of a native intrinsic function (anywhere).

If you do this within a module then in future FTN95 will politely tell you that you have erred.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Nov 25, 2019 12:01 pm    Post subject: Reply with quote

Dan and Paul,

Just now, I reread a month-old post of mine ( http://forums.silverfrost.com/viewtopic.php?p=27959#27959 ) in which I pointed out that FTN95 did not catch instances where a variable was declared in more than one module and was accessible by USE association from more than one module.

It just struck me, and is worth noting here, that section 11.3.2 of the Fortran 95 Standard, which I quoted there, may also cover Dan's complaint. Here is the pertinent quotation (emphasis added by me):

Quote:
Two or more accessible entities, other than generic interfaces, may have the same name only if the name is not used to refer to an entity in the scoping unit. Generic interfaces are handled as described in section 14.1.2.3. Except for these cases, the local name of any entity given accessibility by a USE statement shall differ from the local names of all other entities accessible to the scoping unit through USE statements and otherwise.

The last two words, "and otherwise", may cover Dan's code, since "otherwise" may include intrinsic entities. Do you agree with this interpretation, Paul?

As Paul already stated, Dan's code is in error, but FTN95 failed to catch the error. I confess that I failed to recognise the connection of the topic of this thread to Section 11.3.2 when writing my earlier posts in this thread.

I'll look up more recent Fortran standards to see how they address this question.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Nov 26, 2019 7:06 am    Post subject: Reply with quote

Thanks Paul for quick fix, thanks Mecej4 for discussion, and John for other options
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Dec 19, 2019 2:28 am    Post subject: Reply with quote

mecej4, your last Qute above rom the standards is just exactly why 95% of Fortran users indeed just 'don't care about the Fortran standard'.
Because it's generally waffled gobbledygook which requires TIME to unravel and interpret.
It may be precise and correct, but to the average user it's a pain in the neck.
Users just want simple error messages for their mistakes, and ideally some direction/indication on what to change to get it going again.
Dan being a pioneer in trying to get things moving in that direction.

The 'and otherwěse' you spotted is just a catch-all phrase stuck in by a imo lazy and/or time-strapped programmer !
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Dec 19, 2019 6:20 pm    Post subject: Reply with quote

Dan,

in this context I would like to remark that it might be worthwhile compiling the sources of your first entry (posted Mon Nov 18, 2019 5:43) with other compilers.

I modified both of your files a little (mainly substituting @ by $) in order to be appropriate to be compiled using INTEL's 64 bit compiler ifort.

I changed your second program to a file named module_test.for
Code:

      MODULE MO
      USE CLRWIN$
      CHARACTER*128 PROGEXENAME, CMPROGNM$
      INTEGER*2 N_ARGCOMM_LINE, CMNARGS$
      END MODULE
      PROGRAM AAA
      USE MO
      PROGEXENAME = CMPROGNM$()
      N_ARGCOMM_LINE = CMNARGS$()
      PRINT*, N_ARGCOMM_LINE, ' ', PROGEXENAME
      PAUSE
      END

. Compiling module_test.for via ifort resulted in error messages
Code:

Intel(R) Visual Fortran Intel(R) 64 Compiler Professional for applications runni
ng on Intel(R) 64, Version 11.1    Build 20101201 Package ID: w_cprof_p_11.1.072

Copyright (C) 1985-2010 Intel Corporation.  All rights reserved.

module_test.for(8): error #6410: This name has not been declared as an array or
a function.   [CMPROGNM$]
      PROGEXENAME = CMPROGNM$()
--------------------^
module_test.for(8): error #6054: A CHARACTER data type is required in this conte
xt.   [CMPROGNM$]
      PROGEXENAME = CMPROGNM$()
--------------------^
module_test.for(9): error #6410: This name has not been declared as an array or
a function.   [CMNARGS$]
      N_ARGCOMM_LINE = CMNARGS$()
-----------------------^
compilation aborted for module_test.for (code 1)

Deactivating/commenting out lines
Code:

      PROGEXENAME = CMPROGNM$()
      N_ARGCOMM_LINE = CMNARGS$()

in file module_test.for and compiling it via ifort is successful and results in object file module_test.obj. Via command
Code:

dumpbin.exe module_test.obj /ALL

you may verify that string "CMPROGNM$" occurs only once in file module_test.obj and this as string "MO_mp_CMPROGNM$". This corresponds to the notes of Paul and mecej4 concerning the mangling in the module.

Regards,
Dietmar
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Dec 21, 2019 9:55 am    Post subject: Reply with quote

Dietmar, yes, this matter is still a bit confusing. Will see how this was fixed in the current release. In general, anything declared in some module and then USEd in other place has to be available in this place. Or users will be lost with such Fortran "innovations", most users are still with the old Fortran 77 style, 72 character limit etc. The way how the modules internally mark its internal functions is internal matter of the compiler or possibly Standard, for the user these functions still have the names without module prefix
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 -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3
Page 3 of 3

 
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