(c++) libstdc++-v3 ICE on gcc-2.95 x86-win32 targets
Mumit Khan
khan@xraylith.wisc.EDU
Tue Jul 27 14:59:00 GMT 1999
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
More information about the Gcc-bugs
mailing list