forums.silverfrost.com

In the following program, a type declaration (LOGICAL) is missing for the only variable in the program. Despite the IMPLICIT NONE, the compiler thinks that the variable is implicitly typed as real.
...

As for No. 2, why does that cause problems? Just asking.

Here is an example. Before you compile and run it, think out the answer, and compare that with what the program actually gives. Note that ...

Lack of robustness is not just the compiler's fault. It can be caused by, for example:

1. Assuming that local variables are saved in some subroutines

2. Aliased actual arguments

3. Call ...

Eddie, you make some excellent points in this post.

Optimizer bugs are elusive, hard to preserve while cutting away chunks of source code (in order to prepare a reproducer that is small enough to ...

Sorry, the trick (assigning values of sub-expressions to new variables and then summing the variables) that you suggested is a risky solution. It works sometimes, fooling you into thinking that it is ...

Jcherw: You may find this older thread relevant to your question regarding the performance of linear equation solvers.

http://forums.silverfrost.com/viewtopic.php?t=3063

In that thread, Joh ...

I revisited this thread while working on a different program that reminded me of this bug, and I find that a related bug still affects the 8.51 compiler, with a twist.

As Paul noted, the erroneous ...

The standard reference for transcendental functions is Abramowitz and Stegun, see http://people.math.sfu.ca/~cbm/aands/abramowitz_and_stegun.pdf ; see Chap. 7 for ERF. Netlib is the source for Fortra ...

Eddie, I am not desperate at all, I am ready for Brexit or no Brexit. I have other compilers to use for such situations.

In the actual code where I noticed the problem, the Polyhedron AerMod benchm ...

Thanks; that listing does not exhibit the bug with the unsaved register being used across the function call.

I'll wait for the next version of the compiler.

It crashed with an access violation, since it tried to read memory at absolute address 00000003. The crash is at ERFDIF + 00000027.

I compiled with /opt /p6. Without /opt, the bug does not occur.
...

For the following program, FTN95 V 8.51 generates bad X86 code code when the options /opt /p6 are used.

program terfdif
print *,erfdif(0.6, 0.4)
end program

fun ...

BUT...

Polyhedron did not build for X64 (at least on the page for which I gave a link above). Below the table, under "Compiler switches", you can see for FTN95:
FTN95 ftn95 /p6 /optimize ...

The 64 bit Polyhedron benchmark tests for FTN95 use v8.05 but optimisation was not introduced until v8.10. As I recall, we forgot to disable the switch in v8.05 so this is not to criticise Polyhedro ...

If, indeed, the tridiagonal solution is the main bottleneck, try using the MKL/Lapack routine ?GTSV instead of your own routine. You can call MKL routines from your FTN95 compiled program quite easily ...