[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus 2012-12-23 18:44:52 UTC --- FIXED on the 4.8 trunk. Thanks Andrew for the report. (The new patch is much nicer: It's much shorter, should be more reliable and fixes also some missed-optimization cases :-)
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #10 from Tobias Burnus 2012-12-23 18:43:36 UTC --- Author: burnus Date: Sun Dec 23 18:43:32 2012 New Revision: 194706 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194706 Log: 2012-12-23 Tobias Burnus PR fortran/54884 * module.c (write_symbol1_recursion): Set attr.public_use. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Remove attr.public_use code. * resolve.c (resolve_function, resolve_variable, resolve_typebound_procedure): Ditto. 2012-12-23 Tobias Burnus PR fortran/54884 * gfortran.dg/public_private_module_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-12-19 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #9 from Tobias Burnus 2012-12-19 18:20:10 UTC --- First: I think one should add a pass to frontend-passes.c, similar to doloop_code. The reason is that resolve comes too early for some checks. Quoting from resolve.c: /* If a PRIVATE variable is used in the specification expression of the result variable, it might be accessed from outside the module and can thus not be TREE_PUBLIC() = 0. TODO: sym->attr.public_used only has to be set for the result variable's type-parameter expression and not for dummies or automatic variables. Additionally, it only has to be set if the function is either PUBLIC or used in a generic interface or TBP; unfortunately, proc_name->attr.public_used can get set at a later stage. */ Secondly, a reducted test case for the FoX issue of comment 7 is the following: module m private public :: foo interface foo module procedure bar end interface foo contains pure function mylen() integer :: mylen mylen = 42 end function mylen subroutine bar(x) character(len=mylen()) :: x end subroutine bar end module m The following line in resolve.c's resolve_function should take care of setting the public_use attribute, but it doesn't work: 3128 if (sym && specification_expr && sym->attr.function 3129 && gfc_current_ns->proc_name 3130 && gfc_current_ns->proc_name->attr.flavor == FL_MODULE) 3131sym->attr.public_used = 1; The reason is that (gdb) p gfc_current_ns->proc_name->name $6 = 0x76725fe0 "bar"
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #8 from Andrew Benson 2012-12-19 18:02:44 UTC --- I spoke to soon! I just compiled r194618 of gcc and now I find the same problem.
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #7 from Andrew Benson 2012-12-19 17:31:47 UTC --- The fix for this bug has been working for me, but I'm getting reports from several colleagues (who are trying to install the FoX library so that they can install my software) that compiling the FoX library fails with what seems to be the same problem as reported here: gfortran -g -O2 -o wxml_example wxml_example.o $(../FoX-config --libs --wxml) /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_core.o): In function `__m_wxml_core_MOD_write_attributes': m_wxml_core.F90:(.text+0x1a1): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' m_wxml_core.F90:(.text+0x232): undefined reference to `__m_common_attrs_MOD_get_key_len' m_wxml_core.F90:(.text+0x27d): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' m_wxml_core.F90:(.text+0x321): undefined reference to `__m_common_attrs_MOD_get_key_len' m_wxml_core.F90:(.text+0x3cc): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' m_wxml_core.F90:(.text+0x431): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_core.o): In function `__m_wxml_core_MOD_xml_addattribute_ch': m_wxml_core.F90:(.text+0x2818): undefined reference to `__m_common_namespaces_MOD_getprefixindex' m_wxml_core.F90:(.text+0x2d26): undefined reference to `__m_common_namespaces_MOD_getprefixindex' m_wxml_core.F90:(.text+0x3298): undefined reference to `__m_common_namespaces_MOD_getprefixindex' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_pseudoattributematrixch': m_wxml_overloads.F90:(.text+0xc2): undefined reference to `__fox_m_fsys_format_MOD_str_string_matrix_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_pseudoattributearraych': m_wxml_overloads.F90:(.text+0xea8): undefined reference to `__fox_m_fsys_format_MOD_str_string_array_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_attributematrixch': m_wxml_overloads.F90:(.text+0x2182): undefined reference to `__fox_m_fsys_format_MOD_str_string_matrix_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_attributearraych': m_wxml_overloads.F90:(.text+0x2feb): undefined reference to `__fox_m_fsys_format_MOD_str_string_array_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_charactersmatrixch': m_wxml_overloads.F90:(.text+0x438e): undefined reference to `__fox_m_fsys_format_MOD_str_string_matrix_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o): In function `__m_wxml_overloads_MOD_charactersarraych': m_wxml_overloads.F90:(.text+0x4f78): undefined reference to `__fox_m_fsys_format_MOD_str_string_array_len' /home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_common.a(m_common_namespaces.o): In function `__m_common_namespaces_MOD_checknamespaces': m_common_namespaces.F90:(.text+0x3928): undefined reference to `__m_common_attrs_MOD_get_key_len' m_common_namespaces.F90:(.text+0x39b9): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' m_common_namespaces.F90:(.text+0x3f7b): undefined reference to `__m_common_attrs_MOD_get_key_len' m_common_namespaces.F90:(.text+0x41a9): undefined reference to `__m_common_attrs_MOD_get_key_len' m_common_namespaces.F90:(.text+0x426f): undefined reference to `__m_common_attrs_MOD_get_value_by_index_len' collect2: error: ld returned 1 exit status make[1]: *** [wxml_example] Error 1 make[1]: Leaving directory `/home/jlgan/galacticus/soft/FoX-4.1.0/examples' make: *** [examples_build] Error 2 These problems have occurred when using the most recent checkout of gcc 4.8.0 (the last case I saw of this happening was yesterday). I've been unable to reproduce the problem myself, even when using the same revision. Manually marking all of the functions that are listed as "undefined reference" as PUBLIC solves the issue. In any case, if anyone else is able to reproduce the problem I'd be very interested to hear!
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Tobias Burnus 2012-10-19 10:07:23 UTC --- FIXED on the 4.8 trunk. Thanks Andrew for the bug report!
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #5 from Tobias Burnus 2012-10-18 17:09:19 UTC --- Author: burnus Date: Thu Oct 18 17:09:13 2012 New Revision: 192571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192571 Log: 2012-10-18 Tobias Burnus PR fortran/54884 * resolve.c (specification_expr): Change to bool. (resolve_formal_arglist, resolve_symbol): Set specification_expr to true before resolving the array spec. (resolve_variable, resolve_charlen, resolve_fl_variable): Properly reset specification_expr. (resolve_function): Set public_use when used in a specification expr. 2012-10-18 Tobias Burnus PR fortran/54884 * gfortran.dg/public_private_module_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #4 from Dominique d'Humieres 2012-10-10 13:24:42 UTC --- > Well, I guess the point is that Dominique claimed that the bug reported by > Andrew is a regression of your commit for PR54221: The link errors disappear if I revert revision 190325.
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 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-10-10 09:08:35 UTC --- (In reply to comment #2) > (In reply to comment #1) > > Duplicate of pr54221 (see comment #5)? > > Duplicate of PR54221: No, that's a completely separate issue. > Duplicate of PR54221 comment 5: Well, it links to the Andrew's bug-reporting > email, hence, it is a duplicate. Well, I guess the point is that Dominique claimed that the bug reported by Andrew is a regression of your commit for PR54221: http://gcc.gnu.org/ml/fortran/2012-10/msg00047.html
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2012-10-10 07:42:10 UTC --- There is the following code in resolve.c's resolve_variable: if (specification_expr && sym->attr.access == ACCESS_PRIVATE && !sym->attr.function && !sym->attr.use_assoc && gfc_current_ns->proc_name && gfc_current_ns->proc_name->attr.function) sym->attr.public_used = 1; I don't have a GCC 4.8 build at hand, but I think the issue is that sym->attr.access == ACCESS_PRIVATE is false. I assume that sym->attr.access == ACCESS_UNKNOWN; one probably needs to check instead: && (sym->ns->default_access == ACCESS_PRIVATE || (sym->ns->default_access == ACCESS_UNKNOWN && gfc_option.flag_module_private))) * * * (In reply to comment #1) > Duplicate of pr54221 (see comment #5)? Duplicate of PR54221: No, that's a completely separate issue. Duplicate of PR54221 comment 5: Well, it links to the Andrew's bug-reporting email, hence, it is a duplicate.
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #1 from Dominique d'Humieres 2012-10-10 07:36:10 UTC --- Duplicate of pr54221 (see comment #5)?
