[PATCH] ICE with __real__ in template instantiation

scott snyder snyder@fnal.gov
Sat Oct 30 15:45:00 GMT 1999


hi -

The following input gives an ICE from cc1plus (from both the head cvs
version from a couple days ago and the 2.95 branch) on an i686-pc-linux-gnu
platform:


--------------------------------------------------------------
template <typename T>
class complex
{
public:
  void bar ();
};


template<typename T>
void
complex<T>::bar ()
{
  __complex__ double t;
  __real__ t = 0;
}

void foo ( complex<double>& x )
{
  x.bar ();
}
--------------------------------------------------------------


$ cc1plus x.cc
 void complex<T>::bar () void foo (complex<double> &)
x.cc: In method `void complex<T>::bar () [with T = double]':
x.cc:19:   instantiated from here
x.cc:14: Internal compiler error.
x.cc:14: Please submit a full bug report.
x.cc:14: See <URL: http://www.gnu.org/software/gcc/faq.html#bugreport > for instructions.


Here's where the crash is occuring:

Program received signal SIGSEGV, Segmentation fault.
require_complete_type (value=0x4011d0e0) at ../../../src/gcc/cp/typeck.c:107
107	  if (TYPE_SIZE (type) != 0
(gdb) where
#0  require_complete_type (value=0x4011d0e0)
    at ../../../src/gcc/cp/typeck.c:107
#1  0x8239fce in build_modify_expr (lhs=0x4011d0e0, modifycode=NOP_EXPR, 
    rhs=0x40109540) at ../../../src/gcc/cp/typeck.c:5590
#2  0x823a8af in build_x_modify_expr (lhs=0x4011d0e0, modifycode=NOP_EXPR, 
    rhs=0x40109540) at ../../../src/gcc/cp/typeck.c:6002
#3  0x8218d44 in build_expr_from_tree (t=0x4011ff60)
    at ../../../src/gcc/cp/decl2.c:3814
#4  0x82087b2 in tsubst_expr (t=0x4011d120, args=0x4011d940, complain=1, 
    in_decl=0x40114e80) at ../../../src/gcc/cp/pt.c:7448
#5  0x8208151 in tsubst_expr (t=0x4011d140, args=0x4011d940, complain=1, 
    in_decl=0x40114e80) at ../../../src/gcc/cp/pt.c:7203
#6  0x8208432 in tsubst_expr (t=0x40115f60, args=0x4011d940, complain=1, 
    in_decl=0x40114e80) at ../../../src/gcc/cp/pt.c:7317
#7  0x820aafb in instantiate_decl (d=0x4011ca00)
    at ../../../src/gcc/cp/pt.c:9665
#8  0x820ac19 in instantiate_pending_templates ()
    at ../../../src/gcc/cp/pt.c:9737
#9  0x82182f4 in finish_file () at ../../../src/gcc/cp/decl2.c:3432
#10 0x825001a in finish_translation_unit ()
    at ../../../src/gcc/cp/semantics.c:1721
#11 0x8229dfa in yyparse () at parse.y:360
#12 0x804b366 in compile_file (name=0xbffffd4b "x.cc")
    at ../../src/gcc/toplev.c:3200
#13 0x804e8c9 in main (argc=2, argv=0xbffffc04) at ../../src/gcc/toplev.c:5555


The value passed to require_complete_type is

(gdb) call debug_tree (value)
 <realpart_expr 0x4011d0e0
    permanent
    arg 0 <lookup_expr 0x4011d0c0
        permanent
        arg 0 <identifier_node 0x4011b3c0 t
            permanent
            bindings <binding 0x40115fc0
                permanent scope 0x40108000>
            local bindings <binding 0x4011ff00
                tree_0 tree_2 scope 0x82fa098 value <var_decl 0x4011e800 t>>>>>
(gdb) p value->common.type
$1 = (union tree_node *) 0x0


It has a null type, which is what causes the crash.

Where is the type supposed to get filled in?  This tree resulted
from a template instantiation, so it should have been set up when
tsubst_expr called build_expr_from_tree.  But build_expr_from_tree
doesn't have a case in the switch for realpart and imagpart exprs;
instead, the default case is taken, in which the type field is
not set up.

So, i tried making the following change, to have build_expr_from_tree
treat realpart and imagpart exprs like other unary operations:

--- decl2.c-orig	Sat Oct 30 02:56:25 1999
+++ decl2.c	Sat Oct 30 17:43:01 1999
@@ -3740,6 +3740,8 @@ build_expr_from_tree (t)
     case TRUTH_NOT_EXPR:
     case ADDR_EXPR:
     case CONVERT_EXPR:      /* Unary + */
+    case REALPART_EXPR:
+    case IMAGPART_EXPR:
       if (TREE_TYPE (t))
 	return t;
       return build_x_unary_op (TREE_CODE (t),


With this change, the example compiles without error, and the generated
code appears reasonable.  I've further checked that it does not
change the results of the testsuite.


I ran into these problems in the first place while trying to test out
a recent snapshot of the new libstdc++, which uses these built-in complex
types to implement the std::complex classes.

sss


More information about the Gcc-patches mailing list