(c++) libstdc++-v3 ICE on gcc-2.95 x86-win32 targets

[Mumit Khan <khan at xraylith dot wisc dot EDU>]

The following testcase, pared down version of bits/std_complex.h from 
libstdc++-v3, crashes all gcc-2.95 x86-win32 targets (not x86-linux 
however). The compiler crashes when trying to compile the explicit
specialization of `conj'.

Note that the problem does not occur if we're dealing with the
specialization of complex<double>, only for complex<float>.

Aargh.

  namespace std
  {
      template<typename _Tp> class complex;
      template<> class complex<float>;
      template<> class complex<double>;
      template<typename _Tp> complex<_Tp> conj(const complex<_Tp>&);
      template <typename _Tp>
      class complex
      {
      public:
	  typedef _Tp value_type;
	  complex (const _Tp& = _Tp(), const _Tp & = _Tp());
	  template <typename _Up>
	     complex (const complex<_Up>&);
      private:
	  _Tp _M_real, _M_imag;
      };
      template<> class complex<float>
      {
      public:
	  typedef float value_type;
	  complex(float = 0.0f, float = 0.0f);
	  explicit complex(const complex<double>&);
      private:
	  typedef __complex__ float _ComplexT;
	  _ComplexT _M_value;
	  complex(_ComplexT __z) : _M_value(__z) {}
	  friend complex<float> conj<>(const complex<float>&);
      };
      template<>
      inline complex<float>
      conj(const complex<float> &__x)
      { return complex<float> (~__x._M_value); }
  } 


$ ./xgcc -v -B./ -c libstdc++-complex-ICE.ii
Reading specs from ./specs
gcc version 2.95 19990726 (prerelease)
 ./cc1plus libstdc++-complex-ICE.ii -quiet -version -o /tmp/ccwmedXr.s
GNU C++ version 2.95 19990726 (prerelease) (i586-cygwin32) compiled by GNU C version 2.95 19990726 (prerelease).
libstdc++-complex-ICE.ii: In function `class complex<float> conj<float>(const complex<float> &)':
libstdc++-complex-ICE.ii:33: Internal compiler error.
libstdc++-complex-ICE.ii:33: Please submit a full bug report.
libstdc++-complex-ICE.ii:33: See <URL:http://egcs.cygnus.com/faq.html#bugreport> for instructions.

Now let's look at the gdb backtrace. Note that when it crashes within
put_reg_into_stack, it's because the "part_type" parameter is 0x0, instead
of pointing to a type.

$ gdb cc1plus
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /homes/khan/src/gcc-2.95-cvs/XCYGB20/gcc/cc1plus libstdc++-complex-ICE.ii
 complex<float>::complex(complex float) class complex<float> conj<float>(const complex<float> &)
Program received signal SIGSEGV, Segmentation fault.
0x806d855 in put_reg_into_stack (function=0x0, reg=0x8320448, type=0x0, 
    promoted_mode=SFmode, decl_mode=SFmode, volatile_p=0, original_regno=0, 
    used_p=0, ht=0x0) at ../../gcc/function.c:1708
1708      MEM_SET_IN_STRUCT_P (reg,
(gdb) where
#0  0x806d855 in put_reg_into_stack (function=0x0, reg=0x8320448, type=0x0, 
                                                                  ^^^^^^^^
								  NULL type
                                                                  ^^^^^^^^
    promoted_mode=SFmode, decl_mode=SFmode, volatile_p=0, original_regno=0, 
    used_p=0, ht=0x0) at ../../gcc/function.c:1708
#1  0x806d635 in put_var_into_stack (decl=0x832039c)
    at ../../gcc/function.c:1613
#2  0x82530fe in mark_addressable (exp=0x832039c)
    at ../../../gcc/cp/typeck.c:5016
#3  0x8091b09 in expand_expr (exp=0x82fdc6c, target=0x8320454, tmode=VOIDmode, 
    modifier=EXPAND_NORMAL) at ../../gcc/expr.c:7811
#4  0x8090c16 in expand_expr (exp=0x82fde30, target=0x8320430, tmode=SCmode, 
    modifier=EXPAND_NORMAL) at ../../gcc/expr.c:7484
#5  0x807983a in expand_return (retval=0x82fde48) at ../../gcc/stmt.c:2864
#6  0x82589dc in c_expand_return (retval=0x82fde30)
    at ../../../gcc/cp/typeck.c:7528
#7  0x826f609 in finish_return_stmt (expr=0x82fdc6c)
    at ../../../gcc/cp/semantics.c:317
#8  0x8243f04 in yyparse () at parse.y:3342
#9  0x804bab1 in compile_file (name=0xbffffd38 "libstdc++-complex-ICE.ii")
    at ../../gcc/toplev.c:3265
#10 0x804f559 in main (argc=2, argv=0xbffffc14) at ../../gcc/toplev.c:5441
(gdb) up
#1  0x806d635 in put_var_into_stack (decl=0x832039c)
    at ../../gcc/function.c:1613
1613          put_reg_into_stack (function, XEXP (reg, 1), part_type, part_mode,
(gdb) list
1608             We do it so they end up consecutive.  */
1609          enum machine_mode part_mode = GET_MODE (XEXP (reg, 0));
1610          tree part_type = TREE_TYPE (TREE_TYPE (decl));

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

          Shouldn't this be 
              tree part_type = TREE_TYPE (decl) 
          instead?

1611    #ifdef FRAME_GROWS_DOWNWARD
1612          /* Since part 0 should have a lower address, do it second.  */
1613          put_reg_into_stack (function, XEXP (reg, 1), part_type, part_mode,
1614                              part_mode, TREE_SIDE_EFFECTS (decl), 0,
1615                              TREE_USED (decl) || DECL_INITIAL (decl) != 0,
1616                              0);
1617          put_reg_into_stack (function, XEXP (reg, 0), part_type, part_mode,
(gdb) print part_type
$2 = 0x0
(gdb) p decl
$3 = 0x832039c
(gdb) pt
 <var_decl 0x832039c
    type <record_type 0x83190e8 complex<float> allocated from permanent_obstack
        permanent needs-constructing type_1 type_5 SC
        size <integer_cst 0x831f030 constant permanent 64>
        align 32 symtab 0 alias set -1
        fields <field_decl 0x831e230 _M_value type <complex_type 0x8308430 complex float>
            allocated from permanent_obstack
            permanent nonlocal decl_3 SC file libstdc++-complex-ICE.ii line 26
            size <integer_cst 0x830552c constant permanent 64>
            align 32
            bitpos <integer_cst 0x8309338 constant permanent 0> context <record_type 0x83190e8 complex<float>> arguments <integer_cst 0x8309338 0> chain <type_decl 0x831d7ec complex>>
       needs-constructor X() X(constX&) this=(X&) n_parents 0 use_template=2 interface-unknown
        member-functions <tree_vec 0x831dc90 allocated from permanent_obstack
            permanent
            elt 0 <overload 0x831f008>
            elt 2 <function_decl 0x831ee04 __as>>
        pointer_to_this <pointer_type 0x8319194> reference_to_this <reference_type 0x831ec54> chain <type_decl 0x8319220 complex<float>>>
    allocated from function maybepermanent obstack
    SC file libstdc++-complex-ICE.ii line 33 size <integer_cst 0x831f030 64>
    align 32
    (concat:SC (reg:SF 25)
    (mem:SF (plus:SI (reg:SI 18)
            (const_int -4 [0xfffffffc])) 0))>
(gdb) 

Regards,
Mumit