This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
GCC 3.3.3 shows one regression relative to 3.3.2 on ia64-hpux: libstdc++'s 27_io/ios_init.cc test. The failure appears only in LP64 mode (RUNTESTFLAGS="--target_board unix/-mlp64"). I have tracked this as far as I can, which is not far enough to identify the problem. The proximate cause is that _Unwind_RaiseException (from the system-provided libunwind) returns _URC_FATAL_PHASE1_ERROR; this makes __cxa_throw call terminate. The call stack when this happens is #0 0x9fffffffec1f75b0:0 in kill+0x30 () from /lib/hpux64/libc.so.1 #1 0x9fffffffec11c7f0:0 in raise+0x30 () from /lib/hpux64/libc.so.1 #2 0x9fffffffec1b8e90:0 in abort+0x190 () from /lib/hpux64/libc.so.1 #3 0x9fffffffef782d40 in __cxxabiv1::__terminate (handler=0x9fffffffef467008) at eh_terminate.cc:47 #4 0x9fffffffef782de0 in std::terminate () at eh_terminate.cc:57 #5 0x9fffffffef783430 in __cxa_throw+0x2a0 () from libstdc++.so.5 #6 0x9fffffffef6e5770 in std::__throw_bad_cast () at functexcept.cc:49 #7 0x40000000000125f0 in std::basic_istream <unsigned char,std::char_traits<unsigned char>>::sentry::sentry (this=0x9fffffffffffeff0, __in=@0x9ffffffffffff010, __noskipws=255) at istream.tcc:45 #8 0x400000000000cce0 in std::basic_istream <unsigned char,std::char_traits<unsigned char> >& std::operator>> <unsigned char,std::char_traits<unsigned char> > (__in=@0x9ffffffffffff010, __s=0x9ffffffffffff1f0 "abcde") at istream.tcc:955 #9 0x400000000000a540 in test03 () at 27_io/ios_init.cc:328 #10 0x400000000000bb20 in main () at 27_io/ios_init.cc:402 The test case appears deliberately to provoke a std::bad_cast exception. This is the second time it does that; the first exception is successfully thrown, caught, and dismissed. _Unwind_RaiseException has called __gxx_personality_v0 once for this exception, for stack frame #8 (which I assume is the only one with a cleanup) Breakpoint 2, 0x9fffffffef60e040:0 in _Unwind_GetIP+0x30 () from /lib/hpux64/libunwind.so.1 (gdb) fin ... (gdb) p/x $gr8 $1 = 0x400000000000cce0 (gdb) bt #0 0x9fffffffef7818a0 in __gxx_personality_v0 (version=1, actions=_UA_SEARCH_PHASE, exception_class=0x474e5543432b2b00, ue_header=0x6000000000006130, context=0x9fffffffffffe1d0) at eh_personality.cc:230 #1 0x9fffffffef61cbf0:0 in _Unwind_RaiseException+0x250 () #2 0x9fffffffef783390 in __cxa_throw+0x200 () from libstdc++.so.5 #3 0x9fffffffef6e5770 in std::__throw_bad_cast () #4 0x40000000000125f0 in std::basic_istream<...>::sentry::sentry #5 0x400000000000cce0 in std::basic_istream<...>::operator>> #6 0x400000000000a540 in test03 () #7 0x400000000000bb20 in main () This call to __gxx_personality_v0 returns _URC_CONTINUE_UNWIND; _Unwind_RaiseException does not call it again before returning _URC_FATAL_PHASE1_ERROR to __cxa_throw. In the first (successful) throw, __gxx_personality_v0 is called a total of four times (twice each in search and cleanup phases). My working hypothesis is that the unwind information for this operator>> is somehow damaged, but I do not see anything wrong with it... <_ZStrsIhSt11char_traitsIhEERSt13basic_istreamIT_T0_ES6_PS3_>: [0x400000000000cca0-0x400000000000d170], info at +0x7cc8 v1, flags=0x3 ( ehandler uhandler), len=24 bytes R2:prologue_gr(mask=[rp,ar.pfs],grsave=r41,rlen=11) P7:pfs_when(t=0) P7:mem_stack_f(t=1,size=32) P7:pr_when(t=5) P3:pr_gr(reg=r44) P7:rp_when(t=10) R3:body(rlen=166) B1:label_state(label=1) B2:epilogue(t=3,ecount=0) R3:body(rlen=54) B1:copy_state(label=1) R1:prologue(rlen=0) I am attaching the offending .s file to this email. This does not seem to be an assembler bug, insofar as a GAS 2.14 snapshot from last June and a GAS 2.15 snapshot from today both demonstrate the same problem. The regression was provoked by Ben Kosnik's changes on 2003-12-03 to basic_ios.h, istream.tcc, ostream.tcc, etc., but I do not think there is a bug in that patch; rather I think it provokes a bug elsewhere. Any help would be appreciated. zw
Attachment:
ios_init.s.bz2
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |