GNU Fortran 4.6.0
Dear GNU Fortran Expert: (1) On December 16, 2010, I downloaded: gfortran-snwleo-intel-bin.tar.gz onto my MacBook Pro running Snow Leopard 10.6. Hence, this would be GNU Fortran (GCC) 4.6.0 20101106 (experimental). This followed downloading XCode, which I believe is necessary for the Fortran. The installation appeared to go smoothly. (2) I currently have a suite of 227 main Fortran programs. Despite the fact that these have been developed and debugged over a 40-year period using various IBM mainframes, three Cyber computers, VMS (VAX 32 bit), VMS (Alpha 64-bit), VMS (Itanium 64-bit), and MacBook Pro (64-bit, earlier GCC Fortran version, namely 4.5), the compiler was able to detect more ”errors”. A good example, is the need to use the parentheses in the declaration: character*(1) a, b, c Which had not been previously necessary. I did not mind this because your error messages are extremely clear in meaning and it was a simple matter to make these modifications. (3) I compile using the command: gfortran -c -std=f2008 -fdefault-real-8 -fdefault-integer-8 \ -fdollar-ok -fbounds-check -Wcharacter-truncation \ -Wuninitialized -Wunderflow -Werror -fbacktrace program.for (4) Using the "-v" option when compiling gives the following information: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-$ Target: x86_64-apple-darwin10.4.0 Configured with: ../gcc-4.6-20101106/configure --enable-languages=c++,fortran Thread model: posix gcc version 4.6.0 20101106 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ /usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 xacvopt.for -ffixe$ GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.$ compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.$ GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101106 (experimental) (x86_64-apple-darwin10.$ compiled by GNU C version 4.6.0 20101106 (experimental), GMP version 4.$ GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ as -arch x86_64 -force_cpusubtype_ALL -o xacvopt.o /var/folders/3D/3Dikh2dMHY4$ COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/:/usr/loca$ LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/:/usr/local/lib$ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.4' '-c' '-std=f2008' '-fdefault-$ (5) The reason that I write is that the parameter “end= label” appears to be ignored in a READ statement. (a) This causes the program to crash with a Fortran run error if the very last character of the data set is a carriage return. (I believe that this is the custom with Unix – to complete a plain text file with a carriage return.) I am still becoming familiar with Unix. As you will note from the above, my expertise is with VMS which is very unfussy about such details. (b) Almost all my data for my Fortran programs is read using NAMELIST. If I remove the offending carriage return, the program runs smoothly with no Fortran errors, but the last NAMELIST data set is apparently ignored. I can fix this in a crude manner by adding another, dummy, NAMELIST with no variables in it (again, being careful not to include that offending final carriage return). Then all the data is processed. (6) For the moment, I can also fix the problem more professionally by adding the parameter “ios= iostat” in the READ statement and adding a line to the program with the Fortran statement: if (ios .eq. 5010) goto label I trust that I have described the problem fully. I really doubt that there could be such a basic error in GNU Fortran and I therefore suspect that there is a problem elsewhere. I hope that I do not cause you too much trouble over this but would be pleased to hear from you if you have the time to comment. I can, of course, send you a very short sample file demonstrating the problem. With best wishes for the Season, Larry Lawrence J. Doctors Emeritus Professor Naval Architecture Program School of Mechanical and Manufacturing Engineering The University of New South Wales Sydney, NSW 2052, Australia Telephone: +61-2-9385 4098 Messages: +61-2-9385 4093 Facsimile: +61-2-9663 1222
Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
Dear Sir/Madam: I would firstly like to thank the folks at GCC for their fine work on developing the Fortran compilers, which I have been using for about 12 years now, on a series of four MacBook Pro computers. In total, I have had over 50 years experience using Fortran, this being on a variety of different platforms. I therefore do consider myself as being a very experienced programmer. I have recently installed your gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4 with a 2.4 GHz 8-core Intel Core i9 processor. The computer has 64 GB 2667 MHz DDR4 of memory, with a disk capacity of 8 TB. During my previous experience, when I switched to a new computer on about six or seven occasions, most of my programs (now 553 in number) compiled successfully the first time, but some of the programs required minor modifications. On this occasion, I encountered the following new challenges: (1) I see that you now check consistency of the argument types and rank, in CALL statements. Thus, if an argument would normally be an array, but is unused in some CALL statements, my practice was to use a dummy argument with a short name, such as "d". This has worked for over 50 years without trouble. However, you now check for consistency. Obviously this was easy to fix, as I simple declared a dummy array in a DIMENSION statement with the name "d (1)", which solved the problem. On reflection, I would say that this is an improvement, because it forces the programmer to think carefully when writing the CALL statement. (2) I encountered a curious failure on compilation with the following statement using integer arithmetic: n= (m + 4)/5 with the message Error: Integer division truncated to constant ‘2’ at (1) [-Werror=integer-division] f951: all warnings being treated as errors This error only occurs if both (a) the value of "m" would lead to a truncation (say 7 but not 6), and ALSO if (b) the value of "m" was set in a PARAMETER statement. I can work my way around this difficulty by rewriting the statement as: n= int ((1.0*m + 4)/5) but it does seem clumsy. (3) The new compiler seems to dislike large fixed DIMENSION statements, such as the following at the beginning of the program unit: parameter (n= 105) dimension a (n) The compiler then issues the following message: 3 | dimension a (n) | 1 Error: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage. This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider using ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the code to use an ALLOCATABLE array. [-Werror=surprising] f951: all warnings being treated as errors I agree that the message is clear and I was able to follow the suggestion to use an ALLOCATABLE statement, but I still wonder why you consider the program unsatisfactory in the first place. I can understand (to some degree) why such a large array is frowned upon, because one should economize on the size of arrays. On the other hand, if the use of a large array makes the task of the programmer easier, it should be allowed. Furthermore, an array size of 100 elements or so is very small, considering the size of the RAM and the disk available nowadays. I would be pleased if you have the time to respond and I would like to express my appreciation again for the considerable effort that your group has invested in the Fortran compilers over the years. Sincerely, Larry Lawrence J. Doctors Emeritus Professor Naval Architecture Program School of Mechanical and Manufacturing Engineering The University of New South Wales Sydney, NSW 2052, Australia Email: l.doct...@unsw.edu.au Telephone: +61-2-9371 4158
