Re: [PATCH, Fortran] Optionally suppress no-automatic overwrites recursive warning - for approval

[Jeff Law <law at redhat dot com>]

On 10/25/19 7:54 AM, Tobias Burnus wrote:
> Hi Jeff,
> 
> On 10/25/19 3:22 PM, Jeff Law wrote:
>> So across Fedora the BOZ stuff tripped 2-3 packages. In comparison the
>> function argument stuff broke 30-40 packages, many of which still
>> don't build without -fallow-argument-mismatch.
> 
> Regarding the latter:
> The initial patch was too strict – an also rejected valid code
> (according to the Fortran 2018 standard).
That was my understanding from loosely following the threads.


 That has been fixed.* – Thus,
> either some valid cases were missed (gfortran bug) or all those packages
> indeed have an argument mismatch.
> 
> *That fix is: 2019-10-14 / r276972 / PR fortran/92004 /
> https://gcc.gnu.org/ml/fortran/2019-10/msg00128.html
Yea.  That patch certainly helped lapack and others.

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