[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
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.)
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
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=199118root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@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 bur...@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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 20 20:05:40 2013 New Revision: 199119 URL: http://gcc.gnu.org/viewcvs?rev=199119root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * decl.c (add_global_entry): Use nonbinding name only for F2003 or if no binding label exists. (gfc_match_entry): Update calls. * parse.c (gfc_global_used): Improve error message. (add_global_procedure): Use nonbinding name only for F2003 or if no binding label exists. (gfc_parse_file): Update call. * resolve.c (resolve_global_procedure): Use binding name when available. * trans-decl.c (gfc_get_extern_function_decl): Ditto. 2013-05-20 Tobias Burnus bur...@net-b.de PR fortran/48858 * gfortran.dg/binding_label_tests_17.f90: New. * gfortran.dg/binding_label_tests_18.f90: New. * gfortran.dg/binding_label_tests_19.f90: New. * gfortran.dg/binding_label_tests_20.f90: New. * gfortran.dg/binding_label_tests_21.f90: New. * gfortran.dg/binding_label_tests_22.f90: New. * gfortran.dg/binding_label_tests_23.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/binding_label_tests_17.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_18.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_19.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_20.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_21.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_22.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_23.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
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
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=199120root=gccview=rev Log: 2013-05-20 Tobias Burnus bur...@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 bur...@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
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
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
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
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
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
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
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
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
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
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=gccview=revrev=173500 Log: 2011-05-06 Tobias Burnus bur...@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 bur...@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
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=gccview=revrev=173503 Log: Really commit: 2011-05-06 Tobias Burnus bur...@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
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
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
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.
