|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sat Nov 23, 2019 5:26 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Nov 24, 2019 1:52 am Post subject: |
|
|
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. The more developers violated standard the more successful they were. Fortran-like Matlab is an example. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Nov 25, 2019 9:04 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Nov 25, 2019 10:21 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Mon Nov 25, 2019 12:01 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Nov 26, 2019 7:06 am Post subject: |
|
|
Thanks Paul for quick fix, thanks Mecej4 for discussion, and John for other options |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Dec 19, 2019 2:28 am Post subject: |
|
|
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 ... " |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Dec 19, 2019 6:20 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Dec 21, 2019 9:55 am Post subject: |
|
|
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 |
|
|
|
|
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
|