[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-18 05:19 --- Subject: Bug 16861 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-18 05:18:55 Modified files: gcc/fortran: module.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: nested_modules_2.f90 Log message: 2005-09-18 Paul Thomas [EMAIL PROTECTED] PR fortran/16861 * module.c (read_module): Give symbols from module procedures different true_name entries to those from the module proper. 2005-09-18 Paul Thomas [EMAIL PROTECTED] PR fortran/16861 * gfortran.dg/nested_modules_2.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gccr1=1.37r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.557r2=1.558 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/nested_modules_2.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6074r2=1.6075 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From paul dot richard dot thomas at cea dot fr
2005-09-15 14:25 ---
I did not want to mess around by submitting from a Windows machine again, so
here is a preview of a proposed patch:
==
This proposed patch is a fix for PR16861, in which module procedures with
assumed shape dummy arguments would cause ICEs, when the indices themselves
were use associated.
The patch works by recognising that symbols from different namespaces, within
a module, should have different true_name entries. This permits the correct
resolution of references, when building the array_specs for the assumed shape
arrays. The backend referencing comes right because there is only one symtree
entry for each variable name, regardless of how many true_name entries there
might be.
The cost for this simple patch is slight: Each symbol is represented
in the .mod file so that, in the testcase below, the symbol i appears three
times in foobar.mod; once for each namespace. foobar.mod will be found after
the
testcase.
Evidently, it is not necessary to store this information in the module files,
since g95 does not. I rather like this explicit approach. However, it could be
fixed later by a bit of hacking in the code called by write_symbol[x], such that
only the index in the module namespace is stored and that the references be
redirected to this.
In the course of diagnosing the problem and developing the testcase, I noticed
that the FIXME on lines 3487-3497 had fixed itself and that the chunk of added
code is now redundant. I therefore took the opportunity to remove it. If
anbody recalls what triggered the condition, I would be grateful if they would
let me know. Regtesting does not reveal the need for this.
Regtested on Cygwin/i686 and FC3/Athlon 1700.
OK for mainline and 4.03, when open?
Paul T
===
2005-09-15 Paul Thomas [EMAIL PROTECTED]
PR fortran/16861
* module.c (read_module): Give symbols from module procedures
different true_name entries to those from the module proper.
2005-09-15 Paul Thomas [EMAIL PROTECTED]
PR fortran/16861
* gfortran.dg/nested_modules_2.f90: New test.
Index: gcc/gcc/fortran/module.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/module.c,v
retrieving revision 1.36
diff -c -p -r1.36 module.c
*** gcc/gcc/fortran/module.c9 Sep 2005 00:23:06 - 1.36
--- gcc/gcc/fortran/module.c15 Sep 2005 12:42:44 -
*** read_module (void)
*** 3101,3107
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_intrinsic_op i;
! int ambiguous, symbol, j, nuse;
pointer_info *info;
gfc_use_rename *u;
gfc_symtree *st;
--- 3101,3107
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_intrinsic_op i;
! int ambiguous, symbol, j, nuse, series;
pointer_info *info;
gfc_use_rename *u;
gfc_symtree *st;
*** read_module (void)
*** 3122,3127
--- 3122,3128
/* Create the fixup nodes for all the symbols. */
+ series = 0;
while (peek_atom () != ATOM_RPAREN)
{
require_atom (ATOM_INTEGER);
*** read_module (void)
*** 3144,3149
--- 3145,3158
being loaded again. */
sym = find_true_name (info-u.rsym.true_name, info-u.rsym.module);
+
+ /* If a module contains subroutines with assumed shape dummy
+arguments, the symbols for indices need to be different from
+from those in the module proper(ns = 1). */
+ if (sym !=NULL info-u.rsym.ns !=1)
+ sym = find_true_name (info-u.rsym.true_name,
+ gfc_get_string ([EMAIL PROTECTED],module_name,
series++));
+
if (sym == NULL)
continue;
*** write_symbol1 (pointer_info * p)
*** 3487,3497
if (p-type != P_SYMBOL || p-u.wsym.state != NEEDS_WRITE)
return 0;
- /* FIXME: This shouldn't be necessary, but it works around
- deficiencies in the module loader or/and symbol handling. */
- if (p-u.wsym.sym-module == NULL p-u.wsym.sym-attr.dummy)
- p-u.wsym.sym-module = gfc_get_string (module_name);
-
p-u.wsym.state = WRITTEN;
write_symbol (p-integer, p-u.wsym.sym);
--- 3496,3501
*** write_module (void)
*** 3610,3615
--- 3614,3620
mio_lparen ();
write_symbol0 (gfc_current_ns-sym_root);
+
while (write_symbol1 (pi_root));
mio_rparen ();
===nested_modules_2.f90==
! { dg do-run }
! This tests the patch for PR16861.
!
! Contributed by Paul Thomas [EMAIL PROTECTED]
!
module foo
INTEGER :: i
end module foo
module bar
contains
subroutine sub1 (j)
use foo
integer, dimension(i) :: j
j = 42
end subroutine sub1
subroutine sub2 (k)
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-11 16:28
---
(In reply to comment #22)
A thoroughly reduced testcase is:
module foo
INTEGER :: i
end module foo
module bar
contains
subroutine sub(j)
use foo
integer, dimension(i) :: j !change dimension to explicit clears bug
end subroutine sub
end module bar
module foobar
use foo !or eliminate this to clear bug
use bar
end module foobar
The ICE occurs whilst writing foobar because the symtree for the arrayspec for j
has no symbol for i, as said in the discussion in the PR. This has the effect
of causing the ICE here:
static void
mio_symtree_ref (gfc_symtree ** stp)
{
pointer_info *p;
fixup_t *f;
if (iomode == IO_OUTPUT)
{
mio_symbol_ref ((*stp)-n.sym); right here
If one passes mio_symbol_ref, when there is no symbol, the above compiles.
However, the module is not viable because it lacks the integer pointing to i in
j's arrayspec.
Two suggestive bits of information are:
(i) Interchanging the order of the two final USE statements allows the module to
compile successfully to the extent that it can be USED viably. This I assume
would be a viable workaround for the code concerned. I checked that reversing
the order of USE NullInterp_InterpUtil and USE NullGrid_Vars everywhere in the
first example to the PR produced good code.
(ii) Changing foobar to a program or subroutine gives successful compilations
for either order of the USE statements. Again, viable code is produced. (This is
why I thought that the bug had been cured!)
There must be some crucial difference in the treatment of modules but I have not
yet identified it. I am working my way through the code preceding
gfc_dump_module but have to stop right now. Will pick up again in the morning.
I need to study your contributions, David, to find out what exactly they were
doing. I apologise if I seemed a bit dismissive but I really thought that the
problem was solved; as I now understand, due to (ii) above.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-14 17:12 --- For the example in comment #14, the USE of MOD2 in MOD3 is not parsing the saved MOD2 module correctly causing J1 to be restored with a NULL symtree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-29 10:56 --- Subject: Bug 16861 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-29 10:56:18 Modified files: gcc/fortran: ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr16861.f90 Log message: PR fortran/16861 * resolve.c (resolve_variable): If e-symtree is not set, this ought to be a FAILURE, and not a segfault. * gfortran.dg/pr16861.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.42r2=1.335.2.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.34.2.6r2=1.34.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.148r2=1.5084.2.149 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-19 07:10 --- Subject: Bug 16861 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-19 07:10:06 Modified files: gcc/fortran: ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr16861.f90 Log message: PR fortran/16861 * resolve.c (resolve_variable): If e-symtree is not set, this ought to be a FAILURE, and not a segfault. * gfortran.dg/pr16861.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.397r2=1.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gccr1=1.39r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5369r2=1.5370 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-19 07:24 --- Like comment #5 says, this one is not fixed. The patch I committed only adress part of the issue. Removed patch keyword accordingly. -- What|Removed |Added Keywords|patch | Last reconfirmed|2005-04-18 13:12:03 |2005-04-19 07:24:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18 13:12 --- I think I found a patch for this one. See http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html -- What|Removed |Added CC|coudert at clipper dot ens |fxcoudert at gcc dot gnu dot |dot fr |org GCC build triplet|i686-pc-linux | GCC target triplet|i686-pc-linux | Keywords||patch Last reconfirmed|2005-02-26 18:42:24 |2005-04-18 13:12:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From yosef at phys dot utb dot edu 2005-04-19 01:09 --- Hi, The patch seems to fix part of the problem (the simplified test code from comment 4 now compiles), but the original code that I submitted still causes gfortran to segfault. I simplified my original code to the following test code that also causes gfortran (with the patch) to segfault. module MOD1 implicit none INTEGER, dimension(2) :: lsh end module MOD1 module MOD2 implicit none contains subroutine SUB1(J1) use MOD1 implicit none !input variables COMPLEX, dimension(lsh(1),lsh(2)), intent(inout) :: J1 end subroutine SUB1 end module MOD2 module MOD3 use MOD1 use MOD2 end module MOD3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-18 13:10 --- I confirm this issue is still present as of 2005-01-18. As a important number of people here, this is blocking my code from compiling smoothly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-15 17:13 --- *** Bug 19460 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||cummings at cacr dot caltech ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From paul dot richard dot thomas at cea dot fr 2004-12-02 10:38 --- The 11th November still gives this behaviour. However, if the USE FOO is raised to the module level, all is well. For example, this slightly expanded version compiles and runs fine. module FOO integer :: I=2 end module FOO module BAR use FOO contains subroutine BAZ(J) integer, dimension(I) :: J print * ,BAZ: size(j) =, size(J) end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS program test_mod use FOO USE BAR integer, dimension(I):: j I=3 call BAZ(j) call QUUS(2) print * ,MAIN: size(j) =, size(J) end program test_mod (In reply to comment #4) Confirmed. Here's a shorter testcase: = module FOO integer :: I end module FOO module BAR contains subroutine BAZ(J) use FOO integer, dimension(I) :: J end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS = -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From dmitrym at acres dot com dot au 2004-11-09 05:35 --- The bug 17764 was incorrectly linked to this (see comments in that entry). I simplified the 20k source file above to ~600 bytes. Compilation attempt (using gfortran as of Nov 09, 2004) still gives Internal compiler error. Segmentation fault. Now, the simplified code is: --- snip --- module NullGrid_Vars implicit none ! INTEGER*4, parameter :: lsh = 10 INTEGER*4, save :: lsh end module NullGrid_Vars ! module NullInterp_InterpUtil implicit none contains subroutine NullInterp_Util_cinterp(J1) use NullGrid_Vars implicit none !input variables COMPLEX*16, dimension(lsh), intent(inout) :: J1 end subroutine NullInterp_Util_cinterp end module NullInterp_InterpUtil ! module NullInterp_Interp implicit none contains subroutine NullInterp_cinterp() use NullGrid_Vars use NullInterp_InterpUtil implicit none end subroutine NullInterp_cinterp end module NullInterp_Interp --- snip --- As you may see, the second module (NullInterp_InterpUtil) gives the dimension of its in/out array as the variable lsh from the first module (NullGrid_Vars). However, lsh is a variable (although SAVEd). I'm not a standard guru, but it seems to me that such behavior is wrong, as the array size cannot be known at compilation time. If lsh is made a parameter (uncomment the line, comment the save line), then the code compiles without a hitch. Summary: I believe this is a bug in Fortran source file submitted as a test case, and not a gfortran bug. The 17764 was a genuine gfortran bug, and it was corrected during the last couple days (I checked couple times a week, so cannot pinpoint the exact moment). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
