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
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.
MinGW-users mailing list

This list observes the Etiquette found at 
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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe