Web lists-archives.com

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




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