User account creation filtered due to spam.

Bug 41784 - [OOP] ICE in load_derived_extensions
Summary: [OOP] ICE in load_derived_extensions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2009-10-21 15:24 UTC by Salvatore Filippone
Modified: 2016-11-16 12:20 UTC (History)
2 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test case (866 bytes, text/plain)
2009-10-21 15:24 UTC, Salvatore Filippone
Details
A fix for the PR (304 bytes, patch)
2009-10-22 09:58 UTC, Paul Thomas
Details | Diff
patch (610 bytes, patch)
2009-10-23 18:35 UTC, janus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2009-10-21 15:24:26 UTC
The attached code produces the subject error. 
[sfilippo@donald bug9]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20091021 (experimental) (GCC) 
[sfilippo@donald bug9]$ gfortran -c linmap_type_mod.f90 
linmap_type_mod.f90:105:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.




Build: trunk at r153049 plus provisional patch for PR41781.
Comment 1 Salvatore Filippone 2009-10-21 15:24:58 UTC
Created attachment 18859 [details]
test case
Comment 2 janus 2009-10-21 15:41:59 UTC
The ICE also happens with a clean trunk.

Here is the backtrace:

#0  0x00007fcacadb56a0 in strcmp () from /lib/libc.so.6
#1  0x00000000005419c6 in gfc_find_symtree (st=0x2bcdf30, name=0x0) at /home/jweil/gcc45/trunk/gcc/fortran/symbol.c:2319
#2  0x00000000004ffd9a in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4011
#3  0x0000000000500a26 in read_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4450
#4  0x0000000000502caf in gfc_use_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:5500
#5  0x000000000050a5f8 in accept_statement (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:1525
#6  0x000000000050bb61 in parse_spec (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:2548
#7  0x000000000050d81f in parse_module () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:3944
#8  0x000000000050de8f in gfc_parse_file () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:4180
#9  0x000000000054afa0 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:239
#10 0x00000000009b6efd in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1049
#11 0x00000000009b91e9 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2408
#12 0x00000000009b92aa in toplev_main (argc=2, argv=0x7fffd395cd08) at /home/jweil/gcc45/trunk/gcc/toplev.c:2450
#13 0x00000000005c8be7 in main (argc=2, argv=0x7fffd395cd08) at /home/jweil/gcc45/trunk/gcc/main.c:35
Comment 3 janus 2009-10-21 16:02:18 UTC
Here is a further reduced test case:


module A_mod
  type  :: A
  end type
end module

module B_mod
  use A_mod
  type, extends(A) :: B
  end type
end module

module C_mod
  use B_mod
  type :: C
  end type C
end module

use C_mod, only: C
end


with a slightly different backtrace:


Program received signal SIGSEGV, Segmentation fault.
0x00000000004ffcd5 in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:3997
3997          gcc_assert (derived->attr.flavor == FL_DERIVED);
(gdb) bt
#0  0x00000000004ffcd5 in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:3997
#1  0x0000000000500a26 in read_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4450
#2  0x0000000000502caf in gfc_use_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:5500
#3  0x000000000050a5f8 in accept_statement (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:1525
#4  0x000000000050bb61 in parse_spec (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:2548
#5  0x000000000050d40a in parse_progunit (st=ST_USE) at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:3758
#6  0x000000000050dee9 in gfc_parse_file () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:4192
#7  0x000000000054afa0 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:239
#8  0x00000000009b6efd in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1049
#9  0x00000000009b91e9 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2408
#10 0x00000000009b92aa in toplev_main (argc=2, argv=0x7fffc79cfd78) at /home/jweil/gcc45/trunk/gcc/toplev.c:2450
#11 0x00000000005c8be7 in main (argc=2, argv=0x7fffc79cfd78) at /home/jweil/gcc45/trunk/gcc/main.c:35
Comment 4 janus 2009-10-22 09:31:55 UTC
Here is an even smaller test case with just one module:

module m
  type  :: A
  end type
  type, extends(A) :: B
  end type
end module

use m, only: A
end


