[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings

["rimvydas.jas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145

--- Comment #11 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to Steve Kargl from comment #10)
> Yes, I know -std=legacy implies -fallow-argument-mismatch.  The 
> option degrades an ERROR to a WARNING.  That is all it does.
> With -std=legacy, gfortran is acknowledging that a user is
> throwing potential garbage at it.  [snip]
> If -pedantic or -pedantic-error 
> turns the warning back into an error, so what?  The user can
> remove the idiotic option.  Telling gfortran you want -std=legacy
> 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 how
it is affected by -std=legacy vs -std=legacy -pedantic vs -std=f2008,
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 
> 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=legacy or -std=gnu -fallow-argument-mismatch if -std=f2008
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 
> 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 are
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 forces
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 code
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=foo to prevent issues in future compiler
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 just 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. :)