Re:[c++] i686 toolchain additional shared fails

[Franz Sirl <Franz dot Sirl at arcormail dot de>]

> Surprisingly, I can reproduce the report in such a way that
> explicitly configuring an i586-pc-linux-gnu target reduces the number
> of testsuite failures for dynamically linked executables by four in
> comparison to
> <http://gcc.gnu.org/ml/libstdc++/2001-01/msg00046.html>, as
> demonstrated by the appended logfile. The results for dynamically
> linked executables are the same as for Mr. Kosnik's system but the number of
> failures for statically linked executables differs by eight in
> comparison to <http://gcc.gnu.org/ml/libstdc++/2001-01/msg00042.html>.
> 
> A preliminary analysis shows that all the static executable segfault
> in __throw, throw_helper and next_stack_level, e.g. in throw
> __out_of_range(const char *str) in line 54 for the program
> element_access.st-exe. Does exception-handling not work in glibc-2.1.3 when
> linked statically for "library-exceptions" (out_of_range etc)?
> 
> By the way the results for the gcc- and g++-testsuites are the same
> for both targets.
> 
> I hope this helps
> Peter Schmid
> 
> Backtrace for element_access.st-exe: 
> Program received signal SIGSEGV, Segmentation fault.
> 0x80495bc in next_stack_level (pc=0x804bde2, udata=0xbffff48c, 
>     caller_udata=0xbffff40c)
> Current language:  auto; currently c
> (gdb) bt
> #0  0x80495bc in next_stack_level (pc=0x804bde2, udata=0xbffff48c, 
>     caller_udata=0xbffff40c)
> #1  0x80496be in throw_helper (eh=0x8050c20, pc=0x804bde2, 
>     my_udata=0xbffff54c, offset_p=0xbffff548)
> #2  0x8049a6a in __throw ()
> #3  0x804bde3 in _ZSt14__out_of_rangePKc (str=0x804dafa "__n >=
> this->size()")
>     at ../../../../gcc/libstdc++-v3/src/stdexcept.cc:54
> #4  0x804c366 in _ZNKSs2atEj (this=0xbffff7bc, __n=21) at basic_string.h:435
> #5  0x8049dc6 in _Z6test01v ()
>     at ../../../gcc/libstdc++-v3/testsuite/21_strings/element_access.cc:59
> #6  0x804a04b in main ()
>     at ../../../gcc/libstdc++-v3/testsuite/21_strings/element_access.cc:94
> #7  0x4004da4e in __libc_start_main (main=0x804a040 <main>, argc=1, 
>     argv=0xbffff85c, init=0x8048ae0 <_init>, fini=0x804d9c4 <_fini>, 
>     rtld_fini=0x4000aa20 <_dl_fini>, stack_end=0xbffff854)
>     at ../sysdeps/generic/libc-start.c:92

I see the same thing on powerpc-linux-gnu and I have a theory now, it seems 
this is an incompatibility in exception handling between 
egcs-1.1.2/gcc-2.95.3 and gcc-2.97. If the static tests run on a system with 
a gcc-2.97 compiled glibc, they succeed. If the same lib is compiled with 
egcs-1.1.2 or gcc-2.95.3, they fail like Peter writes above.

Can anyone else confirm this? I have verified myself that the libstdc++ tests 
have additional fails on a standard RH62/x86 system (egcs-1.1.2/glibc-2.1.3) 
and on a standard LInuxPPC system (gcc-2.95.3/glibc-2.1.3), but they succeed 
on my own PPC system running glibc-2.2.1 compiled with gcc-2.97. If I install 
a glibc-2.2.1 compiled with gcc-2.95.3, the tests start to fail again on my 
PPC.

Peter, can you try to build and install a glibc-2.1.3 RPM compiled with 
gcc-2.97 on your system and then bootstrap/check gcc-2.97?

Franz.

Please CC, I'm not subscribed to libstdc++.