http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Rainer Orth changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #39 from Rainer Orth 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=gcc&view=rev&rev=184108
Log:
Use __GTHREAD_MUTEX_INIT_FUNCTION on Tru64 UNIX (PR lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-10 17:01:39 UTC ---
> --- Comment #37 from Jonathan Wakely 2012-02-07
> 09:22:29 UTC ---
> Rainer, you should now be able to define _GTHREAD_USE_MUTEX_INIT_FUNC and
> _GTHREAD_USE_C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Jonathan Wakely changed:
What|Removed |Added
AssignedTo|redi at gcc dot gnu.org |ro at gcc dot gnu.org
--- Comment #37 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #36 from Jonathan Wakely 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=gcc&view=rev&rev=183955
Log:
libgcc/
PR libstdc++/51296
PR libstdc++/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-03 09:50:39 UTC ---
> --- Comment #33 from Jonathan Wakely 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 us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #34 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #33 from Jonathan Wakely 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_NAMESPAC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #32 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.7.0
--- Comment #31 from Jonathan Wak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-01 10:23:33 UTC ---
> --- Comment #29 from Jonathan Wakely 2012-01-31
> 19:09:00 UTC ---
> (N.B. that ChangeLog entry cited the wrong PR)
I know, I've already corrected the ChangeL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #29 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #28 from Rainer Orth 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=gcc&view=rev&rev=183754
Log:
Link C++ tests with -shared-libgcc (PR libitm/51822)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #27 from Jonathan Wakely 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()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-16 18:58:20 UTC ---
> --- Comment #25 from Jonathan Wakely 2012-01-13
> 10:37:52 UTC ---
> Nice digging. POSIX does say the INIT macro is for use when the mutex is
> statically-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #25 from Jonathan Wakely 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_IN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #24 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #23 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #22 from Jonathan Wakely 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/futu
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 noexc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- 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 positiv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-11 17:37:59 UTC ---
> --- Comment #18 from Jonathan Wakely 2012-01-11
> 16:50:09 UTC ---
> Regarding the remaining failures, it appears to be a front-end issue. Fixing
> it
> in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #18 from Jonathan Wakely 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #17 from Jonathan Wakely 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 di
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #16 from 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 i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #15 from Jonathan Wakely 2011-11-28
14:22:24 UTC ---
(In reply to comment #14)
> > --- Comment #13 from Jonathan Wakely 2011-11-26
> > 15:18:40 UTC ---
> > Does this reduced test work with -std=gnu++11 -pthread ?
>
> Unfortunately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 12:42:17 UTC ---
> --- Comment #13 from Jonathan Wakely 2011-11-26
> 15:18:40 UTC ---
> Does this reduced test work with -std=gnu++11 -pthread ?
Unfortunately not, I still get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #13 from Jonathan Wakely 2011-11-26
15:18:40 UTC ---
Does this reduced test work with -std=gnu++11 -pthread ?
#include
#include
#include
struct M {
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
constexpr M() noexcept = defau
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #12 from Jonathan Wakely 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=gcc&view=rev&rev=181740
Log:
PR libstdc++/51296
* testsuite/30_threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 15:55:36 UTC ---
> --- Comment #10 from Jonathan Wakely 2011-11-25
> 15:17:09 UTC ---
> ah so the scan-assembler test is finding the stabs info, not actually a call
> to
> the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #10 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:57:24 UTC ---
> --- Comment #7 from Jonathan Wakely 2011-11-25
> 14:46:07 UTC ---
> Thanks for the info - that error implies the mutex was not correctly
> initialized.
>
> What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #8 from Jonathan Wakely 2011-11-25
14:46:37 UTC ---
(In reply to comment #7)
> __GTHREAD_MUTEX_INIT
> __GTHREAD_MUTEX_INIT
sorry, ignore the double-paste ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #7 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:12:25 UTC ---
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> 2011-11-25 14:06:10 UTC ---
>> --- Comment #3 from Jonathan Wakely 2011-11-24
>> 20:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:06:10 UTC ---
> --- Comment #3 from Jonathan Wakely 2011-11-24
> 20:30:43 UTC ---
> What does this program do, compiled with -std=c++11 -pthread ?
I get
Assertion failed: fal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-25 14:04:26 UTC ---
> --- Comment #2 from Jonathan Wakely 2011-11-24
> 19:26:23 UTC ---
> (In reply to comment #0)
>> FAIL: 30_threads/thread/native_handle/typesizes.cc execution tes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #3 from Jonathan Wakely 2011-11-24
20:30:43 UTC ---
What does this program do, compiled with -std=c++11 -pthread ?
#include
#include
#include
#define VERIFY assert
int main()
{
typedef std::mutex mutex_type;
typedef std::uniq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #2 from Jonathan Wakely 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 -pthrea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
40 matches
Mail list logo
