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  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Thu Nov 21, 2019 2:16 am    Post subject: Reply with quote

I'm still puzzling where these several functions are so different so that they are not included by default into special treatment interface list.

Here is an example you would not find the error for a long time because these two-there functions create pure unimaginable devilry. See bubble help in light yellow on SDBG screenshot how initialized variable becomes undefined (!!!) ***after*** calling these two functions the way i have shown above ? If compiler would not support /UNDEF (or the same /CHECKMATE ) you will not find this bug. I had similar bugs for decades because users in 999 out of 1000 cases when find the bug procrastinate to report it. Even though FTN77/90/95 had /UNDEF from the start, the debugger in some cases was also having bugs which did not allow to apply /DEBUG or /UNDEF for the code or with /DEBUG the bug disappeared. Thanks to integral effect of lazy reporting and usage over time the compilers and debuggers now rarely having problems.




About bugs. I'd say the company (and all people in general) have absolutely wrong attitude respect to reported bugs. All software has bugs. And instead of feeling kind of guilt the SF should encourage users to be like a quality assurance (QA) guard for the software. I'd introduce even competition for "QA winner of the year" based on how many problems were reported in 365 days. I'd personally donate for that purpose, say, a $100. This will return back in the future with the saved time and programs quality.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Nov 21, 2019 8:35 am    Post subject: Reply with quote

Dan

You are presumably using the debugger and currently stepping through the program.

I think you are running the 64 debugger directly from Plato so you probably don't have the fix that provides the correct break point line. In this case the information provided by the debugger will be out of sync.

If the debugger is working correctly and you hover over a variable then it will show its state in relation to the current break point. So your image would be correct if the current break point was before the assignment.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Nov 21, 2019 11:10 am    Post subject: Reply with quote

Program stopped at break point where kCreateFields variable was used in the IF (kCreateFields.eq.1) THEN, that's much below of all these lines i pictured above. The error was telling me that the variable was ... undefined! I specifically went with debugger up and made a picture of something unimaginable.

Then i removed the CMPROGNM$ and cmnargs$ and program started working OK. It also started working OK if i declare these functions in the MAIN program where they were used
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Nov 21, 2019 11:16 am    Post subject: Reply with quote

If you are able to provide more of the code (particularly before this) then I might be able to understand what is wrong.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 22, 2019 3:53 am    Post subject: Reply with quote

I will send you the complete code which is not large. But why the demo what i posted above is not enough? The undefined bug is the consequence of the same problem shown in the first message. It is not worth to cure consequence, there could be infinite amount of them
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1216

PostPosted: Fri Nov 22, 2019 5:47 am    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 22, 2019 2:30 pm    Post subject: Reply with quote

OK, let's start over.
This works OK:
Code:
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@) ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1216

PostPosted: Fri Nov 22, 2019 3:25 pm    Post subject: Reply with quote

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:

Code:
module mo
REAL :: RANDOM@
end module mo

program aaa
use mo

call random_number(RANDOM@)
print *, random@

end
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 23, 2019 8:23 am    Post subject: Reply with quote

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

Code:
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>"
Code:
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.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1216

PostPosted: Sat Nov 23, 2019 10:33 am    Post subject: Re: Reply with quote

DanRRight wrote:
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:

Code:
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@@ .
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 23, 2019 12:36 pm    Post subject: Reply with quote

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? Smile Smile Smile

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


Last edited by DanRRight on Sat Nov 23, 2019 1:43 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1216

PostPosted: Sat Nov 23, 2019 1:30 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 23, 2019 1:48 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1216

PostPosted: Sat Nov 23, 2019 2:22 pm    Post subject: Re: Reply with quote

DanRRight wrote:
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.

DRR wrote:
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.


Last edited by mecej4 on Sat Nov 23, 2019 4:27 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 23, 2019 3:47 pm    Post subject: Reply with quote

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
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  Next
Page 2 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