forums.silverfrost.com

PaulLaidler · Posted: Wed Jan 31, 2018 11:09 am Post subject:

The issue has not been resolved yet. In cases like this we would aim to have a fix in place for the next full release (which will be v8.30). We normally have one or two full releases in a given calendar year. The personal edition (which is free) may be released less frequently. The last full release was in November 2017.

narayanamoorthy_k · Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN

PaulLaidler · Posted: Wed Jan 31, 2018 3:37 pm Post subject:

Moorthy

I don't have any further information on this at the moment.

PaulLaidler · Posted: Wed Jan 31, 2018 7:26 pm Post subject:

This bug in FTN95 has now been fixed for the next release.

LitusSaxonicum · Posted: Sun Feb 04, 2018 6:56 pm Post subject:

Just out of interest:

Routine A calls a subroutine B with the statement:

LitusSaxonicum · Posted: Mon Feb 05, 2018 10:26 am Post subject:

There are more things in heaven and earth, John, than are dreamt of in your philosophy. Now who said that?

The point is that the error message, while true, is unhelpful to a user who has no knowledge of the workings of the compiler. Would IMPLICIT NONE show up the error? Maybe, but a programmer declaring RGB@ to be REAL would also get it. Using the appropriate INCLUDE at least makes sure that the types of all Clearwin+ entities are correctly declared, whether they are used or not.

The floating point stack fault may, indeed, result from FTN95 generating code that upsets the x87 stack, but it can also be generated by the programmer making a mistake.

Eddie

LitusSaxonicum · Posted: Tue Feb 06, 2018 12:15 pm Post subject:

In pointing out the symptom that caused the program not to function, and in protecting the computer from side effects such as destabilizing Windows, Paul & Co have done their job. It's a cultural thing, but I have sensed in the past that whereas we Fortran users see this as a crash, a crash means something else at the compiler programming end - what has been produced is a sensible and proper report and conclusion to trapping something wrong. The fact that it is written in Klingon doesn't mean that it isn't clear to Klingons.

The deep gulf is the result of the lack of a dictionary-manual that explains what it all means, perhaps giving hints on where to look and what to do about it. I'm not sure that a homily on what a bad boy or girl or whatever you've been really cuts it nowadays in the absence of corporal punishment. On the grounds that FTN95.CHM is hard enough to get through, perhaps the answer is another file like CWPLUS.ENH (That was intended to be a serious suggestion).

I'll make a couple of suggestions for it:

1. Floating point stack fault

(a) You passed a function to a subprogram without declaring the type of the function correctly when necessary. (NB, Clearwin+ routines are not intrinsic functions).
(b) Something went wrong with FTN95 (rare).
(c) It is devilry. Exorcists can be found via Google.

2. Floating point divide by zero (floating point coprocessor fault)

(a) You divided something by zero. (Win32). If you test all denominators against zero, you will get compiler warnings, but can trap this condition for yourself. An alternative is to test ABS(denominator) .LT. TINY(denominator), which doesn't give a compiler warning but does do the test.
(b) You divided something by an uninitialised static variable, (because FTN95 sets those to zero).
(c) It is devilry. Exorcists can be found via Google.

The serious point is that there's no middle ground document to explain what some of the more arcane error messages actually mean. Perhaps there should be. Perhaps it's up to the user base. You know who that means.

Eddie