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

["Goodman, Joe" <joe dot goodman at intel dot com>]

We provide a C++ ABI test suite you can download from
http://developer.intel.com/software/products/opensource/.  Please feel free
to download and run this suite.

Joe Goodman
Intel Corporation
Software Solutions Group

The views expressed in this posting do not necessarily reflect the views of
Intel Corporation

-----Original Message-----
From: Benjamin Kosnik [mailto:bkoz@redhat.com]
Sent: Friday, August 02, 2002 9:16 AM
To: gcc@gcc.gnu.org
Cc: rth@redhat.com
Subject: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility


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