C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik <bkoz at redhat dot com>]

I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
same C++ ABI before gcc-3.2 is released.

As far as I know, there is no official ABI testing as per the release
process. Several people have suggested ways to test this. A summary is
here:

http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt

Under: 

IV. Testing ABI changes

[snip]

One. 
(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
one with a new compiler and an old library, and the other with an old
compiler and a new library, and look for testsuite regressions)


I did this last night, and unfortunately cannot say that this approach
is currently working with gcc and gcc-3_2-branch C++ binaries. 

Here are my results, which are tenative. I'm re-running these, as I
started this too late last night to really be sure.

I'd apprecaite it if somebody could verify my results.

3.2 libstdc++.so.5 in a 3.3 build directory, make check == 0K
3.3 libstdc++.so.5 in a 3.2 build directory, make check == 15 FAILS

FAIL: 19_diagnostics/stdexceptions.cc execution test
FAIL: 21_strings/append.cc execution test
FAIL: 21_strings/ctor_copy_dtor.cc execution test
FAIL: 21_strings/element_access.cc execution test
FAIL: 21_strings/insert.cc execution test
FAIL: 21_strings/substr.cc execution test
FAIL: 22_locale/ctor_copy_dtor.cc execution test
FAIL: 23_containers/bitset_ctor.cc execution test
FAIL: 23_containers/bitset_members.cc execution test
FAIL: 23_containers/list_modifiers.cc execution test
FAIL: 23_containers/vector_element_access.cc execution test
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess
errors)
FAIL: 27_io/ios_base_storage.cc execution test
FAIL: 27_io/ios_init.cc execution test
FAIL: 27_io/ios_members.cc execution test

		=== libstdc++-v3 Summary ===

# of expected passes		394
# of unexpected failures	15
# of unexpected successes	26


Debugging the first of these... 

/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/g++ -shared-libgcc
-B/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/ -nostdinc++
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
/.libs -B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/include -g
-ffunction-sections -fdata-sections -fmessage-length=0 -DDEBUG_ASSERT
-DLOCALEDIR="/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libst
dc++-v3/po/share/locale" -nostdinc++
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude/i686-pc-linux-gnu
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude -I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libsupc++
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libio
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/include/backward
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc -DDEBUG_ASSERT -lm -o ./stdexceptions.exe

%ldd stdexceptions.exe 
	libstdc++.so.5 =>
/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src/.
libs/libstdc++.so.5 (0x40015000)
	libm.so.6 => /lib/i686/libm.so.6 (0x400d7000)
	libgcc_s.so.1 => /mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/libgcc_s.so.1
(0x400f9000)
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

looks ok

%./stdexceptions.exe 
Abort (core dumped)

(gdb) where
#0  0x42029241 in kill () from /lib/i686/libc.so.6
#1  0x4202902a in raise () from /lib/i686/libc.so.6
#2  0x4202a7d2 in abort () from /lib/i686/libc.so.6
#3  0x400b1407 in __cxxabiv1::__terminate(void (*)()) (
    handler=0x4202a664 <abort>)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x400b1444 in std::terminate() ()
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x400b15c6 in __cxa_throw (obj=0x804b788, tinfo=0x0, dest=0)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_throw.cc:77
#6  0x08049198 in test03() ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:62
#7  0x0804958f in main ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:110
#8  0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

stepping through it, get to __cxa_throw in eh_thow.cc, line 72:

  // Some sort of unwinding error.  Note that terminate is a handler.
  __cxa_begin_catch (&header->unwindHeader);
  std::terminate ();

Ouch. Isn't this a case of exception regions being screwed?

-benjamin