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

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

[ripero84 at gmail dot com]

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

            Bug ID: 102145
           Summary: TKR mismatches with -pedantic:
                    -fallow-argument-mismatch does not degrade errors to
                    warnings
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ripero84 at gmail dot com
  Target Milestone: ---

In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the
mismatch errors to warnings:

$ cat pedt.f90 
MODULE M
  IMPLICIT NONE
  EXTERNAL :: X
CONTAINS

  SUBROUTINE S(A)
    COMPLEX :: A(*)
    CALL X(A)
  END

  SUBROUTINE T(A)
    REAL :: A(*)
    CALL X(A)
  END

END
$ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch # Expected warning
pedt.f90:8:11:

    8 |     CALL X(A)
      |           1
......
   13 |     CALL X(A)
      |           2
Warning: Type mismatch between actual argument at (1) and actual argument at
(2) (COMPLEX(4)/REAL(4)).
$ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch -pedantic #
Unexpected error
pedt.f90:8:11:

    8 |     CALL X(A)
      |           1
......
   13 |     CALL X(A)
      |           2
Error: Type mismatch between actual argument at (1) and actual argument at (2)
(COMPLEX(4)/REAL(4)).

This is:
- undocumented; and
- unexpected, since it effectively means that by adding -pedantic to a
compilation line that already contains -fallow-argument-mismatch, mismatch
warnings are upgraded to errors, despite -pedantic is only supposed to issue
warnings.

It seems that GCC developers have known for years that -pedantic may change
warnings to errors in the absence of error-raising flags
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929#c9), but it is still
unclear to me whether this is undocumented or wrong behaviour.

Note that there is evidence that -fallow-argument-mismatch is actually being
processed: if the compiler finds multiple mismatches involving a given
argument, it succeeds in only reporting one of them (as an error, not as the
expected warning).

I am seeking clarification about whether this is a bug (the combination of
-pedantic -fallow-argument-mismatch flags should work differently / be
forbidden), a documentation bug (in which case I would appreciate an
explanation of the logic behind this, and an update to the documentation), or
both, and I would be grateful for the fix(/es).

I am aware that -fallow-argument-mismatch is a hack that should be avoided, but
since users still need it, its behaviour and documentation should be at least
consistent.  Note that this issue has already been reported by some Fortran
codes: https://github.com/cp2k/cp2k/issues/1019,
https://gitlab.com/siesta-project/siesta/-/issues/130 .

This seems to affect all versions of gfortran since GCC 10.  It would be nice
if any updates related to this were ported to the 10.x branch.

Thank you for your help.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
                 CC|                            |kargl at gcc dot gnu.org
           Priority|P3                          |P5

--- Comment #1 from kargl at gcc dot gnu.org ---
Bummer.

I do note that the gcc.info description describes -pedantic
in terms of only ISO C/C++, but let's assume -pedantic 
should apply to ISO Fortran as well.  From the gcc manual

-Wpedantic'
'-pedantic'
     Issue all the warnings demanded by strict ISO C and ISO C++; reject
     all programs that use forbidden extensions, ...

>From Fortran 2018, 4.2 Conformance

   A processor conforms to this document if:
   ...
   (10) it contains the capability to detect and report the reason for
   rejecting a submitted program.

Perhaps, gfortran is enforcing the "reject all programs that use
forbidden extensions," portion.

Improvements to the gfortran documentation are encouraged and
welcomed from  all users of gfortran that find it lacking.

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

[ripero84 at gmail dot com]

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

--- Comment #2 from ripero84 at gmail dot com ---
1) The gfortran manual has its own entries for -pedantic and -pedantic-errors:

-Wpedantic
-pedantic
     Issue warnings for uses of extensions to Fortran.  -pedantic also
     applies to C-language constructs where they occur in GNU Fortran
     source files, such as use of \e in a character constant within a
     directive like "#include".

     Valid Fortran programs should compile properly with or without
     this option.  However, without this option, certain GNU extensions
     and traditional Fortran features are supported as well.  With this
     option, many of them are rejected.

     Some users try to use -pedantic to check programs for conformance.
     They soon find that it does not do quite what they want---it finds
     some nonstandard practices, but not all.  However, improvements to
     GNU Fortran in this area are welcome.

     This should be used in conjunction with -std=f95, -std=f2003,
     -std=f2008 or -std=f2018.

