On Tue, 2020-01-21 at 20:41 +0000, devel- request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > ------------------------------ > > Date: Tue, 21 Jan 2020 21:27:47 +0100 > From: Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> > Subject: Re: gcc-10 Fortran argument mismatch issue > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <20200121202747.GA5362@xxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=utf-8 > > Hi, Jeff. > > On Tuesday, 21 January 2020 at 21:16, Jeff Law wrote: > > > > So this is another issue that's going to be seen with gcc-10. I'd been > > hoping to get the time to fix packages correctly, but I think it's > > ultimately going to have to fall to the package maintainers. > > > > gcc has traditionally allowed certain type mismatches for arguments in > > Fortran code. GCC would issue a diagnostic under -Wargument-mismatch > > for these cases, but the issue was not considered fatal. > > > > Starting with gcc-10, these are now fatal errors which look something > > like this: > > > > > > > > Error: Rank mismatch in argument ‘array’ at (1) (rank-1 and scalar) > > Could you give some example(s) how to fix such errors? Is there an entry > for this in the gcc-10 porting guide? > > > While gcc-10 has an option to disable this diagnostic, the potential > > for codegen issues in this space was significant enough that I didn't > > think an opt-out or advertising magic flag workaround was advisable. > > > > A partial list of the affected packages (generated back in October from > > a partial run of my tester): > > Are there any build logs with errors available? Not easily for a variety of reasons. We're working on that, but I doubt it'll be ready during the F32 cycle. But I can give you specific examples pretty easily. wannier90 is probably the best because there's a single instance and we know it's already fixed in newer versions of wannier90. > gfortran -O2 -flto -ffat-lto-objects -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -c ../postw90/comms.F90 > f951: Warning: '-Werror=' argument '-Werror=format-security' is not valid for Fortran > ../postw90/comms.F90:893:29: > > 893 | call my_icopy(localcount,rootglobalarray,1,array,1) > | 1 > Error: Rank mismatch in argument 'zx' at (1) (rank-1 and scalar) What GCC is complaining about is argument types at the call site do not match the arguments at the function definition. In this case, at the call site "rootglobalarray" is a simple integer: > integer, intent(inout) :: rootglobalarray Yet if we look at the definition of my_icopy, the corresponding parameter (ZX) is an array. subroutine my_ICOPY(N,ZX,INCX,ZY,INCY) > ! .. Scalar Arguments .. > integer INCX,INCY,N > ! .. > ! .. Array Arguments .. > integer ZX(*),ZY(*) Thus the types at the call site do not match the types at the definition site and gcc complains. Now if we look at wanner-3.0 from upstream we see the how this was fixed. > integer, dimension(:), intent(inout) :: rootglobalarray > The type at the call site was changed to have an array type. Note the same fix was applied for the "array" argument at the call site (boy was that horribly named!) Note that I'm _not_ a Fortran guy, it's well out of my area of expertise. So while I could help here, particularly for trivial cases like this, it's probably better for package owners to step in and own fixing the Fortran packages. The set of packages I know are affected by these kinds of issues based on last week's builds: arpack cgnslib cp2k dl_poly elk elpa exciting ga getdata grib_api hdf libccp4 mpich MUMPS ncl netcdf-fortran psblas3 qrmumps qrupdate quantum-espresso R R-deldir scalapack scipy scorep wannier90 wsjtx xfoil xrotor Jeff _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
