------- Comment #9 from tbm at cyrius dot com 2007-10-19 21:10 ------- (In reply to comment #8) > Whether or not an ICE occurs depends to some extent > on checking being enabled. With checking enabled, I see this on 4.1 > and the trunk. > > The ICE is here: > > result = expand_expr (exp, target, tmode, > modifier == EXPAND_INITIALIZER > ? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS); > > /* If the DECL isn't in memory, then the DECL wasn't properly > marked TREE_ADDRESSABLE, which will be either a front-end > or a tree optimizer bug. */ > gcc_assert (MEM_P (result)); Julien Cristau just reported an ICE with gcc 4.2 on hppa and I tracked it down to the same piece of quote you're quoting above. Note that my reduced testcase produces an ICE with gcc 4.1, 4.2 and trunk. Dave, can you take a look at it please? The following testcase requires -O: paer% gcc-4.2 -c -O2 basematrix.cc basematrix.cc: In member function ‘void S_BaseMatrix >::_ZTv0_n12_N12S_BaseMatrixI7complexIdEE12MultTransAddES1_(Complex)’: basematrix.cc:33: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6554 Please submit a full bug report, with preprocessed source if appropriate. Testcase: /* Testcase by Martin Michlmayr */ template < typename _CharT > class basic_stringstream; typedef basic_stringstream < char >stringstream; template < typename _CharT > class basic_ios { }; template < typename _CharT > class basic_stringstream: virtual public basic_ios < _CharT > { }; template < typename _Tp > class complex; template <> struct complex { __complex__ double _M_value; }; typedef complex < double >Complex; class BaseMatrix { virtual void MultTransAdd (Complex s); }; template < typename SCAL > class S_BaseMatrix:virtual public BaseMatrix { }; template < > class S_BaseMatrix < Complex >:virtual public BaseMatrix { virtual void MultTransAdd (Complex s); }; void S_BaseMatrix < Complex >::MultTransAdd (Complex s) { stringstream err; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209