Hi Jeff, hi Thomas, hi all,
I had a look at Wannier90. (Fedora uses Version 2.0.0 of 2013, 2.0.1 was
released 2015; current is 3.0 of Feb 2019 and does build.) I think that
problem in Wannier90 it typical for all failing code, although there are
likely a few other failures. Namely,
That code uses something like:
subroutine sub(array, n)
integer array(*)
integer N
end subroutine
with the call:
integer :: scalar
call sub(scalar, 1)
That fails with:
Error: Rank mismatch in argument ‘array’ at (1) (rank-1 and scalar)
That's a scalar actual argument is passed to an array dummy argument.
Technically, the error is correct and the code invalid:
F2018, 15.5.2.4, paragraph 14 has:
"If the actual argument is a … scalar, the corresponding dummy
argument shall be scalar unless … the actual argument …
is an element … of an array."
Fortran 66, https://wg5-fortran.org/ARCHIVE/Fortran66.pdf , [8.4.2, ll. 33-35]
"If a dummy argument of an external function is an array name,
the corresponding actual argument must be an array name
or array element name (10.1.3)"
Fortran IV, p. 104,
http://web.eah-jena.de/~kleine/history/languages/GC28-6515-10-FORTRAN-IV-Language.pdf
"If a dummy argument is an array, the corresponding actual argument
must be (1) an array, or (2) an array element."
[Fortran IV only permitted literal constants in
'dimension(123)' and 'dimension(N)' for dummy arguments,
i.e. the size is variable and provided by the callee.
[Number of ranks not specified, the linked specification
supports rank-7 arrays.]
Fortran 66 seems to be likewise, and specifies only rank-4 arrays.
Fortran 77 has finally assumed-size arrays (which seem to be
backwards, 'dimension(N)' I regard as better than 'dimension(*)'),
supports other lower bounds than 1, has rank-7 arrays and a few
additional array extensions to 66.]
Current result:
* Error with -std=gnu (the default) or -std=f95/f2003/f…
* Downgraded to a warning with either -std=legacy or -fallow-argument-mismatch
However, passing a scalar instead of an array/array
element worked/works with (nearly?) all compilers. Hence, passing
a scalar is seemingly common pattern. Thus, I wonder whether we
should do something about this.
Ideas/possibilities:
* Use warning instead of an error with -std=gnu (and only error
for std=f…)
* Keep the error for most mismatches but downgrade to a warning
if -std=gnu for (only) the scalar-to-array case.
(a) do this always or (b) only for assumes-size dummy args.
* (a) Keep the status quo and require -std=legacy/
-fallow-argument-mismatch to get it compiled.
(b) modify the error message such that the user knows about
the arg-mismatch flag?
* Do something else?
Ideas? Comments? Opinions?
Cheers,
Tobias
On 10/25/19 4:48 PM, Jeff Law wrote:
[…]the function argument stuff broke 30-40 packages, many of which still
don't build without -fallow-argument-mismatch.
Do you know whether those 30–40 packages have code bugs or could there
be gfortran bugs (too strict checking) lurking?
I'm not familiar enough with the issue & packages to know if they're
cases of source bugs or gfortran being too strict.
My plan has always been to extract a few cases and pass them along for
that kind of analysis. I've just been too busy lately with other
regressions :(
A partial list of the affected packages:
R-deldir
R
atlas
cgnslib
cp2k
elk
elpa
exciting
ga
getdata
grib_api
hdf
libccp4
mpich
hwchem
psblas3
qrmumps
qrupdate
quantum-espresso
scalapack
scipy
scorep
wannier90
wsjtx
xfoil
xrotor
There's certainly more, that list just represents those I've locally
worked around with -fallow-argument-mismatch. Several more trigger the
mismatch error, but I haven't bothered working around yet.
That list comes from _after_ the Oct 14 patch to correct issues in the
argument mismatch testing.
Regarding the BOZ: One difference to the argument mismatch is that the
latter has an option to still accept it (-fallow-argument-mismatch) and
potentially generates wrong code – depending what the ME does with the
mismatches – while the former, once parsed, causes no potential ME
problems and as there is no flag, it always requires code changes. (On
the other hand, fixing the BOZ issue is straight forward; argument
changes are trickier.)
Absolutely. That's the primary reason why I haven't contacted the
affected package maintainers yet -- I don't want them blindly adding
-fallow-argument-mismatch to their flags.
Jeff
