How universal are these modern Fortran Features?

[mitch grunes]

(I already tried posting to the old Fortran Usenet group - didn't realize nobody reads it anymore. I guess this is the active Fortran forum - right? I hope it isn't too technical a question.)

How universal are these modern Fortran Features?

1. I'm updating my Fortran code that processes other Fortran code, such as my code diagrammer. I'm about to give up keeping it in card format, along with old Fortran compilability. I want to use free format and some modern features, and for it to be able to process more (almost all?) modern Fortran features.

2. I'd like it to compile on GNU (gfortran), Microsoft, Intel, Apple, NVidia, AMD, ATI, Sun, SGI and DEC Fortrans; maybe on cross-compilers for Android (ARM and Intel CPUs) and IOS; and anything else that is common. (What else is commonly out there?) Unfortunately, I only have PCs, running Windows and Linux, running only gfortran, so I can't test the features I'd like to use on all of them.

3. So, how universal among these compilers are:

A. COMMAND_ARGUMENT_COUNT
B. GET_COMMAND_ARGUMENT

Or would I need a C-language stub to handle the command line?

4. How universally supported among these compilers is module ISO_FORTRAN_ENV, including stdin, stdout, and stderr. Also how universal on the indicated platforms is stdin=5, stdout=6 stderr=0?

5. The draft standard section 3.3.2.1 (

http://j3-fortran.org/doc/year/16/16-007r1.pdf)

limits line length to 132 characters, including free format. If comment lines extend past 132, do the indicated common compilers ignore it, emit an error, or does that vary? Do some modern Fortrans allow non-comments to extend past 132 too?

6. Are VAX and Sun systems still common?

6.5 At one point, VAX file format limited line length to 127 characters - is that still true, and if not, do OPEN, READ or WRITE statements need a special form to handle it?

7. Section 4.4.4.3 of the draft standard says that all non-control characters can appear in free format character constants. But do some of the common compilers have problems with special characters like
| & # @ ! % ~ < > [ ] { } :
inside quotes ('' or ""), even in free format? (On [old] SGI compilers, you had to explicitly disable the pre-processor - or maybe that only for card format?)

8. Is OPEN clause ENCODING='UTF8' supported on all common modern Fortrans?

9. The draft standard allows optional spaces in some keywords:

Table 3.2: Adjacent keywords where separating blanks are optional

BLOCK DATA
END ENUM
END SELECT
DOUBLE PRECISION
END FILE
END SUBMODULE
ELSE IF
END FORALL
END SUBROUTINE
ELSE WHERE
END FUNCTION
END TYPE
END ASSOCIATE
END IF
END WHERE
END BLOCK
END INTERFACE
GO TO
END BLOCK DATA
END MODULE
IN OUT
END CRITICAL
END PROCEDURE
SELECT CASE
END DO
END PROGRAM
SELECT TYPE
​

Last I checked, GNU gfortran does not support "dowhile" in free format. Are there any other cases where common modern Fortran compilers require the optional space be present or not present?

10. Is there a Modern Fortran interpreter, preferably free? (Yes, I know that's silly from some perspectives. Nonetheless...)

11. Of course All trademarks mentioned above are the property of their respective owners, possibly including GNU, gfortran, Microsoft, Intel, Apple, NVidia, AMD, ATI, Sun, SGI and DEC, Android, ARM, IOS, and any that I have accidentally omitted.

Thanks for your time!

P.S. Would posting a link to my diagramming code be a violation of posting guidelines?

 

[xwb]

Just a minor note: there is no Microsoft Fortran compiler

MS sold Powerstation to DEC (DVF - Digital Visual Fortran).
DEC got bought up by Compaq (CVF - Compaq Visual Fortran).
Compaq got bought up by HP
HP sold it to Intel (IVF - Intel Visual Fortran)

If you use IVF or any of the above variants, you can still use the !$MS or !$DEC attributes. Powerstation, DVF and CVF are only up to Fortran 90.

1. When you say "modern", how modern do you wish to go? Many stop at F95, current standard is F08.

11. Free Fortran compilers

https://www.thefreecountry.com/compilers/fortran.shtml

 

[mitch grunes]

In this context, "modern" means "in frequent current use". In other words, what a modern (current) software developer probably has avaiable.

I provide executables for Microsoft windows (created using gfortran and MingW, statically linked, so they don't need any DLLs) and (Ubuntu) Linux (created useing gfortran - again statically linked), but, on other platforms, they have to compile my tools themselves - so whatever they have available, must work. In the past it only required Fortran 77, with minor extensions that were available in the 1980's, but I no longer want to limit my code that way.

For example, I want to write long lines in free format, include special characters in quotes, be able to access command line arguements, and be able to input Unicode (UTF-8) format source code to my program - though the latter, if it is in UTF-8 (i.e., ASCII characters remain in ASCII) probably just means my code has to be written in a way that won't be confused by Unicode strings. (The current version strips out non-ASCII charaters, but that isn't quite good enough, now that Unicode characters are frequently part of source code.) I'd also like to output seperately to standard output and standard error. All of these are part of the Draft Fortran 2015 standard - but maybe not part of older Fortran compilers.

I don't know all the types of development platforms that are in current common use.

I presume most of them can run gfortran, which means they have all the features I need. But I'm not sure about Macs, SGI's, Power PCs (if they still exist), modern mainframes and modern supercoputers, and any other types of modern development platform that exists.)

I realize that mobile devices aren't usually development platforms in themselves, but people frequently carry them with them, so I would like my software to run on them too, if possible. (Maybe I can get the Android development kit running on a PC. Unfortunately IOS mobile devices are out, because I don't have a Mac to develop for them.

 

[xwb]

I've worked on 4 sites using Fortran and in my experience, "in frequent use" is very site dependent. Some sites will always use the latest/greatest. Others will just stick to F77 or F95. Many of the engineers (they are not programmers) are quite resistant to change.

 

[mitch grunes]

I've looked at the standard documents a bit more carefully. They are SO complicated.

The most important thing I want is a command line interface, i.e., COMMAND_ARGUMENT_COUNT and GET_COMMAND_ARGUMENT. They are not in the Fortran 90 and Fortran 95 standards, but they are in Fortran 2003, so that is good enough.

What I could do for backwards compatability is to provide two different mainline programs - one that uses the command line interface, where that is available, and one that prompts for equivalent interactive input, as my current code does. A bit unclean, but practical. And I can continue to provide command scripts for several platforms which effectively provide command-line input, though it's been many, many years since I could test the VAX scripts.

I continue to use old-style variable declarations anyway - they are shorter and easier to read and debug, and the new style provides nothing useful whatsoever, except the possibllity of spcecifying features that impact efficiency, which isn't important to my utilities, because they don't take much time to run. So I COULD retain the ability to compile with some Fortran 77's, provided they support long code lines (as many Fortran 77's did, with a special compiler switch, or if a filename suffix of ".f" instead of ".f77" was used.) However, many Fortran 77 compilers gave special meanings to some special characters inside quotes - e.g., '\n' was often interpreted as a <new line> (line feed) character. Too bad. With such compilers, I could suggest the user substitute \\ for \ inside quotes - and provide a test.

It would have been nice to have the explicit association with standard input, standard output, and standard error, so my command could work like C language Unix filter - i.e., that the user can apply unix re-direction to the input and output streams. But that isn't part of standard Fortran until the Fortran 2015 Draft, which isn't even truly standard yet.

What I can do instead is that if input or output files are not specified on the command line, then I can input and output from and to * instead of a unit number. And provide another option to deal with processors on which the first column of pre-connected output was used for carriage control - yuk.

I don't really need ENCODING='UTF8'. Almost all modern processors use 7 bit ASCII characters (without a parity bit) inside 8 bit bytes anyway, which means that UTF-8 Unicode will probably work too, because they don't really conflict. Maybe there are a few compilers where that won't work - e.g., on IBM Mainframes, which didn't use ASCII. But that is a small world, and I could suggest the user add a clause on such machines. While they are at it, they could substitute char(5) for char(9) in my code to represent the horizontal tab character.

I guess this is the sort of compromise I need to support a variety of platforms and compilers...

 

[mikrom]

The most important thing I want is a command line interface, i.e., COMMAND_ARGUMENT_COUNT and GET_COMMAND_ARGUMENT.

I used only GNU extensions IARGC() and GETARG(), but now I see that my version of gfortran supports the standard 2003 functions COMMAND_ARGUMENT_COUNT() and GET_COMMAND_ARGUMENT() too.

I have this version of gfortran:

$ gfortran --version
GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
....