3.3.3: libstdc++ regression on ia64-hpux - messy EH problem - need help

[Zack Weinberg]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ios_init.s.bz2
Type: application/octet-stream
Size: 30858 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040225/58f09f83/attachment.obj>