* Large number of C++ regressions in past couple of days @ 2000-07-15 10:39 Zack Weinberg 2000-07-15 10:41 ` H . J . Lu 0 siblings, 1 reply; 6+ messages in thread From: Zack Weinberg @ 2000-07-15 10:39 UTC (permalink / raw) To: gcc I'm suddenly getting a huge flood of C++ regressions. See the list at the end. They all appear to have something to do with exception handling. I'm building libstdc++ v2, if that matters. zw FAIL: g++.brendan/eh1.C Execution test FAIL: g++.eh/badalloc1.C Execution test FAIL: g++.eh/catch11.C Execution test FAIL: g++.eh/catch12.C Execution test FAIL: g++.eh/catch3.C Execution test FAIL: g++.eh/catch3p.C Execution test FAIL: g++.eh/catch4.C Execution test FAIL: g++.eh/catch4p.C Execution test FAIL: g++.eh/catch5.C Execution test FAIL: g++.eh/catch5p.C Execution test FAIL: g++.eh/catch6.C Execution test FAIL: g++.eh/catch6p.C Execution test FAIL: g++.eh/catch7.C Execution test FAIL: g++.eh/catch7p.C Execution test FAIL: g++.eh/catch8.C Execution test FAIL: g++.eh/catch8p.C Execution test FAIL: g++.eh/catch9.C Execution test FAIL: g++.eh/catch9p.C Execution test FAIL: g++.eh/catchptr1.C Execution test FAIL: g++.eh/cleanup1.C Execution test FAIL: g++.eh/cleanup2.C Execution test FAIL: g++.eh/flow1.C Execution test FAIL: g++.eh/fntry1.C Execution test FAIL: g++.eh/new1.C Execution test FAIL: g++.eh/new2.C Execution test FAIL: g++.eh/pdel1.C Execution test FAIL: g++.eh/pdel2.C Execution test FAIL: g++.eh/ptr1.C Execution test FAIL: g++.eh/rethrow1.C Execution test FAIL: g++.eh/rethrow2.C Execution test FAIL: g++.eh/rethrow3.C Execution test FAIL: g++.eh/rethrow4.C Execution test FAIL: g++.eh/rethrow5.C Execution test FAIL: g++.eh/rethrow6.C Execution test FAIL: g++.eh/spec1.C Execution test FAIL: g++.eh/spec2.C Execution test FAIL: g++.eh/spec3.C Execution test FAIL: g++.eh/spec4.C Execution test FAIL: g++.eh/tmpl1.C Execution test FAIL: g++.eh/unwind1.C Execution test FAIL: g++.eh/vbase1.C Execution test FAIL: g++.eh/vbase2.C Execution test FAIL: g++.eh/vbase4.C Execution test FAIL: g++.martin/new1.C Execution test FAIL: g++.mike/dyncast1.C Execution test FAIL: g++.mike/dyncast2.C Execution test FAIL: g++.mike/eh10.C Execution test FAIL: g++.mike/eh12.C Execution test FAIL: g++.mike/eh14.C Execution test FAIL: g++.mike/eh16.C Execution test FAIL: g++.mike/eh17.C Execution test FAIL: g++.mike/eh18.C Execution test FAIL: g++.mike/eh2.C Execution test FAIL: g++.mike/eh21.C Execution test FAIL: g++.mike/eh23.C Execution test FAIL: g++.mike/eh24.C Execution test FAIL: g++.mike/eh25.C Execution test FAIL: g++.mike/eh26.C Execution test FAIL: g++.mike/eh27.C Execution test FAIL: g++.mike/eh28.C Execution test FAIL: g++.mike/eh29.C Execution test FAIL: g++.mike/eh3.C Execution test FAIL: g++.mike/eh31.C Execution test FAIL: g++.mike/eh33.C Execution test FAIL: g++.mike/eh34.C Execution test FAIL: g++.mike/eh35.C Execution test FAIL: g++.mike/eh36.C Execution test FAIL: g++.mike/eh37.C Execution test FAIL: g++.mike/eh38.C Execution test FAIL: g++.mike/eh39.C Execution test FAIL: g++.mike/eh40.C Execution test FAIL: g++.mike/eh41.C Execution test FAIL: g++.mike/eh42.C Execution test FAIL: g++.mike/eh44.C Execution test FAIL: g++.mike/eh47.C Execution test FAIL: g++.mike/eh48.C Execution test FAIL: g++.mike/eh49.C Execution test FAIL: g++.mike/eh5.C Execution test FAIL: g++.mike/eh50.C Execution test FAIL: g++.mike/eh51.C Execution test FAIL: g++.mike/eh55.C Execution test FAIL: g++.mike/eh6.C Execution test FAIL: g++.mike/eh8.C Execution test FAIL: g++.mike/p7912.C Execution test FAIL: g++.mike/p9706.C Execution test FAIL: g++.oliva/delete3.C Execution test FAIL: g++.oliva/new1.C Execution test FAIL: g++.other/array1.C Execution test FAIL: g++.other/init7.C Execution test FAIL: g++.other/singleton.C Execution test FAIL: g++.other/vbase2.C Execution test FAIL: g++.pt/fntry1.C Execution test FAIL: g++.robertl/eb31.C Execution test FAIL: g++.robertl/eb50.C Execution test FAIL: g++.robertl/eb66.C Execution test FAIL: g++.robertl/eb88.C Execution test FAIL: g++.robertl/eh990323-1.C Execution test FAIL: g++.robertl/eh990323-2.C Execution test FAIL: g++.robertl/eh990323-3.C Execution test FAIL: g++.robertl/eh990323-4.C Execution test FAIL: g++.robertl/eh990323-5.C Execution test FAIL: g++.robertl/ice990323-2.C Execution test ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Large number of C++ regressions in past couple of days 2000-07-15 10:39 Large number of C++ regressions in past couple of days Zack Weinberg @ 2000-07-15 10:41 ` H . J . Lu 2000-07-15 11:08 ` Zack Weinberg 0 siblings, 1 reply; 6+ messages in thread From: H . J . Lu @ 2000-07-15 10:41 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc On Sat, Jul 15, 2000 at 10:38:58AM -0700, Zack Weinberg wrote: > > I'm suddenly getting a huge flood of C++ regressions. See the list at > the end. They all appear to have something to do with exception > handling. > Have you enabled shared libstdc++? Are you building gcc under glibc 2? H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Large number of C++ regressions in past couple of days 2000-07-15 10:41 ` H . J . Lu @ 2000-07-15 11:08 ` Zack Weinberg 2000-07-15 11:14 ` H . J . Lu 0 siblings, 1 reply; 6+ messages in thread From: Zack Weinberg @ 2000-07-15 11:08 UTC (permalink / raw) To: H . J . Lu; +Cc: gcc On Sat, Jul 15, 2000 at 10:41:25AM -0700, H . J . Lu wrote: > On Sat, Jul 15, 2000 at 10:38:58AM -0700, Zack Weinberg wrote: > > > > I'm suddenly getting a huge flood of C++ regressions. See the list at > > the end. They all appear to have something to do with exception > > handling. > > > > Have you enabled shared libstdc++? Are you building gcc under glibc 2? No and yes (2.1.3), respectively. zw ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Large number of C++ regressions in past couple of days 2000-07-15 11:08 ` Zack Weinberg @ 2000-07-15 11:14 ` H . J . Lu 2000-07-15 14:03 ` Zack Weinberg 0 siblings, 1 reply; 6+ messages in thread From: H . J . Lu @ 2000-07-15 11:14 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc On Sat, Jul 15, 2000 at 11:08:27AM -0700, Zack Weinberg wrote: > On Sat, Jul 15, 2000 at 10:41:25AM -0700, H . J . Lu wrote: > > On Sat, Jul 15, 2000 at 10:38:58AM -0700, Zack Weinberg wrote: > > > > > > I'm suddenly getting a huge flood of C++ regressions. See the list at > > > the end. They all appear to have something to do with exception > > > handling. > > > > > > > Have you enabled shared libstdc++? Are you building gcc under glibc 2? > > No and yes (2.1.3), respectively. As you may know, the EH ABI has changed. But the old EH functions are still in libc.so in glibc. But I thought it would only be a problem if you have shared libstdc++. But on the other hand, you should check 1. If adding -static makes the problems go away: # gcc -static .... 2. Add -Wl,-Map,maplist, # gcc -Wl,-Map,maplist .... to see where those EH functions come from. H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Large number of C++ regressions in past couple of days 2000-07-15 11:14 ` H . J . Lu @ 2000-07-15 14:03 ` Zack Weinberg 0 siblings, 0 replies; 6+ messages in thread From: Zack Weinberg @ 2000-07-15 14:03 UTC (permalink / raw) To: H . J . Lu, Jason Merrill; +Cc: gcc On Sat, Jul 15, 2000 at 11:14:20AM -0700, H . J . Lu wrote: > On Sat, Jul 15, 2000 at 11:08:27AM -0700, Zack Weinberg wrote: > > On Sat, Jul 15, 2000 at 10:41:25AM -0700, H . J . Lu wrote: > > > On Sat, Jul 15, 2000 at 10:38:58AM -0700, Zack Weinberg wrote: > > > > > > > > I'm suddenly getting a huge flood of C++ regressions. See the list at > > > > the end. They all appear to have something to do with exception > > > > handling. > > > > > > Have you enabled shared libstdc++? Are you building gcc under glibc 2? > > > > No and yes (2.1.3), respectively. > > As you may know, the EH ABI has changed. But the old EH functions are > still in libc.so in glibc. This is a different problem. Here's a debug trace - note that, due to optimization, the debug info is useless, so I'm working at the assembly level. $ gdb ./g++-brendan-eh1-C (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x8049bf7 in find_fde (pc=0x804906f) at frame-dwarf2.c:479 479 { (gdb) bt #0 0x8049bf7 in find_fde (pc=0x804906f) at frame-dwarf2.c:479 #1 0x804a460 in __frame_state_for (pc_target=0x804906f, state_in=0xbffffa94) at frame-dwarf2.c:609 #2 0x8049085 in __throw () at libgcc2.c:3168 #3 0x8048285 in Foo::goodTest (this=0xbffffb54) at g++.brendan/eh1.C:42 #4 0x80482c7 in main () at g++.brendan/eh1.C:57 (gdb) disas $pc $pc + 20 Dump of assembler code from 0x8049bf7 to 0x8049c0b: 0x8049bf7 <find_fde+39>: mov (%esi),%eax 0x8049bf9 <find_fde+41>: test %eax,%eax 0x8049bfb <find_fde+43>: jne 0x8049c0b <find_fde+59> 0x8049bfd <find_fde+45>: sub $0xc,%esp 0x8049c00 <find_fde+48>: push %esi 0x8049c01 <find_fde+49>: call 0x8049a50 <frame_init> 0x8049c06 <find_fde+54>: mov (%esi),%eax 0x8049c08 <find_fde+56>: add $0x10,%esp (gdb) info registers eax 0x804906f 134516847 ecx 0x807ef70 134737776 edx 0xbffffa94 -1073743212 ebx 0x807da28 134732328 esp 0xbffff964 -1073743516 ebp 0xbffff97c -1073743492 esi **** 0x10101010 269488144 edi 0x0 0 eip 0x8049bf7 134519799 We're in the loop at the top of find_fde: /* Linear search through the objects, to find the one containing the pc. */ for (ob = objects; ob; ob = ob->next) { if (ob->pc_begin == 0) frame_init (ob); if (pc >= ob->pc_begin && pc < ob->pc_end) break; } (gdb) p objects $1 = (struct object *) 0x10101010 Hmmm... (gdb) b __register_frame_info (gdb) r Breakpoint 1, 0x80497a4 in __register_frame_info (begin=0x807ce60, ob=0x807db40) at /work/src/proto.gcc/gcc/frame-dwarf2.c:479 (gdb) p objects $2 = (struct object *) 0x0 (gdb) stepi # until the return from __r_f_i (gdb) p objects $3 = (struct object *) 0x807db40 (gdb) p *$3 $4 = {pc_begin = 0x0, pc_end = 0x0, fde_begin = 0x807ce60, fde_array = 0x0, count = 0, next = 0x0} Okay - that looks fine so far... (gdb) watch *(long *) &objects Hardware watchpoint 2: *(long *) &objects (gdb) c Hardware watchpoint 2: *(long *) &objects Old value = 0x0807db40 New value = 0x1007db40 0x804841a in init_reg_size_table () at /work/src/proto.gcc/gcc/libgcc2.c:3167 (gdb) disas $pc 0x80483c0 <init_reg_size_table>: push %ebp 0x80483c1 <init_reg_size_table+1>: mov %esp,%ebp 0x80483c3 <init_reg_size_table+3>: push %ebx 0x80483c4 <init_reg_size_table+4>: call 0x8048300 <__default_terminate+16> 0x80483c9 <init_reg_size_table+9>: add $0x3565f,%ebx 0x80483cf <init_reg_size_table+15>: mov $0x1,%ecx 0x80483d4 <init_reg_size_table+20>: movb $0x8,0x248(%ebx) ... 0x804841a <init_reg_size_table+90>: movb $0x10,0x23e(%ebx) 0x8048421 <init_reg_size_table+97>: movb $0x10,0x23d(%ebx) ... 0x80484b4 <init_reg_size_table+244>: movb $0x4,0x224(%ebx) 0x80484bb <init_reg_size_table+251>: mov %ecx,0xffffe170(%ebx) 0x80484c1 <init_reg_size_table+257>: pop %ebx 0x80484c2 <init_reg_size_table+258>: pop %ebp 0x80484c3 <init_reg_size_table+259>: ret Aha! That's where 0x10101010 came from. Here's the source listing of init_reg_size_table: static int dwarf_reg_size_table_initialized = 0; static char dwarf_reg_size_table[DWARF_FRAME_REGISTERS]; static void init_reg_size_table (void) { __builtin_init_dwarf_reg_size_table (dwarf_reg_size_table); dwarf_reg_size_table_initialized = 1; } (gdb) p &dwarf_reg_size_table $9 = (char (*)[17]) 0x807dc4c (gdb) p &objects $10 = (struct object **) 0x807dc64 (gdb) p (unsigned long) $10 - (unsigned long)$9 $11 = 24 The 'objects' list head is located 24 bytes after the beginning of dwarf_reg_size_table. DWARF_FRAME_REGISTERS is 17, so presumably we have some padding between objects and d_r_s_t. But __builtin_init_dwarf_reg_size_table expands to 33 movb instructions, which write over the 33 consecutive bytes starting at 0x224(%ebx) - which is the address of dwarf_reg_size_table. In other words, __b_i_d_r_s_t expects to be initializing an array of 33 bytes, but we're only giving it 17. Boom. This can't have anything to do with glibc; the array and the initialization routine are right next to each other in the same file. Here's the code of the routine that expands bidrst: void expand_builtin_init_dwarf_reg_sizes (address) tree address; { int i; enum machine_mode mode = TYPE_MODE (char_type_node); rtx addr = expand_expr (address, NULL_RTX, VOIDmode, 0); rtx mem = gen_rtx_MEM (mode, addr); i = MAX (FIRST_PSEUDO_REGISTER, DWARF_FRAME_REGISTERS); /*******/ while (i--) { int offset = DWARF_FRAME_REGNUM (i) * GET_MODE_SIZE (mode); int size = GET_MODE_SIZE (reg_raw_mode[i]); if (offset < 0) continue; emit_move_insn (change_address (mem, mode, plus_constant (addr, offset)), GEN_INT (size)); } } Note the MAX() expression. That appeared with this change, although it appears to be unrelated to it: 2000-07-14 Jason Merrill <jason@redhat.com> * dwarf2out.c (dwarf2out_frame_debug_expr): If we store the CFA register in the stack and later in another register, use the new register. --- dwarf2out.c 2000/06/30 07:51:39 1.183 +++ dwarf2out.c 2000/07/14 17:40:38 1.184 @@ -626,7 +626,8 @@ expand_builtin_init_dwarf_reg_sizes (add rtx addr = expand_expr (address, NULL_RTX, VOIDmode, 0); rtx mem = gen_rtx_MEM (mode, addr); - for (i = 0; i < DWARF_FRAME_REGISTERS; ++i) + i = MAX (FIRST_PSEUDO_REGISTER, DWARF_FRAME_REGISTERS); + while (i--) { int offset = DWARF_FRAME_REGNUM (i) * GET_MODE_SIZE (mode); int size = GET_MODE_SIZE (reg_raw_mode[i]); Jason, what was the intent of that change? zw ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Large number of C++ regressions in past couple of days @ 2000-07-15 20:19 David Ronis 0 siblings, 0 replies; 6+ messages in thread From: David Ronis @ 2000-07-15 20:19 UTC (permalink / raw) To: gcc This may not be related, but optimized bootstrap builds generate hundreds of g++ testsuite failures. This has been the case as far back as 2.95.2 and in the entire 2.96 snapshot series (have a look at any of my testsuite posts on the testsuite list archive). My guess that some of the IO library routines are miscompiled and responsible responsible. David Ronis ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-07-15 20:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-15 10:39 Large number of C++ regressions in past couple of days Zack Weinberg 2000-07-15 10:41 ` H . J . Lu 2000-07-15 11:08 ` Zack Weinberg 2000-07-15 11:14 ` H . J . Lu 2000-07-15 14:03 ` Zack Weinberg 2000-07-15 20:19 David Ronis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).