From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17757 invoked by alias); 12 Jan 2012 15:48:22 -0000 Received: (qmail 17733 invoked by uid 22791); 12 Jan 2012 15:48:13 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jan 2012 15:47:59 +0000 From: "ro at CeBiTec dot Uni-Bielefeld.DE" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX Date: Thu, 12 Jan 2012 15:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01389.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-12 15:47:53 UTC --- > --- Comment #20 from Jonathan Wakely 2012-01-11 17:48:25 UTC --- > (In reply to comment #19) >> I've just tried it with the vendor cxx (first disabling noexcept for C++ >> < 2011), and it also fails with EINVAL. > > Well that's something vaguely positive at least ... the root cause probably > isn't a G++ front-end issue or libstdc++ issue. True, though I still don't understand why it wouldn't work in C++ when a similar C testcase does. >> Given that this is mostly autoconf work, I could give it a try myself if >> I can figure out where best to override the __GTHREAD_MUTEX_INIT >> definition from gthr-default.h/gthr-posix.h. The problem seems to be >> that autoconf results go into , which is included way >> before . > > Yes, that's why I thought of making it depend on some new > _GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT macro set in by autoconf, > rather trying to alter gthr-posix.h > > then e.g. > > class __mutex_base > { > protected: > typedef __gthread_mutex_t __native_type; > > -#ifdef __GTHREAD_MUTEX_INIT > -#if defined __GTHREAD_MUTEX_INIT && !defined > _GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT > __native_type _M_mutex = __GTHREAD_MUTEX_INIT; > > constexpr __mutex_base() noexcept = default; > #else > __native_type _M_mutex; Unfortunately, we still need to provide __GTHREAD_MUTEX_INIT_FUNCTION, and it seems best to do so in gthr-posix.h directly, as is done in gthr-dce.h. Here's the patch I came up with so far. gthr-posix.h has Tru64 UNIX-specific code already, so this isn't much worse that what we already have. __GTHREAD_COND_INIT has the same issue, so it needs the same workaround. The std/mutex change is a hack to avoid In file included from /var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/future:40:0, from /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/30_threads/async/async.cc:27: /var/gcc/regression/trunk/5.1b-gcc/build/alpha-dec-osf5.1b/libstdc++-v3/include/mutex:160:5: error: function 'std::mutex::mutex()' defaulted on its first declaration with an exception-specification that differs from the implicit declaration 'std::mutex::mutex()' and the condition_variable.cc change accounts for the fact that gthr.h only documents __GTHREAD_COND_INIT_FUNCTION (analogous to __GTHREAD_MUTEX_INIT_FUNCTION), not __gthread_cond_init. --- gthr-posix.h.dist Sat Jan 7 00:12:15 2012 +++ gthr-posix.h Thu Jan 12 13:50:52 2012 @@ -62,7 +62,13 @@ typedef struct timespec __gthread_time_t in gthr.h for details. */ #define __GTHREAD_HAS_COND 1 +#ifndef __osf__ #define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER +#define __GTHREAD_COND_INIT PTHREAD_COND_INITIALIZER +#else +#define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function +#define __GTHREAD_COND_INIT_FUNCTION __gthread_cond_init_function +#endif #define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT #if defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER) #define __GTHREAD_RECURSIVE_MUTEX_INIT PTHREAD_RECURSIVE_MUTEX_INITIALIZER @@ -71,7 +77,6 @@ typedef struct timespec __gthread_time_t #else #define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION __gthread_recursive_mutex_init_function #endif -#define __GTHREAD_COND_INIT PTHREAD_COND_INITIALIZER #define __GTHREAD_TIME_INIT {0,0} #if __GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK @@ -730,6 +735,20 @@ __gthread_setspecific (__gthread_key_t _ return __gthrw_(pthread_setspecific) (__key, __ptr); } +static inline void +__gthread_mutex_init_function (__gthread_mutex_t *__mutex) +{ + if (__gthread_active_p ()) + __gthrw_(pthread_mutex_init) (__mutex, NULL); +} + +static inline void +__gthread_cond_init_function (__gthread_cond_t *__cond) +{ + if (__gthread_active_p ()) + __gthrw_(pthread_cond_init) (__cond, NULL); +} + static inline int __gthread_mutex_destroy (__gthread_mutex_t *__mutex) { diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex --- a/libstdc++-v3/include/std/mutex +++ b/libstdc++-v3/include/std/mutex @@ -157,7 +157,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION #ifdef __GTHREAD_MUTEX_INIT constexpr #endif - mutex() noexcept = default; + // mutex() noexcept = default; + mutex() = default; ~mutex() = default; mutex(const mutex&) = delete; diff --git a/libstdc++-v3/src/condition_variable.cc b/libstdc++-v3/src/condition_variable.cc --- a/libstdc++-v3/src/condition_variable.cc +++ b/libstdc++-v3/src/condition_variable.cc @@ -36,10 +36,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION #else condition_variable::condition_variable() noexcept { - int __e = __gthread_cond_init(&_M_cond, 0); - - if (__e) - __throw_system_error(__e); + __GTHREAD_COND_INIT_FUNCTION(&_M_cond); } condition_variable::~condition_variable() noexcept I've rebuilt libstdc++.so with those changes and am currently rerunning the testsuite. The previously failing 30_threads testcases pass now. Would this approach (with a proper fix in instead of the hack) be appropriate from the C++ view? I'll include something along this line in this weekend's bootstrap and see if it causes other problems. Rainer