-pedantic-errors
     Like -pedantic, except that errors are produced rather than
     warnings.

The first lines of each description are quite clear about -pedantic issuing
warnings and -pedantic-errors issuing errors instead of warnings, in what
sounds like a very reasonable strategy.  But then the second paragraph of
-pedantic says that many (unspecified) non-standard features will be rejected.

2) This answers part of my issue: the behaviour is indeed documented, just in a
way that has proved confusing to me.  It think that a more accurate description
would start with: 

-pedantic: Issue warnings for some uses of extensions to Fortran, raise
otherwise warnings to errors for others.  Not all extensions will raise
warnings or errors.

which sounds bad.

3) If this is the intended behaviour I can propose some tweaks to the
documentation, but as I said first I would like to have a confirmation (ideally
by the person who set up the interaction between -pedantic and
-fallow-argument-mismatch) that this is really intended behaviour, not
accidental.

4) Apologies for not going into the C discussion, my C is limited, and to start
with I don't understand the "warnings demanded by strict ISO C" statement:
ISO/IEC 9899:2017, Annex I (informative) "Common warnings" says that "An
implementation may generate warnings in many situations, none of which are
specified as part of this International Standard", so I don't really know what
the "demanded warnings" are.

Thank you for your help.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Sep 08, 2021 at 02:14:26PM +0000, ripero84 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
> 
> --- Comment #2 from ripero84 at gmail dot com ---
> 1) The gfortran manual has its own entries for -pedantic and -pedantic-errors:
> 

Seems I owe you an apology.  I failed to check the gfortran
manual as I assumed these options where inherited from gcc
general option pool, and thus, documented in the gcc manual.

(option descriptions removed)

> 2) This answers part of my issue: the behaviour is indeed
>    documented, just in a way that has proved confusing to me.

Well, there are lots of things that gfortran does that I
find confusing, and I've contributed to some of it. ;)

>  It think that a more accurate description
> would start with: 
> 
> -pedantic: Issue warnings for some uses of extensions to Fortran, raise
> otherwise warnings to errors for others.  Not all extensions will raise
> warnings or errors.
> 
> which sounds bad.

Yes, it sounds bad, but at least reflects reality.  -pedantic
is not really pedantic.

> 3) If this is the intended behaviour I can propose some tweaks
> to the documentation, but as I said first I would like to have
> a confirmation (ideally by the person who set up the interaction
> between -pedantic and -fallow-argument-mismatch) that this is
> really intended behaviour, not accidental.

You would need to ping Thomas about the intended behavior.

> 
> 4) Apologies for not going into the C discussion, my C is limited,
>

No apology needed given gfortran's manual documents (badly?)
these options.  Given the lack of volunteers to maintain 
gfortran at the moment, the best path forward may be an
attempt to clarify the option descriptions.

After years of contributing to gfortran, I have come to the
conclusion that all extensions should require options to
permit them.  -std=gnu would activate the options; while, 
any other -std=... would de-active all of the extensions
and issue errors.  But, that ship has sailed.

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

[rimvydas.jas at gmail dot com]

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

Rimvydas (RJ) <rimvydas.jas at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rimvydas.jas at gmail dot com

--- Comment #4 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to ripero84 from comment #0)
> In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the
> mismatch errors to warnings:
> 
> This is:
> - undocumented; and
> - unexpected, since it effectively means that by adding -pedantic to a
> compilation line that already contains -fallow-argument-mismatch, mismatch
> warnings are upgraded to errors, despite -pedantic is only supposed to issue
> warnings.

This made many projects just simply remove -pedantic[-errors] and -Werror[=foo]
from building recipes for newer gfortran versions until behavior changes.  Any
software that includes hdf.inc, netcdf.inc and especially mpif.h is simply not
suitable for checking if actually deprecated and/or deleted features are being
used in the user when code compilation aborts on first file with argument
mismatch even for -std=legacy -pedantic.  Without going into unrelated and even
mildly disheartening long paragraphs without useful information, most of this
started with removal of -Wargument-mismatch option.
While it is understandable why it was done like this from compiler developer
perspective, it is a major breakage for what user expects or expected
previously from the compiler.  The -std=legacy already implies
-fallow-argument-mismatch, so why even warn about mismatches by default?  Same
for -std=gnu -fallow-argument-mismatch, user already supplied option to
specifically enable the extension, because code needs it.  It used to be that
-pedantic (or -Wpedantic) was safe to use to check if some unintended deleted
language features are present in the codebase.  Now with -pedantic acting like
-pedantic-errors and without any support to -Wno-0 or -Wno-error=0 (yes,
anything opt==0 "enabled by default") it is very complicated.

