* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
@ 2012-11-25 18:20 ` fmartinez at gmv dot com
2012-11-25 18:21 ` fmartinez at gmv dot com
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: fmartinez at gmv dot com @ 2012-11-25 18:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
2012-11-25 18:20 ` [Bug fortran/55465] " fmartinez at gmv dot com
@ 2012-11-25 18:21 ` fmartinez at gmv dot com
2012-11-26 16:38 ` janus at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: fmartinez at gmv dot com @ 2012-11-25 18:21 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
2012-11-25 18:20 ` [Bug fortran/55465] " fmartinez at gmv dot com
2012-11-25 18:21 ` fmartinez at gmv dot com
@ 2012-11-26 16:38 ` janus at gcc dot gnu.org
2012-11-26 17:08 ` janus at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: janus at gcc dot gnu.org @ 2012-11-26 16:38 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (2 preceding siblings ...)
2012-11-26 16:38 ` janus at gcc dot gnu.org
@ 2012-11-26 17:08 ` janus at gcc dot gnu.org
2012-11-26 17:36 ` fmartinez at gmv dot com
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: janus at gcc dot gnu.org @ 2012-11-26 17:08 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (3 preceding siblings ...)
2012-11-26 17:08 ` janus at gcc dot gnu.org
@ 2012-11-26 17:36 ` fmartinez at gmv dot com
2012-11-26 17:41 ` burnus at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: fmartinez at gmv dot com @ 2012-11-26 17:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (4 preceding siblings ...)
2012-11-26 17:36 ` fmartinez at gmv dot com
@ 2012-11-26 17:41 ` burnus at gcc dot gnu.org
2012-11-26 19:52 ` juno.krahn at nih dot gov
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-11-26 17:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (5 preceding siblings ...)
2012-11-26 17:41 ` burnus at gcc dot gnu.org
@ 2012-11-26 19:52 ` juno.krahn at nih dot gov
2012-11-26 19:55 ` juno.krahn at nih dot gov
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: juno.krahn at nih dot gov @ 2012-11-26 19:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (6 preceding siblings ...)
2012-11-26 19:52 ` juno.krahn at nih dot gov
@ 2012-11-26 19:55 ` juno.krahn at nih dot gov
2012-11-26 20:20 ` anlauf at gmx dot de
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: juno.krahn at nih dot gov @ 2012-11-26 19:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (7 preceding siblings ...)
2012-11-26 19:55 ` juno.krahn at nih dot gov
@ 2012-11-26 20:20 ` anlauf at gmx dot de
2012-11-26 20:25 ` anlauf at gmx dot de
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gmx dot de @ 2012-11-26 20:20 UTC (permalink / raw)
To: gcc-bugs
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]
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (8 preceding siblings ...)
2012-11-26 20:20 ` anlauf at gmx dot de
@ 2012-11-26 20:25 ` anlauf at gmx dot de
2012-11-26 20:58 ` anlauf at gmx dot de
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gmx dot de @ 2012-11-26 20:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (9 preceding siblings ...)
2012-11-26 20:25 ` anlauf at gmx dot de
@ 2012-11-26 20:58 ` anlauf at gmx dot de
2012-11-27 9:49 ` fmartinez at gmv dot com
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: anlauf at gmx dot de @ 2012-11-26 20:58 UTC (permalink / raw)
To: gcc-bugs
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
(...).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (10 preceding siblings ...)
2012-11-26 20:58 ` anlauf at gmx dot de
@ 2012-11-27 9:49 ` fmartinez at gmv dot com
2012-11-30 17:21 ` juno.krahn at nih dot gov
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: fmartinez at gmv dot com @ 2012-11-27 9:49 UTC (permalink / raw)
To: gcc-bugs
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 *
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (11 preceding siblings ...)
2012-11-27 9:49 ` fmartinez at gmv dot com
@ 2012-11-30 17:21 ` juno.krahn at nih dot gov
2013-05-20 20:14 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: juno.krahn at nih dot gov @ 2012-11-30 17:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (12 preceding siblings ...)
2012-11-30 17:21 ` juno.krahn at nih dot gov
@ 2013-05-20 20:14 ` burnus at gcc dot gnu.org
2013-05-20 20:18 ` burnus at gcc dot gnu.org
2013-05-22 6:39 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-05-20 20:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (13 preceding siblings ...)
2013-05-20 20:14 ` burnus at gcc dot gnu.org
@ 2013-05-20 20:18 ` burnus at gcc dot gnu.org
2013-05-22 6:39 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-05-20 20:18 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug fortran/55465] Name collision in C binding (calling C from Fortran)
2012-11-25 18:19 [Bug fortran/55465] New: Name collision in C binding (calling C from Fortran) fmartinez at gmv dot com
` (14 preceding siblings ...)
2013-05-20 20:18 ` burnus at gcc dot gnu.org
@ 2013-05-22 6:39 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-05-22 6:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread