[Bug fortran/55465] New: Name collision in C binding (calling C from Fortran)

[Bug fortran/55465] New: Name collision in C binding (calling C from Fortran)

[fmartinez at gmv dot com]

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

             Bug #: 55465
           Summary: Name collision in C binding (calling C from Fortran)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fmartinez@gmv.com


The following compile error is generated. Maybe not a bug but is passes through
the Intel compiler and I cannot see the reason why it would not compile.
Essentially I am trying to use the binding to call from Fortran the same C
function in two different ways. The interface sql_set_env_attr has two
implementations, one sql_set_env_attr_int where the parameter value is passed
as c_int and another one sql_set_env_attr_ptr where the parameter value is
passed as c_ptr.
In any case the message is somewhat misleading as it identifies the name of the
binding SQLSetEnvAttr as global body and as interface body.
Compilation diagnostics follow:


m_odbc_if.f90:168.4:

    function sql_set_env_attr_ptr( input_handle, &
    1
m_odbc_if.f90:153.4:

    function sql_set_env_attr_int( input_handle, &
    2
Error: Binding label 'SQLSetEnvAttr' in interface body at (1) collides with the
global entity 'SQLSetEnvAttr' at (2)
make: *** [/home/fmmf/pulsar/Linux/Debug/obj/m_odbc_if.o] Error 1

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[fmartinez at gmv dot com]

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

--- Comment #1 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-11-25 18:19:56 UTC ---
Created attachment 28773
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28773
Supporting file to compile the main source for the report

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[fmartinez at gmv dot com]

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

--- Comment #2 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-11-25 18:21:36 UTC ---
Created attachment 28774
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28774
The main file where the problem is encountered

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #3 from janus at gcc dot gnu.org 2012-11-26 16:37:31 UTC ---
(In reply to comment #0)
> Essentially I am trying to use the binding to call from Fortran the same C
> function in two different ways. The interface sql_set_env_attr has two
> implementations, one sql_set_env_attr_int where the parameter value is passed
> as c_int and another one sql_set_env_attr_ptr where the parameter value is
> passed as c_ptr.

I'm not sure if this is legal. In any case, here is a reduced test case:


module m_odbc_if

  implicit none

  interface sql_set_env_attr
    function sql_set_env_attr_int( input_handle,attribute,value,length ) &
                                   result(res) bind(C,name="SQLSetEnvAttr")
      use, intrinsic :: iso_c_binding
      implicit none
      type(c_ptr), value :: input_handle
      integer(c_int), value :: attribute
      integer(c_int), value :: value
      integer(c_int), value :: length      
      integer(c_short) :: res
    end function
    function sql_set_env_attr_ptr( input_handle,attribute,value,length ) &
                                   result(res) bind(C,name="SQLSetEnvAttr")
      use, intrinsic :: iso_c_binding
      implicit none
      type(c_ptr), value :: input_handle
      integer(c_int), value :: attribute
      type(c_ptr), value :: value
      integer(c_int), value :: length      
      integer(c_short) :: res
    end function
  end interface

end module

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2012-11-26 17:08:20 UTC ---
Note: The same behavior occurs with all gfortran versions I tried (4.3, 4.6,
4.7 and trunk).


The check which rejects it is in gfc_verify_binding_labels (resolve.c). It was
committed with the inital ISO_C_BINDING patch:

http://gcc.gnu.org/viewcvs?view=revision&revision=126185

This commit also includes a test case which is basically equivalent to the one
in comment 3 (i.e. two interfaces binding to the same label):

http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/binding_label_tests_3.f03?view=markup


So it seems that this error is indeed triggered on purpose and not by accident.
It may well be that ifort just fails to detect this error (ifort is not exactly
known for good diagnostics). Have you checked other compilers?

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[fmartinez at gmv dot com]

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

--- Comment #5 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-11-26 17:36:04 UTC ---
I have also tried with ekopath and g95 and both take it without a diagnostic.
I have been checking section 15.4 of the ISO standard and I have found nothing
that forbids that two fortran procedures have the same binding label. But this
is just my interpretation.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-11-26 17:40:49 UTC ---
(In reply to comment #3)
> I'm not sure if this is legal. In any case, here is a reduced test case:

The issue is in related to PR 48858; I think the code is valid on most 32bit
(e.g. x32-gnu-linux, i386-gnu-linux) systems. I also find the standard a bit
confusing, but I think it is supposed to be valid - cf. bug 48858 comment 9.


Regarding the specific issue:

      integer(c_int), value :: value
vs.
      type(c_ptr), value :: value

On a 64 bit system it is invalid as "int" ("integer(c_int),value") is a 32 bit
value and "void*" ("type(c_ptr),value") is a 64 bit pointer. If "value" is
supposed to be a pointer address, it should use "integer(c_intptr_t)". I think
that's the case as I find "SQLPOINTER ValuePtr" in the references to
SQLSetEnvAttr.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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

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

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

--- Comment #7 from Juno Krahn <juno.krahn at nih dot gov> 2012-11-26 19:51:55 UTC ---
IMHO, this is valid code regardless of whether the binary argument types can be
seen as equivalent. The standard is quite vague, but see my comment at bug
48858 comment 13. The standard defines that the binding label itself is a
unique global entity, but does not specify that the interface definition is
unique.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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

--- Comment #8 from Juno Krahn <juno.krahn at nih dot gov> 2012-11-26 19:55:11 UTC ---
Also, I should have mentioned that multiple interface specs used to work in Gnu
Fortran, and it still works in current Intel, Sun and Open64 Fortran compilers.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #9 from Harald Anlauf <anlauf at gmx dot de> 2012-11-26 20:20:24 UTC ---
(In reply to comment #7)
> IMHO, this is valid code regardless of whether the binary argument types can be
> seen as equivalent. The standard is quite vague, but see my comment at bug
> 48858 comment 13. The standard defines that the binding label itself is a
> unique global entity, but does not specify that the interface definition is
> unique.

Well, then somebody should also complain to NAG.
The code in comment #6 fails to compile.

% nagfor -c -f2003 pr55465.f90
NAG Fortran Compiler Release 5.3.1(907)
Error: pr55465.f90: Duplicate binding label 'SQLSetEnvAttr' for external
procedure SQL_SET_ENV_ATTR_INT and external procedure SQL_SET_ENV_ATTR_PTR
[NAG Fortran Compiler error termination, 1 error]

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[anlauf at gmx dot de]

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

--- Comment #10 from Harald Anlauf <anlauf at gmx dot de> 2012-11-26 20:24:56 UTC ---
(In reply to comment #9)
> Well, then somebody should also complain to NAG.
> The code in comment #6 fails to compile.

And to IBM.

% xlf -qversion
IBM XL Fortran for AIX, V14.1 (5765-J04, 5725-C74)
Version: 14.01.0000.0001
% xlf2008 -c pr55465.f90 -qlanglvl=2008pure
"pr55465.f90", line 16.4: 1516-194 (S) A binding label must not be the same as
the name of a program unit, common block, external procedure, and another
binding label, ignoring differences in case.
"pr55465.f90", 1516-036 (S) Entity sql_set_env_attr_ptr has undefined type.
** m_odbc_if   === End of Compilation 1 ===
1501-511  Compilation failed for file pr55465.f90.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[anlauf at gmx dot de]

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

--- Comment #11 from Harald Anlauf <anlauf at gmx dot de> 2012-11-26 20:57:53 UTC ---
I'm also having difficulties to see how the interface definition
could be standard compatible.  The F2k8 draft says:

15.5.1     Definition and reference of interoperable procedures
A procedure that is interoperable may be defined either by means other than
Fortran or by means of a Fortran subprogram, but not both.

 If the procedure is defined by means other than Fortran, it shall
    • be describable by a C prototype that is interoperable with the interface,
    • have a name that has external linkage as defined by 6.2.2 of ISO/IEC
9899:1999, and
    • have the same binding label as the interface.

Can somebody show the C prototype of the function SQLSetEnvAttr()?

Note that allowed prototypes are restricted by

15.3.7 Interoperability of procedures and procedure interfaces

and in particular:

(4) any dummy argument with the VALUE attribute is interoperable with the
corresponding formal
    parameter of the prototype,

(6) the prototype does not have variable arguments as denoted by the ellipsis
(...).

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[fmartinez at gmv dot com]

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

--- Comment #12 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2012-11-27 09:49:20 UTC ---
After readign the standard carefully again (I have the formal version for f2k3,
not the draft for f2k8) I cannot really see how the need for the interfaces to
be unique can be derived. Regardless whether some compilers issue certains
messages or not; actually this is also just different interpretations of the
same text.

The propotype for SQLSetEnvAttr I do not think that realy matters for the
discussion but I have added at the end of this comment.

>From what I see, the interface need not be unique (I share the point with Juno)
The bahaviour that I would expect (and this is again just an interpretation) is
that for a definition of a Fortran interface, when invoked, a C function is
called based on the provided label (from the f2k3 'A reference to such a
procedure causes the function described by the C prototype to be called as
...'). Not mandatory to be always a different one; maybe.

15.4.1 Binding labels for procedures defines how a label must be defined and
behaves with respect to the defining fortran interface but it says nothing
about being unique.

In my case I have to invoke SQLSetEnvAttr with more than one represetnation of
the ValuePtr (this is because of the way in which the ODBC library behaves
internally; not very nice) and in the way I see the implementation once I need
the void * to behave as an integer and then as an actual pointer (c_ptr).

I'll try to find another way out of this, but the one I tried seem to be the
natural one.
I'll give c_intptr_t an opprtunity; it is not in my standard and I had not
consider it all (not awware of it actually).





SQLRETURN SQLSetEnvAttr(
     SQLHENV      EnvironmentHandle,
     SQLINTEGER   Attribute,
     SQLPOINTER   ValuePtr,
     SQLINTEGER   StringLength);

SQLHENV = void *
SQLINT = int
SQLPOINTER = void *

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[juno.krahn at nih dot gov]

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

--- Comment #13 from Juno Krahn <juno.krahn at nih dot gov> 2012-11-30 17:21:08 UTC ---
This issue was once discussed by members of the Fortran standards committee. I
don't recall if that was on usenet or somewhere in the committee meeting notes.
The conclusion was that it is useful to allow for multiple explicit interfaces
in order to interface correctly with C libraries, and that the standards allow
for it.

The standards state that the defined interface must be compatible with the C
routine, but there are multiple ways to define a single interface. For example,
a pointer argument can be a pass-by-reference or just a C pointer. It might
make sense to validate that each interface spec does in fact have the same
binary call signature. Depending on compiler internals, that may be difficult
to implement.

In any case, it might be good to keep this as an optional warning because it is
not that common and could in fact be an error.

As for previous comments, yes someone should report this problem to NAG and
IBM.

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[burnus at gcc dot gnu.org]

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

--- Comment #14 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/55465] Name collision in C binding (calling C from Fortran)

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as FIXED (on the 4.9 trunk).

The example of comment 3 is now accepted.

(I am still not sure whether it is valid, but gfortran does not try to enforce
that the interface matches the C one by ensuring consistency between difference
INTERFACE declarations. Before, it also rejected identical INTERFACE
declarations (with different Fortran name or in different scoping units), which
was definitely a bug.)

[Bug fortran/55465] Name collision in C binding (calling C from Fortran)

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2013-05-22
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Juno Krahn from comment #13)
> This issue was once discussed by members of the Fortran standards committee.
> I don't recall if that was on usenet or somewhere in the committee meeting
> notes. The conclusion was that it is useful to allow for multiple explicit
> interfaces in order to interface correctly with C libraries, and that the
> standards allow for it.

Well, at least some standard committee members believe that the code in comment
0 is invalid: http://mailman.j3-fortran.org/pipermail/j3/2013-May/006397.html

Let's open this PR - and use it to track the addition of some diagnostic. It
might be a warning or error, it might depend on -std= or not.