If you have checking scripts or tools that rely on previous behavior and you
are willing to compile separate gfortran version, you could use my old WIP that
almost work as expected or at least provide a way to -Wno-error=pedantic on
these.  Helped me a lot until we phased out those tools.

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

[rimvydas.jas at gmail dot com]

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

--- Comment #5 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51441&action=edit
old WIP for arg mismatch

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

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #4)
> (In reply to ripero84 from comment #0)
> > In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the
> > mismatch errors to warnings:
> > 
> > This is:
> > - undocumented; and
> > - unexpected, since it effectively means that by adding -pedantic to a
> > compilation line that already contains -fallow-argument-mismatch, mismatch
> > warnings are upgraded to errors, despite -pedantic is only supposed to issue
> > warnings.
> 
> This made many projects just simply remove -pedantic[-errors] and
> -Werror[=foo] from building recipes for newer gfortran versions until
> behavior changes.

Good for those projects.  The correct response would have been
to fix the source, which has never conformed to any Fortran
standard (starting with Fortran 66).


> Any software that includes hdf.inc, netcdf.inc and
> especially mpif.h is simply not suitable for checking if actually deprecated
> and/or deleted features are being used in the user when code compilation
> aborts on first file with argument mismatch even for -std=legacy -pedantic.

Well, that's what it should do!  Argument mismatch has never
been permitted by any Fortran standard.  So, PEDANTICALLY
speaking it is an error to allow.  The correct solution is
to fix the source code.

> Without going into unrelated and even mildly disheartening long paragraphs
> without useful information, most of this started with removal of
> -Wargument-mismatch option.

No, it started when gfortran grew the ability to diagnosis the
the problem.  It is an error.  gfortran is telling the user
it is an error.  

> While it is understandable why it was done like this from compiler developer
> perspective, it is a major breakage for what user expects or expected
> previously from the compiler.

No, it is not.  The -fallow-argument-match option was given to
user to allow them to compile their broken code.  It was decided
to degrade a error into a warning with this option.  If you then
use an option that wants to PEDANTIC with respect to the requirements
of the Fortran 66, 77, 90, 95, 2003, 2008, and 2018 standard, then
you're going to get an error.

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

[rimvydas.jas at gmail dot com]

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

--- Comment #7 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to kargl from comment #6)
> Well, that's what it should do!  Argument mismatch has never
> been permitted by any Fortran standard.  So, PEDANTICALLY
> speaking it is an error to allow.
Pedantically it an error to support *any* extension then.

> > Without going into unrelated and even mildly disheartening long paragraphs
> > without useful information, most of this started with removal of
> > -Wargument-mismatch option.
> 
> No, it started when gfortran grew the ability to diagnosis the
> the problem.  It is an error.  gfortran is telling the user
> it is an error.  
Gfortran was able to diagnose most of these before under -Wargument-mismatch.

> No, it is not.  The -fallow-argument-match option was given to
> user to allow them to compile their broken code.  It was decided
> to degrade a error into a warning with this option.  If you then
> use an option that wants to PEDANTIC with respect to the requirements
> of the Fortran 66, 77, 90, 95, 2003, 2008, and 2018 standard, then
> you're going to get an error.
Nobody said -fallow-argument-mismatch should work under say -std=f2008 (and it
is OK if it doesn't).  Users complain about -std=legacy or -std=gnu behavior
and -pedantic acting like -pedantic-errors when it shouldn't.  All this done
was force users to make haste changes to keep code compiling while disturbing
sometimes carefully crafted codes or simply splitting units into separate
fortran souces so that compiler "does not see" this information.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Sep 12, 2021 at 07:34:17PM +0000, rimvydas.jas at gmail dot com wrote:
> 
> > No, it is not.  The -fallow-argument-match option was given to
> > user to allow them to compile their broken code.  It was decided
> > to degrade a error into a warning with this option.  If you then
> > use an option that wants to PEDANTIC with respect to the requirements
> > of the Fortran 66, 77, 90, 95, 2003, 2008, and 2018 standard, then
> > you're going to get an error.
> Nobody said -fallow-argument-mismatch should work under say -std=f2008 (and it
> is OK if it doesn't).  Users complain about -std=legacy or -std=gnu behavior
> and -pedantic acting like -pedantic-errors when it shouldn't.  All this done
> was force users to make haste changes to keep code compiling while disturbing
> sometimes carefully crafted codes or simply splitting units into separate
> fortran souces so that compiler "does not see" this information.
> 

Yes, it should behave like -pedantic-errors.  Why not ask the
people involved in deciding on -fallow-argument-mismatch behavior.
An argument mismatch was never permitted under any Fortran standard.
It was decided that gfortran would now issue an error if it detected
a mismatch.  -fallow-argument-mismatch was added to allow users,
who refuse to fix their code, the ability to downgrade the error
to a warning.  If -pedantic changes -fallow-argument-mismatch
back to an error, then don't use -pedantic.

And, no, the code was not "carefully crafted".  Code, which exploits
argument mismatch, has always been invalid Fortran.  It is time that
those codes are fixed.

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

[rimvydas.jas at gmail dot com]

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

--- Comment #9 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to Steve Kargl from comment #8)
> Yes, it should behave like -pedantic-errors.
Actually no, -pedantic is equivalent to -Wpedantic, while -pedantic-errors is
-Werror=pedantic.  Rest is interpretation vs expectation.

> -fallow-argument-mismatch was added to allow users,
> who refuse to fix their code, the ability to downgrade the error
> to a warning.  If -pedantic changes -fallow-argument-mismatch
> back to an error, then don't use -pedantic.
The -std=legacy already implies -fallow-argument-mismatch and wrongfully warns
by default.  Consider gfortran -std=legacy -Wpedantic -Wno-error=pedantic -c.

> And, no, the code was not "carefully crafted".  Code, which exploits
> argument mismatch, has always been invalid Fortran.  It is time that
> those codes are fixed.
Until every compiler vendor agree on universal module format for things like
"USE MPI" or "USE MPI_F08", the HPC applications will continue to use F77
"mpif.h" include, unless "buffer" type would get standardized.  Many projects
already split things like:
 call mpi_foo(1, MPI_INTEGER, N); ..... ; call mpi_foo(1., MPI_REAL, N) into
separate compilable sources and in the end such compiler behavior change solved
nothing other than creating lots unnecessary work for users and package
maintainers for every different OS.  It will become more evident when more HPC
systems get replaced from older LTS having older versions of gfortran.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Sep 12, 2021 at 11:40:31PM +0000, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145
> > -fallow-argument-mismatch was added to allow users,
> > who refuse to fix their code, the ability to downgrade the error
> > to a warning.  If -pedantic changes -fallow-argument-mismatch
> > back to an error, then don't use -pedantic.
> The -std=legacy already implies -fallow-argument-mismatch and wrongfully warns
> by default.  Consider gfortran -std=legacy -Wpedantic -Wno-error=pedantic -c.
> 

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.  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.  Either you want gfortran to compile 
your garbage or you want gfortran to faithfully follow the
Fortran standard.

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. 

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.


> > And, no, the code was not "carefully crafted".  Code, which exploits
> > argument mismatch, has always been invalid Fortran.  It is time that
> > those codes are fixed.
> Until every compiler vendor agree on universal module format for things like
> "USE MPI" or "USE MPI_F08", the HPC applications will continue to use F77
> "mpif.h" include, unless "buffer" type would get standardized.

I don't care what other Fortran vendors do.  Other Fortran vendors
have a monetary reason to bend to the purses of users.  gfortran
does not have that burden (at least, I've never seen a dime for 
2 decades of contributions to gfortran).  gfortran is likely the
most used Fortran compiler on this planet; it does not need to 
lower its standards.  If your friend jumps off a bridge, should
you follow?

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

[rimvydas.jas at gmail dot com]

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. :)