http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2010-09-27 18:40:36 UTC --- > 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.