From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9DF85385842D; Mon, 13 Sep 2021 05:18:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9DF85385842D From: "rimvydas.jas at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings Date: Mon, 13 Sep 2021 05:18:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rimvydas.jas at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 05:18:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102145 --- Comment #11 from Rimvydas (RJ) --- (In reply to Steve Kargl from comment #10) > Yes, I know -std=3Dlegacy implies -fallow-argument-mismatch. The=20 > option degrades an ERROR to a WARNING. That is all it does. > With -std=3Dlegacy, gfortran is acknowledging that a user is > throwing potential garbage at it. [snip] > If -pedantic or -pedantic-error=20 > turns the warning back into an error, so what? The user can > remove the idiotic option. Telling gfortran you want -std=3Dlegacy > and -pedantic is an oxymoron. Nobody would complain if compiler acted consistently and error would happen only with -pedantic-errors. See gcc/testsuite/gfortran.dg/hollerith8.f90 h= ow it is affected by -std=3Dlegacy vs -std=3Dlegacy -pedantic vs -std=3Df2008, specifically the part: call wrtout (9hHELLO YOU, 9) Warning: Legacy Extension: Hollerith constant at (1) Users would be satisfied with: Warning: Legacy extension: Invalid argument mismatch at (1). It not so hard to acknowledge that consistency was broken and it is still easily fixable. There is nothing oxy about -pedantic not giving hard error when there is -pedantic-errors for this. > The Fortran standard for more that 55 years has said argument=20 > mismatch is invalid Fortran. In the old days, Fortran processors > lacked the ability to diagnose the problem. gfortran can, under > some circumstance, diagnose the issue and should tell the user > via an error message that the Fortran code is invalid. Still there is no good reason to break older codebases that were accepted 3 years ago with -std=3Dlegacy or -std=3Dgnu -fallow-argument-mismatch if -st= d=3Df2008 strictly rejects them. > I'll also point out that you stated some projects have started to > remove -pedantic because -fallow-argument-mismatch is throwing > an error. Why are these projects using -pedantic if the projects > are not actively fixing the reported warnings. It seems the=20 > issue with -fallow-argument-mismatch is doing what it ought to > do. That is, encourage user to FIX THEIR INVALID FORTRAN CODE. Previously -pedantic was used in makefile recipes to check (usually in a separate compilation) for new warnings differences between compiler releases about new legacy or deleted features, because it is easier way than diff standard texts or code changes in compiler frontend. Sadly these recipes a= re being removed now. As for fixing part, consider: program test stop 1 contains subroutine todo1 call mpi_send(1) end subroutine subroutine todo2 call mpi_send(1.) end subroutine end program Hard diagnostic is now issued even for unreachable code parts and this forc= es users to simply move out code parts giving hard errors to separate fortran sources by use of wrappers without interfaces (often with real bugs when co= de changes getting merged from different development branches). Not only this forces anyone debugging such changes to rely on LTO alone, but encourages avoiding use of -Werror or -Werror=3Dfoo to prevent issues in future compil= er releases because compiler has growing inconsistency reputation. > I don't care what other Fortran vendors do. Other Fortran vendors > have a monetary reason to bend to the purses of users. MPI issue is not what other Fortran vendors are doing. The given MPI implementation (possibly MPI vendor optimized or debugging one) needs to provide mpi.mod or mpi_f08.mod modules for every gfortran major version jus= t to import information about MPI interfaces. This is why f77 mpif.h (usually without explicit interfaces or use of "!gcc$ attributes no_arg_check :: arg= ") include way is still preferred. As for last bit, it is quite surprising and really unnecessary in modern times. If you need to know, then all depends = on the given friend and how consistent he/she is. :)=