[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-10 17:01:39 UTC --- --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:22:29 UTC --- Rainer, you should now be able to define _GTHREAD_USE_MUTEX_INIT_FUNC and _GTHREAD_USE_COND_INIT_FUNC (either in gthr-posix.h or os_defines.h or wherever you see fit) and then the tests should pass. I've already posted a patch that does this: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00499.html Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #39 from Rainer Orth ro at gcc dot gnu.org 2012-02-10 18:10:19 UTC --- Author: ro Date: Fri Feb 10 18:10:12 2012 New Revision: 184108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184108 Log: Use __GTHREAD_MUTEX_INIT_FUNCTION on Tru64 UNIX (PR libstdc++/51296) PR libstdc++/51296 * config/os/osf/ctype_base.h, config/os/osf/ctype_configure_char.cc, config/os/osf/ctype_inline.h, config/os/osf/error_constants.h: Copy from config/os/generic. * config/os/osf/os_defines.h: Likewise. (_GTHREAD_USE_MUTEX_INIT_FUNC, _GTHREAD_USE_COND_INIT_FUNC): Define. * configure.host osf*: Use os/osf for os_include_dir. Added: trunk/libstdc++-v3/config/os/osf/ trunk/libstdc++-v3/config/os/osf/ctype_base.h - copied, changed from r184107, trunk/libstdc++-v3/config/os/generic/ctype_base.h trunk/libstdc++-v3/config/os/osf/ctype_configure_char.cc - copied, changed from r184107, trunk/libstdc++-v3/config/os/generic/ctype_configure_char.cc trunk/libstdc++-v3/config/os/osf/ctype_inline.h - copied, changed from r184107, trunk/libstdc++-v3/config/os/generic/ctype_inline.h trunk/libstdc++-v3/config/os/osf/error_constants.h - copied, changed from r184107, trunk/libstdc++-v3/config/os/generic/error_constants.h trunk/libstdc++-v3/config/os/osf/os_defines.h - copied, changed from r184107, trunk/libstdc++-v3/config/os/generic/os_defines.h Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure.host
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg00499.htm ||l Resolution||FIXED --- Comment #40 from Rainer Orth ro at gcc dot gnu.org 2012-02-10 18:13:25 UTC --- Fixed for 4.7.0.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #36 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:19:35 UTC --- Author: redi Date: Tue Feb 7 09:19:27 2012 New Revision: 183955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183955 Log: libgcc/ PR libstdc++/51296 PR libstdc++/51906 * gthr-posix.h: Allow static initializer macros to be disabled. (__gthrw_pthread_cond_init): Define weak reference unconditionally. libstdc++-v3/ PR libstdc++/51296 * include/std/mutex (__mutex_base::~__mutex_base): Declare noexcept. * src/c++11/condition_variable.cc (condition_variable): Use macro for initializer function. PR libstdc++/51906 * config/os/bsd/darwin/os_defines.h: Disable static initializer for recursive mutexes. Modified: trunk/libgcc/ChangeLog trunk/libgcc/gthr-posix.h trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/bsd/darwin/os_defines.h trunk/libstdc++-v3/include/std/mutex trunk/libstdc++-v3/src/c++11/condition_variable.cc
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added AssignedTo|redi at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:22:29 UTC --- Rainer, you should now be able to define _GTHREAD_USE_MUTEX_INIT_FUNC and _GTHREAD_USE_COND_INIT_FUNC (either in gthr-posix.h or os_defines.h or wherever you see fit) and then the tests should pass.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #32 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03 08:50:24 UTC --- Created attachment 26559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26559 proposed patch Since a similar problem exists for darwin11's PTHREAD_RECURSIVE_MUTEX_INITIALIZER this solution is not OSF-specific. This allows config/os/*/os_defines.h to define one or more of: _GTHREAD_USE_MUTEX_INIT_FUNC _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC _GTHREAD_USE_COND_INIT_FUNC which will cause gthr-posix.h to #undef the INIT macro and define an INIT_FUNCTION instead. Would this work here too? You could either add a config/os/osf/os_defines.h file (which would also need the other files in config/os/generic to be copied for osf) or you could just put this in gthr-posix.h #ifdef __osf__ # define _GTHREAD_USE_MUTEX_INIT_FUNC # define _GTHREAD_USE_COND_INIT_FUNC #endif
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03
08:52:17 UTC ---
Oops, this hunk would be needed too
--- a/libstdc++-v3/src/c++11/condition_variable.cc
+++ b/libstdc++-v3/src/c++11/condition_variable.cc
@@ -36,7 +36,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#else
condition_variable::condition_variable() noexcept
{
-int __e = __gthread_cond_init(_M_cond, 0);
+int __e = __GTHREAD_COND_INIT_FUNCTION(_M_cond, 0);
if (__e)
__throw_system_error(__e);
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-03 09:48:15 UTC --- Since a similar problem exists for darwin11's PTHREAD_RECURSIVE_MUTEX_INITIALIZER this solution is not OSF-specific. This allows config/os/*/os_defines.h to define one or more of: _GTHREAD_USE_MUTEX_INIT_FUNC _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC _GTHREAD_USE_COND_INIT_FUNC which will cause gthr-posix.h to #undef the INIT macro and define an INIT_FUNCTION instead. Would this work here too? You could either add a config/os/osf/os_defines.h I guess so. I'll try it with this weekend's bootstrap. file (which would also need the other files in config/os/generic to be copied for osf) or you could just put this in gthr-posix.h #ifdef __osf__ # define _GTHREAD_USE_MUTEX_INIT_FUNC # define _GTHREAD_USE_COND_INIT_FUNC #endif Since that file already has osf-specific code (and the port will go away after 4.7 anyway), I'll probably go this route. Thanks. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-03 09:50:39 UTC --- --- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-03 08:52:17 UTC --- Oops, this hunk would be needed too I know, I already had this in my failed attempt to use __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION and __GTHREAD_COND_INIT_FUNCTION everywhere. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-01 10:23:33 UTC --- --- Comment #29 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31 19:09:00 UTC --- (N.B. that ChangeLog entry cited the wrong PR) I know, I've already corrected the ChangeLog. The wording quoted in comment 25 is a POSIX defect: http://austingroupbugs.net/view.php?id=70#c127 Ok. Unfortunately this doesn't help for Tru64 UNIX, which won't change at this point. I wonder if we could use pthread_mutex_init() only for the threads support instead of globally? Otherwise, we should probably disable it on osf instead of leaving it broken. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #31 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-01 10:58:32 UTC --- (In reply to comment #30) I wonder if we could use pthread_mutex_init() only for the threads support instead of globally? I'll add some extra preprocessor conditions around the mutex init code, so that os_defines.h can force std::mutex to use the init function even if the INIT macro is defined by gthr-posix.h That should also help for PR 51906
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #28 from Rainer Orth ro at gcc dot gnu.org 2012-01-31 11:40:21 UTC --- Author: ro Date: Tue Jan 31 11:40:17 2012 New Revision: 183754 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183754 Log: Link C++ tests with -shared-libgcc (PR libitm/51822) PR libstdc++/51296 * testsuite/libitm.c++/c++.exp (lang_link_flags): Add -shared-libgcc. Correct libgomp references. Modified: trunk/libitm/ChangeLog trunk/libitm/testsuite/libitm.c++/c++.exp
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #29 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-31 19:09:00 UTC --- (N.B. that ChangeLog entry cited the wrong PR) The wording quoted in comment 25 is a POSIX defect: http://austingroupbugs.net/view.php?id=70#c127
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-16 18:58:20 UTC --- --- Comment #25 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-13 10:37:52 UTC --- Nice digging. POSIX does say the INIT macro is for use when the mutex is statically-allocated: In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes that are statically allocated. For most platforms it works fine for automatic variables and in C++ for member variables too. Maybe something scans the BSS segment at startup to find mutexes?! In any case, it looks as though we should definitely use the init function instead of the macro on Tru64. Unfortunately, while my test to do so fixes the 30_threads failures, it introduced tons of failures elsewhere (both libstdc++ and others). I don't fully understand what's happening there, but perhaps we need a fix in libstdc++ instead, especially given that the use of PTHREAD_MUTEX_INITIALIZER at hand isn't standard-conforming. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-16 19:36:49 UTC --- C++11 requires that std::mutex::mutex() is constexpr, so that a global std::mutex will be statically initialized. If that constructor is constexpr it can't call pthread_mutex_init(). But C++11 also requires non-global, non-static mutexes to be possible, so we can't use the PTHREAD_MUTEX_INITIALIZER either. The option we've taken is to ignore the text I quoted in comment 25 and rely on the macro working for non-statically allocated mutexes, which works on most platforms.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-13 10:25:34 UTC --- I've done some more digging and found that the EINVAL error is generated inside libpthread.so, by a function called __thdIsAddrInStack. And in fact, if I make M m static, the test passes. While I do have Tru64 UNIX V5.1 sources, some parts are missing, libpthread sources unfortunately among them, so I cannot determine why this is done or suggest another workaround. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #25 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-13 10:37:52 UTC --- Nice digging. POSIX does say the INIT macro is for use when the mutex is statically-allocated: In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes that are statically allocated. For most platforms it works fine for automatic variables and in C++ for member variables too. Maybe something scans the BSS segment at startup to find mutexes?! In any case, it looks as though we should definitely use the init function instead of the macro on Tru64.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2012-01-12 15:47:53 UTC ---
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 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 bits/c++config.h, which is included way
before bits/gthr.h.
Yes, that's why I thought of making it depend on some new
_GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT macro set in bits/c++config.h 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.distSat Jan 7 00:12:15 2012
+++ gthr-posix.hThu Jan 12 13:50:52 2012
@@ -62,7 +62,13 @@ typedef struct timespec __gthread_time_t
in gthr.h for details. */
#define __GTHREAD_HAS_COND1
+#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
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-12 16:16:30 UTC --- (In reply to comment #21) 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()' Does adding 'noexcept' to ~__mutex_base() make that hack unnecessary? The destructor should be implicitly noexcept, but G++ doesn't implement that yet (PR 50043) so adding 'noexcept' there is ok.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-12 18:17:56 UTC --- Does adding 'noexcept' to ~__mutex_base() make that hack unnecessary? The destructor should be implicitly noexcept, but G++ doesn't implement that yet (PR 50043) so adding 'noexcept' there is ok. Yep, that does the trick. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-11 16:50:09 UTC --- Regarding the remaining failures, it appears to be a front-end issue. Fixing it in the library could be done with an autoconf macro to detect that the testcase in comment 13 works. If that macro isn't defined, use the init function instead of the init macro. I'm not sure if/when I'll be able to work on that.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 17:37:59 UTC --- --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-11 16:50:09 UTC --- Regarding the remaining failures, it appears to be a front-end issue. Fixing it in the library could be done with an autoconf macro to detect that the testcase in comment 13 works. If that macro isn't defined, use the init function instead of the init macro. I've just tried it with the vendor cxx (first disabling noexcept for C++ 2011), and it also fails with EINVAL. I'm not sure if/when I'll be able to work on that. 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 bits/c++config.h, which is included way before bits/gthr.h. If all else failed, one could do so in libgcc/gthr-posix.h. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 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.
I'm not sure if/when I'll be able to work on that.
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 bits/c++config.h, which is included way
before bits/gthr.h.
Yes, that's why I thought of making it depend on some new
_GLIBCXX_BROKEN_GTHREAD_MUTEX_INIT macro set in bits/c++config.h 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;
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 12:42:17 UTC --- --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-26 15:18:40 UTC --- Does this reduced test work with -std=gnu++11 -pthread ? Unfortunately not, I still get 22 : Invalid argument Only if I add an explicit call to pthread_mutex_init does the testcase work. I've no real idea why this happens. pthread_mutex_init(3) states Use the PTHREAD_MUTEX_INITIALIZER macro to statically initialize a mutex without calling this routine. Statically initialized mutexes need not be destroyed using pthread_mutex_destroy(3). Use this macro as follows: pthread_mutex_t mutex= PTHREAD_MUTEX_INITIALIZER Only normal mutexes can be statically initialized. While I do have Tru64 UNIX sources, libpthread is only partially included and the implementation of pthread_mutex_lock is missing. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-28
14:22:24 UTC ---
(In reply to comment #14)
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-26
15:18:40 UTC ---
Does this reduced test work with -std=gnu++11 -pthread ?
Unfortunately not, I still get
22 : Invalid argument
IMHO it's fortunate since it's not just problem in the std::mutex code ;)
Only if I add an explicit call to pthread_mutex_init does the testcase
work.
Very strange, especially since the definitions you gave in comment 9 don't seem
to do anything complicated.
Does this work?
#include stdio.h
#include string.h
#include pthread.h
struct M {
pthread_mutex_t m;
M() noexcept {
pthread_mutex_t tmp = PTHREAD_MUTEX_INITIALIZER;
m = tmp;
}
};
int main()
{
M m;
int e = pthread_mutex_lock(m.m);
if (e)
printf(%d : %s\n, e, strerror(e));
return e;
}
If that works, we might be able to fix it using fixincludes (similar to PR
50982 comment 32)
Otherwise I suppose we must not define __GTHREAD_MUTEX_INIT on Tru64, causing
std::mutex to use the init function instead.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 14:34:38 UTC --- Does this work? No, I still get EINVAL. Otherwise I suppose we must not define __GTHREAD_MUTEX_INIT on Tru64, causing std::mutex to use the init function instead. The strange thing is that is seems to have worked so far without issues, e.g. in emutls.c. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-28 14:40:21 UTC --- (In reply to comment #16) The strange thing is that is seems to have worked so far without issues, e.g. in emutls.c. and in libstdc++-v3/include/ext/concurrence.h maybe the difference is -std=c++11
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-26 15:15:26 UTC --- Author: redi Date: Sat Nov 26 15:15:22 2011 New Revision: 181740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181740 Log: PR libstdc++/51296 * testsuite/30_threads/thread/native_handle/typesizes.cc: Do not run on alpha*-*-osf*. * testsuite/30_threads/future/cons/constexpr.cc: Disable debug symbols. * testsuite/30_threads/shared_future/cons/constexpr.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/30_threads/future/cons/constexpr.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/constexpr.cc trunk/libstdc++-v3/testsuite/30_threads/thread/native_handle/typesizes.cc
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-26
15:18:40 UTC ---
Does this reduced test work with -std=gnu++11 -pthread ?
#include stdio.h
#include string.h
#include pthread.h
struct M {
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
constexpr M() noexcept = default;
};
int main()
{
M m;
int e = pthread_mutex_lock(m.m);
if (e)
printf(%d : %s\n, e, strerror(e));
return e;
}
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:04:26 UTC --- --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 19:26:23 UTC --- (In reply to comment #0) FAIL: 30_threads/thread/native_handle/typesizes.cc execution test This one should definitely not run on Tru64, disabling that is pre-approved. Ok, thanks. Is -pthread all that's needed for this platform? Yes, should be. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:06:10 UTC --- --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 20:30:43 UTC --- What does this program do, compiled with -std=c++11 -pthread ? I get Assertion failed: false, file thread.cc, line 21 IOT/Abort trap Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:12:25 UTC --- --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:06:10 UTC --- --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 20:30:43 UTC --- What does this program do, compiled with -std=c++11 -pthread ? I get Assertion failed: false, file thread.cc, line 21 IOT/Abort trap I've run it under gdb (which has massive problems on that platform right now), and it seems that in alpha-dec-osf5.1b/libstdc++-v3/include/mutex:172 gthread_mutex_lock(_M_mutex) returns EINVAL. Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-25 14:46:07 UTC --- Thanks for the info - that error implies the mutex was not correctly initialized. What are these macros defined to (if defined)? __GTHREAD_MUTEX_INIT __GTHREAD_MUTEX_INIT __GTHREAD_MUTEX_INIT_FUNCTION FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIvEC2Ev FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIiEC2Ev FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIvEC2Ev FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIiEC2Ev These errors indicate a front-end problem (failing to do static init for the constexpr constructor) or a bug in the testcase.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-25 14:46:37 UTC --- (In reply to comment #7) __GTHREAD_MUTEX_INIT __GTHREAD_MUTEX_INIT sorry, ignore the double-paste ;)
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-11-25 14:57:24 UTC ---
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-25
14:46:07 UTC ---
Thanks for the info - that error implies the mutex was not correctly
initialized.
What are these macros defined to (if defined)?
__GTHREAD_MUTEX_INIT
__GTHREAD_MUTEX_INIT
__GTHREAD_MUTEX_INIT_FUNCTION
With -g3 -save-temps, I find
#define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
and
#define PTHREAD_MUTEX_INITIALIZER {_PTHREAD_MSTATE_CONFIG, _PTHREAD_MVALID |
_PTHREAD_MVF_STA}
#define _PTHREAD_MSTATE_CONFIG 0x0020
#define _PTHREAD_MVALID (0x05bcafe1L)
#define _PTHREAD_MVF_STA 0x0800L
FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not
_ZNSt6futureIvEC2Ev
FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not
_ZNSt6futureIiEC2Ev
FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not
_ZNSt13shared_futureIvEC2Ev
FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not
_ZNSt13shared_futureIiEC2Ev
These errors indicate a front-end problem (failing to do static init for the
constexpr constructor) or a bug in the testcase.
I think it's a testcase bug: for the first case, grep reveals
#.stabsfuture:Tt4100=s16!1,020,4071;__base_ctor
::4102=#4100,3,4103=*4100,4104=4105=k4106=4072,3;:_ZNSt6futureIvEC2ERKSt10shared_ptrINSt13__future_base11_State_baseEE;0A.;__comp_ctor
::4102:_ZNSt6futureIvEC1ERKSt10shared_ptrINSt13__future_base11_State_baseEE;0A.;__base_ctor
::4107=#4100,3,4103,3;:_ZNSt6futureIvEC2Ev;2A.;__comp_ctor
::4107:_ZNSt6futureIvEC1Ev;2A.;__base_ctor
::4108=#4100,3,4103,4109=4110=4100,3;:_ZNSt6futureIvEC2EOS0_;2A.;__comp_ctor
::4108:_ZNSt6futureIvEC1EOS0_;2A.;__base_ctor
::4111=#4100,3,4103,4112=4113=k4110,3;:_ZNSt6futureIvEC2ERKS0_;2A.;__comp_ctor
::4111:_ZNSt6futureIvEC1ERKS0_;2A.;operator=::4114=#4100,4115=4110,4103,4112,3;:_ZNSt6futureIvEaSERKS0_;2A.4116=#4100,4115,4103,4109,3;:_ZNSt6futureIvEaSEOS0_;2A.;get::4117=#4100,3,4103,3;:_ZNSt6futureIvE3getEv;2A.;share::4118=#4100,4095,4103,3;:_ZNSt6futureIvE5shareEv;2A.;;,128,0,727,0
With -g0, grep finds nothing else.
Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-25 15:17:09 UTC --- ah so the scan-assembler test is finding the stabs info, not actually a call to the constructor
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-11-25 15:55:36 UTC ---
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-25
15:17:09 UTC ---
ah so the scan-assembler test is finding the stabs info, not actually a call
to
the constructor
Right. I see we already have a few -g0's in constexpr.cc tests:
libstdc++-v3/testsuite/20_util/unique_ptr/cons/constexpr.cc:// { dg-options
-std=gnu++0x -fno-inline -save-temps -g0 }
libstdc++-v3/testsuite/20_util/shared_ptr/cons/constexpr.cc:// { dg-options
-std=gnu++0x -fno-inline -save-temps -g0 }
libstdc++-v3/testsuite/20_util/weak_ptr/cons/constexpr.cc:// { dg-options
-std=gnu++0x -fno-inline -save-temps -g0 }
libstdc++-v3/testsuite/20_util/enable_shared_from_this/cons/constexpr.cc:// {
dg-options -std=gnu++0x -fno-inline -save-temps -g0 }
This was done for PR libstdc++/46869, the same issue.
Rainer
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-24 CC|redi at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 18:53:29 UTC --- The point of that change was to enable C++11 threading on platforms that support Pthreads without the Timeouts option, so the fact the tests now run instead of being UNSUPPORTED is intended. We could always take alpha*-*-osf* out of the target list, but I'll try to figure out how to make them work on Tru64
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24 19:26:23 UTC --- (In reply to comment #0) FAIL: 30_threads/thread/native_handle/typesizes.cc execution test This one should definitely not run on Tru64, disabling that is pre-approved. Is -pthread all that's needed for this platform?
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-24
20:30:43 UTC ---
What does this program do, compiled with -std=c++11 -pthread ?
#include mutex
#include system_error
#include assert.h
#define VERIFY assert
int main()
{
typedef std::mutex mutex_type;
typedef std::unique_lockmutex_type lock_type;
try
{
mutex_type m;
lock_type lock(m);
VERIFY( lock.owns_lock() );
VERIFY( (bool)lock );
}
catch (const std::system_error e)
{
VERIFY( false );
}
catch (...)
{
VERIFY( false );
}
return 0;
}
