On 11/15/22 15:17, LIU Hao wrote:
I think that when there is a real bug, we should fix it. As for
standard themselves, I think that C/C++ standards are important.
Praising POSIX-alike standards for mingw-w64, who's CRT is a wrapper
around Windows system CRT, seems a bit misplaced for me. Using
在 2022-11-15 04:50, Jacek Caban 写道:
I was short on spare time lately, my apologies. I was planning to learn your code to have more
insightful comments, but it requires non-trivial amount of time that I couldn't allocate. Anyway, I
don't think there is any procrastination, your threading model is
022 15:52
To: LIU Hao<mailto:lh_mo...@126.com>;
mingw-w64-public@lists.sourceforge.net<mailto:mingw-w64-public@lists.sourceforge.net>;
JonY<mailto:jo...@users.sourceforge.net>
Subject: Re: [Mingw-w64-public] Adding a new thread model to GCC
On 11/14/22 09:57, LIU Hao wrote:
> 在
et>
Subject: Re: [Mingw-w64-public] Adding a new thread model to GCC
On 11/14/22 09:57, LIU Hao wrote:
> 在 2022/10/25 04:50, Jacek Caban 写道:
>>
>> This also may be supported in existing threading models. Overflow is
>> trivial to fix by waiting in a loop. (There are othe
On 11/14/22 09:57, LIU Hao wrote:
在 2022/10/25 04:50, Jacek Caban 写道:
This also may be supported in existing threading models. Overflow is
trivial to fix by waiting in a loop. (There are other reasons why OS
support for absolute timeout is slightly better, but the price of
this design decisi
在 2022/10/25 04:50, Jacek Caban 写道:
This also may be supported in existing threading models. Overflow is trivial to fix by waiting in a
loop. (There are other reasons why OS support for absolute timeout is slightly better, but the price
of this design decision makes it questionable. I plan to
在 2022/10/25 04:50, Jacek Caban 写道:
Those 4 points describes problems that you solve in the new threading model, but there is no reason
they can't be fixed for existing threading models. In fact, ideally they would be fixed for all
threading models. Except now we need to worry about one more t
On 10/24/22 05:40, LIU Hao via Gcc-patches wrote:
在 2022/10/21 20:34, i.nix...@autistici.org 写道:
got it...
anyway it seems logical to me the way I proposed :)
Below is a message forwarded from mingw-w64-public, elaborating the
necessity of a new thread model.
As there are objections from
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
On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
> SHLIB_PTHREAD_CFLAG = -pthread
> SHLIB_PTHREAD_LDFLAG = -Wl,-lpthrea
On 17 April 2016 at 17:56, lh_mouse wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_t
I have added a thread model and added its corresponding header files. But it
failed the linker.
The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
SHLIB_PTHREAD_CFLAG = -pthread
SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
I copied the file to 'gcc/libgcc/config/i386/t-ming
A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
documented in gthr.h.
I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
Specifically, here are the two questions:
0) Should __gthread_time_t be a struct or a plain integral type?
The 'struct
step bootstrap of GCC and test whether it is working.
--
Best regards,
lh_mouse
2016-04-15
-
发件人：Yuta Nakai
发送日期：2016-04-15 22:09
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] Adding a new thread model to GCC
W
What I mean is that i want the patch "to use your new thread model".
How can I build gcc with mcfgthread?
From: lh_mouse
Sent: 15 April 2016 23:01
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Adding a new thread mo
16-04-15 19:59
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] Adding a new thread model to GCC
Hi lh_mouse,
Where can I get a patch(es) for gcc in order to use your new thread model?
From: lh_mouse
Sent: Wednesday, April 13, 20
Hi lh_mouse,
Where can I get a patch(es) for gcc in order to use your new thread model?
From: lh_mouse
Sent: Wednesday, April 13, 2016 18:17
To: gcc; mingw-w64-public
Subject: [Mingw-w64-public] Adding a new thread model to GCC
Hi all,
The '
he current system
time that the problem is.
--
Best regards,
lh_mouse
2016-04-15
-
发件人：Adrien Nader
发送日期：2016-04-14 19:42
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Adding a new thread model to GCC
On
On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being
> compatible with very old Windows versions, also having a number of drawbacks:
> 0) its implementation is very inefficient, and
> 1) its mutexes and cond
On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8
> and later.
Yes. On Windows 8, given
On Thu, Apr 14, 2016, lh_mouse wrote:
> C++0x threading APIs are currently unimplemented.
>
> It is only because gthr.h is so obscure about __gthred_time_t.
> It doesn't say anything about whether __gthread_time_t should be a struct
> (like struct timespec) or a plain integer or even a floating p
Best regards,
lh_mouse
2016-04-14
-
发件人：Ruben Van Boxem
发送日期：2016-04-14 18:17
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：Re: [Mingw-w64-public] Adding a new thread model to GCC
I'd really really really suggest just using --enab
eforge.net
抄送：
主题：Re: [Mingw-w64-public] Adding a new thread model to GCC
I'd really really really suggest just using --enable-threads=windows or
something, and implement them using somthing compatible to the windows
runtime if at all possible. This is available on Windows 7+ and seems as
re
Maybe we misunderstand each other?
I understood your question as a proposal to make -D_WIN32_WINNT=xy imply
also implicitly some --enable-threads=xy. That would be a problem, because
semantics of -D_WIN32_WINNT=xy should imho have no implication on chosen
run time, but just on what's made availab
I'd really really really suggest just using --enable-threads=windows or
something, and implement them using somthing compatible to the windows
runtime if at all possible. This is available on Windows 7+ and seems as
reasonable as anything.
If there are better routines in e.g. Windows 8 or 10, it w
If we use --enable-threads=win32-win7 , the result gcc running on and
target to win7 or later looks reasonable.
On Thu, Apr 14, 2016 at 2:34 PM, Martin Mitáš wrote:
>
>
> Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
>> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>
Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>
> --enable-threads=win32-vista
> --enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
> --enable-threads=win32-win8 // Windows 8 and Windows Server 2012
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
Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
--enable-threads=win32-vista
--enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
--enable-threads=win32-win8 // Windows 8 and Windows Server 2012
--enable-threads=win32-win8.1 // Windows 8.1 and Windows Ser
Yes I learnt those *ByAddress* functions a few months ago and was shocked that
Microsoft had plagiarized futex from Linux.
As you have pointed out already, those APIs are only available on Windows 8
and later.
If we need fuex semantics on Windows 7 and earlier, we must simulate it.
However, sin
Thanks for your reply. :>
However I am still having problems building GCC. (Yesterday stage 1 was ok, but
during stage 2 autoconf just failed to find any standard headers. I am still
struggling with it.)
Once I build gcc successfully I will have a look at that configure.ac. Wish me
luck. (btw t
On 13 April 2016 at 10:17, lh_mouse wrote:
> Hi all,
>
> The 'win32' thread model of gcc has been there since long long ago, being
> compatible with very old Windows versions, also having a number of drawbacks:
> 0) its implementation is very inefficient, and
> 1) its mutexes and condition var
Hi all,
The 'win32' thread model of gcc has been there since long long ago, being
compatible with very old Windows versions, also having a number of drawbacks:
0) its implementation is very inefficient, and
1) its mutexes and condition variables require dynamic initialization and are
unusabl
39 matches
Mail list logo
