[Bug fortran/48858] New: Incorrect error for same binding label on two generic interface specifics

[Bug fortran/48858] New: Incorrect error for same binding label on two generic interface specifics

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

           Summary: Incorrect error for same binding label on two generic
                    interface specifics
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: longb@cray.com


For this example code:

> cat ck1.c
#include <stdio.h>
void Cfun ( int n, int *array){

  if ( array == NULL )
    printf ( "call %d passes NULL as arg 2 \n", n);
  else
    printf ( "call %d passes array address as arg 2 \n", n);
}

[The C part compiles fine.]

> cat ck.f90
module graph_partitions
  use,intrinsic :: iso_c_binding

  interface Cfun
     subroutine cfunc1 (num, array) bind(c, name="Cfun")
       import :: c_int
       integer(c_int),value :: num
       integer(c_int)       :: array(*)
     end subroutine cfunc1

     subroutine cfunf2 (num, array) bind(c, name="Cfun")
       import :: c_int, c_ptr
       integer(c_int),value :: num
       type(c_ptr),value    :: array
     end subroutine cfunf2
  end interface
end module graph_partitions

program test
  use graph_partitions
  integer(c_int) :: a(100)

  call Cfun (1, a)
  call Cfun (2, C_NULL_PTR)
end program test


I get

> gcc -c ck1.c
> gfortran ck.f90 ck1.o
ck.f90:11.22:

     subroutine cfunf2 (num, array) bind(c, name="Cfun")
                      1
ck.f90:5.22:

     subroutine cfunc1 (num, array) bind(c, name="Cfun")
                      2
Error: Binding label 'Cfun' in interface body at (1) collides with the global
entity 'Cfun' at (2)
ck.f90:20.22:

....

Same behavior for 4.5.2 and 4.6.0.

The same code compiles and executes fine with the Cray, Intel, and PGI
compilers.  The expected output is:

> ./a.out
call 1 passes array address as arg 2 
call 2 passes NULL as arg 2 
>

This code should compile.  There is only one "entity" with the binding lablel
"Cfun".  In the words in the standard, only one "entity of the program" with
this binding label.  The names cfunc2 and cfunc1 are both local identifiers.
(Sections 16.2 and 16.3).

This construction is specifically allowed in the standard to allow users to
call a C function with multiple interfaces, similar to what is illustrated
here.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #1 from Bill Long <longb at cray dot com> 2011-05-03 21:51:29 UTC ---
As an aside, the code in the Description is a "work-around" to avoid using the
TR 29113 feature that allows Optional arguments.  This would be the preferred
code in the future:

> cat cknew1.f90
module graph_partitions
  use,intrinsic :: iso_c_binding

  interface 
     subroutine Cfun (num, array) bind(c, name="Cfun")
       import :: c_int
       integer(c_int),value :: num
       integer(c_int),optional:: array(*)
     end subroutine Cfun
  end interface

end module graph_partitions

program test
  use graph_partitions
  integer(c_int) :: a(100)

  call Cfun (1, a)
  call Cfun (2)
end program test


The Intel and PGI compilers already support this (no compile errors, correct
output).  The Cray compiler also does if the NEW_FORTRAN environment variable
is set (which just disables the error about having an OPTIONAL dummy in a
BIND(C) interface).  

