Bug 47082 - [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
[4.6 Regression] [OOP] ICE in gfc_conv_component_ref
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P4 normal
: 4.6.0
Assigned To: Paul Thomas
: ice-on-valid-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-28 20:00 UTC by Salvatore Filippone
Modified: 2011-02-02 19:52 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-12-29 15:58:51


Attachments
test case (5.65 KB, text/plain)
2010-12-28 20:00 UTC, Salvatore Filippone
Details
Fix for the PR and a tidy up in module.c (1.96 KB, patch)
2011-02-01 22:32 UTC, Paul Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2010-12-28 20:00:08 UTC
Created attachment 22858 [details]
test case

trunk at r168261: 
[sfilippo@localhost V1]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20101227 (experimental) (GCC) 
[sfilippo@localhost V1]$ gfortran -ggdb -fbacktrace bug29_1.f90 -c
bug29_1.f90: In function 'psb_cdall':
bug29_1.f90:244:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:501
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 janus 2010-12-28 21:05:34 UTC
Here is a reduced test case:


module m0
  implicit none
  type :: t0
  end type
end module

module m1
  use m0
  implicit none
  type, extends(t0) :: t1
    integer, allocatable :: i
  end type
  class(t0), pointer, private :: idxmap
end module

module m2
  use m0
  implicit none
  type t2
    class(t0), allocatable :: indxmap
  end type
end module

program bug29
  use m1
  use m2
  implicit none
  type(t2) :: desc
  allocate(t1 :: desc%indxmap)
end
Comment 2 janus 2010-12-29 15:58:51 UTC
I have stared at this problem for a while now, but I'm still puzzled about its origin. All I could come up with is this ad-hoc patch:

Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c    (revision 168301)
+++ gcc/fortran/trans-expr.c    (working copy)
@@ -6085,6 +6085,7 @@ gfc_trans_class_init_assign (gfc_code *code)
 
   rhs = gfc_copy_expr (code->expr1);
   gfc_add_vptr_component (rhs);
+  gfc_get_derived_type (rhs->ts.u.derived);
   gfc_add_def_init_component (rhs);
 
   sz = gfc_copy_expr (code->expr1);


This does not solve the problem fully, but it reduces it to PR46448:

/tmp/cc9UG1CN.s: Assembler messages:
/tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined
Comment 3 janus 2011-01-04 13:28:33 UTC
(In reply to comment #2)
> This does not solve the problem fully, but it reduces it to PR46448:
> 
> /tmp/cc9UG1CN.s: Assembler messages:
> /tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined

After PR46448 is solved now, the patch fully fixes the test case. Still it feels a bit hackish.
Comment 4 janus 2011-01-04 13:31:11 UTC
Btw, since 4.5 cleanly compiles comment #1, this clearly is a regression.
Comment 5 Paul Thomas 2011-02-01 10:00:14 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > This does not solve the problem fully, but it reduces it to PR46448:
> > 
> > /tmp/cc9UG1CN.s: Assembler messages:
> > /tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined
> 
> After PR46448 is solved now, the patch fully fixes the test case. Still it
> feels a bit hackish.

Not entirely:
If you change the line in module m1 from-
  class(t0), pointer, private :: idxmap
to
  type(t0), pointer, private :: idxmap

then the reduced testcase of comment #1 compiles.  Comparing themain programme between the two, you will see a symtree '@2' in the failing case that points to the vtype, '__vtype_m0_T0'.  I would guess that this has no backend_decl.

Calling gfc_get_derived_type then associates (I think) the backend_decls with that of the symtree '__vtype_m0_T0', which is somehow pointing to a different symbol.

I will explore further at lunchtime.

Paul
Comment 6 Paul Thomas 2011-02-01 22:32:21 UTC
Created attachment 23206 [details]
Fix for the PR and a tidy up in module.c

Janus's patch is fine.  My comment is incorrect; the tidy-up in module.c gets rid of the unique symtrees but the segfault remains.  I have commented as to why the fix of comment #3 works.

I'll submit it in Janus's name.

Paul
Comment 7 Paul Thomas 2011-02-02 19:51:07 UTC
Author: pault
Date: Wed Feb  2 19:51:03 2011
New Revision: 169767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169767
Log:
2011-02-02  Janus Weil  <janus@gcc.gnu.org>
	    Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47082
	* trans-expr.c (gfc_trans_class_init_assign): Add call to
	gfc_get_derived_type.
	* module.c (read_cleanup): Do not use unique_symtrees for vtabs
	or vtypes.

2011-02-02  Janus Weil  <janus@gcc.gnu.org>
	    Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47082
	* gfortran.dg/class_37.f03 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_37.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 8 Paul Thomas 2011-02-02 19:52:28 UTC
Fixed on trunk.

Grazie, Salvatore!

Paul and Janus