On 9.03 update

I installed this update and got the following issues:

1. Run time error: call to missing routine __return_pstach_ptr The debugger points on error on completely legitimate line. In one crash cases the error was in the first line of the first function after CONTAINS keyword in module.

I added some other dump function before this function like this

   integer function Emptyempty()
      aaaaa= 1
      bbbbb= 2
      ccccc= 3
   Emptyempty = 2
   end function

and the __return_pstach_ptr error shifted to the first line of other function far from the start of the module

2. %sd/%su not working
3. lcase still not working after FTN95 update of Nov 3 2023
4. SALFLIBC64.DLL name is supplied all in capital letters while some other before were in lower case. As a result the directory has both files creating confusion and conflicts

This release of FTN95 requires matching DLLs with the same date. They can be downloaded from the same place.

Same date May 14, same Support place above

My Version of FTN95/x64 v9.03.0.0 is time stamped 18/05/2024, although this may be the timestamp I downloaded the 8 files I updated.

My recent files are:

 Volume in drive C has no label.
 Volume Serial Number is 88FF-836A

 Directory of C:\Program Files (x86)\Silverfrost\FTN95_9.03F

09/10/1998  03:15 PM           974,336 SIMPLE.DLL
17/12/2022  09:28 AM        10,094,080 simdem32.dll
05/03/2023  11:02 AM         4,520,448 plato32.exe
15/03/2023  06:35 AM           404,968 clearwin64.a
15/03/2023  06:35 AM           375,390 clearwin64f.dll
07/09/2023  12:30 PM         6,134,272 plato.exe
07/09/2023  12:34 PM           891,392 platosdbg64.dll
10/09/2023  10:09 AM         3,264,512 sdbg64.exe
23/10/2023  10:23 AM           499,712 Slink64.exe
03/11/2023  01:09 PM            30,720 mk32.exe
03/11/2023  01:10 PM         1,222,144 src.exe
03/11/2023  01:10 PM         1,221,632 scc.exe
03/11/2023  01:15 PM             3,072 dbk_link.exe
03/11/2023  01:16 PM           105,472 dbk_link4.exe
03/11/2023  01:16 PM           114,688 dbk_link2.exe
03/11/2023  01:17 PM           522,752 sdbgdll.dll
03/11/2023  01:17 PM            82,432 sdbg.exe
03/11/2023  01:17 PM            82,432 wsdbg.exe
03/11/2023  01:17 PM            47,616 slim.exe
03/11/2023  01:18 PM           223,232 slink.exe
03/11/2023  01:18 PM         5,929,573 ftn95.chm
18/05/2024  03:24 PM         2,403,840 ftn95.exe
18/05/2024  03:24 PM        11,130,368 simdem64.dll
18/05/2024  03:24 PM         1,958,912 ClearWin64.dll
18/05/2024  03:24 PM           324,286 ClearWin64.lib
18/05/2024  03:24 PM         2,786,304 salflibc.dll
18/05/2024  03:24 PM         3,287,642 salflibc.lib
18/05/2024  03:24 PM           439,808 SALFLIBC64.DLL
18/05/2024  03:24 PM             2,562 salflibc64.lib
18/05/2024  03:25 PM    <DIR>          include
              44 File(s)     61,364,550 bytes
               7 Dir(s)  303,176,040,448 bytes free

John, Where have you downloaded it from? From here above or from personal support contract website?

Dan,

I downloaded from here (the support thread), but there might be a problem with your other .dll's ?

903 did not work for me so i returned to 902. But it got me unexplained errors recently in CLEARWIN64.DLL couple of which required to corner them for a week, one is still not resolved. Other appeared no one knows how and disappeared similarly after a week of tries

Tried september's 904 and returned back to 902. The 904 just crashes in the middle of compilation and other programs compile but still do not start because of missing __return_pstach_ptr. The handymen/workarounders here who never report any problems or suggested a single improvement or change in decades would particularly like compiler itself (not the program) crash report:

When fail to find the workaround they will just wait someone else will report it. By the way many other programmers even do not know what is Access Violation, never exhibited them in MATLAB for example. Because millions of active users is there doing serious work. I had 50 per day last week

Dan

As far as I know there are no issues of this kind with v9.05.

The v9.05 download includes FTN95, SLINK64 and the DLLs so the problems that you have had because you used a new FTN95 with old DLLs should not happen with v9.05.

Dan,

I had problems with (drectly) running programs compiled with /check.

However if i used 'SDBG64 program.exe', this helped identify any errors. This may help in your case ? I am not sure if this can overcome any apparent incompatibilities you may be identifying.

Paul, Sorry i mistyped 9.04 but actually 11 Sep 2024 update I used was 9.05. May be this update is more stable but i can not see how it handles my program crashes because this time my programs crash the compiler itself 😉 . First and second picture above are about 9.05. Rest of pictures are about 9.02

Besides, some other my programs also do not run with 9.05 because it is still missing something like __return_pstach_ptr I do not know what it comes from (Fig.2 above)

John, I always use SDBG64 and directly run only programs compiled with /NOCHECK. By the way typing 'SDBG64 Program.exe' or 'SDBG Program.exe' is the same, SDBG/SDBG64 recognize 32/64 bit programs automatically

__return_pstack_ptr may be called by programs compiled with FTN95 /64.

This function is located in any clearwin64.dll built after 10 April 2024.

If it is missing when you run your application then you must be accessing a clearwin64.dll that was built before this date.

Search your computer to find out where your DLLs are located and which versions are currently being accessed.

Now compiler distinguish cap/noncap letters ?

No it makes no difference.

