Lahey/Fujitsu Linux64 Fortran v8.1
Speed – Dependability – Great Tech Support.
Lahey Computer Systems Inc. have combined 39 years of producing award-winning Fortran language systems with Fujitsu’s compiler expertise and high-performance code generator to deliver the most-productive, best-supported Fortran 95 language system for the PC.
Whether you write new Fortran programs or downsize existing applications, you need speed, dependability, and great tech support.
LF64 v8.1 Delivers!
Important features include …
- Intel EM64T and AMD AMD64 64-bit optimizations
- Unsurpassed global compile-time and runtime diagnostics
- Automatic Parallelization
- OpenMP Support
- Wisk, Winteracter Starter Kit – Graphics package
- Small and medium memory models
- BLAS and LAPACK v4.0 routines – thread-safe
- Fujitsu’s SSL2 math library – thread-safe
- Fujitsu’s FDB debugger
- Automake, automatic make utility
LF64 v8.1 is available in two configurations, Express and PRO:
LF64 Express includes the powerful Lahey/Fujitsu Fortran 95 optimizing compiler, command line debugger, online documentation, and free e-mail support.
- LF64 Performance.
- LF64 Optimizations.
- Link GNU C and assembly object files.
- Legacy Fortran Support.
- ANSI/ISO-Compliant Fortran 95.
- Free Technical Support.
LF64 PRO adds auto-parallelization, OpenMP compatibility, the Winteracter Starter Kit, WiSK, for creating Windows GUIs and displaying graphics, thread-safe BLAS and LAPACK, Polyhedron’s Automake utility, and the Fujitsu SSL2 math library (thread-safe for parallel applications).
- OpenMP compatibility
- Winteracter Starter Kit.
- BLAS and LAPACK
- Fujitsu Scientific Subroutine Library 2
- Free Technical Support
“Polyhedron ran our suite of Fortran benchmarks on a Pentium D820 dual core 2.8 GHz processor, with 2 x 1MB L2 cache and 800 MHz FSB, and running SUSE 9.3 Linux. Specifying the switch –fast, the benchmarks ran an average of 21.8% faster than they did when built with LF95 Linux v6.2. Try LF64 v8.1 on your code today! “
- Constant folding
- Common subexpression elimination
- Copy propagation
- Strength Reduction
- Algebraic simplifications
- Dead code elimination
- Peephole optimization
- Loop invariant code motion
- Transform array element to simple variable
- Local Instruction scheduling
- Address calculation optimization
Program Reconstruction Optimizations
- Loop unrolling
- Loop interchange
- Inlining mathematical functions
- Stack optimization
- SSE2 and SSE3 instructions
- Prefetch instructions
- Using fast input/output libraries
Link GNU C and assembly object files
LF64 supports static linking with GNU C or assembly. Combine your Fortran and C/C++ code into one executable. For the routines you don’t want to develop yourself, you can also link with C/C++ routines from commercially available libraries.
Legacy Fortran Support
LF64 extends its language support in other directions adding many legacy Fortran features, including VAX structures and the various UNIX service routines. These features further facilitate your move to cost/performance efficiency on the PC platform:
- Unlimited number of continuation lines in free or fixed source form
- DO UNTIL statement
- FIND statement
- STRUCTURE and END STRUCTURE statements
- UNION and END UNION statements
- MAP and END MAP statements
- RECORD statement
- Non-standard POINTER statement
- AUTOMATIC statement
- STATIC statement
- VALUE statement
- BYTE statement
- Hollerith constants
- Alternative forms of binary, octal, and hexadecimal constants
- Binary, octal, or hexadecimal constants in a DATA, declaration statement
- Period structure component separator
- IMPLICIT UNDEFINED statement
- Namelist input/output on internal file
- FORM = ‘BINARY’
- TOTALREC specifier
- STATUS = ‘SHR’
- Gw, $, , and R edit descriptors
- LOC intrinsic function
- The following service subroutines: ABORT, BIC, BIS, CLOCK, CLOCKM, CLOCKV, DATE, ERROR, ERRSAV, ERRSET, ERRSTR, ERRTRA, EXIT, FDATE, FLUSH, FREE, GETARG, GETCL, GETDAT, GETENV, GETLOG, GETPARM, GETTIM, GETTOD, GMTIME, IBTOD, IDATE, IETOM, IOSTAT_MSG, ITIME, IVALUE, LTIME, MTOIE, PERROR, PRECFILL, PRNSET, PROMPT, QSORT, REDLEN, SETBIT, SETRCD, SLEEP, SLITE, SLITET, TIMER
- The following service functions: ACCESS, ALARM, BIT, CHDIR, CHMOD, CTIME, DRAND, DTIME, ETIME, FGETC, FORK, FPUTC, FSEEK, FSEEKO64, FSTAT, FSTAT64, FTELL, FTELLO64, GETC, GETCWD, GETFD, GETGID, GETPID, GETUID, HOSTNM, IARGC, IERRNO, INMAX, IOINIT, IRAND, ISATTY, JDATE, KILL, LINK, LNBLNK, LONG, LSTAT, LSTAT64, MALLOC, NARGS, PUTC, RAN, RAND, RENAME, RINDEX, RTC, SECNDS, SECOND, SH, SHORT, SIGNAL, STAT, STAT64, SYMLNK, SYSTEM, TCLOSE, TIME, TIMEF, TTYNAM, UNLINK, WAIT
ANSI/ISO-Compliant Fortran 95
LF64 is a complete implementation of the ANSI/ISO Fortran 95 standard. Fortran 95 offers some small but important improvements over Fortran 90, including the ability to create your own elemental procedures, default initialization for structure components, the NULL intrinsic for initializing pointers, the FORALL construct, and a standard CPU_TIME intrinsic procedure.
The LF64 compiler automatically parallelizes DO loops and array operations without you having to make modifications to the program. This makes it easy to migrate source programs to other platforms (as long as the program conforms with the Fortran Standard). The effect is to save elapsed execution time by using two or more CPUs simultaneously. For instance, if a DO loop can be executed in parallel by dividing it in half, then, theoretically, the execution time of this DO loop may be cut in half. In practice, improving performance requires some care and some work on the part of the programmer. During compilation, the auto-parallel function will return information regarding which processes were (and which were not) parallelized and why. While certain loops can be analyzed sufficiently to be parallelized by the compiler without input from the programmer, many loops have data dependencies that prevent automatic parallelization because of the potential for incorrect results. For that reason, LF64 PRO also includes optimization control lines (OCLs) that provide information necessary for the compiler to parallelize these otherwise unparallelizable loops. The OCLs are Fortran comments in a particular format, for example:
Note that programs with OCLs are standard-conforming and can be compiled with other compilers that do not support OCLs.
Four compiler switches control automatic parallelization: –parallel, –threads, –threadstack, and –ocl. Details of automatic parallelization (loop slicing, interchange, distribution, fusion, and reduction, as well as OCL syntax and specifiers) are documented in the LF64 User’s Guide and at www.lahey.com/doc.htm.
OpenMP v2.0 Compatibility
OpenMP specifies a set of compiler directives, library routines, and environment variables for shared-memory parallelism in Fortran and C/C++ programs. LF64 PRO v8.1 supports the OpenMP v2.0 specification for Fortran. Like automatic parallelization, OpenMP directives are used to parallelize a program that runs on a computer with more than one processor. With OpenMP you have more control over how code is parallelized, but also more coding to do.
Winteracter Starter Kit
Use the Winteracter Starter Kit – WiSK – for creating true X/Windows programs with Fortran. WiSK is a subset of the X/Winteracter Library created by Interactive Software Services, Ltd. (X/Winteracter is available from Lahey.) X/Winteracter is a Fortran 95-callable, 64-bit, X/Windows, user-interface and graphics development kit. Derived from X/Winteracter, WiSK provides a library of subroutines for window management, input handling, dialog management, and high resolution graphics. Designed for use with X11R6 and Open Motif 2.2.
X/Winteracter offers a wide range of powerful GUI capabilities to the Fortran 9x developer under X Windows, including:
- Multiple windows.
- Memory bitmap manipulation & bitmap viewer windows.
- Text editor windows, with optional command lines.
- Event handling.
- Text based menus, including floating menus (toolbars have still to be implemented).
- Dialog handling, including tabbed dialogs and nearly all control types (grid controls are the current exception).
- Common dialogs, e.g. file selector, message box, etc.
- Presentation graphics.
- and more!
Below are examples of WiSK’s capabilities:
BLAS and LAPACK
BLAS is a library for vector and matrix operations. The BLAS thread-safe version is based on BLAS provided on Netlib. BLAS includes 57 functions. The total number of routines for all precision types amounts to approximately 170.
BLAS thread-safe version provides the following routines:
Level 1 BLAS : Vector operations
Level 2 BLAS : Matrix and vector operations
Level 3 BLAS : Matrix and matrix operations
Sparse-BLAS : Sparse vector operations
The thread-safe implementation of BLAS has exactly the same subroutine names and calling parameters as those of the Netlib baseline version.
- the thread-safe version can be used in the environment of SMP (Symmetric Multiple Processing)
- subroutines of the thread-safe version can be called from an OpenMP Fortran program
The purpose of using BLAS thread-safe version is to have a subroutine concurrently perform operations on different sets of data that are independent from each other, and thus reduce the time necessary to finish all the operations.
LAPACK is a library of linear algebra routines. The LAPACK thread-safe version is based on LAPACK 3.0 provided on Netlib. LAPACK includes approximately 300 functions. The total number of routines for all precision types amounts to approximately 1100.
LAPACK provides the following routines:
- Linear equations
- Linear least squares problems
- Eigenvalue problems
- Singular value decomposition
The LAPACK thread-safe version, like the BLAS version, can be called from an OpenMP program in the environment of SMP.
Fujitsu Scientific Subroutine Library 2
The Fujitsu Scientific Subroutine Library 2 (SSL2) has been in use for years in Japan on Fujitsu mainframe and workstation hardware. SSL2 offers over 250 optimized thread-safe routines in the following areas:
Matrix Storage Mode Conversion
Linear Equations and Matrix Inversion (Direct Method)
Least Squares Solution
Eigenvalues and Eigenvectors
Eigenvalues and Eigenvectors of a Real Matrix
Eigenvalues and Eigenvectors of a Complex Matrix
Eigenvalues and Eigenvectors of a Real Symmetric Matrix
Eigenvalues and Eigenvectors of a Hermitian Matrix
Eigenvalues and Eigenvectors of a Real Symmetric Band Matrix
Eigenvalues and Eigenvectors of a Real Symmetric Generalized Eigenproblem
Eigenvalues and Eigenvectors of a Real Symmetric Band Generalized Eigenproblem
Nonlinear Simultaneous Equations
Minimization of Function with a Variable
Unconstrained Minimization of Multivariable Function
Unconstrained Minimization of Sum of Squares of Functions (Nonlinear Least Squares Solution)
Nonlinear Programming (Constrained Minimization of Multivariable Function)
Interpolation and Approximation
Discrete Real Fourier Transforms
Discrete Cosine Transforms
Discrete Sine Transforms
Discrete Complex Fourier Transforms
Numerical Differentiation and Quadrature
Sine and Cosine Integrals
Normal Distribution Functions
Pseudo Random Numbers
Pseudo Random Generation
Pseudo Random Testing
- Intel© EM64T or AMD© AMD64 64-bit processor.
- 32 MB of RAM.
- 70 MB of available hard disk space for LF64 Linux PRO; 40 MB for LF64 Linux Express.
- X-Windows to use WiSK and view the online PDF documentation.
- 64-bit version of as, the GNU assembler.
- 64-bit version of ld, the GNU linker.
- 64-bit versions of C startup and support object files crt1.o, crti.o, crtn.o, crtbegin. o, and crtend.o.
- 64-bit versions of C runtime and support libraries libc, libm, libpthread, librt, libgcc, libgcc_eh, libgcc_s, and libelf.
- A compatible version of the Linux operating system. Table 1 shows the versions of Linux that are known to be compatible with LF64. Other Linux variants might be compatible if they include kernel version 2.6.9 or later and libc version 2.3.4 or later.
LF64 v8.1 supported distributions
|Open SUSE 10.3||2.6.22||2.6.1|
Computer Transition Systems
P.O. Box 4553
Microcenter RC – Brasil
Ravenholm Computing A/S
Micro Sigma S.A.
SOS Software Service GmbH
Daishin Electric Inc.
Mr. Menso de Jong
NL-2012 PG Haarlem
P.O. Box 674
NL-2100 AR Heemstede
Scientific Formosa, Inc.
Origin is a software application for data analysis and publication-quality graphing, tailored to the needs of scientists and engineers. The application offers an easy-to-use interface for beginners, and the ability for advanced users to customize analysis and graphing tasks using themes, templates, custom reports, batch processing and programming.
OriginPro offers all of the features of Origin plus extended analysis tools in the following areas:
- Peak Fitting
- Surface Fitting
- Signal Processing
- Image Processing
With over 100 built-in graph types, Origin makes it easy to create and customize publication-quality graphs. You can simply start with a built-in graph template and then customize every element of your graph to suit your needs. Easily add additional axes, as well as multiple panels/layers to your graph page. Save your settings as a custom template for repeat use.
Once your graph is customized to look exactly the way you want it to be, export your graph for publications in many raster or vector formats, copy-paste to other applications, use Origin’s slide-show capability to present your graphs, or simply export all graphs to PowerPoint.
Please select an area from the list below to learn more about our various graph types:
- Column, Bar & Pie
- Line & Symbol
Origin contains powerful tools for all of your analytic needs, including peak analysis, curve fitting, statistics, and signal processing. To make data analysis more efficient, Origin supports many common formats for importing data, and exporting results. Multi-sheet workbooks and an integrated Project Explorer help you organize your Origin projects. Streamline your workflow by saving workbooks as analysis templates for repeat use.
- Curve Fitting
- Peak Analysis
- Signal Processing
- Image Processing
Origin includes two built-in programming languages: Origin C, a C-based compiled language, and a scripting language called LabTalk™. Use them to automate graphing and analysis. Origin comes with an Integrated Development Environment (IDE), Code Builder , that makes it easy to write and debug your own code. Origin is also an Automation Server for users of VB, C++, C# and LabVIEW™.
- Origin C
- Automation Server
- Developer Kit
qtConsole – A Fortran Library for Configuring the Output to Windows’ Console
Standard Fortran does not offer any way to alter the output to the Windows Console (DOS box) when using READ and WRITE’s. qtConsole offers the programmer various ways to configure the output including:
- Coloured text and numbers
- Positioning the cursor
- Clearing the console.
- Position the console window relative to the desktop
- Change of the number of character rows and columns to be buffered by a console.
Most Fortran programs use READ(*,…), PRINT and WRITE(*,…) statements for console output (under Windows the console is also referred to as the DOS box, DOS command window). The Fortran standard stipulates the use of one single colour (usually white text on black background). But, with the qtConsole function qtConSetTextColor a foreground and background colour can be set (256 colour combinations are at your disposal). With this, your PRINT and WRITE(*,…) commands will output coloured texts and numbers.
Additionally, the function qtConWrite allows the position of text output (by row and column specification). With this, you may highlight texts and numbers, so you can catch the users attention, for example, if a value runs out of range.
Also, the size of the console and the size of the console window can be controlled. To clear the console, simply call qtConClearConsole.
If you think the console’s cursor is too small – default size is usually 25% of the font size – change its size ny calling qtConSetConsoleCursorSize, for example to maximize it to 100%. Or if you want to make the cursor invisible, give it a size of 0.
Within the coordinates range of a console the cursor can be positioned calling qtConSetCursorPosition. Then, the output of a PRINT and WRITE(*,…) command starts at the cursor position set. Or a READ(*,…) command expects user input starting at that cursor position.
Here is complete overview of the qtConsole functions:
|Console Size and Position|
|qtConGetConsoleBufferSize||Get the size (rows and columns) of the internal console buffer|
|qtConSetConsoleBufferSize||Change the size (rows and columns) of the internal console buffer|
|qtConGetConsoleCoordinatesRange||Get the console coordinates’ range|
|qtConGetLargestConsoleWindowSize||Get the maximum size of the console window|
|qtConGetConsoleWindowCoordinates||Get the coordinates of the console window (relative to the desktop)|
|qtChangeConsole||Change the size of the console window|
|qtConSetConsoleWindowPosition||Position the console window (relative to the desktop)|
|qtConGetPrimaryScreenSize||Get the resolution of the primary screen|
|qtConGetCursorPosition||Get cursor’s position|
|qtConGetConsoleCursorSize||Get size of the cursor|
|qtConSetConsoleCursorSize||Set cursor’s size (0 – 100)|
|qtConGetTextColor||Get active color (used for output)|
|qtConSetTextColor||Set active color (for subsequent output)|
|qtConConvertToColorValue||Convert color code into an integer value|
|qtConWrite||Output text, optionally position|
|qtConClearConsole||Clear the console|
|qtConSetConsoleWindowTitle||Change the title of the console window (caption)|
|qtConFlushConsoleInputBuffer||Flush the console input buffer (clears READ buffer)|
|qtConGetErrorInformation||Get the meaning of an error code|
Scope of Supply
qtConsole consists of a static library (.lib) and several pre-compiled MODULE files (.mod). The functions and their usage is described in the manual (PDF), including examples and several illustrations.
To ease usage, a demonstration program (Ex01.f90) is provided, that demonstrates many essential functions. For all compiler systems that are supported (see below) ready-to-use projects are provided, that include the demo program and all the other files needed. So, after loading the project, a “Build” will create the demo program (Ex01.exe). Compare the “Instructions for Installation and First Usage” below.
At present the following variants exist:
- Compaq Visual Fortran v6.6
- Intel Visual Fortran (Win32) v10.1 and higher
- Silverfrost FTN95 (Win32) v5.5 and higher
It may be that compatible compilers can use qtConsole too. Try yourself using the evaluation version (see below). If you own a compiler that is not supported by qtConsole, but you would like to have a binding for this, let us know (mailto:email@example.com). If there is sufficient demand, we will try to develop a version for your compiler.
You can download an evaluation copy here which has a few functional limitation (1) including the manual (PDF (2); download size: about 1.6 MB):
qtConsole.zip or as self extracting archive
- Create a directory on your PC (e.g. C:qtConsole).
- Copy the file you have downloaded into this directory.
- Unzip this file into this directory.
- Then you are ready to start one of the files suitable to your development system: CVFEx01Ex01.dsw, IVFEx01Ex01.sln, or FTN95Ex01Ex01.ftn95p (a double click on the file symbol in Windows File Explorer should start-up your development environment), which create the demo program Ex01.exe.
- After this perform a “Build”.
- The Ex01.exe should be built and you can run it.
(1) The evaluation copy allows the usage of all functions until the end of the year. When starting a program that calls qtConsole functions a message box pops up at the beginning which displays a message accordingly. On purchase of a qtConsole Licence you will receive a licence file, which activates the “full version”, that can be used without limitation (no message box, no time limit).
The evaluation copy is converted into a fully functioning version by purchase of a qtConsole licence (no re-installation necessary).
A qtConsole licence grants a single named user (the licensee) the usage of the qtConsole software (single user licence) for to create applications (.exe) that he/she may distribute freely. This means, there are no runtime fees or any other royalties to be paid additionally. The complete licence conditions are to be found in the manual.
The licence is supplied (QTCON.0010) by sending a licence file via email. The licence file contains the data the licensee specifies (name and address), the licence number, and the licence key.
To use the qtConsole software the following is needed
- PC running Windows, hard disk with about 6 MB available.
- One of the following operating systems: Microsoft Windows 2000, Windows 2003, Windows XP, Windows Vista, Windows 7.
- A Fortran compiler system as supported (see above).
The qtXLS Library offers the programmer routines to access files in the Microsoft Excel format (.xls).
New: 32 and 64-bit versions for Intel Visual Fortran (see release notes).
With qtXLS routines you can
||create files in the Excel data format|
||create tables (sheets) in these files|
||write data to tables (sheets)|
||read data from tables (sheets)|
||enquire information about tables (sheets) and columns|
To perform these functions the library provides you with the following routines:
|Function group / qtXLS routine||Function|
|qtXLSCreateEXCELFile||Create Excel file|
|qtXLSOpenEXCELFile||Open Excel file|
|qtXLSCloseEXCELFile||Close Excel file|
|qtXLSCreateTable||Create a table (sheet) and define columns|
|qtXLSReadRows||Read rows from table (sheet)|
|qtXLSWriteRows||Write rows to table (sheet)|
|qtXLSGetTableNames||Get table (sheet) names in the file|
|qtXLSDoesTableNameExist||Check if a table (sheet) name exists|
|qtXLSGetColumnInfo||Enquire information about columns|
|qtXLSGetRowCount||Enquire number of rows in a table (sheet)|
|qtXLSGetNumericValue||Convert the value of a SQL numeric type into a real value|
|Error handling functions|
|qtXLSGetErrorMessages||Get error messages|
|qtXLSSetErrorLevel||Control error handling|
|qtXLSSetErrorMessagesDisplay||Set up display of error messages|
|qtXLSGetszStringLength||Get length of a null-terminated string|
|qtSetLicence_qtXLS||Authorize usage of qtXLS (Fortran only)|
|qtXLSSetLicencePath||Set path for licence file|
The example program
qtXLSDemoWriteTable.f90 (Fortran 90 source file)
qtXLSDemoWriteTable.cpp (C/C++ source file)
creates the following Excel sheet. The program demonstrates how the qtXLS routines are used.
The qtXLS software is provided as a dynamic-link-library (qtXLS.dll) together with bindings determined to use with your compiler (import libraries and other files necessary to compile and link).
Supported Compiler Systems (Bindings)
At present the following compilers are supported
- Absoft ProFortran for Windows v10.0
- Compaq Visual Fortran v6.6
- Intel Visual Fortran (v8.1, v9.x)
- Lahey/Fujitsu Fortran for Windows (LF95) v5.7
- Microsoft Visual C++ v6 and v7 (2003)
- Silverfrost / Salford FTN95 (for Win32) v5.0 and later
These binding may also be suitable for newer versions of the compilers and possibly also for compatible compilers. If your compiler is not listed, but you would like to use qtXLS nevertheless, simply try out the binding anyway to which your compiler manufacturer claims to be compatible.
You can download an evaluation copy of qtXLS (software and documentation in PDF format (2)). The software is limited in function (1). Size of the download file approx. 4 MB
(1) The evaluation copy allows to import and export of rows limited to 50 rows of a single table (sheet). Upon start of a program based on qtXLS there will be a message informing about this limitation.
(2) The Adobe Acrobat Reader (to read documents in PDF format) is to be found here.
Prices & Licensing
The evaluation copy can be changed into a version without limitation (1) by purchase of a qtXLS licence.
The licence allows you to use the qtXLS software for the development of programs, i.e. to create executable files (.exe). In addition, the licence covers the right to the passing on of the qtXLS.dll as well as the licence file (that you will receive on purchase of qtXLS). This means, there are no royalty or run-time fees to pay.
We deliver the licence (QTXLS.0010) by sending a licence file via Mail (no shipping costs apply). The licence file contains the data specified by you (for example, name and address), a licence number and a licence key.
IIF you prefer to obtain qtXLS on a CD-ROM together with a manual, order both items QTXLS.0010 and QTXLS.0100 (the licence file will be put on the CD-ROM).
To be able to use the qtXLS software, the following is required::
- PC with a Pentium processor, hard disk with at least 15 MB memory available, a minimum of 32 MB RAM.
- One of the following operating systems: Microsoft Windows 95, Windows 98, Windows NT 4.0, Windows 2000, 2003, Windows XP and compatible.
qtXLS is based on Microsoft Excel ODBC drivers. At installation of Excel these are usually installed. If these drivers are missing, they are either supplied by installation of Microsoft Excel or by installation of the
This is probably the cheaper alternative, because the MDAC can be downloaded for free from Microsoft’s WebSite. If the link above doesn’t help you to find them, try the search function in Microsoft’s “Download Center”.
Of course, besides the above, a compiler system is needed (see the list of supported compilers above).
Access Databases and Spreadsheets in Fortran on a PC under Windows
With ForDBC the Fortran programmer can read and write tables of any database for which an ODBC driver is supplied.
Most databases, such as Oracle, Microsoft, IBM and Sybase, are equipped with an ODBC driver (ODBC=Open Database Connectivity Standard). This is also true for spreadsheets: Excel and Lotus.
Under Windows an ODBC interface is available. However the ODBC functions are not easy to access by a Fortran programmer because the documentation and the tools supplied by Microsoft are designed for C/C++ or VB programmers. ForDBC offers help! The Fortran interface provided by ForDBC is almost complete with respect to the ODBC v3.5 specification. This means that with ForDBC you can call all of these ODBC functions as if they were programmed in Fortran. Furthermore hundreds of ODBC and SQL specific constants are supplied. Simply include them in your Fortran program the source line
and you are ready to use the ODBC functions and constants as you find them documented in the Windows ODBC API. This documentation either comes with your compiler (e.g., Compaq Visual Fortran, or Intel Visual Fortran, or Microsoft Visual Studio) or it can be found in the Microsoft Windows Platform Software Development Kit (SDK) which is supplied with most software development tools offered by Microsoft. You can also find it on Microsoft’s Developer WebSite. Getting started with ODBC can be tedious, so ForDBC is equipped with several example programs (completely in Fortran) which show you how to use ODBC. They demonstrate how to read from, or write to, tables in a Microsoft Access database or an Excel spreadsheet.
ForDBC comes with concise documentation which provides you with the essential information that you need for a quick start into ODBC programming.
Users of Compaq Visual Fortran and Intel Visual Fortran are supplied with a complete workspace (.dsw) and solution (.sln), respectively, which contains several sample projects which show how to access a database in several ways.
ForDBC comes complete with source code, delivered with the licence and software by e-mail. You can use it in your programs and distribute these without any royalty payments or runtime fees.
ForDBC is available for the following compilers:
Lahey LF95 V5.7
Compaq Visual Fortran V6.6
Intel Visual Fortran 9.x and higher
Salford V4.x (not 5)
Windows 98 and upwards (Win32 systems).
- A new function GET_WOW_VER@ has been added to be used in place of GET_OS_VER@ in compatibility mode.
- A new FTN95 command line option /DOLLAR_MOD has be added so that certain module names ending with a dollar sign will be treated as system modules.
- FTN95 is now compatible with .NET 4.5 running on Windows 8. Note that all FTN95 generated .NET code must be compiled and linked against version 6.35 or above. Architectural changes in Windows 8 prevent .NET code produced by previous versions of FTN95 from functioning. This includes ftn95lib. It is therefore vital that all Fortran source code is recompiled and linked with version 6.35 and be distributed with an ftn95lib of the same version.
Outline summary of bugs that have been fixed:
- An FTN95 (/OPT) optimiser bug for Windows 8 and .NET version 4.5 has been fixed.
- An internal subroutine COMMON variable was conflicting with a host variable with the same name.
- The FRACTION intrinsic produces invalid IL on .NET version 4.5 has been fixed
- A regression in the FTN95 .NET syntax of the form below has been fixed:
c = "System.Drawing.Color"%"Red"[/code]
- An issue setting breakpoints in the Win32 debugger plug-in inside Visual Studio has been fixed.
- On some x64 PCs FTN95 .NET assemblies would start up in 64-bit mode resulting in an immediate exception. This has been fixed.
- The command line option /MESSAGE_SET_TO_ERROR was not working. This has been fixed.
- Clearwin+: %ac[INS] regression fixed. Also %ac[Ctrl+H] and %ac[Ctrl+I] now working
- Clearwin+: Added [mouse_click] option to %bv to allow processing of a single left mouse click. The corresponding CALLBACK_REASON is “MOUSE_CLICK”.
- Clearwin+: %bv extended to allow more icon colours. The default is now 256 colours whilst the options [4bits] and [24bits] provide alternatives.
- FTN95 will no longer compile and link against .NET 1.1. FTN95 now defaults to .NET 2.0
PLATO (see full history)
- New feature: Changed the default CLR_VER to 2.
- New feature: 64 bit functionality is now dependent on ClearWin64.dll being on the PATH.
- Bug fix: Commands “goto” etc. in “Find Results 2” output were being applied to “Find Results 1”.
- Bug fix: Windows 7 taskbar behaviour was not programmed.
- New feature: Added 64 bit gFortran functionality via new x64 platform.
- New feature: Properties dialog for References is now platform dependent.
- *.cs files can now be included in a DBK_LINK2/4 command line in order to transmit assembly attributes to the exe/dll.
- /CHECK argument checking now extended to module subprograms.
- /LINK with /DEBUG now activates /3GB in SLINK.
- ASSEMBLEY_INTERFACE now allows ARRAY=”REF” (default ARRAY=”NET”) to allow star-sized arrays to be passed only as a reference to the first element of each array in the argument list.
- Clearwin+: Two new functions have been added to the library as an alternative or addition to %gr[user_surface]. These are CREATE_USER_SURFACE@ and SELECT_USER_SURFACE@. The associated %gr is identified by its Windows handle (see %lc) and the programmer must store the associated device context and DIB pointer. CALL CREATE_USER_SURFACE@(width, height, hdc, ptr) !(inputs width and height and returns hdc and ptr – all INTEGERs) ia = SELECT_USER_SURFACE@(hwnd, hdc, ptr) !(inputs all arguments and returns non-zero value on success)
- Clearwin+: New standard callback HELP_LOOKUP added. This takes two character strings. The first is the full path of a .CHM help file. The second is the keyword that identifies the topic that is to be displayed. This keyword must be included in the .HHK file that forms part of a Microsoft project to compile the .CHM file. Note: HELP_CONTENTS can already be used with .CHM files.
Outline summary of bugs that have been fixed:
- TYPE definition failed to propagate in a particular subprogram that was internal to the main program.
- RECOVER_DIB_BLOCK@ had 2048 horizontal pixel limit.
- A particular ALLOCATE statement reported and incorrect array rank.
- PAD was not working in the RESHAPE intrinsic except for integers.
- VAX initialisation statements failed when the list contained an array that was not the first item in the list.
- Assignment via a pointer failed when pointing to an element of an array of user-defined type which, in turn, had array members.
- Assignment to NULL using =>NULL() rather than NULLIFY was failing under .NET.
- MAXLOC and MINLOC intrinsics could not be called directly in order to set an array index.
- For arrays of rank one, MAXLOC and MINLOC now only return a scalar when DIM=1 is an explicit argument.
- SET_SUFFIX@ and SET_SUFFIX1@ were only working correctly for extensions of length three.
- Logical test for element by element character equality was failing for scalar against array constructor.
- Clearwin+ Improvement: %`rs can produce unwelcome additional height with XP theme.
Existing option [no_additional_depth] used to restore old (non-XP) height.
- Clearwin+: Documentation has been added for existing functions import_gif@ and export_gif@. These are similar to import_bmp@ and export_bmp@. Interfaces are now included in standard header files.
- Clearwin+ Improvement: import_image@ has been extended to handle GIF files and resources.
- ENUM type included in /f2k features.
- New function count_files@ added to FTN95 library.
- New features added to Plato including image and HTML editing.
Outline summary of bugs that have been fixed:
- Stack pointer was corrupted in call to a matrix function.
- Virtual memory allocation failure under 64 bit Windows 7.
- Wild card failure with “ftn95 dir*.f95”.
- Another buffer problem when using a wild card on the command line.
- Mixed single and double expression for certain complex values gave incorrect results.
- a certain character function failed on assignment.
- a check caused an access violation when a host variable was passed to an internal subroutine.
- /opt failed in a certain cos with sin expression.
- Locked register occurred with /checkmate when using ALLOCATE and ANY.
- False error report “Non-conformant array shapes..” with a certain array of user-defined TYPE.
- Comment embedded directive FTN95$FREE was not working when placed before a LIBRARY directive.
- User-defined assignment operator caused /check to give a false runtime error report
- Redundant USE statements or ‘wrong’ order caused loss of module data for TYPE elements
- Setting breakpoints in DLLs in Win32 Visual Studio debugging sessions
- Debug data tip display in Win32 Visual Studio 2010 debugging sessions
- Expansion of array data tips in Win32 Visual Studio 2010 debugging sessions and setting their values
- Clearwin+: %ht buffer problem when screen resolution is very high
- Clearwin+: %ht problem – jpeg images did not display correctly on a wide screen
- Clearwin+: clearwin_info@(“PRINTER_COPIES”) was not working
- Clearwin+: %dd%rd gave double call to callback when grave is not used
- Clearwin+: %lv with vertical scroll and button below was not working correctly. Button click was sometimes failing to respond
- Clearwin+: clearwin_info@(‘FILTER_ITEM_SELECTED’) was not working for get_multiple_file_names@
Outline summary of bugs that have been fixed:
- Compiler regression at 6.00: character variable comparision failed when using /full_undef (i.e. /checkmate)
- Long path names could not be used with wild card command line “FTN95 *.f90” etc.
- Pure functions as procedure arguments were constrained to be INTENT(IN) but the standard does not require this.
- FILL@ gave locked register failure with /opt.
- Compiler failed to create runtime code for array assignment with INTEGER*8 array index and the same index on the RHS.
- CHECK mode gave false runtime error for INTEGER*2 do-loop index (changed externally) when index was used in a CONTAINed subroutine.
- SDBG: In some circumstances Windows loads DLLs with Unicode details instead of ANSI. SDBG detects this and acts accordingly
- ClearWin+: Two problems with the %eb horizontal scrollbar have been fixed
- ClearWin+: Regression fix: This was caused by spurious mouse_hover event (see 301) in %ib and affected use of SDBG in particular
- ClearWin+: %lv was not working under Windows 7 when using the XP theme/manifest
- ClearWin+: %ps was failing in a special case
- Support for Visual Studio 2010
- Support for .NET 4.0
- A new compiler option /NO_TRUNCATE has been added.
- ClearWin+: A new option [mouse_hover] has been added to %ib
- ClearWin+: The standard callback COPY has now been implemented for %cw
- ClearWin+: The local font given by %fn is now applied to %pb
- ClearWin+: New library routines have been added to make it easier to use %eb[user_colours]
- ClearWin+: Check boxes in %lv can now be set and reset under program control
- ClearWin+: Mouse wheel messages are now available with %gr[full_mouse_input]
- ClearWin+: GET_MULTIPLE_FILENAMES@ has been made available
Outline summary of bugs that have been fixed:
- A specific test for character equality was failing with /FULL_UNDEF
- There was a failure to flag a compilation error when a DO loop end control value is not a scalar.
- The logical test in a WHERE statement was not failing as it should when there is a rank miss-match.
- There was a false comment about a derived type not being used.
- There was a failure to flag a compilation error when a certain array expression is a assigned to a scalar.
- The FTN95 intrinsic LS could not be overloaded within a user MODULE.
- A certain usage of ALLOCATE failed when applying /CHECK.
- A certain function call in which an array section was passed did not return a value.
- There was a false warning about “use without an initial value” for an array section in a READ statement.
- There was a false runtime error when an array section was passed as an argument and the array has varying size.
- An array assignment involving a member of a member of a user type failed to compile.
- There was a false warning about an array member of a user type being redefined.
- There was a Missing error report when SIZE is called for an assumed-size array.
- The TRANSFER intrinsic was failing when passing a character variable and using /FULL_UNDEF.
- FILL@ gave an internal compiler failure when only two arguments are supplied.
- A certain piece of code using a vector subscript and INTEGER*2 was failing.
- FILE8@ returned the file size modulo 4GB
- ClearWin+: Two problems with the %eb horizontal scrollbar have been fixed
- A new command line option /RAGGED_ARRAYS has been added for use with /CHECK and /CHECKMATE. This option prevents a runtime failure when a non-rectangular array is passed to a subprogram as is the case with some BLAS/LAPACK routines.
- An optional new memory model in salflibc.dll has now been made the default. The environment variable FTN95_NEW_MEMORY can be set to FALSE in order to switch this off.
- Plato is now fully integrated with SDBG when this feature is switched on in the Options dialog.
- Plato can now print files using syntax colouring.
- ClearWin+: A new option has been added for %cw called [local_font] that causes %cw to use the current %fn and %ts.
- ClearWin+: A new option [popup] has been added to %gr so that a %pm menu appears with %gr[full_mouse_input].
- ClearWin+: Additional keyboard characters have been added for %ac including plus (+) and minus (-) characters.
- ClearWin+: A new CLEARWIN_INFO@ information string has been added: OPENGL_ALIVE
Outline summary of bugs that have been fixed:
- Improved Windows 7 compatibility
- Several issues that are generally seen on x64 operating systems with large amounts of RAM have been fixed. These issues manifested themselves as out-of-memory errors and unexplained floating point exceptions (that were in-fact underflows)
- Fixed a problem with building on Windows 7/Windows Server 2008 and deploying lower versions of Windows where certain system functions could not be located in kernel32.dll.
- /EXPLIST was failing when used with a large file and /CHECK.
- SELECTED_INT_KIND and SELECTED_REAL_KIND did not respond to /ALT_KINDS.
- When not using /LINK a bad object file was sometimes created despite reported compilation errors.
- An access violation occurred when a constructor for a user defined type was assigned to an integer.
- Windows NT text console commands (WCREATE@ et al) now function correctly on consoles with more than 50-lines of line buffer
- Windows 7 compatibility
- New comment embedded directive STDCALL added for use before an EXTERNAL statement.
- New routine ENABLE_DEALLOCATE@ added to allow DEALLOCATE to be applied after ALLOCATE with SHARENAME.
- New routine DOWNLOAD@ added. This is similar to READ_URL@ but reads into memory.
- Many of the /CHECK features are now available when using /F_STDCALL.
- ClearWin+: %ht now accepts JPEG images.
- ClearWin+: %ht now uses a standard callback COPY_TEXT in order to copy all of the text in the current HTML page to the clipboard.
- ClearWin+: %th now provides an option for Microsoft style context sensitive help.
Outline summary of bugs that have been fixed:
- MODULE user defined type with array initialisation was not written to the MOD file.
- /ALT_KINDS failed in subroutines.
- Regression in Plato: /CLR_VER project option was not working.
- There was a particular failure of INTEGER*8 with /CHECK.
- /CONFIG failed to restore /CHECKMATE setting from config file.
- /CONFIG failed to work under Windows Vista.
- SYSTEM_CLOCK returned incorrect results for very fast processors.
- Regression at 5.20: Type initialiser lead to offset error.
- Regression at 3.40: There was a failure to parse “i+1” in B(i+1)%C = 0
- Inconsistent pointer block in /CHECK argument.
- ClearWin+: %si icons were not displayed correctly for non-standard DPI settings.
- ClearWin+: %lv did not scroll initial selection into view.
- C style preprocessing directives can now appear in the label field (except for #include).
- New memory model used in salflibc.dll. Currently available for beta testing by setting an environment variable.
- ALLOCATE extended to include SHARENAME keyword argument for Win32 inter-process shared memory and file mapping.
Outline summary of bugs that have been fixed:
- The dialog box reporting runtime errors sometimes failed to appear.
- NEAREST intrinsic did not always expanded correctly inline.
- /CHECK failure when using a certain statement function.
- A certain combination of using UBOUND with ALLOCATE failed.
- ALLOCATE failure for array of CHARACTER type with elements of variable length.
- ALLOCATE regression when using certain CHARACTER members in a TYPE definition within a MODULE.
- Array of a derived TYPE with zero size not handled correctly by the compiler.
- Problem with IBSET when used with pointers.
- INTEGER*1 range problem with /CHECKMATE.
- False error report when a certain subroutine was passed as an argument in a MODULE.
- Array bounds check failed when the index was an array element.
- Missing TARGET caused access violation in a particular construction.
- False warning issued for a particular EQUIVALENCE statement.
- Regression in DBK_LINK: vcLinkText@ etc. in Visual ClearWin samples, failed to link.
- False /CHECK runtime failure when optional CHARACTER argument was absent.
- Simple assignment to member of .NET class failed to pass JIT compiler.
- Namelist with array slice gives “Digit(s) expected” error.
- Incorrect results in sorting algorithm
- Regression with respect to recursive subroutine call
- Compiler crash when taking substring of function returning a character string
- /ISO should flag error when using REAL as a DO variable
- Regression with respect to false warning about unreachable code
- Win32 Visual Studio debugger crash on Windows Vista when debugging external DLLs
- Custom build steps in Visual Studio plugin when installed to non-default location
New features include:
- Support for Visual Studio 2008
- Additional project support in Visual Studio 2005/2008. User folders can now be created in the solution explorer
- Plato Version 4 now supports Unicode. Note that version 4 is not compatible with Windows 9x
- Further support for Windows Vista and Windows Server 2008
The following is a summary of FTN95 bugs that have been fixed at version 5.20.
- ‘Compile’ file in Visual Studio solution explorer behaviour fixed.
- Further fixes and support for debugging under Vista.
- False type warning when using REAL(COUNT(i)) as an argument.
- Error not reported for array assignment with mismatched shapes.
- ALLOCATE does not fail when size of block overflows.
- /OLD_ARRAYS gives a false error report when A(1) is not an argument.
- Missing “TYPE” in “END TYPE” causes a module to terminate prematurely.
- Error not reported when named DO statement does not have matching ENDDO name.
- OPENF@ not working under .NET.
- NINT(AR,1) fails for two-dimensional array AR.
- PRIVATE not implemented when member is used in module.
- Initialisation of TYPE members within a MODULE fails for large arrays.
- “Operand incompatible with opcode” failure on integer*1 = integer*4 assignment.
- USE ONLY f=>g does not link when the function g is declared in another module.
- Compiler crashes when writing linker data for a certain module.
- Warning about unreachable code not provided in /DEBUG mode.
- SUM intrinsic used as argument for DOT_PRODUCT does not compile.
- IBITS not working for INTEGER*8.
- /CONVERT not working.
- IACHAR not available in array initialisation implied DO loop.
- Explicit declaration needed for a function used on RHS of a statement function.
- False warning when compiler-defined constant is not used.
The following changes has been made:
- Use of ALLOCATABLE in TYPE declaration is now tollerated though not standard conforming.
- /WIDE_SOURCE limit increased to 1024 characters per line.
- GET_COMMAND_ARGUMENT intrinsic function, character limit increased from 128 to 256.
- Improved compatibility with AMD Geode range of processors
- Improvide Vista support from SDBG and Visual Studio Win32 debugger
The following is a summary of FTN95 bugs that have been fixed at version 5.10.
- Poor error report when MAX is used with an array argument.
- .NET false error report about miss-matched argument types in function call.
- False warning with ALLOCATE, statement will not be executed.
- ABS not implemented for INTEGER*8.
- Missing error report when trying to use JUMP@ under .NET.
- Some array sections not checked at runtime for shape conformance.
- Another .NET false error report about miss-matched argument types.
- Operand incompatible with opcode failure with particular use of TRANSFER intrinsic.
- False warning, RESULT not set in certain recursive function definitions.
- Character variable in a particular WHERE test gives internal compiler error.
- An INCLUDE statement corrupts some CONTAINed subroutines.
- False error report for certain internal PURE routines.
- FORALL statement using SUM intrinsic fails to initialise correctly.
- User-defined assignment was not implemented in the context of an paricular array assignment.
- Regression in Plato3 fixed: Problem with project file list and dependency checking.
- Regression in FTN95 fixed: Arrays were not correctly initialised (i.e. simultaneously declared and initialised) in modules.
- In some circumstances the Visual Studio 2005 integration was not fully installed and theefore not fully functional.
- Arguments are now passed to the debugee when using the Visual Studio debugger in Win32 mode
- NEW FEATURE: Visual Studio 2005 integration.
- NEW FEATURE: Microsoft .NET 2.0 compatibility.
The following is a summary of FTN95 bugs that have been fixed at version 5.00.
- REPEAT intrinsic has 32K limit on second argument.
- Illegal memory reference bug in matrix reallocation program.
- UNDEF failure with OPTIONAL character argument.
- Register tracking failure over INVOKE.
- Use of /PROFILE can cause incorrect function return.
- Missing label not reported when followed by CONTAINS.
- Recovery from underflow is not automatic for Win64.
- <= is not parsed correctly in some situations.
- Particular use of User-defined == operator fails.
- Optional INTENT(OUT) causes runtime failure with FULL_UNDEF.
- Initialisation fails with TARGET and UNDEF.
- Regression at 4.9. Assigned GOTO does not work in fixed format.
- Regression at 4.9. Access violation when reading a MODULE.
- BIT_SIZE does not work for 64 bit integers.
- SIZE = len fails in READ statement.
- INTENT(IN) does not prevent assignment via a READ statement.
- Incorrect result for a particular use of the TRANSFER function.
- Incorrect result for a complex arithmetic calculation.
- Size of .NET debug information reduced
- An assigned GOTO with array value failed to compile.
- An access violation occurred when reading a certain TYPE from a module.
- Changes essential for using /F_STDCALL
- NEW FEATURE: /LOCAL_ZERO added for .NET only. Like /ZEROISE but for local variables. Cannot be used with /UNDEF.
- NEW FEATURE: Size of /UNDEF executable reduced for .NET MODULE containing large array.
- NEW FEATURE: Size of .NET DLL reduced when it contains a large MODULE array.
- NEW FEATURE: NET OBJECTs can now be initialised when declared.
- NEW FEATURE: REAL assigned to hexadecimal value now generates a warning.
- NEW FEATURE: /F_STDCALL option added for Win32
The following is a summary of FTN95 bugs that have been fixed at version 4.9.
- Missing member initialation in array elements of user-defined TYPE.
- INQUIRE(PAD=…) missing.
- Runtime problem with SHAPE intrinsic – arrays erroneously reported as not conforming.
- Corrupt header of very large record in unformatted IO.
- INTEGER i = ‘F’ does not generate warning or code for .NET.
- /OPT failure with benchmark test
- INTENT(OUT) fails for .NET objects with /CHECK.
- FORALL construct gives incorrect results for multiple “overlapping” assignments.
- FORALL construct expanded incorrectly.
- Call to routine with optional arguments fails under /CHECK.
- False error report with MVBITS.
- NET false runtime error “Array subscript > upper bound”.
- False compilation error “Duplicate sub-program name”.
- Problem with implied-DO in PARAMETER initialisation.
- /OPT failure – mixed REAL*4 and REAL*8 in DO-loop assignment.
- False compilation error for computed GOTO with integer expression.
- /STATISTICS gives floating point exception for “zero” elapsed time.
- /INTS should not over-ride INTEGER*4.
- INTENT(IN) problem with /CHECK and .NET DLL.
- Problem with different TYPEs with same member name.
- Garbage collection problem under .NET.
- Temporary array overwrites allocated array.
- False /CHECK runtime error “Too few array elements”.
- Member of TYPE falsely reported as missing.
- False error report with pointer assignment.
- TYPE constructor fails when passing a pointer.
- INQUIRE gives error when calculating IOLENGTH of TYPE.
- NEW FEATURE: UNDEF array values in a MODULE are nolonger stored as static values.
- NEW FEATURE: ASSEMBLY_INTERFACE extended to allow pass by reference.
- NEW FEATURE: SLINK modified to make executables “Large address aware”.
- NEW FEATURE: New comment embedded directives added (see help file).
- NEW FEATURE: UBOUND and SIZE can be used with .NET arrays.
- NEW FEATURE: /UNDEF applied to .NET NEW@ array.
The following is a summary of FTN95 bugs that have been fixed at version 4.8.
- Automatic DEALLOCATE (on exit from subprogram) not implemented for .NET.
- IO problem when OPEN follows OPEN on the same unit without intervening CLOSE.
- Regression. Blank lines after a comment causes error report line numbers to go wrong.
- /OPTIMISE problem when ASSIGN TO is used in a DO loop.
- ALLOCATE size is incorrect when calculated using INTEGER*1 variable arithmetic.
- Paricular application of MVBITS under .NET gives incorrect result.
- NET problem with MODULE procedure that has an internal function.
- Locked register problem with PRODUCT.
- Problem with open_wav_file_read@ when invalid file is encountered.
- IO is not initialised when READF@ called without prior OPEN etc.
- Foating point stack overflow problem. Incorrect assembly instruction under Win32.
- Problem with CSHIFT when used with /SAVE and /CHECKMATE.
- INTENT(INOUT) used with array passes incorrect address.
- False warning with INQUIRE and implied DO.
- NET problem with /DEBUG etc, too many members in TYPE causes access violation.
- NET problem with /CHECK and passing character variables to subprograms.
- False warning 133 with .NET and /CHECK.
- NET assignment of 2-dim .NET array element to variable does not work.
- NET assignment of character variable to string does not work when string is an argument in a subprogram.
- VAX style DATA list does not work for CHARACTER variables.
- Regression. Problem with CODE command when full stop is the first character in an assembly comment.
- ENTRY point problem under .NET when using /UNDEF.
- False warning with logical IF statement.
- FCORE4 failure at runtime when using /CHECK.
- Bug fix for regression at 4.70 concerning subprogram ENTRY points
- Windows XP control styles are now available.
- Fix for fatal error in 4.70 release of Plato3; this occurred when restarting a project after a project file had been deleted.
- A subprogram ENTRY point problem in .NET dll.
- Regression. A subroutine ENTRY point problem – incorrect bound for 2-dim automatic array.
- An alternate RETURN fails for subprogram with CHARACTER argument.
- A .NET problem with DATE_AND_TIME optional arguments.
- A Win32 problem when storing long CHARACTER variables in a MODULE.
- A Win32 problem when using CHAR intrinsic in a subprogram.
- A .NET linker problem when using optional arguments.
- A .NET problem with /FULL_UNDEF when using CHARACTER variables.
- A Win32 problem with /CHECK – subprogram fails to match generic.
- A JIT (.NET) problem when printing a substring and compiling with /CHECKMATE.
- Regression. Complex expression has incorrect sign.
- A Generic functions fail to distingish between .NET objects.
- An array name beginning with “IF” fails to parse.
- A CHARACTER PARAMETER name beginning with “FUNCTION” fails to parse.
- A problem with EQUIVALENCE linked to COMMON BOLCK.
- An optimising problem with MINLOC.
- Passing TRIM(ADJUST(C)) as an argument gives access violation.
- A problem with differing TYPEs having the same member name.
- /UNDEF does not trap scalar argument when array is expected.
- A vector subscript in implied DO loop causes run-time access violation.
- A problem with INTEGER PARAMETER used as KIND value in IMPLICIT REAL statement.
- /ALT_KINDS documented but not implemented.
- IN(…) FORALL(…) not implemented.
- A problem with parsing f(d%list(1)%array).
- A problem with WHERE statement when LHS of assignment is ALLOCATABLE.
- A problem with PUBLIC attribute in mutually recursive TYPEs.
- A false error message for pointer assignment.
- A problem with array section for array member of user-defined TYPE.
- “LIBRARY” cannot be used as the name of a variable.
- A problem passing signed array argument to a generic function.
- A problem with member intialisation when one TYPE is derived from another.
- A false run-time error “Active do-loop index altered”.
- An assumed size array falsely accepted in subroutine.
- A problem passing array section to function that returns an array.
- A problem with ENTRY point and unused argument.
- A false error message for rank of WHERE construct.
- A false error message for rank of WHERE construct nested in FORALL.
- A DO WHILE test not calculated correctly.
- A problem with execution order in array of elements of user-defined TYPE.
- A missing bounds check for an array section.
- A problem with DO loop variable declared in a MODULE.
- A problem when calling TRANSFER from a subroutine.
- Attempting to index a scalar value element of a derived type was causing a compiler crash. The compiler now issues an error message.
- Introduction of a C-style preprocessor, making use of #ifdef..#endif etc. This requires the use of the compiler switch /CFPP.
- A problem where the type of an allocatable array in the main program block was not being shown in the debugger when there is a contained routine has been fixed.
- The TRIM intrinsic was returning garbage when used on a local character variable with length determined by an argument. This has been solved.
- Calling the size intrinsic with a call to the pack intrinsic as its argument was causing a crash at runtime. This has been fixed.
- Arrays with the INTENT(OUT) attribute are now set to the undefined state on entry to the routine they are defined in when using /FULL_UNDEF.
- An unwanted “END statement not executed” warning, produced when an alternate return and format statement have been used, has now been removed.
- A problem where variables declared in a module cannot be seen correctly from the main program in a different file has been fixed.
- The compile option is now shown in each file’s context menu in the Visual Studio .NET FTN95 plugin even when Visual C++ .NET is not installed.
- A problem with ALLOCATE returning an invalid pointer in some cases when a result statement is used has been solved.
- When a function has been overloaded and all overloads accept a pointer to an array of differing rank as their only argument then a compile time error was produced. This has now been fixed.
- Attempting to call a subroutine that expects an array argument with a scalar now gives an error when compiled with /CHECK.
- A new Win32 debugger is avaliable for Microsoft Visual Studio .NET 2003 capable of debugging Salford applications.
- The F2000 standard keyword ‘TYPEALIAS’ is now accepted as well as the non-standard variant, ‘TYPE_ALIAS’.
- .MOD files will now only be updated if any interface or module variable is changed (or added or deleted). This reduces the number of compilations required when using makefiles, for example.
- A memory leak related to IF constructs and the generation of array temporaries has been fixed.
- Assumed shape arrays in ENTRY statements could in some circumstances cause invalid errors. This is now solved.
- Spurious errors could be caused with derived type constants containing array pointer components. This has been fixed.
- An Internal Compiler Error with UBOUND has been solved.
- CHARACTER variables used with UNPACK could generate invalid machine instructions, this is now solved.
- A problem related to Real*10 and equivalence in certain cases has been fixed.
- A problem with namelists contained within modules has been fixed.
- A problem related to very large source files containing thousands of labels has been solved.
- An equivalance bug related to the re-use of a value from a register rather than memory has been fixed.
- A problem related to bit_test@ has been solved. BTEST was not affected.
- Some problems using mixed CHECK and DEBUG code have been identified and solved.
- An internal compiler error concerned with the use of array valued functions in some cases has been fixed.
- Calling routines with CHARACTER,POINTER elements of a derived type now behaves correctly in all cases.
- A problem related to the printing of an array with array name as index has been solved.
- A CHECK problem where missing OPTIONAL arguments were not detected has been fixed.
- An internal compiler error related to derived type array component elements in exceptional circumstances has been fixed.
- An INQUIRE issue with IOLENGTH related to derived types has been solved.
- A problem related to CHECK and statement functions has been fixed.
- ASSEMBLY_INTERFACE statements are not permitted in MODULE or CONTAIN’ed routines in /CLR mode. Only routines that would normally be callable by other .NET languages can be exposed and called in this way. A new diagnostic has been introduced to correctly inform the user of this.
- Incorrect reporting of some source formatting errors has been fixed.
- Generic interfaces having the same name as a specific contained within the interface are now handled correctly in all cases.
- Erroneous symbols being added to debuggable MODULE’s when inside type definitions have been removed.
- Derived types with pointer components behave correctly in all cases.
- Calling array valued functions in modules in .NET configuration was causing problems n some cases. This is fixed.
- .NET enumerations passed from .NET languages to Fortran now behave correctly.
- A .NET linker error related to calling contained routines has been fixed.
- An UNDEF problem related to derived types with pointer elements has been fixed.
- Derived types with the SEQUENCE attribute that are used as routine arguments behave correctly in .NET mode when declarations of the TYPE appear both in caller and callee.
- A problem related to some temporary variables being incorrectly SAVE’d with the use of a global SAVE statement has been fixed.
- Use of ALLOCATED has been restricted to ALLOCATABLE arrays as specified by the standard with /ISO, a warning is generated as standard. ASSOCIATED should be used for POINTERS.
- A problem related to pointer assignment in unusual circumstances has been resolved.
- A problem related to /INTS when using some mathematical constucts has been resolved.
- Compatibility with version 1.1 of the .NET framework.
- FTN95 now integrates with Microsoft Visual Studio .NET 2003.
- Other miscellaneous bugs fixed.
- /CONFIG producing an access violation has been fixed.
- Win32 DLL’s can now be called from .NET correctly in all cases.
- An optimisation problem related to nested DO loops within contained routines has been fixed.
- An optimisation problem related to the use of special loops for for loops in certain circumstances has been fixed.
- Another optimisation problem related to maxval and related functions has been fixed. Use of non-numeric arguments in calls to MIN/MAX diagnosed correctly.
- Several bugs related to /P6 have been fixed.
- Many optimisation improvements have been identified and implemented. This results in a significant speed increase with code compiled with /OPTIMISE (~10% or more).
- A problem with the initialisation expressions in calls to REAL in certain circumstances has been fixed
- A problem related to the upper and lower bounds of some pointer arrays has been fixed.
- A /CHECK problem with an incorrect error of “Active do-loop index altered” solved.
- A specific problem with calling TRANSPOSE with certain arguments in a WHERE block has been fixed.
- NAMELIST and aliasing now behaves correctly.
- A problem in /CHECK mode where /INHIBIT_CHECK 11 was previously required has been solved.
- Problems with an assignment of a matmul result to an array section in some cases has been fixed.
- Nested array valued intrinsics now behave correctly accross the board.
- ISTAT is set correctly when an UNALLOCATED variable is DEALLOCATED in all cases.
- Character vaiables will only accept assignments of character variables.
- Functions being called as subroutines correctly detected.
- Some uses of STDCALL routines inside MODULE’s were causing problems with argument mismatches, now fixed.
- Use of intrinsic names as variables inside modules in certain circumstances is now fixed.
- Other miscellaneous bugs fixed.
- A debugger problem related to modules precceding the main program within the same file has been fixed. Module variables now display correctly in the debugger.
- Entry statements with the same result variable as a function with a result clause now behave properly when the variable is used after the entry statement. A related problem with variables declared as INTENT(IN) when using entry statements that contained the dummy argument has been fixed.
- Use of an array as a result variable in a public function contained within a module used to produce an erroneous error message.
- A problem related to Integer*2 causing an internal compiler error when used in a substring statement when compiling with /UNDEF has been fixed.
- A MINLOC/MAXLOC problem when two values were the same in an array, where the pos of the second (or higher) value was being picked up, in certain circumstances has been fixed for both Win32 and .NET.
- If a library file is not found when using the LIBRARY directive when using Visual Studio .NET a dialog is presented allowing the user to choose the correct file.
- A problem with recursive entry statements implemented in certain circumstances has been fixed.
- An optimisation, where array temporaries are not required for one dimensional array sections has been introduced.
- If a do-loop index was subsequently used as an array constructor variable inside the same do-loop, the index was incremented incorrectly. This has been fixed.
- A problem related to calling functions via an interface with OPTIONAL and keyword arguments in certain circumstances has been fixed.
- Automatic arrays larger than 19648 bytes in CHECK mode were failing at runtime, this has been solved.
- An equivalence bug with multiple equivalences in some circumstances has been fixed.
- Allocatable arrays which have the SAVE attribute are now correctly dealt with.
- A problem with ENTRY statements inside MODULE’s with in .NET configuration has been fixed.
- Square brackets can now be used for array constructors.
- New intrinsics, GET_COMMAND and COMMAND_ARGUMENT_COUNT and GET_COMMAND_ARGUMENT added, these are part of the Fortran 200x standard.
- A problem related to optional arguments when calling generic functions in certain circumstances has been fixed.
- Other miscellaneous bugs fixed.
- The default directory structure has been changed to “C:Program FilesSalford SoftwareFTN95”. It was changed to conform with ‘standard practice’ and for compliance with standards for Microsoft .NET (which we are now supporting). Please accept our apologies for any inconvienience caused.
- A new switch is available, /CLR – this enables FTN95 to produce code suitable for the Microsoft .NET runtime environment. Note that a new linker DBK_LINK.EXE is required to link .NET object code (.dbk files). This enables transparent mixing of FTN95 generated code with other CLR language code such as C# and VB .NET.
- FTN95 can now be used inside Microsoft Visual Studio .NET, with the usage of a Visual Studio .NET plugin. Multi-threaded programming is possible in .NET configuration using the switch /MULTI_THREADED.
- Further improvements have been made to the IO library, with the .NET IO library operating completely in .NET managed C++.
- A bug related to characters being invalidly replaced has been fixed.
- Some minor equivalence fixes have been made.
- A floating point stack overflow in /CHECK mode with very large source files has been fixed.
- A problem with read statements in implied do loops has been fixed.
- CPU_TIME intrinsic now returns correct processor time on NT based systems.
- Business format for Integer*8 fixed.
- A character comparison bug has been fixed where the right hand side of the expression was empty in certain circumstances.
- Changes have been made so that debug relocation entries in excess of 64K are handled correctly.
- Many other miscellaneous bug fixes.
- There is a new option, /NO_SCALAR_TO_ARRAY, available. This option will make the compiler treat an ‘<array> = <scalar>’ assignment expression as an error. This can be useful to debug old code.
- Improvements have been made to the IO library with much of the code being replaced.
- Reentrant IO has been implemented in order that functions within IO statements may themselves perform IO, this is an extension to the standard. This is disabled by default and can be enabled by calling the function: enable_reentrant_io@(.TRUE.)
- Many miscellaneous bugs have been fixed.
- The SAVE attribute for large arrays in functions has been modified such that the array is no longer included in the object file. This can in some situations give a great reduction in object and executable file size.
- Many small problems found when utilising advanced features of the Fortran 95 standard have now been overcome.
- The link between ClearWin+ and OpenGL has been extended. Many existing OpenGL applications are written in terms of an additional library of functions known as GLUT.
- Many of the GLUT routines – such as those which construct models of entire objects – are now directly callable once an OpenGL window has been opened using %OG. Other functions are declared in OPENGL.INS in such a way that the GLUT function is replaced by an equivalent function in SALFLIBC.DLL.
- Thus the only change which should be required to make a GLUT/OpenGL Fortran program work under ClearWin+ is to include OPENGL.INS in any routine which makes GLUT calls.
- A new option is available with Win32 compilers, /PROGRESS_METER, which will add an estimate of how far the compilation has progressed on the console title bar (like “FTN95 (50%)”) when a compilation is estimated to take longer than about a second.
- The environment variable used to configure the compiler has been renamed to SALFORD_COLOUR from FTN95COLOUR. Versions of the C++ compiler newer than 3.06 and versions of SLINK newer than 1.27 will use this variable also. This is the only way to get SLINK to display colours, use “set SALFORD_COLOUR=*” if you want to switch on colour without changing the defaults.
- The compiler now supports a new syntax for specifying zero-terminated strings (for passing to C/C++ routines): “foo”C (as in Compaq Visual Fortran.) This can save a C_EXTERNAL statement for simple calls, although C_EXTERNAL is still the recommended way to interface to C, as the zero-termination used here works for variables, as well as permitting call-by-value arguments.
- “FTN95 /?” output has been enhanced (especially with Win32.) The line-wrapping routines used to output the help now work correctly. /PAUSE is no longer required with Win32 compilers, as the output will automatically pause after every screenfull.
- A new option, /HEXPLIST, has been added which is similar to /EXPLIST, except that the actual hexadecimal bytes for the instructions generated are also output in the .LIS file. Subprogram calls and references to SAVE, COMMON, MODULE or PARAMETER data will not have the correct addresses fixed up yet so these bytes will differ after the linking process is complete. This option is mainly intended for (very) low-level debugging.
- A new datatype, INTEGER(KIND=4), has been added. This is a 64 bit integer type. As the x86 architecture only provides native support for this datatype using the FPU, programs will be considerably slower using this type compared to INTEGER(KIND=3). Note that the compiler’s memory limitations are still 32-bit (e.g. array indices). Note also that several components of the run-time system (e.g. the IOSTAT=var, INQUIRE(…)) will not work correctly when INTEGER(4) arguments are given to them. Actual Input/Output of these large integers is fully supported, however. Because of this we do not recommend the use of “/DEFINT_KIND 4” unless there is only simple (or no) I/O.
- A new compiler option is available with the compiler: “/COLOUR”. This will cause the compiler to output colour messages using low-level console routines with win32 versions of the compiler, or to output ANSI sequences with DBOS versions of the compiler (requires ANSI.SYS or equivalent to be loaded.) These colours can be redefined with win32 compilers using the environment variable “FTN95COLOUR” which has the following syntax:
SET FTN95COLOUR=<e>[;<w>[;<c>[;<s>[;<l>]]]]where <n>,<l>, <e>,<w>, and <c> are one of the following:
k – blacK
b – Blue
g – Green
c – Cyan
r – Red
m – Magenta
y – Yellow
w – White
* – Use default value
A preceding hyphen indicates that high intensity will be used. The values specify the following colours:
<e> Error messages
<w> Warning messages
<c> Comment messages
<s> Summary lines (e.g. “NO ERRORS [<…> FTN95/WIN32 v2.00]”)
<l> Program source in error reports
An example setup would be:
If this environment variable is unset (or the compiler is a DBOS version), the compiler will assume a value of “-r;-y;-g;w;-w” for FTN95COLOUR.
- The environment variable FTN95ANSI is now ignored.
- Some support has been added to aid users wishing to use MMX or SSE extensions. A new intrinsic CPUID@ has been added which takes two arguments, the first being the Input value, the second being any datatype which is larger than 16 bytes (usually a rank one INTEGER(3) array of size 4.) This will return the EAX, EBX, ECX and EDX values returned from a “cpuid” instruction. Two other intrinsics (which use CPUID@) have also been added: HAS_MMX@ and HAS_SSE@ which are both LOGICAL(3) functions which return .TRUE. if the feature is available on the running machine. CODE..EDOC fully supports the new MMX and SSE instructions.
- To force a variable to be aligned to a different boundary than is usual for the data-type, an new specification has been added to the type-declaration statement, ALIGN(n), where n is 8,16,32,64 or 128 and is the size (in bits) of the alignment required, e.g. “INTEGER(2), ALIGN(32) :: a, b, c” would declare 3 2-byte integers which are aligned on 4-byte boundaries. This extension should be used with care as incorrect alignment can result in code running slower or not at all (if it uses some SSE instructions.)
- The check-mode heap mechanism has been extended to allow for large memory footprints. The default heap size is now equal to the amount of physical memory minus 8M. This heap will “spill over” into the non-check heap for allocation of “large” (see below) arrays. The heap’s behaviour can be altered using the routines described below for version 1.52 with the following additions:
Sets the size of “large” for the heap “spillover”.
Calling this with the value of HUGE(1) will suppress the “spill over” mechanism.
- Modules with very large uninitialised arrays will no longer create large .OBJ files.
- A new option “/P6PRESENT” has been added. This will set the /P6 flag if the compiler is being run on a Pentium Pro or above. This is most usefully set with /LGO since the executable will not run on 386/486/Pentium class machines.
- A new option “/NO_COMMENT” has been added. This will suppress all comments while allowing warnings and errors to be output.
- /PAUSE_ON_ERROR now has a different behaviour under win32. Now the compiler pauses every screen-full of information only if a warning or error has been output, much as if the output had been piped through through a conditional “more”. Redirecting or piping the compiler output will cause win32 versions of the compiler to ignore the /PAUSE_ON_ERROR option and not pause after any messages.
- Many bugs have been fixed.
- Default compiler switches can now also be set using the environment variable FTN95CFG. This over-rides values in the FTN95.CFG files, but it is over-ridden by the command-line switches, OPTIONS statement and !FTN95$OPTIONS pragma.
- Three new compiler switches have been added:
These set the default kind for INTEGER, REAL (implying COMPLEX), and LOGICAL types. The value for <n> must vary from 1 to 3 for REAL and LOGICAL, and 2 or 3 for INTEGER. Note that this allows the user to specify LOGICAL(KIND=1) as a default type, and note also that the compiler is not standard conforming if the default kinds are changed as the standard requires that (excuse the C!): sizeof(INTEGER) == sizeof(REAL) == sizeof(LOGICAL) == (2 * sizeof(COMPLEX))
- A new compiler pragma has been added: “!FTN95$LIBRARY” which is equivalent to the LIBRARY directive, e.g.
is equivalent to
- FTN95 will now print a comment when a user specifies the kind of a type using an integer value, e.g. “INTEGER(3)”, as this is non-portable, and may cause problems when using the code on another compiler. If you don’t like it, you can switch it off with “/SET_ERROR_LEVEL S 981” on the command-line or in a configuration file.
- A bug in allocating derived-types which contain both CHARACTER components as well as at least two derived-type components has been fixed.
- A bug in SELECT..CASE statements where the expression to select was a variable length character function which could cause program crashes has been fixed.
- A bug in the processing of IMPLICIT statements which contain derived-types has been fixed.
- PRIVATE attributes are now faulted if applied to non-module variables/functions.
- ELEMENTAL SUBROUTINEs can now have INTENT(OUT) arguments.
- The presence of the blank SAVE statement in a routine with CHARACTER(*) arguments could cause incorrect code to be generated. This is now fixed.
- FTN95 will now correctly report an error when a user attempts I/O on an expression which is a derived-type which has POINTER components.
- Complex CHARACTER statement functions no longer cause an internal compiler error.
- MAXVAL/MINVAL would return the incorrect result in some cases with /P6. This has been fixed.
- A regression with “IF (X) a,b,c” where X is REAL and a==b or b==c which caused the IF to jump incorrectly when X==0.0 has been fixed.
- A regression from version 1.52 with respect to memory leaks in WHERE loops involving varying-size arrays has been fixed.
- Contains a fix to a memory leak inside ClearWin+ which could, after some time, make the machine stop responding. This was caused by an initialisation routine being called repeatedly. Only programs using ClearWin+ may be affected, the FTN95 compiler itself is not changed from 1.52.
- The user can now specify the size of the CHECK mode heap using the environment variable “FTN95CHECKHEAP”. It is recommended that this is set to half the physical memory, e.g. “set FTN95CHECKHEAP=32” would allow FTN95 to use 32M for CHECK mode heap. The larger this value, the better the chance of catching a dangling pointer, but this should not be set too high to avoid excess paging to disk.
- The size of the CHECK mode heap can also be set in a program with a routine SET_CHECK_HEAP@ which takes a single integer argument to specify the heap in bytes. This call *must* be made before the 1st ALLOCATE statement in a program and over-rides the FTN95CHECKHEAP value. Use of this routine after an ALLOCATE or more than once in a program may cause programs to operate incorrectly.
- The intrinsics ISHFT and ISHFTC now work correctly when used in specification expressions when the intrinsic has an array argument.
- A memory leak with CHECK mode ALLOCATE which caused a page-fault has been fixed.
- FORALL now works correctly with array dummy arguments.
- EQUIVALENCE now works correctly on MODULE variables.
- CHARACTER assignments have been optimised for execution speed.
- Comments are no longer upper-cased in a listing file (except for !FTN95$ pragmas.)
- FORMAT statements and FORMAT= strings are now compiled to be out of the code stream when compiled with /OPTIMISE to reduce code cache usage, reduce cache line fills and improve BTB lookups by reducing the number of branches executed.
- A bug which caused a spurious IMPLICIT error with a PRIVATE module variable has now been fixed.
- Very large CHARACTER variables are now allocated on a 16-byte boundary to aid the faster Pentium II/III REP STOS/MOVS sequences.
- Fixed a regression using NAMELIST declared in a module and used in its contained module procedure.
- /UNDEF will now correctly trap undefined ALLOCATABLE variables.
- Some error messages have been altered so that members of a derived-type are consistently called “components” in line with the ISO standard.
- ALLOCATABLE derived-type arrays would not apply default component values to all the members after an ALLOCATE. This has been fixed.
- Some intrinsics would give wrong results when the arguments were components of arrays of a derived type, e.g. “MINVAL(A(:)%X)”. This has been fixed.
- Array constructor expressions like (/1.0*X, 2.0*X/) where X is also an array caused FTN95 to report conformance errors. This has been fixed.
- The intrinsics SUM and PRODUCT are now optimised for small constant-sized array arguments by unrolling the loop.
- COMPLEX SUM/PRODUCT intrinsic calls where DIM was absent caused the compiler to crash. This is now fixed.
- REAL(KIND=3) and INTEGER(KIND=1) SUM/PRODUCT intrinsics no longer causes an ‘incorrect operand’ error.
- FTN95 is now much more tolerant of what constitutes an end-of-line character for the source file. Previously, the presence of a Unix-style line in an MS-DOS formatted text file would cause error messages to report incorrect line numbers and/or appear on incorrect lines.
- Lines containing semicolons no longer cause some compiler messages to be output on incorrect lines.
- /UNDEF now detects the output of undefined variables (with /FULL_UNDEF for CHARACTER output) with PRINT/WRITE. Previously, UNDEF checks were only performed if the item to output was an expression rather than a variable. This can be inhibited using /INHIBIT_CHECK (see notes for version 1.26 below.)
- Derived TYPEs without the SEQUENCE attribute now have their components re-ordered to improve alignment and cache utilisation. SEQUENCE TYPEs are now aligned on 1 byte boundaries (previously 2 bytes) to aid calling C++ code, the components are allocated in order as previously.
- Allocation of stack-based variables has been improved to reduce memory usage and improve data alignment by filling in any padding from “odd” sized variables (e.g. REAL(3) which previously wasted 6 bytes of stack as it requires 16 bytes of storage after alignment, yet the variable only uses 10 bytes.) This should improved cache hits and memory bandwidth.
- Raising a negative REAL number by a REAL number was not reported as an error in some cases. This has been fixed.
- Exponentiation of a REAL with a REAL which is a whole integer with /OPTIMISE has been improved to be much faster. This optimisation is also applied to COMPLEX exponentiation where the imaginary part is zero.
- Problems with the SAVE attribute incorrectly being applied to compiler generated temporaries have been fixed.
- Functions which return derived TYPE results when the type has default values now correctly initialise the result.
- Some problems with varying-length CHARACTER functions have been fixed.
- Several optimiser bugs have been fixed.
- Z format input no longer requires the input to be upper-case.
- Conformance checks between the arguments of an ELEMENTAL call are now implemented.
- An optimiser bug with /INTS which caused array-bounds corruption has been fixed.
- /P6 now uses the conditional-move instruction for the integer DIM intrinsic (and the implied DIM in array bounds calculations) as well as in some MAX/MIN, MAXVAL/MINVAL and MAXLOC/MINLOC calls.
- A bug with /P6 and statements like:
IF (ABS(x) .GT. SIN(y)) STOP
has been fixed.
- Arithmetic IF statements now work correctly with /P6.
- A compiler bug which caused a spurious error with the following sequence has been fixed:
REAL R(10), P
- A DATA statement with a REAL array being initialised with a CHARACTER(LEN=0) constant and a repeat count, e.g. “DATA FOO/10*”/” now works correctly.
- Using an array element as the lower or upper bound of an array loop, e.g.:
INTEGER :: I, J(2) = (/1,10/)
DO I = J(1), J(2)
PRINT *, I
generated incorrect code with /OPTIMISE which caused an infinite loop to be generated. This has been fixed.
- A spurious warning of ‘<fun> has been called with too many arguments” with /CHECK and no-interface calls has been fixed.
- A bug with vector subscripts being applied to a base-zero array has been fixed.
- A spurious “right hand side is not a POINTER or TARGET” error has been fixed.
- Problems with array-valued functions and the RESULT clause has been fixed.
- An optimiser problem which caused an infinite loop on run-time with an optimised DO loop has been fixed.
- REAL(KIND=3) arguments no longer cause a strange error message in check mode about argument type mismatch.
- /PROFILE no longer causes some INTEGER valued functions to return erroneous results.
- A memory leak with modules has been fixed.
- Several spurious errors with array-constructors have been fixed.
- ELEMENTAL CHARACTER functions had a problem which caused them to broadcast their first value — this has now been fixed.
- OPTIONAL POINTER dummy arguments will now not cause an error when used with the PRESENT intrinsic.
- POINTER array dummy arguments will now not cause a “argument … has been called with too few array elements” error with /CHECK mode.
- Several bugs relating to overloaded generic procedures have been fixed.
- Problems with expressions like ‘A(10)%I(:)’ where ‘I’ is a POINTER component have been fixed.
- Setting the environment variable FTN95ANSI to any value will result in FTN95 outputting ANSI.SYS escape codes to use colour in error displays and the help screen.
- A new clause can be added to a FUNCTION/SUBROUTINE declaration. The extended syntax for a sub-program declaration is:
(<type> FUNCTION | SUBROUTINE) <name> ([<args>]) [ALIAS <str>] [RESULT(<name>)]
This allows you to specify the external name for a routine if the standard Fortran default (all uppercase) is not what you want, e.g.:
SUBROUTINE foo ALIAS ‘TheFunction’
END INTERFACECALL foo
The call to ‘foo’ above will actually be reported to the linker as a call to ‘TheFunction’. Note that the ‘()’ are required for a routine with no
arguments. This can also be used in the definition of a routine, e.g.:
RECURSIVE FUNCTION foo(i) ALIAS ‘foo’ RESULT(n)
INTEGER :: i, n
END FUNCTION foo
This function would be called in C with “n = foo(&i)” instead of “n = FOO(&i)” if it followed the default Fortran rules.
- A spurious error with IMPLICIT definitions of FUNCTION types has been fixed.
- Student Edition
- A new option /RUNTRACE has been added. This adds a call to RUN_TRACE@ after every line. This routine gets the current line number, the current function name, and the current filename as arguments. The default action is to output these values to the screen, but the user can supply their own RUN_TRACE@ routine provided it is declared as:
SUBROUTINE RUN_TRACE@(line_num, fun_name, file_name)
CHARACTER(*) fun_name, file_name
- /CHECK will now produce a clear diagnostic when an OPTIONAL argument which has not been supplied is used in a sub-program.
- /CHECK will now diagnose INTERFACE mismatch problems where the INTERFACE does not have the same arguments as the actual routine.
- A memory-leakage problem when using automatic arrays in a module procedure where the size of these arrays depended on the size of an array pointer dummy argument has been fixed.
- IMPLICIT NONE with USE ONLY caused occasional spurious IMPLICIT errors when used with modules containing NAMELISTs — this has now been fixed.
- A bug which caused incorrect code to be generated for POINTER functions which were of a user-defined TYPE has now been fixed.
- Some array-valued functions without RESULT clauses were causing a compiler crash.
- /IGNORE now works with all errors and warnings. Previously it would only suppress warnings and comments. Use with care…
- A new option /NO_SCREEN_MESSAGES has been added. This gives the same behaviour as FTN77 when /LIST is present (i.e. all warnings etc. are added to the list file but not output to screen.)
- A bug which caused some occasional spurious errors when a user-defined TYPE component shared the same name as a dummy argument of a different type has been fixed.
- A new option /MAC_EOL has been added which will allow FTN95 to compile an Apple Macintosh text file (i.e. CRs only, no LF).
- Placing /LINK or /LGO into FTN95.CFG now works correctly.
- A bug in /CHECK which caused a compiler GPE with certain CONTAINed functions has been fixed.
- A bug with /CHECK which caused a spurious run-time error about CHARACTER dummy arguments being declared longer than the actual argument has been fixed.
- Scalar variables erroneously used in function calls/array references are now trapped correctly.
- Error checking of IF/WHERE/DO WHILE statements has been improved with regard to the appearance of array-valued or scalar expressions.
- Some non-standard constructs were not being detected with /ISO, such as mixing default and non-default kind variables in an EQUIVALENCE statement — this has now been fixed.
- An obscure bug in the EQUIVALENCE algorithm caused spurious errors with some redundant EQUIVALENCE statements, e.g.
REAL a(4), b(4), c(2, 4)
COMMON a, b
This has now been fixed.
- Error messages with incorrectly nested END* statements have been improved, and a case which caused the compiler to hang has been fixed.
- Comments are now supported in /OPTIONS files, and the FTN95.CFG files. A comment must appear on a line of its own, the first character of which must be ‘!’.
- Individual checks can now be inhibited with /INHIBIT_CHECK <n>, or using the new directives !FTN95$INHIBIT_CHECK and !FTN95$ENABLE_CHECK to disable/enable checks on a per-function basis. The following check numbers are currently
1 – suppress marking DO-loop indices as unwritable in a function call
2 – ” ” INTENT(IN) args ” ” ” ”
3 – suppress POINTER checking via PCHECK but allow POINTER checking on any function called.
4 – suppress POINTER checking completely
5 – suppress the argument type/size checking on function entry
6 – suppress CHECK mode function calls
These should only be used as a workaround for code which has known bugs.
- A new command line option has been added (/SET_ERROR_LEVEL) as well as a new compiler directive !FTN95$SET_ERROR_LEVEL. These both allow reconfiguration of warnings and comments to suppress them or raise their
error level. The syntax is:
/SET_ERROR_LEVEL <Level> <ErrorNum>
Where <ErrorNum> is the number of the warning/comment (found by using /ERROR_NUMBERS) and <Level> is one of the following: Suppress, Comment, Warning, Restricted, Error, Fatal (or just the 1st character of these words.) “Restricted” messages are silent unless /RESTRICT_SYNTAX is on (see below) when they become errors.
- A new option /RESTRICT_SYNTAX has been added which causes the compiler to reject code which is standard-conforming, but “dubious”, such as using an EQUIVALENCED variable as a DO-loop index, which can result in undefined behaviour. The following are currently restricted (with the error number following in square brackets):
– Using EQUIVALENCED DO-loop indices where the body contains function calls or has assignments to other EQUIVALENCED variables. 
– Variables in INCLUDE files which are not PARAMETERs, nor in a COMMON block, and are not INTRINSIC or EXTERNAL (or C_EXTERNAL etc.) This traps mis-spellings in an INCLUDE file for code which would not compile with IMPLICIT NONE. 
– Variables which could be confused with DO loops, or be from a badly formed DO loop, such as DO10I. 
– Variables with the same name as a Fortran keyword. 
These can all be configured using /SET_ERROR_LEVEL, e.g. “/SET_ERROR_LEVEL S 306” would allow the use of Fortran keywords as variable names when /RESTRICT_SYNTAX was switched on.
- This version has the capability of calling routines in dynamic link libraries generated for DEC Visual Fortran (DVF). Fixed problems with embedded blanks in integers in run time format parsing.
Also fixed problems with the first edit descriptor following a non comma delimited descriptor not being recognised if it is lower case. (Salford extension.)
- Logical values are now treated as zero for false and non zero for true, whereas previously only the value ‘1’ was treated as true.
- A problem using COUP@ with trailing blanks which sometimes caused garbage to be displayed has been fixed.
- Several problems with the CheckMate facility have been fixed as well as bugs in complex conjugation.
- Changed result of MINLOC/MAXLOC to return array result. MINLOC/MAXLOC always return an array result, except for one particular case, i.e. arguments with array rank 1 and DIM=1.
- Several bugs fixed which are difficult to describe briefly.
- CHECK mode has been extended to check POINTER variables for various errors such as dangling pointers, attempting to deallocate a block twice and attempting to deallocate part of a allocated block.
- IMPLICIT NONE scoping in CONTAINed routines now works correctly.
- Varying-length CHARACTER functions no longer cause “can’t free locked registers” error messages.
- Enhancements to the stability of conditional compilation have been made.
- Various bugs have been fixed.
- Two new compiler switches have been added: /FPP and /SPARAM. These are to allow conditional compilation. The first switch must be present when compiling a file containing CIF/CELSE/CENDIF statements when there is no /SPARAM present. While configuring this flag as set does not affect the eventual results of compilation, compiling will be slower as an extra pass and a temporary file are required to pre-process a file.
- Added new compiler switch /VPARAM to support extension to CIF processing. The /VPARAM <name> <val> switch allows a user to over-ride a specific SPECIAL PARAMETER value, unlike /SPARAM which sets all SPECIAL PARAMETER values to the same value. /VPARAM values over-ride any /SPARAM values.
- CIF statements have been extended to cope with all the integer relation operators (.EQ.,.LT., /=, >=, etc) and also the new form CIF (BooleanVariable) which allows processing when BooleanVariable is non-zero, useful in conjunction with /VPARAM.
- A new compiler switch /XREAL has been added which sets the default kind for REAL to 3 (c.f. /DREAL)
- A new compiler switch /PAUSE_ON_ERROR has been added which causes the compiler to wait for a keypress after every warning/error/comment.
- FTN95 now has default options files. When FTN95 is invoked, it first looks for a file FTN95.CFG in its directory, then looks for a file FTN95.CFG in the current directory. These files are the same format as files used by the /OPTIONS switch.
- Two new directives have been added: !FTN95$FOR_DBOS and !FTN95$FOR_WIN32. These are used to confirm the target, i.e. if a file contained !FTN95$FOR_WIN32, and was compiled using a DBOS version of FTN95, an error message will be output.
- Several bugs connected with pointers have been fixed.
- Several bugs connected with the optimisation of DO loops have been removed.
- The optimiser can now switch the variables that it holds in registers within a routine if that generates better code.
- Several spurious syntax errors associated with CODE/EDOC sequences have been resolved.
- The SELECT CASE statement had problems when some of the cases involved a range, this has been fixed.
- A bug which could cause the /CHECK option to generate incorrect code in certain circumstances has been fixed.
- Problems involving pointers (to arrays) in common have been fixed.
- The NOT function now works with short integer arguments.
- Several spurious syntax errors associated with MODULE’s and INTERFACE’s have bee fixed.
- A bug which caused the debugger to print misleading information after a reference to undefined data (/UNDEF) has been resolved.
- COMMON blocks starts now aligned on 8-byte boundaries (previously 4-byte.)
- “Simple” functions are now implemented, where a simple function is one like:
INTEGER FUNCTION SIMPLE(I)
INTEGER :: I
SIMPLE = ifun(I)
END FUNCTIONThe code produced for these functions is optimised to remove the need for a “(Result of SIMPLE)” variable, i.e. the body of the function would simply be:
push address of I
without any need to load EAX with the return value.
- Added new directives:
- Added support for directives a la DVF, currently only:
This permits a user to use OPTIONS statement in a standard-conforming manner, e.g.:
Specify the format of the source to preserve compatibility across source formats. Use in files like WINDOWS.INS, like:
Silverfrost FTN95 is a full Fortran 95 standards compliant compiler, capable of producing fast executables for Win32 and for Microsoft .NET. FTN95 ships with the world’s best runtime checking and a great range of supporting software. All standard and many vendor-specific legacy language features are supported, so that Fortran projects may be any combination of Fortran 77, Fortran 90 and Fortran 95.
- Full Fortran 95 language compatibility
- Comprehensive integration with Microsoft Visual Studio .NET
- Standalone editor – Plato3
- The world’s best runtime checking
- Very fast compilation speed
- Excellent compile-time diagnostics
- Full souce level debugging
- Builds console, Windows® and Microsoft .NET 1.1 and 2.0 applications
- free graphics – use Simdem a public domain library built with FTN95, includes full source code
Windows® Specific Features
- Visual Studio .NET integrated debugger
- Binary compatibility with FTN77 object and library code
- Complete I/O library compatibility with FTN77
- Inline Mnemonic Assembler using CODE…EDOC
- Microsoft Visual C++ Interoperability
- Salford C/C++ Interoperability
- GUI building with Salford Clearwin+
- Full support for REAL*10, COMPLEX*20
- Virtual Common
- Small EXE and OBJ files
Microsoft .NET Specific Features
- Full Fortran .NET debugging facilities
- Effortless porting of existing Fortran code to .NET
- No language restrictions
- Use Salford CHECKMATE technology within .NET programs
- Fast runtime performance
- Simple inter-language operability
- Recompile existing code and use it immediately with .NET
- No steep .NET learning curve to be negotiated
- Easily attach a .NET Windows Forms front end to a Fortran backend
- Create and manipulate .NET objects within Fortran
For the time being we are unable to offer the following product ranges although we are currently working hard to increase the number of products we can offer in the future. Please contact us to talk about alternative products that we may be able to offer you.