Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

[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= 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.Doctors@UNSW.edu.au
Telephone: +61-2-9371 4158

Re: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

[Jonathan Wakely]

On Thu, 29 Jul 2021, 11:59 Lawrence Doctors, <l.doctors@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.Doctors@UNSW.edu.au
> Telephone: +61-2-9371 4158
>
>