Please check if this crashes in your case

Dan,

I have read through all the posts in this thread again, and I am at a loss as to what you mean by 'bug' and what your 'demo' does. There are fragments of code and there are comments that show a misunderstanding of what those fragments should mean.

I do not see anything that I could call 'a reproducer'. Even if you sent Paul a larger and more complete piece of code, you would still need to attach a description of what the code is expected to do, what you see it doing instead, and how to induce the behaviour that you are calling a 'bug'.

OK, let's start over. This works OK:

module mo
REAL(KIND=2)::RANDOM@, RAN
contains 
end module mo

program aaa
use mo

RAN=RANDOM@()

print*, ran
pause
end

Why my program at the start of this thread does not ? Why module does not 'mangle' all other own Silverfrost intrinsic functions with @ while mangles these two CMPROGNM@ and cmnargs@ (and probably cmnam@) ?

The program that you posted today (22 Nov 2019) has bugs already. With FTN95, you only get warnings when you compile, and you will see a 'symbol not defined' message when you attempt to link. For details, compile with the /exp option and look at the CALL statements generated in the listing.

If you ignore the warnings and attempt to link, SLINK/SLINK64 gives you an EXE with the execute attributes set despite the missing external. If you ignore the warnings and attempt to run the EXE, you will of course see the program abort.

If you attempt to compile the program with another Fortran compiler, you will see more elements that are either wrong (from the p.o.v. of the standard) or not meaningful without extensions to the standard.

So, Dan, let's start again; preferably, with an example that uses only standard Fortran; or, with known and recognised extensions with the consequences of using the extensions understood beforehand.

You may find it instructive to try the following modified version:

module mo
REAL :: RANDOM@
end module mo

program aaa
use mo

call random_number(RANDOM@)
print *, random@

end

Sorry yesterday code was wrong, discard, i posted it without check.

Same questions still stay. Why this code containing silverfrost-specific @function winio@ works not mangling anything and without requiring any interfaces or special care and does not mangle anything

module mo
contains
function fff
  i=winio@('Not mangled ? Hit esc %es')
  fff=2
end function
end module mo
!.............
program aaa
use mo
i=fff()
end

And how this can work at all where there is total zero hints that this is 100% Silverfrost-specific, not even 'use clearwin' or 'include. <clearwin.ins>'

i=winio@('Not mangled ? Hit esc %es')
end

Clearly here care was taken to recognize its own compiler-specific @ functions. Why there was not done same things for all @ functions? If Salford/Silverfrost started violating Standard - do that for all @ functions same way, that will have logic.

Quoted from DanRRight Why this code containing silverfrost-specific @function winio@ works not mangling anything and without requiring any interfaces or special care and does not mangle anything

There is no name mangling at the Fortran level. It is only when you link (or run the program in the debugger and view lower level entities or produce a /exp listing or a linker map) that you will see the name mangling.

Compile your program with /debug, link, and open the EXE in SDBG/SDBG64. Press F11, and you will see:

CALL      MO!FFF

Thus, the mangled name is MO!FFF, i.e., the module name followed by the function/subroutine name, with '!' as the separator.

If you look further, you will see that the mangled name generated by the WINIO@ call is WINDOW_PRINTF@@ .

Hell, the dog and cat knows that FTN95 calls functions inside modules with the <name of module>!<name of function>. You see that every time you have an error in function inside the module (read : almost always with ftn90 style). What is not mangled inside the module? 😃 😃 😃

The whole thread not about this. I guess if my english is that confusing or you intentionally fly circles missing the point i tried articulate several times different way. Anyone knows this compiler has its intrinsic functions completely non-standard. For the users to easily recognize them they are mostly end with @. I showed last time the examples when without anything additionally needed (which is not true for other compilers) the FTN95 understands these functions. It recognizes these functions inside the modules and in the Main as you have seen that. User expects this as a standard behavior of FTN95. Standard for FTN95.

