[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Wed Mar 13 07:21:33 2019 New Revision: 269635 URL: https://gcc.gnu.org/viewcvs?rev=269635=gcc=rev Log: 2019-03-13 Thomas Koenig PR fortran/66695 PR fortran/77746 PR fortran/79485 * gfortran.h (gfc_symbol): Add bind_c component. (gfc_get_gsymbol): Add argument bind_c. * decl.c (add_global_entry): Add bind_c argument to gfc_get_symbol. * parse.c (parse_block_data): Likewise. (parse_module): Likewise. (add_global_procedure): Likewise. (add_global_program): Likewise. * resolve.c (resolve_common_blocks): Likewise. (resolve_global_procedure): Likewise. (gfc_verify_binding_labels): Likewise. * symbol.c (gfc_get_gsymbol): Add argument bind_c. Set bind_c in gsym. * trans-decl.c (gfc_get_module_backend_decl): Add bind_c argument to gfc_get_symbol. (gfc_get_extern_function_decl): If the sym has a binding label and it cannot be found in the global symbol tabel, it is the wrong one and vice versa. 2019-03-13 Thomas Koenig PR fortran/66695 PR fortran/77746 PR fortran/79485 * gfortran.dg/binding_label_tests_30.f90: New test. * gfortran.dg/binding_label_tests_31.f90: New test. * gfortran.dg/binding_label_tests_32.f90: New test. * gfortran.dg/binding_label_tests_33.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/binding_label_tests_30.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_31.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_32.f90 trunk/gcc/testsuite/gfortran.dg/binding_label_tests_33.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #10 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #9) > Sorry if that maybe a stupid question but is it wise that close before the > new release to start such a bigger coding? Well, it turned out to be much less invasive than my first approach.
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #9 from Jürgen Reuter --- Sorry if that maybe a stupid question but is it wise that close before the new release to start such a bigger coding?
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77746 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #8 from Thomas Koenig --- Created attachment 45946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45946=edit First step towards a patch Expect quite a few regressions, but this seems to do the trick for this PR and PR 77746 + PR 79485.
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 --- Comment #7 from Thomas Koenig --- gfc_verify_binding_labels seems strange. First, I am not sure what to make of /* Verify that any binding labels used in a given namespace do not collide with the names or binding labels of any global symbols. As far as I read the standard, there is no harm in names colliding - binding labels have their separate namespace. The logic follows from the comment. For the subroutine s() bind(C, name="f") this gsym = gfc_find_case_gsymbol (gfc_gsym_root, sym->binding_label); looks for a name, and if (!gsym) gsym = gfc_get_gsymbol (sym->binding_label); creates it. We would probably be better off putting the C binding labels into a separate space.
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |7.5
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #6 from G. Steinmetz --- Update : $ cat z1.f90 module m contains integer function f() end end module m2 use m contains subroutine s() bind(c, name='f') integer :: x x = f() end end $ gfortran-9-2018 -c z1.f90 z1.f90:11:0: 11 | x = f() | internal compiler error: in fold_convert_loc, at fold-const.c:2426 0x8a9b87 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2425 0x6ed255 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool, bool) ../../gcc/fortran/trans-expr.c:9063 0x6fd58d gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10449 0x6bfdaf trans_code ../../gcc/fortran/trans.c:1822 0x6e7674 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6509 0x6c3b39 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2216 0x67440b translate_all_program_units ../../gcc/fortran/parse.c:6112 0x67440b gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6bc89f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 --- $ cat z2.f90 module m contains integer function f() end end module m2 use m contains subroutine s() bind(c, name='f') print *, f() end end $ gfortran-9-2018 -c z2.f90 f951: Error: using result of function returning 'void'
