gFortran and MAKE

I have the code which was made in gFortran which FTN95 was unable to compile due to conflict in common block or possible error. Fun is that conflicting variable is just 1 symbol long. The authors of the code are not responding hence there are two options: to find what for this variable was used in the code or to use gFortran and let it compile the code as is. Code is very large, so it was not easy to find the purpose of this variable. So i decided to try gFortran to compile this code. The ability of FTN95 to catch the bugs like a terminator became its Achilles heel. While gFortran makes executable like crazy despite of gazillion of errors in the source code. But unfortunately this code uses MAKE utility i am not familiar with at all.

My questions are:

1. Do anyone has the experience with MAKE utility used for compilation with gFortran? The MAKE file has options for all Fortran compilers in the world since Roman Empire, кроме FTN95, so i get sick after 3 minutes trying to decipher what is what there.

2. What source to download gFortran compiler do you recommend?

3. How to install gFortran without any potential conflicts with FTN95?

Dan, I think that for running Gfortran the easiest way is to find a Linux system with Gfortran installed on it. A Linux VM on Windows will do almost as well.

You can obtain Gfortran for Windows from equation.com, Lahey, and with various Mingw distributions. These distributions also provide make Note that these distributions provide the compiler and tools for command line usage. If you want a GUI for building, you have to choose and install one yourself.

FTN95 comes with its own make utility, mk32. In many cases, the use of **make **is not really needed; just compile all the Fortran source files and link them together. In more complicated cases, the Fortran sources may need some kind of preprocessing, and it may be necessary to compile some C sources in addition and link the resulting object files together with some libraries.

Perhaps, if you can post the declarations of the variables in the offending common block and what FTN95 says about the code, we can help. Similarly, if you can post the makefile here, some helpful comments may be made.

As far as

3. How to install gFortran without any potential conflicts with FTN95? is concerned, there is nothing to worry about.

Hello,

I used the make utility on UNIX systems in former times and did not think it was an enigma 😉

In bigger projects you defined relations between sources and objects to be created in so called Makefiles. Instead of calling scripts or batch files you called the make utility with special parameters in order to create the objects. One of these parameters could be the name of the object you wanted to create. (This is only roughly spoken).

The make utility checked which objects were out of date (this depends on the relations defined in the Makefile mentioned above) and executed the commands to create them (which are defined in the Makefile, as well).

You should keep in mind that in the former times studios were not at hand.

If you use scripts or batch files no check is done if files to be created are out of date. This is a big difference when using make as opposed to scripts or batches.

If you create libraries e.g. depending on more than 1 fortran source file then in a batch file you would create the object files from all the source files involved and then archive them into a library. If some of the object files are not out of date the compile step for creating these object file would not be necessary.

There is an option of the make utility (-n), which shows what make would execute (if called without option -n) which I found very handsome.

As far as I know some of the studios have options to create the corresponding Makefiles for the projects.

I do not know if the Makefiles on UNIX and Windows/gfortran differ very much but I would suspect not.

By the way I just have in mind that the use of TABs were important for the rules defining how an object was created from a source file (which often is the complete compile command with all its options).

Regards, Dietmar

Apologies for being dim, but isn't the point of compiler error messages that you can go away and resolve the problem in the Fortran source code, not to change your compiler? (Unless, of course, the error message was bogus). Surely the error message points you (not always accurately) to the issue at hand?

Error No. XYZ1234 This compiler can't handle the following line of code. Use Gee Fort instead.

Unbelievable!

It's far more difficult to resolve a problem for which no error message is emitted, like those programs that predict the end of the world just because I drove to the supermarket in a diesel car and carried my shopping home in a plastic bag, instead of walking with a basket made of reclaimed newspapers on my head.

Eddie

Quoted from LitusSaxonicum ... isn't the point of compiler error messages that you can go away and resolve the problem in the Fortran source code, not to change your compiler? (Unless, of course, the error message was bogus).

It is not unusual to be in a situation where the code being worked on uses, say, F2003 features that are supported by Compiler A, and is beset by bugs that compiler B is better at catching, but compiler B only supports F95. Compiler A is not as good at catching errors. Compiler B, when it sees F2003 features that it does not understand, is likely to issue many error messages.

There is no obvious choice here.

Mecej4,

If it's a large, pre-existing code, then it's unlikely to use modern features. If it does, then they are the very things most likely to cause problems! Dan seems to have a problem caught by FTN95 that the other compiler ignores. Is that truly a good reason to wrestle with the other compiler? I didn't get the impression that there were many error messages. He didn't say that it was an unsupported feature in FTN95 that caused the problem - and indeed, the code he has to wrestle with might have been emitting wrong results for years or even decades - I know of examples.

Most of the other compilers don't have inbuilt graphics, or tools to build GUIs - or at least not unless one wants to spend a lot of money on third-party add-ons. Some of us think that they are more important than the latest gizmos even if those gizmos are indispensable to others. That pretty much makes using the alternative to FTN95 out of the question as far as I am concerned.

Perhaps it's my good fortune to only ever need to work on Fortran that I wrote myself. Just about everything I've seen written by anybody else might just as well be in Klingon*. I put that down to only programming as a side interest as well as having a pedestrian and old-fashioned style, I am reminded of the notorious quote that it is possible to write Fortran in any language!

Eddie

*Just like the BMW factory doesn't seem to put indicators on its cars, or at least, their drivers cannot find the switch, many Fortran programmers seem to be unaware of how useful comments can be. Ally this to a preference for statement numbers chosen at random, and Cotton-eyed Joe structures if they eschew statement numbers, then the incomprehensibility is not difficult to explain.

The link that John S. gave is for G95, not Gfortran.

G95 is outdated and lacks many of the Fortran 2003 and 2008 features that are present in Gfortran. G95 does not support X64 on Windows, and may have some incompatibilities with Windows 10. Gfortran was forked from G95 in 2003.

Gfortran has many authors, whereas G95 has essentially one (he did a beautiful job back then, but ...).

Dan,

I have abandoned use of make and now use 'simple' .bat files to control compile and load, using either: slink64 @load_list.txt >> ftn95.tce or gfortran @load_gf.txt >> gf_build.tce 2>&1

With this approach, I can define local environment variables for different compilation options for groups of .f90 files and do a rebuild, eg optimisation or stack size selection. slink64 Ver 8.05 certainly encouraged this approach when .lib files were not supported. (I am still using this approach, without yet going back to the .lib files)

The build times for my programs are now so quick that the faster MAKE strategies are no longer needed. Not even time for a coffee !

By using the following as the first two lines of my build .bat, there is no confusion with using incompatible .mod or .obj files. del *.obj del *.mod

It should not be too difficult to convert a make to a do_build.bat

John

Sorry, i had no time to clean the code from elementary errors FTN95 complaining due to different default TAB size of Gfortran and FTN95. Newer FTN95 probably already can handle different TAB sizes, but there was no time even to look how this works

My understanding is the TAB is not part of the Fortran standard. I do not know what interpretation ifort, gFortran or FTN95 apply to TAB, but it certainly is not portable.

There is also the issue of the possible different interpretation that FTN95 and Plato apply to TABS, as what you see may not be what you get. In general, there is no guarantee that the representation of TAB characters by the IDE will be the same as the compiler interpretation. This has been shown in past posts reporting line length errors, either 72 or 132 length lines. Plato will allow you to change the tab settings which can make for strange errors when compiling with FTN95 !!

I would recommend scanning the source code for tabs and replacing them in a way that is compatible with the compiler that was used to develop the code. If you are writing a scanner with FTN95, remember to use the subroutine READ_TABS@(unitno), to enable tabs to be identified.

gFortran has a compile option -Wtabs to help locate tabs in code. FTN95 should have the same.

Recent versions of FTN95 have the '/TABS n' command line option which allows you to change from the default tab size of 8.

Also recent versions of Plato automatically adds /TABS n to a command line and uses the a value for n that equals the current user tab setting.

Paul,

Thanks for the update.

Definition of TAB interpretation is not easy to find. I could not find what gFortran does although I think it may be similar to iFort, which has the first tab to column 6 for F77 format. I am not sure what free format does. (Could not find /TABS in ftn95.chm either)

Doesn't Plato has an option to replace all tabs with equivalent spaces when the file is saved ? (tools>settings>text editor) 'Replace tabs with spaces' which could be a good thing for free format. This could cause a lot of problems if it was old fixed format code developed on ifort. 'Show whitespace symbols' is also very useful (which I always use, as with /IMPLICIT_NONE !!)

My preference is to not use the tab character in code.

John

Plato can be set to replace tabs with spaces as you type. There is also a macro to replace all existing tabs with spaces. In both cases you need a manual 'Save' afterwards.

I tried /TABS with Gfortran sources in a batch file and it did not perform well in some cases when compiled file also had INCLUDEd files. I used WIDE_SOURCES instead and all was compiled OK. Will make a demo reproducer hopefully quick

I have had many attempts at correcting TAB characters in Fortran source code I have needed to fix.

My utilities include: count_char.exe which counts all characters [1:255] that appear in a file scan_file.exe which lists a text file identifying control characters and provides a character count.

PLATO does a good job of identifying tab characters, especially if 'Show whitespace symbols' is enabled, but it does not remove the TAB characters and replace with the correct number of spaces

(my impression of ..) The best advice I can give is don't use tab characters in Fortran code.

Once you change the IDE, the info on tab positioning is lost.

JohnCampbell

/TABS is missing from ftn95.chm and I have corrected this.

So where is the good installation files for gfortran?

You get again these

*** Unwritable expresssions in read statement or *** READ can have a maximum of two non-keyword specifiers

and you are guessing and guessing trying and trying different things to understand what the heck this may mean. Need second opinion from different compiler because that not user-friendly diagnostics got on my nerves. As if it was hard to tell that it is not allowed to over-write the parameter iz or what and where these freaking keywords specifiers are. What, there was competition to write things the shortest and most cryptic way as there are no memory to fit the compiler into 64kB floppy disk?

parameter (ix=100, iy=100, iz=1000)
Real*8 BEJ (3, ix, iy, iz, 3) 
character text32*32

  open(unit=118,file='aaa', STATUS='old')
    read (118,'(a)') text32
    read (text32, '(4x, 3i6)',err=1,end=2) i1, iz, i3
  close (118) 

!... Errors
goto 1000
1 print*, 'Error reading'
goto 1000
2 print*, 'End reached'
1000 continue

end

Dan,

Not sure what your post is asking, but yes, gFortran does have a better error message in this case:

FTN95 gives: C:\temp\forum\dan\dan2.F90(8) : error 304 - Non-writable expression in READ statement C:\temp\forum\dan\dan2.F90(8) : error 52 - Compilation abandoned

gFortran gives: C:\temp\forum\dan\dan2.f90(8) : error - Named constant 'iz' in variable definition context (item in READ) at column 1 Compilation failed.

iz is a parameter so can't appear in a read statement.

I am in the good position of having FTN95 and gFortran installed and can easily switch between them in PLATO Ver 5, switching via Tools > Settings > Miscellaneous

Regarding installing gFortran, there are a number of options for downloading, and I have an approach via environment variables to make installs of both gFortran and FTN95 easier to manage. I'm sure I have explained this in previous posts.

Thanks John. What specifically installation do you have? Please provide the exact link. There are many different options i do not have time to try

Dan,

equation.com > Programming tools > Fortran, C, C++ This provides a self extracting file, eg gcc-8.3.0-64.exe download and then install into : C:\Program Files (x86)\gcc_eq\gcc_8.3.0

Then create the following environment variables, either via a .bat file or via control panel > system (these work on Win 7)

set f95.ver=8.40F set _gcc.ver=8.3.0

set gcc_dir=C:\Program Files (x86)\gcc_eq\gcc%_gcc.ver% set gcc_path=%_gcc_dir%\bin;%_gcc_dir%\libexec\gcc\x86_64-w64-mingw32\%_gcc.ver% set EQ_LIBRARY_PATH=%_gcc_dir%\x86_64-w64-mingw32\lib

set gcc.ver=%_gcc.ver% set gcc_dir=%_gcc_dir%

set f95_dir=C:\Program Files (x86)\Silverfrost\ftn95_%f95.ver% set ftn95_path=%f95_dir% set f95include=%f95_dir%\include set mod_path=%f95_dir%\include

set Path=C:\ProgramData\Oracle\Java\javapath;%gcc_path%;%ftn95_path%;%orig_path%;c:\utils

Note:

1. set orig_path= ' this is the original path prior to installing gFortran or FTN95, but excluding some unnecessary rubbish. your call ! I create orig_path in Control Panel > System > Advanced system settings > Environment Variables > System Variables > New... by cutting and pasting of Path value.

2. all other variables can be created similarly. I have chosen names as their sorted order is important. MS Win 7 does not do multiple pass definition !!

3. changing installed versions is merely changing the value of f95.ver and _gcc.ver to the appropriate value.

4. c:\utils contains most of my own programs to help with programming.

5. equation.com version of gFortran is different to mingw-w64 version (used for clearwin64 ?) in that it is a static build that does not use .dll's. I find this satisfactory. If you need to use clearwin64, ie gFortran + clearwin+ graphics, that requires .dll's, you may need to install mingw-w64 version. Downloading is a bit more complex, to choose the options you require. I have both but would need to review my last install ( forgotten the options !! )

6. Typically FTN95 is my preferred software development and when combined with /IMPLICIT_NONE is my most reliable approach.

Quoted from DanRRight There are many different options i do not have time to try I assume this refers to mingw-w64 version. Let me know if this version is required.

I hope this helps

John