It does not recognize few mentioned above functions if they are placed inside the modules though it should as the users already expect that compiler must recognize its own intrinsic @ functions if the name is not taken by the user which is extremely unlikely (or dangerous because Silverfrost may take the name@ in the future).

The excuse 'it's being mangled' (read: FTN95 does not recognize its own intrinsic function when it is in module) sounds like 100% error unless there exist reasons for that. Because it recognizes all other functions with no problem. If such rock solid reason for these specific functions indeed exist then Help file should warn user in bold red font about their uncommon behavior. 'Uncommon' means uncommon for FTN95 users not for the users of all other compilers or Fortran Standard

In Fortran, no names are reserved names, whether they are keywords or not. What this means is that intrinsic functions, whether standard or vendor extension functions, can be replaced by the user's definitions of variables, functions, etc.

Consider, for example, the SQRT standard intrinsic function. If you declare SQRT as a variable or a function in your code, within that scope the standard SQRT is not available.

Suppose, next, that Silverfrost provided a nonstandard intrinsic, SQRT@. If you declare SQRT@ in your code, the nonstandard Silverfrost SQRT@ would not be available in the scope of that declaration.

I think that you should consider spending some time reading Metcalf, Reid and Cohen's book, Modern Fortran Explained, https://global.oup.com/academic/product/modern-fortran-explained-9780198811893?cc=us&lang=en& , if only to clarify topics that remain obscure after your having consulted your pet animals.

Some FTN95 functions are non-standard and are reserved. How many time i have to show two line example with winio@ ? If you like to take winio@ name it's up to you to shot yourself in the foot and stay empty handed. You probably still can take this name and keep the winio@ functionality but that requires special movements.

Quoted from DanRRight Some FTN95 functions are non-standard and are reserved.

Please name an example, and I will look it up in the documentation. Off-hand, I don't know of any that are reserved.

Quoted from DRR If you like to take winio@ name it's up to you to shot yourself in the foot and stay empty handed.

That is precisely what you did, in your second example in the first post of this thread, and I have been trying to point out that fact to you in numerous ways. You declared CMPROGNM@ and cmnargs@ in the module. Within the scope of those declarations, those are no longer the FTN95 extended intrinsic functions of the same names.

If 'within the scope of those declarations, those are no longer the FTN95 extended intrinsic functions of the same names' and Silverfrost agrees with such treatment of their intrinsic names (they are who decide to follow or not the whatever standard or practice with this respect. I'd strongly suggest NOT to) then as i requested the HELP should clearly write that declarations of these functions should be only withing the code where these functions are called, not in the module which then will be USEd.

Do you now see my stance on that? I do not look religiously at the Standard and scopes like FTN77-95 also did not completely care. Ftn77-95 was 'teaching' its users to accept a LOT of exceptions all these decades.

And now I just follow the logic of FTN95:

1. these functions are compiler specific and have to be treated special way

2. as some functions have to be declared as integer*2, some need specify the character length, etcetc declaring in the module and USE has to be allowed like it was done for MAIN program otherwise it will cause confusion for years. Mangling by module has to be unmangled by the compiler

3. plus this declaration in the module has conveniences for the user: declare ones in the module and then just use in many places.

Since the user accepted existence of Silverfrost-specific 'non-standard' functions then for this user it's like other compilers do not exist and the FTN95 is a Standard

The logic of FTN95 requires that if first of my codes at the beginning of the thread works then declaring the same Silverfrost-specific functions in the module (like i have done in the second code) should also work the same way. The fact it does not since now the CMPROGNM@ is called mo!CMPROGNM@ because module 'mangled' it this way has no reason for not being recognized by the compiler. It is just ridiculous compiler can not do that.

Again, if Silverfrost decided to give up with treatment of its extensions then pitfalls of this have to be articulated to the users. This module 'mangling' when user is not expecting it with the chance 1000000:1 is one of such sh!tties which costed me a lot of nerves in the past when there was no communication with the user community

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

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 :

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.

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.

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.

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.

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):

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.

Thanks Paul for quick fix, thanks Mecej4 for discussion, and John for other options

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

      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

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

      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

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

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