Backtrace (same as in comment #2):

#0  0x00007fb6d07bd6a0 in strcmp () from /lib/libc.so.6
#1  0x0000000000541a26 in gfc_find_symtree (st=0x1fc9330, name=0x0) at /home/jweil/gcc45/trunk/gcc/fortran/symbol.c:2326
#2  0x00000000004ffd9a in load_derived_extensions () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4011
#3  0x0000000000500a26 in read_module () at /home/jweil/gcc45/trunk/gcc/fortran/module.c:4450
Comment 5 Paul Thomas 2009-10-22 09:58:09 UTC
Created attachment 18865 [details]
A fix for the PR

I'll regtest etc. on Saturday, when I am back from my travels.

Paul
Comment 6 janus 2009-10-22 10:05:38 UTC
(In reply to comment #5)
> Created an attachment (id=18865) [edit]
> A fix for the PR

This patch fixes fixes comment #3, but not comment #4 and comment #1.

Thanks, Paul.
Comment 7 Dominique d'Humieres 2009-10-22 14:39:43 UTC
(In reply to comment #5)
> Created an attachment (id=18865) [edit]
> A fix for the PR

If I add

@@ -4008,6 +4014,9 @@ load_derived_extensions (void)
 	  nuse = number_use_names (name, false);
 	  j = 1;
 	  p = find_use_name_n (name, &j, false);
+
+	  if (p == NULL) continue;
+
 	  st = gfc_find_symtree (gfc_current_ns->sym_root, p);
 	  dt = st->n.sym;
 	  st = gfc_find_symtree (derived->f2k_derived->sym_root, name);

to this patch (borrowed from other places in module.c), comment #4 and comment #1 are also fixed. 
The patch passes my tests, starting a full regtest.
Comment 8 janus 2009-10-22 15:09:35 UTC
(In reply to comment #7)
> If I add [...] to this patch (borrowed from other places in module.c),
> comment #4 and comment #1 are also fixed. 

The ICEs do go away, but on Salvatore's original code I now get:

gfortran-4.5 -O3   -I../lib -I.  -c psb_prec_type.f03
Fatal Error: Reading module psb_base_mod at line 124 column 55: Expected integer

Lines 124-132 in psb_base_mod.mod are:

((739 ('psb_c_base_sparse_mat' 'psb_c_base_mat_mod') (
'psb_d_base_sparse_mat' 'psb_d_base_mat_mod') ('psb_s_base_sparse_mat'
'psb_s_base_mat_mod') ('psb_z_base_sparse_mat' 'psb_z_base_mat_mod')) (
740 ('psb_c_coo_sparse_mat' 'psb_c_base_mat_mod') ('psb_c_csr_sparse_mat'
'psb_c_csr_mat_mod')) (741 ('psb_d_coo_sparse_mat' 'psb_d_base_mat_mod')
('psb_d_csr_sparse_mat' 'psb_d_csr_mat_mod')) (742 (
'psb_s_coo_sparse_mat' 'psb_s_base_mat_mod') ('psb_s_csr_sparse_mat'
'psb_s_csr_mat_mod')) (743 ('psb_z_coo_sparse_mat' 'psb_z_base_mat_mod')
('psb_z_csr_sparse_mat' 'psb_z_csr_mat_mod')))

Column 55 is the end of line 124.

It seems the patch does not quite do the right thing yet.
Comment 9 Dominique d'Humieres 2009-10-22 20:09:45 UTC
(In reply to comment #8)
> The ICEs do go away, but on Salvatore's original code I now get: ...

I get such problem now and then when using an obsolete module file and in general it goes away after recompiling it. Now here we may need:

          if (p == NULL)
        {
          skip_list ();
          continue;
        }

instead of just "if (p == NULL) continue;"?

Unfortunately none of the tests I have in store detected the problem (regtesting went without regression), so I cannot test it.

BTW, is there any good reason why 'p' is NULL?
Comment 10 Mikael Morin 2009-10-23 17:17:52 UTC
(In reply to comment #9)
> Now here we may need:
> 
>           if (p == NULL)
>         {
>           skip_list ();
>           continue;
>         }
skip_list() is unnecessary here as we have parsed everything already and the locus is on the closing parenthesis. However, mio_rparen() is needed so that we do not miss any parenthesis (this is also the case without skip_list).
The unformatted patch should look like this (it fixes the reduced testcase, but not tested further) :
Index: module.c
===================================================================
--- module.c	(revision 153473)
+++ module.c	(working copy)
@@ -4008,6 +4008,7 @@
 	  nuse = number_use_names (name, false);
 	  j = 1;
 	  p = find_use_name_n (name, &j, false);
+	  if (p) {
 	  st = gfc_find_symtree (gfc_current_ns->sym_root, p);
 	  dt = st->n.sym;
 	  st = gfc_find_symtree (derived->f2k_derived->sym_root, name);
@@ -4019,6 +4020,7 @@
 	      st->n.sym = dt;
 	      st->n.sym->refs++;
 	    }
+	  }
 	  mio_rparen ();
 	}
       mio_rparen ();



> BTW, is there any good reason why 'p' is NULL?
B is not imported (or use-associated in the fortran jargon)


NB : skip_list() wouldn't work anyway because it stops when the level variable is 0 (see the code). The character under the locus _shall_ be an opening parenthesis at the time skip_list() is called.
Comment 11 janus 2009-10-23 18:35:21 UTC
Created attachment 18883 [details]
patch

I propose the attached patch. It's an extended version of Paul's patch from comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile completely (at least the version I have).
Comment 12 Dominique d'Humieres 2009-10-23 19:34:53 UTC
> I propose the attached patch. It's an extended version of Paul's patch from
> comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile
> completely (at least the version I have).

Does the executable works as expected?
Would it be difficult to extract from the PSBLAS code showing the error in comment #8 with the change in comment #7? If I get the code, I can try to do the reduction.
Comment 13 Salvatore Filippone 2009-10-23 19:43:41 UTC
(In reply to comment #12)
> > I propose the attached patch. It's an extended version of Paul's patch from
> > comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile
> > completely (at least the version I have).
> 
> Does the executable works as expected?
I have yet to achieve full compilation under gfortran (the patched compiler is bootstrapping right now), and I will have little to no time to test the executables until next week. 

> Would it be difficult to extract from the PSBLAS code showing the error in
> comment #8 with the change in comment #7? If I get the code, I can try to do
> the reduction.
If error in comment #8 shows up again I will do the reduction asap. 
The code is a development version, the stable version is already available with a BSD like license, but the F2003 features are only being used in the development (by definition that is highly unstable). 
 


Comment 14 Salvatore Filippone 2009-10-23 20:40:10 UTC
I can confirm that my code compiles now. 
Whether it runs is an entirely different matter, which I will look at in the next few days...

Salvatore 
Comment 15 janus 2009-10-24 16:51:05 UTC
Subject: Bug 41784

Author: janus
Date: Sat Oct 24 16:50:41 2009
New Revision: 153534

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153534
Log:
2009-10-24  Janus Weil  <janus@gcc.gnu.org>
	    Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/41784
	* module.c (load_derived_extensions): Skip symbols which are not being
	loaded.


2009-10-24  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/41784
	* gfortran.dg/extends_8.f03: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/extends_8.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog

Comment 16 janus 2009-10-24 16:53:24 UTC
Fixed with r153534. Closing.