We start off with some examples intended to test whether it's possible to create a function with LEN given by specification expression via function name, and SIZE given by specification expression via result name. Preliminary examples: interface1.f90, and interface2.f90. Final examples: interface3.f90, and interface4.f90.

Now I would like to present an example that is quite mysterious to me. It attempts to use 4*atan(1.0d0) in an initialization expression, so that we can use the calculated value of pi as a parameter. Firstly, we compile the file constant1.f90 which calculates the first seventeen significant figures of pi and saves them as character LENs of a user-defined type. Then we compile the file constant2.f90 which defines a named constant instance of this user-defined type. Since this is a constant, we can use the LENs of its subobjects to define the constant pi. We link the two resulting object files together to create a program. Where did we violate the standard such that an expression which was not an initialization expression ultimately was used in an initialization expression? Answer: this lies in Corregendum 1 where constant expressions are pretty much expunged from the standard, and good riddance to them, too! Thanks to Steve Lionel at Intel for informing me about the effect of the Corrigendum on my examples here and to Richard Maine of X3J3 for telling me how to find it.

I also have some examples that lf95 5.70f, cvf 6.6c, and g95 Windows download of 12/18/04 all seem to fail on. First consider elem_assign.f90, which tries to do an elemental defined assignment. New x and permuted x should be the same, of course. Update 2/15/06: some code which plausibly trips over this bug is to be found at order_stat.i90, test program at order_stat_test.f90. lf95 7.10.02 and ifort Package ID: W_FC_C_9.0.029 still trip, but g95 gcc version 4.0.2 (g95!) Dec 21 2005 has fixed this. Now examine cyclic_specs1.f90, where compilers seem to be required by the standard to encounter an internal compiler error. Instead they all seem to find some excuse to reject this code. Here's a more tedious example: first compile logical_gen.f90, then run it and compile the resulting file logical_all.f90. None of the above-mentioned compilers can do this. If you can get it to compile and run it should yield a truth table for the 1024 possible binary logical operations in f95. Correction: now that I have seen Corregendum 1 it is apparent that the above example now is only valid as an extension to the f95 standard. But I will leave it in play as it's still valid in f03 and instead provide logical_genb.f90 which creates logical_allb.f90 which should in turn produce a truth table with 768 entries, but this time should work on any f95 compiler.

As an example of generic programming in Fortran I offer GENERIC_BLAS.ZIP which is a template version of the well-known BLAS package. It should be complete with README.TXT file, *.bat files from which the user can hopefully puzzle out how to compile and test on his own machine, and input files for the test programs.
New 3/30/06: upgraded GENERIC_BLAS.ZIP to work with extended precision, REAL(SELECTED_REAL_KIND(18,4931)).

A little test of whether the elemental intrinsics accept all their possible arguments is test_intrinsic1.f90.
An example of stream I/O portable across g95 (4/2/06), cvf 6.6C3, ifort 9.0.030, and lf95 7.10.02 fire.f90.
Portability is increased also to ftn96 PE 4.9.0 with fire2.f90 by working around ftn95 bugs and implementing ftn95 syntax for stream I/O when detected.

Another example of code that messes up a lot of compilers: logical.f90 which also needs the include files logical.i90 and ifaces.i90. This doesn't compile on lf95 7.10.02 nor ftn95 PE 4.9.0 and results in a spurious standards warning on ifort 9.0.030 and cvf 6.6c3 when f95 standards checking is in force. Works OK on g95 4/2/06. It seems that having an intrinsic extension operator can cause unanticipated problems for compilers.

New 10/14/07: My first attempts at using BIND(C) for Windows programming. A console example and a Windows example.
New 1/9/08: Some bug fixes for the console example and the Windows example.
New 7/20/10: Adaptation of the Windows example to use !GCC$ ATTRIBUTES STDCALL and function WinMain so that it works also with 32-bit gfortran.
New 12/20/10: Simple Windows program to send a test pattern to my TV.
New 3/16/08: An attempt to create a program that uses multiple calling conventions in gfortran.
New 4/30/08: Tests whether some functions exist in gfortran.
New 12/20/10: Windows and Linux utilities to read and write floating control word and status word as well as mxcsr and read time stamp counter and get CPUID.
New 12/31/10: I have improved my Hello, world in Opengl program. It needs a relatively recent Windows version of gfortran, such as those available at http://www.equation.com. I hope you find this example useful.
New 1/11/11: Further improvements to my Hello, world in Opengl program. The opengl_types, gl, and glu module are improved and this example has a 3-d image and text.
New 1/21/11: I am posting a C example program to demonstrate that Pinyo Taeprasartsit's MinGW 64-bit freeglut package works.
New 1/21/11: Now I have a Fortran version of the above example, with screenshot, 64-bit executable, and build instructions.
New 2/10/11: I have been working on the GridView example from Norman Lawrence, Compaq Visual Fortran: a guide to creating Windows applications, Digital Press 2002. The book can be found at Google Books and there is a companion site with the source code for the book as well. So I have fixed some bugs in the program and added some enhancements as an exercise in learning how to make Win32 API and OpenGL work in Fortran. Please take a look at the result here.
New 6/14/11: Example using OpenGL to show an AVL tree.
New 7/27/12: I have been reading NeHe's OpenGL tutorial pages. I have converted Lessons 01-05 to gfortran. New 8/2/12: Now I have Lessons 06-10 converted. New 8/8/12: Now I have Lessons 11-15 converted. New 8/13/12: Now I have Lessons 16-20 converted.