You need to find a way to ensure that the latest clearwin64.dll is the one that is accessed by your application.

There are various ways to do this. You could rename the ones that you don't want to use. This is better than deleting them in case you need to backtrack.

Paul, If someone here wants to see one of images of devilry it is above just in front of your eyes on the green field. This is of the same sort of things how due to quality control issue USA lost the Venus planet space race to USSR when just one single letter in the Fortran source code caused Mariner 1 to crash. Same multiyear problem we had before with the older DLLs in the path.

Anyway, after cleaning this devilry the other codes compile and run OK but one code still crash the compiler. This is latest pic for this if this tells you anything

Runtime error from program:c:\program files (x86)\silverfrost\ftn95\ftn95.exe
Access Violation
The instruction at address 100540eb attempted to read from location 00000000

 100540d5 load_resource(<ptr>char,enumÄresource_type,enumÄlogical)#70 [+0016]

 10054e2a size_bitmap(<ptr>void,<ptr>char,<ref>int,<ref>int)#70 [+002d]

 1006120b get_icon(<ref>(<ptr>char),<ref>(<ptr>char),<ref>enumÄlogical,<ptr>structÄwindow [+0152]

 100c2dda do_format_code(<ref>(<ptr>char),<ref>(<ptr>char),int,int,int,enumÄlogical,enumÄ [+1179]

 100d60b7 __winio [+0ba3]

 0058cb6d do_winio_check(<ptr>structÄtree_record,enumÄlogical) [+052f]

 0058d1de amd_do_function(<ptr>structÄtree_record) [+00e7]

 005842ôì;d
eax=00000000   ebx=00000000   ecx=03e8d844
edx=03e8d3c4   esi=00000000   edi=03e8d828
ebp=03e8d790   esp=03e8d634   IOPL=0
ds=002b   es=002b   fs=006b
gs=0063   cs=0023   ss=002b
flgs=00210202 [NC OP NZ SN DN NV]

 100540eb  cmpb     [ebx],0x7b 
 100540ee  jne      1005423d 
 100540f4  push     0xf0f0f0f0 

Dan,

show us the results of: Runtime error from program:c:\program files (x86)\silverfrost\ftn95_905\ftn95.exe

(after you rebuild all binaries with the revised FTN95 compiler path settings !)

If you are doing this path update, also make sure that you update any toolbar links to the correct path (expecially for plato and sdbg64)

The picture above shows that compiler itself crashes when compiling the program even after i fixed manually capital/lower case letters conflict. Nothing is generated after crash. The 903 also had the same cap/lowercase letters conflict. And before that salflibc64 and SALFLIBC64 were also in lower and upper case letters. All that i suppose was making ever lasting conflict of permanent presence of not the same dates compiler system subroutines.

Dan,

What I am trying to suggest to you is that in the directory 'C:\Program Files (x86)\Silverfrost\' you should have multiple versions of ftn95, for example : C:\Program Files (x86)\Silverfrost\ftn95_8.91 C:\Program Files (x86)\Silverfrost\ftn95_9.00 C:\Program Files (x86)\Silverfrost\ftn95_9.03 C:\Program Files (x86)\Silverfrost\ftn95_9.05

By changing the system 'PATH' environment variable, you can then adjust which version of the FTN95 compiler and importantly have some control so that each version is consistent within itself.

This may help you to identify the source of the problem.

At the moment you appear to be suggesting that the compiler version you are using has an ICE, but are not clearly identifying what version of the compiler it is or providing a small reproducer to help identify the problem.

I am left to assume that the compiler version you are using is assembled from an inconsistent set of files.

When updating to a new compiler version, I try to generate the update from either:

1. a complete download from silverfrost.com, or
2. create a new ftn95 tree copy and then copy all files from the support: https://forums.silverfrost.com/Forum/Topic/3780

A sample from my system environment variables include: set f95.ver=9.04F set f95_dir=%ProgramFiles(x86)%\Silverfrost\ftn95_%f95.ver% set f95include=%f95_dir%\include set ftn95_path=%f95_dir% set mod_path=%f95_dir%\include set path=%gcc_path%;%f95_path%;%orig_path%;C:\utils;

( note: the order of processing these system environment variables can be a challenge to manage )

Dan

By default, file names are not case-sensitive under Windows. So Windows should have prevented you from having files with the same case-insensitive name in the same folder.

It is possible to set a flag on a folder in order to make its files case sensitive but this is not the default behaviour. Pehaps Linux allows case sensitive differences.

In short, there appears to be something wrong with the way that you are working. We currently do not offer support for systems other than Windows.

Paul, Windows so far did not care about capital/lower case names of files. But Windows is in decline. PC sales too. Chrome, Android, iOS take the world, all are UNIX and Linux based. Chrome based laptops still minors but because they cost 3x less they with time will eat Windows share to the root. Only one Windows supercomputer is left in the Top500 list, the rest are on Linux. People slowly start using and mixing Linux, iOS and Windows in virtual environment. Even Windows itself offering virtualization where you can have different OSes. I was first who encountered this capital/lowercase letters conflict. 99 others whom i call procrastinators will not come here and report it but just silently flee to other compilers

Dan

This will be my last attempt to try to persuade you to avoid using folders that contain DLLs with duplicate (case insensitive) names. A folder containing ClearWin64.dll must not also contain clearwin64.dll.

It makes no difference if you are working under Windows or Linux. When linking, SLINK64 will link to the first DLL that it finds (case insensitive). Likewise your application will load the first DLL at load time.

So if the version of first DLL found is older than that of the compiler, you can get this kind of issue and (in this case) that is what has happened.

No change to FTN95 or SLINK64 will fix this issue.