One more question about block-scoped static objects:
>From compiled assembly I have learned that GCC uses a 64-bit integer guard to
>ensure once-initialization of static objects with block scopes.
Code in gcc/libstdc++-v3/libsupc++/guard.cc uses a global mutex to protect
multiple threads from ra
Thanks to ktietz, Elieux, mingwandroid (via IRC) and jwakely (via mail),
the integration of mcfgthread and gcc has been accomplished.
This 9000- patch applies to the gcc-5-branch after all other patches from
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc-git are
applied.
Aft
>>> If the current code assumes a struct and the Windows API calls need an
>>> integer then either the existing code needs to be made more flexible,
>>> or you need to define it as a struct and then convert to an integer
>>> inside your new gthread wrapper functions.
>>
>> The Windows APIs involved
On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is referenced in
>> gcc/libstdc++-v3/include/
On 18 April 2016 at 10:18, lh_mouse wrote:
>> I don't see why it has to be a struct, it just has to be suitable as
>> an argument to the relevant __gthread functions.
>
> The type __gthread_time_t is referenced in
> gcc/libstdc++-v3/include/std/mutex:157
> __gthread_time_t __ts = {
>
> I don't see why it has to be a struct, it just has to be suitable as
> an argument to the relevant __gthread functions.
The type __gthread_time_t is referenced in
gcc/libstdc++-v3/include/std/mutex:157
__gthread_time_t __ts = {
static_cast(__s.time_since_epoch().count()),
Oh I missed the build-in specs in gcc/config/i386/mingw32.h and it was lack of
-lmcfgthread in it that caused the failure. Stage 1 seemed ok.
Already hacked that. Rebuilding.
Apologize for that.
--
Best regards,
lh_mouse
2016-04-18
And don't forget that --enable-threads=win32 also enables emulated TLS, which
is completely unnecessary if we have some kind of TLS support.
Because pthread_key_create() requires a destructor, TLS must still be emulated
on x86 because there is no native support. The fiber local storage (FLS) API