It is a separate issue from this BUG, but it might be a nice enhancement to
enable the TR feature of allowing OPTIONAL arguments in BIND(C) interfaces. It
appears that some other vendors have already jumped on that bandwagon.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-04 08:23:41 UTC ---
(In reply to comment #0)
> This code should compile.  There is only one "entity" with the binding lablel
> "Cfun".  In the words in the standard, only one "entity of the program" with
> this binding label.  The names cfunc2 and cfunc1 are both local identifiers.
> (Sections 16.2 and 16.3).
> 
> This construction is specifically allowed in the standard to allow users to
> call a C function with multiple interfaces, similar to what is illustrated
> here.

I think I have to re-read that standard; I once got the impression that it
wasn't allowed to have two different interfaces pointing to the same entity.


(In reply to comment #1)
[BIND(C) with OPTIONAL arguments]
> The Intel and PGI compilers already support this (no compile errors, correct
> output).

Having a correct output is probably not surprising as most Fortran compilers
already handle OPTIONAL internally by passing a NULL pointer. Thus, also for
gfortran it would only a few lines (allowing it unless -std=f95/f2003/f2008 is
specified - and rejecting with BIND(C) the combination of OPTIONAL with VALUE).
I was thinking of introducing an flag -std=f2008tr, which will allow F2008 with
the two TR, which are being drafted: TR 29113 and the coarray TR.

It's on my agenda (cf. PR 48820 and http://gcc.gnu.org/wiki/TR29113Status), but
as it is a post-F2008 item, I thought I wait for the PDTR or FDTR and
concentrate until then on, e.g., coarrays.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #3 from Bill Long <longb at cray dot com> 2011-05-04 22:40:31 UTC ---
On 5/4/11 3:28 AM, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

>
> (In reply to comment #1)
> [BIND(C) with OPTIONAL arguments]
>> The Intel and PGI compilers already support this (no compile errors, correct
>> output).
>
> Having a correct output is probably not surprising as most Fortran compilers
> already handle OPTIONAL internally by passing a NULL pointer. Thus, also for
> gfortran it would only a few lines (allowing it unless -std=f95/f2003/f2008 is
> specified - and rejecting with BIND(C) the combination of OPTIONAL with VALUE).
> I was thinking of introducing an flag -std=f2008tr, which will allow F2008 with
> the two TR, which are being drafted: TR 29113 and the coarray TR.
>

Seems like a reasonable approach.  PGI and Intel are nominally out of 
compliance since the current ban on BIND(C) and OPTIONAL is a 
constraint.  Tying to compiler options is a way to avoid that issue.

> It's on my agenda (cf. PR 48820 and http://gcc.gnu.org/wiki/TR29113Status), but
> as it is a post-F2008 item, I thought I wait for the PDTR or FDTR and
> concentrate until then on, e.g., coarrays.
>

Sounds like a good plan to me.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-06 18:12:29 UTC ---
Author: burnus
Date: Fri May  6 18:12:25 2011
New Revision: 173500

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173500
Log:
2011-05-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        PR fortran/48820
        * lang.opt (std=f2008tr): New.
        * libgfortran.h (GFC_STD_F2008_TR): New macro constant.
        * decl.c (verify_c_interop_param): Allow OPTIONAL in BIND(C)
        procedures for -std=f2008tr/gnu/legacy.

2011-05-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        PR fortran/48820
        * gfortran.dg/bind_c_usage_22.f90: New.
        * gfortran.dg/bind_c_usage_23.f90: New.
        * gfortran.dg/bind_c_usage_24.f90: New.
        * gfortran.dg/bind_c_usage_24_c.c: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/bind_c_usage_22.f90
    trunk/gcc/testsuite/gfortran.dg/bind_c_usage_23.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/lang.opt
    trunk/gcc/fortran/libgfortran.h
    trunk/gcc/fortran/options.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-06 18:33:36 UTC ---
Author: burnus
Date: Fri May  6 18:33:31 2011
New Revision: 173503

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173503
Log:
Really commit:

2011-05-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        PR fortran/48820
        * gfortran.dg/bind_c_usage_24.f90: New.
        * gfortran.dg/bind_c_usage_24_c.c: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/bind_c_usage_24.f90
    trunk/gcc/testsuite/gfortran.dg/bind_c_usage_24_c.c

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-22 14:17:45 UTC ---
The OPTIONAL problem is solved by allowing OPTIONAL with -std=gnu (default) and
-std=f2008tr.

Regarding the original problem: I think I have convince myself that having two
procedures with the same binding label (and a different) interface is valid
according to the standard.

One probably could check that the number of arguments is the same and warn
otherwise. (For variadic arguments, the number of arguments can vary, but
calling a variadic function from Fortran has some potential issues and is also
invalid. Passing too many arguments should work, but is with stdcall
problematic.)

The general diagnostic might be better hidden behind some -W arning flag.

* * *

For a similar report and patch, cf
http://gcc.gnu.org/ml/fortran/2011-05/msg00154.html

Regarding that patch: I think it disables the error if one item is a procedure
and one is a variable/derived type. (I have not checked, though.)

* * *

The current check is in any case too tight. The following is perfectly valid:
(Same interface, same binding label, but different procedure name.)

interface
  subroutine foo() bind(C, name="foo")
   end subroutine foo
end interface
end

subroutine test
interface
  subroutine bar() bind(C, name="foo")
   end subroutine bar
end interface
end subroutine test

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu.org

--- Comment #7 from Daniel Franke <dfranke at gcc dot gnu.org> 2011-07-24 19:18:48 UTC ---
Tobias, did comment #4/#5 implement #35161?

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-24 19:56:56 UTC ---
(In reply to comment #7)
> Tobias, did comment #4/#5 implement #35161?

No. The original issue of this PR and of PR 35161 is unfixed. (I think they are
duplicates.)

The only change (commit of comment #4) is: If one wants to pass NULL to denote
an absent argument, one can now use OPTIONAL with BIND(C), which is allowed
with TS 29113. Thus, there exists now a better solution for the main usage,
where the issue occurs. But it does not solve all issues.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-07 22:14:15 UTC ---
See also discussion starting at
  http://j3-fortran.org/pipermail/j3/2008-December/002123.html

Fortran 2003 has in "16.1 Scope of global identifiers"

"Program units, common blocks, external procedures, and entities with binding
labels are global entities of a program. The name of a program unit, common
block, or external procedure is a global identifier and shall not be the same
as the name of any other such global entity in the same program, except that an
intrinsic module may have the same name as another program unit, common block,
or external procedure in the same program. A binding label of an entity of the
program is a global identifier and shall not be the same as the binding label
of any other entity of the program; nor shall it be the same as the name of any
other global entity of the program that is not an intrinsic module, ignoring
differences in case. An entity of the program shall not be identified by more
than one binding label."

Fortran 2008 has in "16.2 Global identifiers" - the "{>>}"/"{<<}" was added by
me for emphasis.

"Program units, common blocks, external procedures, entities with binding
labels, external input/output units, pending data transfer operations, and
images are global entities of a program. The name of a common block with no
binding label, external procedure {>>}with no binding label{<<}, or program
unit that is not a submodule is a global identifier. The submodule identifier
of a submodule is a global identifier. A binding label of an entity of the
program is a global identifier. An entity of the program shall not be
identified by more than one binding label.

The global identifier of an entity shall not be the same as the global
identifier of any other entity. Furthermore, a binding label shall not be the
same as the global identifier of any other global entity, ignoring differences
in case."


See also: http://www.j3-fortran.org/doc/year/08/08-295.txt ; we might need to
handle also "COMMON /foo/" where "foo" is also no global identifier any more.
(I don't know whether one needs to handle it somewhere.)

Cf. also
http://j3-fortran.org/doc/year/08/08-196.txt
http://j3-fortran.org/doc/year/08/08-187.txt
F03/0076 at http://j3-fortran.org/doc/year/08/08-006Ar4.txt

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-07 22:15:51 UTC ---
*** Bug 35161 has been marked as a duplicate of this bug. ***

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, wrong-code

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-07 22:30:44 UTC ---
(In reply to comment #9)
> we might need to handle also COMMON /foo/

Example for a now (F2008) valid programs:

a) Currently rejected - but shouldn't since F2008

use iso_c_binding
contains
subroutine one()
  bind(C, name="com1") :: /foo/
  integer(c_int) :: a
  common /foo/ a
end subroutine
subroutine two()
  bind(C, name="com2") :: /foo/
  integer(c_long) :: a
  common /foo/ a
end subroutine two
end

b) For the following program no error is printed - but one gets:
  Warnung: Named COMMON block 'foo' at (1) shall be
           of the same size as elsewhere (4 vs 8 bytes)
which is surprising as one should generate one common block with assembler name
"foo_" and one with assembler name "com1".

Currently only one is generated (which has either the name "com1" or "foo_"):

use iso_c_binding
contains
subroutine one()
  bind(C, name="com1") :: /foo/
  integer(c_int) :: a
  common /foo/ a
end subroutine
subroutine two()
  integer(c_long) :: a
  common /foo/ a
end subroutine two
end

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-25 15:37:35 UTC ---
For a (vaguely) related issue, see PR 53478.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[juno.krahn at nih dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

Juno Krahn <juno.krahn at nih dot gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juno.krahn at nih dot gov

--- Comment #13 from Juno Krahn <juno.krahn at nih dot gov> 2012-11-13 18:14:43 UTC ---
I just came across this issue, using code that used to compile under gfortran.

The standards reference in the previous comment is in reference to program
units, which includes binding labels. It asserts that global identifiers are
unique entities, but interface definitions are not program units. Multiple
interfaces can refer to the same unique. I don't have a reference, but I
remember this specific issue being discussed at one point with the Fortran
Standards committee, and the consensus was that multiple interfaces to a single
BIND(C) name is both valid and useful.

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Mon May 20 20:03:48 2013
New Revision: 199118

URL: http://gcc.gnu.org/viewcvs?rev=199118&root=gcc&view=rev
Log:
2013-05-20  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        * decl.c (gfc_match_bind_c_stmt): Add gfc_notify_std.
        * match.c (gfc_match_common): Don't add commons to gsym.
        * resolve.c (resolve_common_blocks): Add to gsym and
        add checks.
        (resolve_bind_c_comms): Remove.
        (resolve_types): Remove call to the latter.
        * trans-common.c (gfc_common_ns): Remove static var.
        (gfc_map_of_all_commons): Add static var.
        (build_common_decl): Correctly handle binding label.

2013-05-20  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        * gfortran.dg/test_common_binding_labels.f03: Update dg-error.
        * gfortran.dg/test_common_binding_labels_2_main.f03: Ditto.
        * gfortran.dg/test_common_binding_labels_3_main.f03: Ditto.
        * gfortran.dg/common_18.f90: New.
        * gfortran.dg/common_19.f90: New.
        * gfortran.dg/common_20.f90: New.
        * gfortran.dg/common_21.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/common_18.f90
    trunk/gcc/testsuite/gfortran.dg/common_19.f90
    trunk/gcc/testsuite/gfortran.dg/common_20.f90
    trunk/gcc/testsuite/gfortran.dg/common_21.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-common.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels.f03
    trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels_2_main.f03
    trunk/gcc/testsuite/gfortran.dg/test_common_binding_labels_3_main.f03

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Mon May 20 20:08:05 2013
New Revision: 199120

URL: http://gcc.gnu.org/viewcvs?rev=199120&root=gcc&view=rev
Log:
2013-05-20  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        PR fortran/55465
        * decl.c (add_global_entry): Add sym_name.
        * parse.c (add_global_procedure): Ditto.
        * resolve.c (resolve_bind_c_derived_types): Handle multiple decl for
        a procedure.
        (resolve_global_procedure): Handle gsym->ns pointing to a module.
        * trans-decl.c (gfc_get_extern_function_decl): Ditto.

2013-05-20  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48858
        PR fortran/55465
        * gfortran.dg/binding_label_tests_10_main.f03: Update dg-error.
        * gfortran.dg/binding_label_tests_11_main.f03: Ditto.
        * gfortran.dg/binding_label_tests_13_main.f03: Ditto.
        * gfortran.dg/binding_label_tests_3.f03: Ditto.
        * gfortran.dg/binding_label_tests_4.f03: Ditto.
        * gfortran.dg/binding_label_tests_5.f03: Ditto.
        * gfortran.dg/binding_label_tests_6.f03: Ditto.
        * gfortran.dg/binding_label_tests_7.f03: Ditto.
        * gfortran.dg/binding_label_tests_8.f03: Ditto.
        * gfortran.dg/c_loc_tests_12.f03: Fix test case.
        * gfortran.dg/binding_label_tests_24.f90: New.
        * gfortran.dg/binding_label_tests_25.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_24.f90
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_25.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_13_main.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_3.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_4.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_5.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_6.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_7.f03
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_8.f03
    trunk/gcc/testsuite/gfortran.dg/c_loc_tests_12.f03

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
All issues of this PR should be now FIXED (on the 4.9 trunk).

The commit in comment 14 ensures that for COMMON, the binding label is all what
matters.
The commit in comment 15 ensures the same for procedures.
And the commit in comment 16 permits multiple INTERFACE declarations -
especially if they are the same! - for the same binding label.

Thanks for the report and the patience. (I am still not sure whether the code
in comment 0 is valid or not, but the commit of comment 16 permits it.)

[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858

--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Actually, a future gfortran patch might again disable the support for the code
in comment 0 (original bug report) by doing interface checks.

That's not only in line with my interpretation of the standard but also with
Malcolm Cohen's at
http://mailman.j3-fortran.org/pipermail/j3/2013-May/006399.html

That will be tracked at PR 55465.


(The commits in this PR are still all useful: They allowed optional with
bind(C), handle common/procedure names as local identifier if they have a C
binding and permit multiple INTERFACE declarations for the same procedure
(identical or not). The only thing which might change is the latter - by
requiring the characteristics are the same.)