forums.silverfrost.com

sigment · Joined: 17 Dec 2007 Posts: 10

Hi,

The program below gives different results with /OPTIMISE but shouldn't.
I am running FTN95 5.21. This is a very serious bug that will break a lot of code.

PaulLaidler · Posted: Fri Aug 22, 2008 8:10 am Post subject:

Thank you for reporting this bug.
As a temporary work-around you can use /inhibit_opt 30.

LitusSaxonicum · Posted: Tue Aug 26, 2008 1:28 pm Post subject:

Clearly a bug, and clearly deserving attention. Certainly a bug that could cause a lot of code written to 90 or 95 standards to misbehave. However, if one codes this in Fortran-77 (or earlier) style � with a GOTO � it works perfectly.

On reading the helpfile (FTN95.chm), I saw that the presence of GOTO inhibits optimisation. Is it therefore the case that the code with a GOTO is simply not optimised, which is why it works? With so few loop iterations, it is difficult to see the effect on runtime of the optimiser. I presume that it is significant.

I also experimented with doing something with I, as apart from printing the values, I and J aren�t used. If I put K=I above the inner loop, and then printed A(K) not A(I), the optimised code also worked.

The machinations of the optimiser are a mystery.

As far as using /INHIBIT_OPT30 goes, where does one find a list of optimisations and their numbers? This option is undocumented � are there any other useful facilities of this type? How one would decide which optimisations to �inhibit� is a difficult question. Is there not a case to be made for dividing/grouping optimisations into classes, such as �completely safe�, �probably safe�, �possibly unsafe� and permitting the programmer to select which level to employ? I recollect that MS Fortran did something of the sort.

Eddie

PaulLaidler · Posted: Tue Aug 26, 2008 4:41 pm Post subject:

FTN95 carries out significant optimisation even when /OPT is not used.
Many of the extra optimisations are concerned with reducing the number of register transfers at machine code level. You should always do some test runs and timings with and without /OPT before using /OPT for your permanent release.

/INHIBIT_OPT is not intended for general use and so remains undocumented.

We recognise this as a significant bug and plan to fix it as soon as possible.

LitusSaxonicum · Posted: Wed Aug 27, 2008 5:10 pm Post subject:

Paul,

I wasn't suggesting that INHIBIT_OPT went on general release!

It is clear from your answer that (internally at least) optimisations are seen in two categories: those that are safe to unleash on the run-of-the-mill user, and those that need to be deliberately invoked (and therefore must implicitly contain some risk of unintended side effects, else why not include them in the former category). It therefore isn't surprising to me that there are cases where optimisation doesn't work, but this is a particularly simple case that one would expect to.

You didn't answer as to whether the GOTO equivalent works because the optimisation isn't applied, or whether it is applied and it works with GOTO and not CYCLE.

Eddie