Web lists-archives.com

Re: [Mingw-users] GCC-4.9.3 is now our current release




Yep thats the one :) the patch in question goes a little futher and 
checks for pthreads-w32 but else the idea is the same.
Ill have a look at the differences might be your version is better.

Still having random problems with thread lockup with pthreads-w32,
at O3 optimiaztion it would lock up every time, at O2 it does less so 
but it still happens, not sure anything more can be done with compiler 
switches so it must be a regression somewhere in the library.

latest winpthreads works flawlessly, though it needs a little patching 
for compatibility with mingw.org.
Sadly i dont think the mingw.org devs will ever accept that library even 
if i can stand in for gcc not even having to rely on it besides for 
building gcc itself.

patch against thread here

diff -urN gcc-5.3.0.old/libstdc++-v3/include/std/thread 
gcc-5.3.0/libstdc++-v3/include/std/thread
--- gcc-5.3.0.old/libstdc++-v3/include/std/thread    2015-03-26 
20:59:08.000000000 +0100
+++ gcc-5.3.0/libstdc++-v3/include/std/thread    2016-03-15 
23:05:54.288398100 +0100
@@ -83,9 +83,26 @@
        operator==(thread::id __x, thread::id __y) noexcept
        { return __gthread_equal(__x._M_thread, __y._M_thread); }

+      template<typename _Tp, typename = __void_t<>>
+    struct __less
+    {
+      static bool
+      _S_less(const _Tp& __x, const _Tp& __y)
+      { return _GLIBCXX_THREAD_ID_LESS(__x, __y); }
+    };
+
+      template<typename _Tp>
+    struct __less<_Tp, __void_t<decltype(std::declval<const _Tp&>()
+                         < std::declval<const _Tp&>())>>
+    {
+      static bool
+      _S_less(const _Tp& __x, const _Tp& __y)
+      { return __x < __y; }
+    };
+
        friend bool
        operator<(thread::id __x, thread::id __y) noexcept
-      { return __x._M_thread < __y._M_thread; }
+      {    return __less<native_handle_type>::_S_less(__x._M_thread, 
__y._M_thread); }

        template<class _CharT, class _Traits>
      friend basic_ostream<_CharT, _Traits>&

and the check for pthreads-w32  here

diff -urN gcc-5.3.0.old/libstdc++-v3/config/os/mingw32/os_defines.h 
gcc-5.3.0/libstdc++-v3/config/os/mingw32/os_defines.h
--- gcc-5.3.0.old/libstdc++-v3/config/os/mingw32/os_defines.h 2015-01-05 
13:33:28.000000000 +0100
+++ gcc-5.3.0/libstdc++-v3/config/os/mingw32/os_defines.h 2016-03-15 
23:02:55.988148500 +0100
@@ -78,4 +78,11 @@
  // See libstdc++/59807
  #define _GTHREAD_USE_MUTEX_INIT_FUNC 1

+#ifdef PTW32_VERSION
+// See libstdc++/67114
+# ifndef _GLIBCXX_THREAD_ID_LESS
+#  define _GLIBCXX_THREAD_ID_LESS(X, Y) ((X).x < (Y).x)
+# endif
+#endif
+

Regards Ralph Engels.

Den 16-03-2016 kl. 15:35 skrev K. Frank:
> Hi Ralph!
>
> On Wed, Mar 16, 2016 at 2:01 AM, ralph engels <ralphengels@xxxxxxxxx> wrote:
>> Its a nasty hack indeed :) atm im looking at a small patch against
>> libstdc++ instead,
>> since thats where most of  the problem lies using pthreads-w32 (< no
>> such operator in thread).
> I assume that by "thread" you mean the c++-header file thread that
> implements std::thread, and that operator< for thread::id won't compile
> because operator< is not defined for __gthread_t (which is no longer
> a pointer).
>
> I was able to patch a version of thread (over five years old) by implementing
> operator< explicitly:
>
>        // friend bool
>        // operator<(thread::id __x, thread::id __y)
>        // { return __x._M_thread < __y._M_thread; }
>
>        // implement operator< explicitly in terms of the internals of
>        // pthreads-win32's ptw32_handle_t so that std::thread can use pthreads
>
>        friend bool
>        operator<(thread::id __x, thread::id __y)
>        { return ( (__x._M_thread.p < __y._M_thread.p)  ||  (
> (__x._M_thread.p == __y._M_thread.p) && (__x._M_thread.x <
> __y._M_thread.x) ) ); }
>
>
> I don't really know where and how operator< is used, but this implementation
> worked for me.
>
> Note, oddly, that operator== is defined (in my copy of thread) in terms of
> __gthread_equal, and that is implemented in terms of the members of
> __gthread_t struct.  I imagine that it's just corner-cutting that a
> __gthread_less
> isn't defined / implemented and used to implement operator<.
>
> The cleanest approach probably would be to introduce a __gthread_less
> (basically the code in the body of my patched operator<, above), and
> use it to implement operator<, but implementing operator< directly, as
> above, worked for me.
>
>
> Good luck.
>
>
> K. Frank
>
>
>> ...
>> Den 16-03-2016 kl. 03:51 skrev K. Frank:
>>> Hello Ralph!
>>>
>>> On Tue, Mar 15, 2016 at 12:57 PM, ralph engels <ralphengels@xxxxxxxxx> wrote:
>>>> Needed some changes but i can report that gcc now builds with
>>>> pthreads-w32 again.
>>>>
>>>> Three things that needed changes.
>>>> ...
>>>> pthread_t is cast from a struct but gcc expects it to be of scalar
>>>> integer type, again restrict to build time and cast pthread_t to
>>>> unsigned int for release
>>>> ...
>>> ...
>>> Based on old (about five years ago) pthreads-win32 and mingw gcc
>>> 4.6, I see a problem with your approach, and I'm surprised it works.
>>>
>>> pthread_t maps (is typedef'ed) to ptw32_handle_t which is a struct:
>>> ...
>>> I just don't see how you can cast from ptw32_handle_t (a two-member
>>> struct) to an unsigned int, and not break all kinds of stuff.
>>> ...
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@xxxxxxxxxxxxxxxxxxxxx
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe