On Thu, 29 Jul 2021, 11:59 Lawrence Doctors, <l.doct...@unsw.edu.au> wrote:
> 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: > This mail seems off-topic for this mailing list, which is about development of GCC, see https://gcc.gnu.org/lists.html The gcc-help or fortran mailing lists would be more appropriate. > (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. > Is this related to https://gcc.gnu.org/gcc-8/porting_to.html#fortran ? Or maybe the item about dummy arguments at https://gcc.gnu.org/gcc-8/changes.html#fortran > (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 was a new warning in GCC 6, which is an error because you're using -Werror to turn warnings into errors. https://gcc.gnu.org/gcc-6/changes.html#fortran 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= 1050000) > 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 > Again, you've turned a warning into an error. 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. Because you asked for warnings to be errors. 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. It is allowed, that's why it's only a warning by default. GCC provides various ways to control warnings/errors, see the manual. Furthermore, an array size of 1000000 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 > >
