forums.silverfrost.com

[DanRRight]

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.

[JohnCampbell]

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:
a) a complete download from silverfrost.com, or
b) create a new ftn95 tree copy and then copy all files from the support: http://forums.silverfrost.com/viewtopic.php?t=4245

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 )

[PaulLaidler]

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.

[DanRRight]

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

[PaulLaidler]

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.