Between 20100607 and 20100624, all Tru64 UNIX V5.1B EH tests started to fail, e.g. FAIL: g++.old-deja/g++.mike/eh33.C execution test This testcase segfaults like this: Program received signal SIGSEGV, Segmentation fault. __cxa_call_unexpected (exc_obj_in=0x70) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/unwind-cxx.h:374 374 return (c & 1); (gdb) where #0 __cxa_call_unexpected (exc_obj_in=0x70) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/unwind-cxx.h:374 #1 0x0000000120001a40 in foo () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/eh33.C:10 #2 0x0000000120001a80 in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/eh33.C:15 I'll start a reghunt to identify the culprit patch. Rainer
A reghunt revealed that this patch 2010-06-09 Iain Sandoe <iains@gcc.gnu.org> PR bootstrap/43170 * tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test references. Move the main () test reference ahead of pthread_create(). Add a comment to explain the requirements of the test. is the culprit. After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. I've yet to determine how the change could have this effect.
>After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. No it should be detected that way as it has emulated TLS support.
> --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-09-27 18:14:21 UTC --- >>After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. > > No it should be detected that way as it has emulated TLS support. But that support was present before, and still GCC_CHECK_TLS didn't detect it before Iain's patch. Something is certainly fishy here... Rainer
(In reply to comment #3) > But that support was present before, and still GCC_CHECK_TLS didn't > detect it before Iain's patch. Something is certainly fishy here... His patch was explicitly to fix checking for TLS when emulated TLS was used. Sometimes it would detect it as working and other times it would not.
(In reply to comment #4) > (In reply to comment #3) > > But that support was present before, and still GCC_CHECK_TLS didn't > > detect it before Iain's patch. Something is certainly fishy here... > > His patch was explicitly to fix checking for TLS when emulated TLS was used. > Sometimes it would detect it as working and other times it would not. As I recall, the patch was to circumvent a race condition - which manifest most frequently in the decision as to whether libgomp used TLS or not. It's odd that after this time a problem should show in libstdc++ (which was never, AFAIR flagged up in the original problem series). As for a platform with TLS - Darwin is regularly testing libstdc++ on powepc, and x86 .. so there must be some corner case at work.
> As I recall, the patch was to circumvent a race condition - which manifest most > frequently in the decision as to whether libgomp used TLS or not. I see no indications of this sort of problem here: before your patch, TLS support was reliably/consistently detected to be missing, now it's reliably found to be present. > It's odd that after this time a problem should show in libstdc++ (which was > never, AFAIR flagged up in the original problem series). I had noticed the problem (all C++ EH tests failing on Tru64 UNIX) before, but only now found the time to investigate. There are no other serious testsuite regressions caused by the patch as far as I can see. > As for a platform with TLS - Darwin is regularly testing libstdc++ on powepc, > and x86 .. so there must be some corner case at work. As is Solaris 8 and 9 without GNU as, which use emutls as well.
(In reply to comment #6) > > As I recall, the patch was to circumvent a race condition - which manifest most > > frequently in the decision as to whether libgomp used TLS or not. > > I see no indications of this sort of problem here: before your patch, > TLS support was reliably/consistently detected to be missing, now it's > reliably found to be present. IIUC, comment #2 indicates that the platform should show as having (emulated) TLS. If that is so, the situation is that the problem you now see was masked by a faulty configure macro, fixed by the patch. I will try and dig out the test code we used to stress the TLS implementation - it might be worth running that on the alpha to see whether is shows a difference. (it's probably attached to 43170). IIRC the fix was quite heavily discussed on patches - there might be something useful in those threads.
This is another instance of the same problem as PR target/46131: with emutls enabled, C++ EH tests rely on the presence of the real libpthread.so functions, not the dummies in libgcc. So the solution is the same: link libstdc++.so with -pthread. I'll submit a patch shortly.
Proposed patch.
Author: ro Date: Tue Nov 2 16:16:22 2010 New Revision: 166199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166199 Log: PR target/45693 * configure.host (osf*): Set os_include_dir to os/generic. Add -lpthread to OPT_LDFLAGS. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure.host
Fixed for 4.6.0.
Author: ro Date: Fri Dec 3 12:46:12 2010 New Revision: 167422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167422 Log: Backport from mainline: 2010-11-02 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR target/45693 * configure.host (osf*): Set os_include_dir to os/generic. Add -lpthread to OPT_LDFLAGS. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/configure.host