Argument-mismatch fallout (was: Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval)
Tobias Burnus
tobias@codesourcery.com
Fri Oct 25 18:38:00 GMT 2019
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
>
More information about the Gcc-patches
mailing list