Re: Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
(Adding the OP). (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. This warning was introduced because people all to often would write code like x = 3/7 and expect the same result as for x = 3./7.. As often, it is a delicate balance between warning too much and too little. Because this is an error, I assume you use -Werror. The error message gives you a hint, although an indirect one, of how to downgrade this particular error to a warning: Compile with $ gfortran -Wall -Werror -Wno-error=integer-division foo.f90 and you will get a warning again. If you want to still have an error for other unintended cases you may have missed, you can use n = (m+4-mod(m+4,5))/5 which, while also admittedly clumsy, will be evaluated at compile-time if m is a parameter. Hope this helps. Best regards Thomas
Re: Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
On 29.07.21 13:26, Iain Sandoe wrote: … perhaps someone here can see what the issue might be? Lawrence Doctors wrote: (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. I note that the Fortran standard requires that the actual argument must be an array (including array element see also "Storage Sequence") if the dummy argument is an (assumed-/explicit-size) array. Namely, Fortran Fortran 2018 requires in "15.5.2.4 Ordinary dummy variables": "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless • the actual argument is default character, of type character with the C character kind (18.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array, • the dummy argument has assumed-rank, or • the dummy argument is an assumed-type assumed-size array." And "15.5.2.11 Sequence association" "Sequence association only applies when the dummy argument is an explicit-shape or assumed-size array. [...] An actual argument represents an element sequence if it is an array expression, an array element designator, a default character scalar, or a scalar of type character with the C character kind" [...] "An actual argument that represents an element sequence and corresponds to a dummy argument that is an arrayis sequence associated with the dummy argument. The rank and shape of the actual argument need not agreewith the rank and shape of the dummy argument, but the number of elements in the dummy argument shallnot exceed the number of elements in the element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element sequence." (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] 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 am confused. Can you give an example? I do get a warning (or with -Werror an error) for: implicit none integer :: n integer,parameter :: m = 7 n= (m + 4)/5 end But not for 6 (→ 6+4 = 10). That seems to be fine. Or did I miss something? (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] This kinds of makes sense, but not for the main program. All variable in the main program have implicitly the SAVE attribute and by construction, the main program cannot be called neither recursively nor concurrently. Thus: That's a (known) bug. You can use an explicit "save :: a" to silence this warning – in newer than May 17, 2021 versions of GCC - or wait for the proper fix. See the existing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 In both cases, I note that you do not have to use -Werror; try -Wno-error=surprising and -Wno-error=integer-division to downgrade those two error categories back to warnings. Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
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 > 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" > Cc: Lawrence Doctors > > 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 >
