At a first look, this does not seem to involve anything Darwin-specific (particularly, since this is x86_64, so nothing using experimental support).
… perhaps someone here can see what the issue might be? Iain > Begin forwarded message: > > From: Lawrence Doctors <l.doct...@unsw.edu.au> > Subject: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS > Big Sur Version 11.4 > Date: 29 July 2021 at 11:58:40 BST > To: "g...@gcc.gnu.org" <g...@gcc.gnu.org> > Cc: Lawrence Doctors <l.doct...@unsw.edu.au> > > 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= 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 > > 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 > 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 >
