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= 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]
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
