Re: Adding a new thread model to GCC

2023-01-09 Thread Eric Botcazou via Gcc-patches 
> fixed now.
> bootstrapped successfully!

Thanks for fixing it.  Another way out is to hide the Win32 API by defining  
__GTHREAD_HIDE_WIN32API like libstdc++ does in its header files.

-- 
Eric Botcazou

Re: Adding a new thread model to GCC

2022-12-24 Thread Jonathan Yong via Gcc-patches 

On 12/24/22 21:22, i.nix...@autistici.org wrote:

On 2022-12-24 15:57, i.nix...@autistici.org wrote:

On 2022-12-24 15:42, i.nix...@autistici.org wrote:


fixed and tested.

Jonathan Yong, could you please apply the attached patch too?



kings regards!


oh no...

please wait.


fixed now.
bootstrapped successfully!


Jonathan Yong, could you please apply the attached patch too?



best!


Done, pushed to master, thanks.

Re: Adding a new thread model to GCC

2022-12-24 Thread i.nixman--- via Gcc-patches 

On 2022-12-24 15:57, i.nix...@autistici.org wrote:

On 2022-12-24 15:42, i.nix...@autistici.org wrote:


fixed and tested.

Jonathan Yong, could you please apply the attached patch too?



kings regards!


oh no...

please wait.


fixed now.
bootstrapped successfully!


Jonathan Yong, could you please apply the attached patch too?



best!
diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 9485dd50bf9..146357fa436 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -93,8 +93,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #endif
 #define WIN32_LEAN_AND_MEAN
 #include 
-/* Now undef the windows BOOL.  */
+/* Now undef the windows BOOL and CC_NONE */
 #undef BOOL
+#undef CC_NONE
 
 /* Key structure for maintaining thread specific storage */
 static DWORD __gthread_objc_data_tls = TLS_OUT_OF_INDEXES;
@@ -604,6 +605,7 @@ __gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex,
 
 #define WIN32_LEAN_AND_MEAN
 #include 
+#undef CC_NONE
 
 __GTHREAD_WIN32_INLINE int
 __gthread_detach (__gthread_t __thr)

Re: Adding a new thread model to GCC

2022-12-24 Thread i.nixman--- via Gcc-patches 

On 2022-12-24 15:42, i.nix...@autistici.org wrote:


fixed and tested.

Jonathan Yong, could you please apply the attached patch too?



kings regards!


oh no...

please wait.

Re: Adding a new thread model to GCC

2022-12-24 Thread i.nixman--- via Gcc-patches 

On 2022-12-24 13:50, i.nix...@autistici.org wrote:

On 2022-12-24 05:58, NightStrike wrote:


I think this might have broken fortran.  I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:

In file included from /tmp/rtmingw/mingw/include/windows.h:71,
 from ../libgcc/gthr-default.h:606,
 from ../../../libgfortran/../libgcc/gthr.h:148,
 from ../../../libgfortran/io/io.h:33,
 from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
  298 | { CC_LIST, CC_FORTRAN, CC_NONE,
  |^~~



yes, you are right!
this is because the `CC_NONE` was previously defined in `wingdi.h` as
`#define CC_NONE 0`

thinking...


fixed and tested.

Jonathan Yong, could you please apply the attached patch too?



kings regards!
diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 9485dd50bf9..2b5b782c894 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -93,8 +93,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #endif
 #define WIN32_LEAN_AND_MEAN
 #include 
-/* Now undef the windows BOOL.  */
+/* Now undef the windows BOOL and CC_NONE */
 #undef BOOL
+#undef CC_NONE
 
 /* Key structure for maintaining thread specific storage */
 static DWORD __gthread_objc_data_tls = TLS_OUT_OF_INDEXES;

Re: Adding a new thread model to GCC

2022-12-24 Thread i.nixman--- via Gcc-patches 

On 2022-12-24 05:58, NightStrike wrote:


I think this might have broken fortran.  I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:

In file included from /tmp/rtmingw/mingw/include/windows.h:71,
 from ../libgcc/gthr-default.h:606,
 from ../../../libgfortran/../libgcc/gthr.h:148,
 from ../../../libgfortran/io/io.h:33,
 from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
  298 | { CC_LIST, CC_FORTRAN, CC_NONE,
  |^~~



yes, you are right!
this is because the `CC_NONE` was previously defined in `wingdi.h` as 
`#define CC_NONE 0`


thinking...

Re: Adding a new thread model to GCC

2022-12-23 Thread i.nixman--- via Gcc-patches 

On 2022-12-24 05:58, NightStrike wrote:


I think this might have broken fortran.  I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:

In file included from /tmp/rtmingw/mingw/include/windows.h:71,
 from ../libgcc/gthr-default.h:606,
 from ../../../libgfortran/../libgcc/gthr.h:148,
 from ../../../libgfortran/io/io.h:33,
 from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
  298 | { CC_LIST, CC_FORTRAN, CC_NONE,
  |^~~



hmm...

I don't remember if I specified `fortran` in `--enable-language` in my 
test builds...

will try to build again now...

Re: Adding a new thread model to GCC

2022-12-23 Thread i.nixman--- via Gcc-patches 

On 2022-12-23 23:59, Jonathan Yong wrote:


Done, pushed to master branch. Thanks Eric.



thank you Jonathan!

Re: Adding a new thread model to GCC

2022-12-23 Thread NightStrike via Gcc-patches 
On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
 wrote:
>
> On 12/22/22 12:28, i.nix...@autistici.org wrote:
> > On 2022-12-22 12:21, Jonathan Yong wrote:
> >
> > hello,
> >
> >> On 12/16/22 19:20, Eric Botcazou wrote:
>  The libgcc parts look reasonable to me, but I can't approve them.
>  Maybe Jonathan Yong can approve those parts as mingw-w64 target
>  maintainer, or maybe a libgcc approver can do so.
> >>>
> >>> OK.
> >>>
>  The libstdc++ parts are OK for trunk. IIUC they could go in
>  separately, they just wouldn't be very much use without the libgcc
>  changes.
> >>>
> >>> Sure thing.
> >>>
> >>
> >> Ping, need help to commit it?
> >
> > yes, it would be great if we can merge the path into gcc-13!
> >
> > I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows,
> > with msvcrt and ucrt runtime - works as it should!
> >
> > Eric ^^^
> >
> >
> >
> > best!
>
> Done, pushed to master branch. Thanks Eric.


I think this might have broken fortran.  I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:

In file included from /tmp/rtmingw/mingw/include/windows.h:71,
 from ../libgcc/gthr-default.h:606,
 from ../../../libgfortran/../libgcc/gthr.h:148,
 from ../../../libgfortran/io/io.h:33,
 from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
  298 | { CC_LIST, CC_FORTRAN, CC_NONE,
  |^~~

Re: Adding a new thread model to GCC

2022-12-23 Thread Jonathan Yong via Gcc-patches 

On 12/22/22 12:28, i.nix...@autistici.org wrote:

On 2022-12-22 12:21, Jonathan Yong wrote:

hello,


On 12/16/22 19:20, Eric Botcazou wrote:

The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a libgcc approver can do so.


OK.


The libstdc++ parts are OK for trunk. IIUC they could go in
separately, they just wouldn't be very much use without the libgcc
changes.


Sure thing.



Ping, need help to commit it?


yes, it would be great if we can merge the path into gcc-13!

I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows, 
with msvcrt and ucrt runtime - works as it should!


Eric ^^^



best!


Done, pushed to master branch. Thanks Eric.



OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-12-22 Thread i.nixman--- via Gcc-patches 

On 2022-12-22 12:21, Jonathan Yong wrote:

hello,


On 12/16/22 19:20, Eric Botcazou wrote:

The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a libgcc approver can do so.


OK.


The libstdc++ parts are OK for trunk. IIUC they could go in
separately, they just wouldn't be very much use without the libgcc
changes.


Sure thing.



Ping, need help to commit it?


yes, it would be great if we can merge the path into gcc-13!

I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows, 
with msvcrt and ucrt runtime - works as it should!


Eric ^^^



best!

Re: Adding a new thread model to GCC

2022-12-22 Thread Jonathan Yong via Gcc-patches 

On 12/16/22 19:20, Eric Botcazou wrote:

The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a libgcc approver can do so.


OK.


The libstdc++ parts are OK for trunk. IIUC they could go in
separately, they just wouldn't be very much use without the libgcc
changes.


Sure thing.



Ping, need help to commit it?

Re: Adding a new thread model to GCC

2022-12-18 Thread Jonathan Yong via Gcc-patches 

On 10/31/22 15:22, i.nixman--- via Gcc-patches wrote:

On 2022-10-31 09:18, Eric Botcazou wrote:

Hi Eric!

thank you very much for the job!
I will try to build our (MinGW-Builds project) builds using this patch 
and will report back.


@Jonathan

what the next steps to be taken to accept this patch?



I don't see any obvious problems with it, looks OK to me.

Re: Adding a new thread model to GCC

2022-12-16 Thread Eric Botcazou via Gcc-patches 
> The libgcc parts look reasonable to me, but I can't approve them.
> Maybe Jonathan Yong can approve those parts as mingw-w64 target
> maintainer, or maybe a libgcc approver can do so.

OK.

> The libstdc++ parts are OK for trunk. IIUC they could go in
> separately, they just wouldn't be very much use without the libgcc
> changes.

Sure thing.

-- 
Eric Botcazou

Re: Adding a new thread model to GCC

2022-12-16 Thread Jonathan Wakely via Gcc-patches 
On Mon, 31 Oct 2022 at 09:19, Eric Botcazou via Libstdc++
 wrote:
> I have attached a revised version of the original patch at:
>   https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html
>
> This reimplements the GNU threads library on native Windows (except for the
> Objective-C specific subset) using direct Win32 API calls, in lieu of the
> implementation based on semaphores.  This base implementations requires
> Windows XP/Server 2003, which was the default minimal setting of MinGW-W64
> until end of 2020.  This also adds the support required for the C++11 threads,
> using again direct Win32 API calls; this additional layer requires Windows
> Vista/Server 2008 and is enabled only if _WIN32_WINNT >= 0x0600.
>
> This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when the
> switch --enable-libstdcxx-threads is passed, which means that C++11 threads
> are still disabled by default *unless* MinGW-W64 itself is configured for
> Windows Vista/Server 2008 or later by default (this has been the case in
> the development version since end of 2020, for earlier versions you can
> configure it --with-default-win32-winnt=0x0600 to get the same effect).
>
> I only manually tested it on i686-w64-mingw32 and x86_64-w64-mingw32 but
> AdaCore has used it in their C/C++/Ada compilers for 3 years now and the
> 30_threads chapter of the libstdc++ testsuite was clean at the time.

The libgcc parts look reasonable to me, but I can't approve them.
Maybe Jonathan Yong can approve those parts as mingw-w64 target
maintainer, or maybe a libgcc approver can do so.

The libstdc++ parts are OK for trunk. IIUC they could go in
separately, they just wouldn't be very much use without the libgcc
changes.


> 2022-10-31  Eric Botcazou  
>
> libgcc/
> * config.host (i[34567]86-*-mingw*): Add thread fragment after EH one
> as well as new i386/t-slibgcc-mingw fragment.
> (x86_64-*-mingw*): Likewise.
> * config/i386/gthr-win32.h: If _WIN32_WINNT is at least 0x0600, define
> both __GTHREAD_HAS_COND and __GTHREADS_CXX0X to 1.
> Error out if _GTHREAD_USE_MUTEX_TIMEDLOCK is 1.
> Include stdlib.h instead of errno.h and do not include _mingw.h.
> (CONST_CAST2): Add specific definition for C++.
> (ATTRIBUTE_UNUSED): New macro.
> (__UNUSED_PARAM): Delete.
> Define WIN32_LEAN_AND_MEAN before including windows.h.
> (__gthread_objc_data_tls): Use TLS_OUT_OF_INDEXES instead of 
> (DWORD)-1.
> (__gthread_objc_init_thread_system): Likewise.
> (__gthread_objc_thread_get_data): Minor tweak.
> (__gthread_objc_condition_allocate): Use ATTRIBUTE_UNUSED.
> (__gthread_objc_condition_deallocate): Likewise.
> (__gthread_objc_condition_wait): Likewise.
> (__gthread_objc_condition_broadcast): Likewise.
> (__gthread_objc_condition_signal): Likewise.
> Include sys/time.h.
> (__gthr_win32_DWORD): New typedef.
> (__gthr_win32_HANDLE): Likewise.
> (__gthr_win32_CRITICAL_SECTION): Likewise.
> (__gthr_win32_CONDITION_VARIABLE): Likewise.
> (__gthread_t): Adjust.
> (__gthread_key_t): Likewise.
> (__gthread_mutex_t): Likewise.
> (__gthread_recursive_mutex_t): Likewise.
> (__gthread_cond_t): New typedef.
> (__gthread_time_t): Likewise.
> (__GTHREAD_MUTEX_INIT_DEFAULT): Delete.
> (__GTHREAD_RECURSIVE_MUTEX_INIT_DEFAULT): Likewise.
> (__GTHREAD_COND_INIT_FUNCTION): Define.
> (__GTHREAD_TIME_INIT): Likewise.
> (__gthr_i486_lock_cmp_xchg): Delete.
> (__gthr_win32_create): Declare.
> (__gthr_win32_join): Likewise.
> (__gthr_win32_self): Likewise.
> (__gthr_win32_detach): Likewise.
> (__gthr_win32_equal): Likewise.
> (__gthr_win32_yield): Likewise.
> (__gthr_win32_mutex_destroy): Likewise.
> (__gthr_win32_cond_init_function): Likewise if __GTHREADS_HAS_COND is 
> 1.
> (__gthr_win32_cond_broadcast): Likewise.
> (__gthr_win32_cond_signal): Likewise.
> (__gthr_win32_cond_wait): Likewise.
> (__gthr_win32_cond_timedwait): Likewise.
> (__gthr_win32_recursive_mutex_init_function): Delete.
> (__gthr_win32_recursive_mutex_lock): Likewise.
> (__gthr_win32_recursive_mutex_unlock): Likewise.
> (__gthr_win32_recursive_mutex_destroy): Likewise.
> (__gthread_create): New inline function.
> (__gthread_join): Likewise.
> (__gthread_self): Likewise.
> (__gthread_detach): Likewise.
> (__gthread_equal): Likewise.
> (__gthread_yield): Likewise.
> (__gthread_cond_init_function): Likewise if __GTHREADS_HAS_COND is 1.
> (__gthread_cond_broadcast): Likewise.
> (__gthread_cond_signal): Likewise.
> (__gthread_cond_wait): Likewise.
> (__gthread_cond_timedwait): Likewise.
>

Re: Adding a new thread model to GCC

2022-11-02 Thread i.nixman--- via Gcc-patches 

On 2022-11-02 21:27, Eric Botcazou wrote:

Great!  Did you check that C++ threads are enabled in your build?  If 
they
are, you must be able to run the attached C++ test; if they are not 
(because
the MinGW64 build is configured for older versions of Windows), you 
need to

configure the compiler with the option --enable-libstdcxx-threads.


I already checked everything before, but now I re-checked it again - 
everything works!


the output:
$ ./t
Start thread 0
Start thread 1
Start thread 2
Start thread 3


thank you!

Re: Adding a new thread model to GCC

2022-11-02 Thread Eric Botcazou via Gcc-patches 
> I was able to successfully build gcc-trunk using the provided patch.
> moreover, I was able to successfully build all of the packages used in
> the toolchain!
> (gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses,
> readline, gdbm, tcl, tk, openssl, xz-utils, sqlite, python3, binutils,
> gdb, make)

Great!  Did you check that C++ threads are enabled in your build?  If they 
are, you must be able to run the attached C++ test; if they are not (because 
the MinGW64 build is configured for older versions of Windows), you need to 
configure the compiler with the option --enable-libstdcxx-threads.

-- 
Eric Botcazou#include 
#include 
#include 
#include 
#include 

#define NUM_THREADS 4

std::condition_variable cond;
std::mutex mx;
int started = 0;

void
do_thread ()
{
  std::unique_lock lock(mx);
  std::cout << "Start thread " << started << std::endl;
  if(++started >= NUM_THREADS)
cond.notify_all();
  else
cond.wait(lock);
}

int
main ()
{
  std::vector vec;
  for (int i = 0; i < NUM_THREADS; ++i)
vec.emplace_back(_thread);
  for (int i = 0; i < NUM_THREADS; ++i)
vec[i].join();
  vec.clear();
  return 0;
}

Re: Adding a new thread model to GCC

2022-11-02 Thread i.nixman--- via Gcc-patches 



hi Eric, Jonathan,

I was able to successfully build gcc-trunk using the provided patch.
moreover, I was able to successfully build all of the packages used in 
the toolchain!
(gmp, mpfr, mpc, isl, libgnurx, bzip2, termcap, libffi, expat, ncurses, 
readline, gdbm, tcl, tk, openssl, xz-utils, sqlite, python3, binutils, 
gdb, make)


at first glance everything seems to be working as before!
I posted the information about this and the link to the archive on the 
project page: https://github.com/niXman/mingw-builds/issues/622




best!

Re: Adding a new thread model to GCC

2022-11-01 Thread Eric Botcazou via Gcc-patches 
> I have faced with "#error Timed lock primitives are not supported on
> Windows targets" and I'm not sure I understood the reason correctly.
> 
> as far as I understand, the definition for
> `_GTHREAD_USE_MUTEX_TIMEDLOCK` comes from libstdc++/configure as a
> result of some test.
> 
> why did I faced with this error? what should I do to avoid this?

Run autoheader + autoconf in the libstdc++-v3 source repository.

-- 
Eric Botcazou

Re: Adding a new thread model to GCC

2022-10-31 Thread i.nixman--- via Gcc-patches 

On 2022-10-31 09:18, Eric Botcazou wrote:

hello Eric!

This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when 
the
switch --enable-libstdcxx-threads is passed, which means that C++11 
threads
are still disabled by default *unless* MinGW-W64 itself is configured 
for
Windows Vista/Server 2008 or later by default (this has been the case 
in

the development version since end of 2020, for earlier versions you can
configure it --with-default-win32-winnt=0x0600 to get the same effect).


I have faced with "#error Timed lock primitives are not supported on 
Windows targets" and I'm not sure I understood the reason correctly.


as far as I understand, the definition for 
`_GTHREAD_USE_MUTEX_TIMEDLOCK` comes from libstdc++/configure as a 
result of some test.


why did I faced with this error? what should I do to avoid this?



you can configure it --with-default-win32-winnt=0x0600 to get the same 
effect


are you talking about the `--with-default-win32-winnt=` option used on 
MinGW-builds script?





best!

Re: Adding a new thread model to GCC

2022-10-31 Thread i.nixman--- via Gcc-patches 

On 2022-10-31 09:18, Eric Botcazou wrote:

Hi Eric!

thank you very much for the job!
I will try to build our (MinGW-Builds project) builds using this patch 
and will report back.


@Jonathan

what the next steps to be taken to accept this patch?



best!



I have attached a revised version of the original patch at:
  https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html

This reimplements the GNU threads library on native Windows (except for 
the
Objective-C specific subset) using direct Win32 API calls, in lieu of 
the

implementation based on semaphores.  This base implementations requires
Windows XP/Server 2003, which was the default minimal setting of 
MinGW-W64
until end of 2020.  This also adds the support required for the C++11 
threads,
using again direct Win32 API calls; this additional layer requires 
Windows

Vista/Server 2008 and is enabled only if _WIN32_WINNT >= 0x0600.

This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when 
the
switch --enable-libstdcxx-threads is passed, which means that C++11 
threads
are still disabled by default *unless* MinGW-W64 itself is configured 
for
Windows Vista/Server 2008 or later by default (this has been the case 
in

the development version since end of 2020, for earlier versions you can
configure it --with-default-win32-winnt=0x0600 to get the same effect).

I only manually tested it on i686-w64-mingw32 and x86_64-w64-mingw32 
but
AdaCore has used it in their C/C++/Ada compilers for 3 years now and 
the

30_threads chapter of the libstdc++ testsuite was clean at the time.


2022-10-31  Eric Botcazou  

libgcc/
* config.host (i[34567]86-*-mingw*): Add thread fragment after EH one
as well as new i386/t-slibgcc-mingw fragment.
(x86_64-*-mingw*): Likewise.
* config/i386/gthr-win32.h: If _WIN32_WINNT is at least 0x0600, define
both __GTHREAD_HAS_COND and __GTHREADS_CXX0X to 1.
Error out if _GTHREAD_USE_MUTEX_TIMEDLOCK is 1.
Include stdlib.h instead of errno.h and do not include _mingw.h.
(CONST_CAST2): Add specific definition for C++.
(ATTRIBUTE_UNUSED): New macro.
(__UNUSED_PARAM): Delete.
Define WIN32_LEAN_AND_MEAN before including windows.h.
	(__gthread_objc_data_tls): Use TLS_OUT_OF_INDEXES instead of 
(DWORD)-1.

(__gthread_objc_init_thread_system): Likewise.
(__gthread_objc_thread_get_data): Minor tweak.
(__gthread_objc_condition_allocate): Use ATTRIBUTE_UNUSED.
(__gthread_objc_condition_deallocate): Likewise.
(__gthread_objc_condition_wait): Likewise.
(__gthread_objc_condition_broadcast): Likewise.
(__gthread_objc_condition_signal): Likewise.
Include sys/time.h.
(__gthr_win32_DWORD): New typedef.
(__gthr_win32_HANDLE): Likewise.
(__gthr_win32_CRITICAL_SECTION): Likewise.
(__gthr_win32_CONDITION_VARIABLE): Likewise.
(__gthread_t): Adjust.
(__gthread_key_t): Likewise.
(__gthread_mutex_t): Likewise.
(__gthread_recursive_mutex_t): Likewise.
(__gthread_cond_t): New typedef.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT_DEFAULT): Delete.
(__GTHREAD_RECURSIVE_MUTEX_INIT_DEFAULT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Define.
(__GTHREAD_TIME_INIT): Likewise.
(__gthr_i486_lock_cmp_xchg): Delete.
(__gthr_win32_create): Declare.
(__gthr_win32_join): Likewise.
(__gthr_win32_self): Likewise.
(__gthr_win32_detach): Likewise.
(__gthr_win32_equal): Likewise.
(__gthr_win32_yield): Likewise.
(__gthr_win32_mutex_destroy): Likewise.
	(__gthr_win32_cond_init_function): Likewise if __GTHREADS_HAS_COND is 
1.

(__gthr_win32_cond_broadcast): Likewise.
(__gthr_win32_cond_signal): Likewise.
(__gthr_win32_cond_wait): Likewise.
(__gthr_win32_cond_timedwait): Likewise.
(__gthr_win32_recursive_mutex_init_function): Delete.
(__gthr_win32_recursive_mutex_lock): Likewise.
(__gthr_win32_recursive_mutex_unlock): Likewise.
(__gthr_win32_recursive_mutex_destroy): Likewise.
(__gthread_create): New inline function.
(__gthread_join): Likewise.
(__gthread_self): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_init_function): Likewise if __GTHREADS_HAS_COND is 1.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__GTHREAD_WIN32_INLINE): New macro.
(__GTHREAD_WIN32_COND_INLINE): Likewise.
(__GTHREAD_WIN32_ACTIVE_P): Likewise.
Define WIN32_LEAN_AND_MEAN before including windows.h.
(__gthread_once): Minor tweaks.
(__gthread_key_create): Use ATTRIBUTE_UNUSED and TLS_OUT_OF_INDEXES.

Re: Adding a new thread model to GCC

2022-10-31 Thread Eric Botcazou via Gcc-patches 
> could you please refresh/recheck your patch for the current gcc master
> and solve the objections noted in the thread? is it possible?

I have attached a revised version of the original patch at:
  https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html

This reimplements the GNU threads library on native Windows (except for the
Objective-C specific subset) using direct Win32 API calls, in lieu of the
implementation based on semaphores.  This base implementations requires
Windows XP/Server 2003, which was the default minimal setting of MinGW-W64
until end of 2020.  This also adds the support required for the C++11 threads,
using again direct Win32 API calls; this additional layer requires Windows
Vista/Server 2008 and is enabled only if _WIN32_WINNT >= 0x0600.

This also changes libstdc++ to pass -D_WIN32_WINNT=0x0600 but only when the
switch --enable-libstdcxx-threads is passed, which means that C++11 threads
are still disabled by default *unless* MinGW-W64 itself is configured for
Windows Vista/Server 2008 or later by default (this has been the case in
the development version since end of 2020, for earlier versions you can
configure it --with-default-win32-winnt=0x0600 to get the same effect).

I only manually tested it on i686-w64-mingw32 and x86_64-w64-mingw32 but
AdaCore has used it in their C/C++/Ada compilers for 3 years now and the
30_threads chapter of the libstdc++ testsuite was clean at the time.


2022-10-31  Eric Botcazou  

libgcc/
* config.host (i[34567]86-*-mingw*): Add thread fragment after EH one
as well as new i386/t-slibgcc-mingw fragment.
(x86_64-*-mingw*): Likewise.
* config/i386/gthr-win32.h: If _WIN32_WINNT is at least 0x0600, define
both __GTHREAD_HAS_COND and __GTHREADS_CXX0X to 1.
Error out if _GTHREAD_USE_MUTEX_TIMEDLOCK is 1.
Include stdlib.h instead of errno.h and do not include _mingw.h.
(CONST_CAST2): Add specific definition for C++.
(ATTRIBUTE_UNUSED): New macro.
(__UNUSED_PARAM): Delete.
Define WIN32_LEAN_AND_MEAN before including windows.h.
(__gthread_objc_data_tls): Use TLS_OUT_OF_INDEXES instead of (DWORD)-1.
(__gthread_objc_init_thread_system): Likewise.
(__gthread_objc_thread_get_data): Minor tweak.
(__gthread_objc_condition_allocate): Use ATTRIBUTE_UNUSED.
(__gthread_objc_condition_deallocate): Likewise.
(__gthread_objc_condition_wait): Likewise.
(__gthread_objc_condition_broadcast): Likewise.
(__gthread_objc_condition_signal): Likewise.
Include sys/time.h.
(__gthr_win32_DWORD): New typedef.
(__gthr_win32_HANDLE): Likewise.
(__gthr_win32_CRITICAL_SECTION): Likewise.
(__gthr_win32_CONDITION_VARIABLE): Likewise.
(__gthread_t): Adjust.
(__gthread_key_t): Likewise.
(__gthread_mutex_t): Likewise.
(__gthread_recursive_mutex_t): Likewise.
(__gthread_cond_t): New typedef.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT_DEFAULT): Delete.
(__GTHREAD_RECURSIVE_MUTEX_INIT_DEFAULT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Define.
(__GTHREAD_TIME_INIT): Likewise.
(__gthr_i486_lock_cmp_xchg): Delete.
(__gthr_win32_create): Declare.
(__gthr_win32_join): Likewise.
(__gthr_win32_self): Likewise.
(__gthr_win32_detach): Likewise.
(__gthr_win32_equal): Likewise.
(__gthr_win32_yield): Likewise.
(__gthr_win32_mutex_destroy): Likewise.
(__gthr_win32_cond_init_function): Likewise if __GTHREADS_HAS_COND is 1.
(__gthr_win32_cond_broadcast): Likewise.
(__gthr_win32_cond_signal): Likewise.
(__gthr_win32_cond_wait): Likewise.
(__gthr_win32_cond_timedwait): Likewise.
(__gthr_win32_recursive_mutex_init_function): Delete.
(__gthr_win32_recursive_mutex_lock): Likewise.
(__gthr_win32_recursive_mutex_unlock): Likewise.
(__gthr_win32_recursive_mutex_destroy): Likewise.
(__gthread_create): New inline function.
(__gthread_join): Likewise.
(__gthread_self): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_init_function): Likewise if __GTHREADS_HAS_COND is 1.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__GTHREAD_WIN32_INLINE): New macro.
(__GTHREAD_WIN32_COND_INLINE): Likewise.
(__GTHREAD_WIN32_ACTIVE_P): Likewise.
Define WIN32_LEAN_AND_MEAN before including windows.h.
(__gthread_once): Minor tweaks.
(__gthread_key_create): Use ATTRIBUTE_UNUSED and TLS_OUT_OF_INDEXES.
(__gthread_key_delete): Minor tweak.
(__gthread_getspecific): Likewise.
(__gthread_setspecific):

Re: Adding a new thread model to GCC

2022-10-24 Thread Jacek Caban via Gcc-patches 

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 other mingw-w64 developers, I am putting 
those patches against mingw-w64-crt on hold for now. Despite that, all 
threading facilities - mutexes, condition variables, once flags, etc. 
- are still fully functional within the mcf thread model.


In addition, I will keep maintaining my personal builds (from GCC 12 
release branch) with these patches at https://gcc-mcf.lhmouse.com/.



 Forwarded Message 
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing 
implementations, we don't need to make

> things more complicated than they are.
>

Okay okay, I think I have to compose a thorough list of problems that 
we are facing at the moment, and had better have a permalink to the 
mailing list archive that I can reference elsewhere. I have been tired 
of repeating the same grounds of arguments again and again:



1. In a DLL, destructors of static objects and callbacks that are 
registered
    with `atexit()`, are executed by `LdrShutdownProcess()`, after all 
the other
    thread have been terminated `ZwTerminateProcessO(NULL, status)`. 
This means
    that, if another thread has been terminated while holding a mutex, 
the mutex
    can never get unlocked. If a destructor attempts to lock the same 
mutex,
    deadlocks will occur. Destructors of executables do not suffer 
from this

    issue, because they are executed before `RtlExitUserProcess()`.

    Standard behavior: Static destructors and exit callbacks should be 
executed
    while other threads are running. If another thread attempts to 
access a
    destroyed object, the behavior is undefined; the user is 
responsible to

    prevent this from happening, by joining or suspending it.


2. Following 1, in a DLL, static destructors and exit callbacks are still
    invoked when `_Exit()` or `quick_exit()` is called.

    Standard behavior: `_Exit()` should not perform any cleanup; not 
even open
    files are flushed. `quick_exit()` shall invoke all quick-exit 
callbacks in

    reverse order, then call `_Exit()`.


3. There is a use-after-free bug [1] about thread-local destructors. I 
suspect

    this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to
    register thread-local destructors, which could interleave with
    `emutls_destroy()`.

    Standard behavior: This is not allowed to happen. mcfgthread 
solves this

    issue by running thread-local destructors and thread-specific key
    destructors as two separate passes [3].

    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816
    [2] 
https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96
    [3] 
https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249



4. In the win32 thread model, thread-specific key destructors are 
called at

    process exit [4], after static destructors.

    Standard behavior: They shall be called only when a thread exits, 
and the
    associated thread-specific values are not a null pointer. They 
shall not be

    called when a program terminates; instead, users are responsible for
    deallocating such resources before calling `exit()`. This 
requirement is
    missing in POSIX, but formally specified by ISO/IEC 9899:2017, as 
the 4th

    paragraph in '7.26.6.1 The tss_create function'.

    [4] 
https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134



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 threading model, meaning that 
future bugs will be even harder to fix.





5. Wait operations, of timed mutexes and condition variables, should take
    absolute time points as `struct timespec`.

    Standard behavior: Both POSIX and ISO C specifies them as such, 
while all
    Windows APIs take relative durations as a 32-bit integer of 
milliseconds,

    which can also easily get overflown.



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 elaborate more on that 
on mingw ML, but I need to find time to do a bit of research first).



Jacek

Re: Adding a new thread model to GCC

2022-10-24 Thread i.nixman--- via Gcc-patches 

On 2022-10-24 08:15, Eric Botcazou wrote:

could you please refresh/recheck your patch for the current gcc master
and solve the objections noted in the thread? is it possible?





Hi,


I can do the former, but not the latter as my development setup (mostly
testing) on Windows has nearly vanished in the meantime.  But this 
rewritten

implementation is the one used by the C/C++/Ada compilers from AdaCore.



ah, it's great!


thank you very much!




best!

Re: Adding a new thread model to GCC

2022-10-24 Thread Eric Botcazou via Gcc-patches 
> could you please refresh/recheck your patch for the current gcc master
> and solve the objections noted in the thread? is it possible?

I can do the former, but not the latter as my development setup (mostly 
testing) on Windows has nearly vanished in the meantime.  But this rewritten 
implementation is the one used by the C/C++/Ada compilers from AdaCore.

-- 
Eric Botcazou

Re: Adding a new thread model to GCC

2022-10-24 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?


My proposal was to reimplement (and extend) the native thread model 
(win32)
instead of adding a new one, the advantage being that you don't need an 
extra

threading layer between GCC and Windows.


Hello Eric,

could you please refresh/recheck your patch for the current gcc master 
and solve the objections noted in the thread? is it possible?




best!

Re: Adding a new thread model to GCC

2022-10-23 Thread LIU Hao via Gcc-patches 

在 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 other mingw-w64 developers, I am putting those patches against 
mingw-w64-crt on hold for now. Despite that, all threading facilities - mutexes, condition 
variables, once flags, etc. - are still fully functional within the mcf thread model.


In addition, I will keep maintaining my personal builds (from GCC 12 release branch) with these 
patches at https://gcc-mcf.lhmouse.com/.



 Forwarded Message 
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing implementations, we 
don't need to make
> things more complicated than they are.
>

Okay okay, I think I have to compose a thorough list of problems that we are facing at the moment, 
and had better have a permalink to the mailing list archive that I can reference elsewhere. I have 
been tired of repeating the same grounds of arguments again and again:



1. In a DLL, destructors of static objects and callbacks that are registered
with `atexit()`, are executed by `LdrShutdownProcess()`, after all the other
thread have been terminated `ZwTerminateProcessO(NULL, status)`. This means
that, if another thread has been terminated while holding a mutex, the mutex
can never get unlocked. If a destructor attempts to lock the same mutex,
deadlocks will occur. Destructors of executables do not suffer from this
issue, because they are executed before `RtlExitUserProcess()`.

Standard behavior: Static destructors and exit callbacks should be executed
while other threads are running. If another thread attempts to access a
destroyed object, the behavior is undefined; the user is responsible to
prevent this from happening, by joining or suspending it.


2. Following 1, in a DLL, static destructors and exit callbacks are still
invoked when `_Exit()` or `quick_exit()` is called.

Standard behavior: `_Exit()` should not perform any cleanup; not even open
files are flushed. `quick_exit()` shall invoke all quick-exit callbacks in
reverse order, then call `_Exit()`.


3. There is a use-after-free bug [1] about thread-local destructors. I suspect
this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to
register thread-local destructors, which could interleave with
`emutls_destroy()`.

Standard behavior: This is not allowed to happen. mcfgthread solves this
issue by running thread-local destructors and thread-specific key
destructors as two separate passes [3].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816
[2] 
https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96
[3] 
https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249



4. In the win32 thread model, thread-specific key destructors are called at
process exit [4], after static destructors.

Standard behavior: They shall be called only when a thread exits, and the
associated thread-specific values are not a null pointer. They shall not be
called when a program terminates; instead, users are responsible for
deallocating such resources before calling `exit()`. This requirement is
missing in POSIX, but formally specified by ISO/IEC 9899:2017, as the 4th
paragraph in '7.26.6.1 The tss_create function'.

[4] 
https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134



5. Wait operations, of timed mutexes and condition variables, should take
absolute time points as `struct timespec`.

Standard behavior: Both POSIX and ISO C specifies them as such, while all
Windows APIs take relative durations as a 32-bit integer of milliseconds,
which can also easily get overflown.


--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-22 Thread NightStrike via Gcc-patches 
On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches
 wrote:
>
> On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
> >>>/How does this compare with Eric B's proposal at 
> >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? 
> >>>/>>//>>/My proposal was to reimplement (and extend) the native thread 
> >>>model />>/(win32) />>/instead of adding a new one, the advantage being 
> >>>that you don't need an />>/extra />/> threading layer between GCC and 
> >>>Windows. />
> > I agree!
>
> I agree as well and I expressed that on mingw-w64 ML when the patch was 
> introduced [1]. My main concern with the new threading model is that instead 
> of solving root of the problem, it introduces more fragmentation with no 
> clear benefit.
>
> On top of that, mcfgthread library is way more invasive than it needs to be. 
> It requires maintaining per-thread struct and reimplements a number of things 
> instead of leveraging OS capabilities. Author also plans to make invasive 
> changes to mingw-w64-crt, which go against it current approach of being 
> agnostic to threading model.
>
> Jacek
>
> [1] https://sourceforge.net/p/mingw-w64/mailman/message/37719727/

FWIW, Eric's proposal makes more practical sense.  Right now, people
ship many permutations of the compiler:
x86, x64, x86+x64
dw2, sjlj (rarely), seh
win32, posix+winpthread

This is not sustainable, and certain combinations are largely
incompatible (which makes for instance providing a windows release of
MySpecialLibrary.dll confusing).  We used to have a matrix of
combinations on the website, but I see that that's no longer present.
In any case, it took a long time for sjlj to fall out of vogue (maybe
old habits die hard?).  That implies, to me, that winpthreads
similarly won't be deprecated, it'll just be yet another set of
archives to download and confuse people with.

Re: Adding a new thread model to GCC

2022-10-21 Thread Jacek Caban via Gcc-patches 

On 10/21/22 14:29, LIU Hao wrote:

在 2022/10/21 20:13, Jacek Caban 写道:


This is not true for past 15 years, CRITICAL_SECTIONS use something 
like RtlWaitOnAddress (an equivalent of futexes) since Vista, see 
Wine implementation for details:

https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/sync.c#L190




Ah Jacek, nice to see you here.

I haven't dug into this too much, though. From my limited knowledge 
(mostly from reading disassembly) now CRITICAL_SECTION uses 
`NtWaitForAlertByThreadId` (and no longer keyed events or semaphores). 
As with `WaitOnAddress()`, there seems to be some global data 
structure, protected by a spin lock. It's just another undocumented 
syscall. Keyed events are still functional.



NtWaitForAlertByThreadId() is an underlying syscall that's used by 
WaitOnAddress(). Anyway, you don't need to worry about that if you just 
use public CRITICAL_SECTION APIs.



Jacek

Re: Adding a new thread model to GCC

2022-10-21 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 12:19, LIU Hao wrote:

在 2022/10/21 19:54, i.nix...@autistici.org 写道:





Jacek Caban, who is also a mingw-w64 developer, expressed the same
idea a few days ago.

While integrating mcfgthread into gcc is practically possible, my 
concerns are:


  * GCC never provides a threading library. It always depends on glibc,
musl, win32 APIs, winpthreads, etc.


I think you didn't understand me.

I mean not to integrate your library into GCC as real separate library.
I mean to do changes on 
config/i386/gthr-win32.h+config/i386/gthr-win32.c+config/i386/gthr-win32-cond.c 
etc using your code to have an implementation of everything needed for 
C/C++ threads on Windows.




  * Tampering with the win32 thread model in a dramatic way is not
acceptiable due to backwards compatibility. There are distributions
that have win32 as the default thread model, such as Debian.

  * I personally need more control for future development, for example,
re-implement pthread or adding libcxx support, which doesn't fit in
GCC.


got it...
anyway it seems logical to me the way I proposed :)


best!

Re: Adding a new thread model to GCC

2022-10-21 Thread Jacek Caban via Gcc-patches 

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:

/How does this compare with Eric B's proposal at />>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html 
? />>//>>/My proposal was to reimplement (and extend) the native thread model />>/(win32) />>/instead 
of adding a new one, the advantage being that you don't need an />>/extra />/> threading layer between GCC and 
Windows. />

I agree!


I agree as well and I expressed that on mingw-w64 ML when the patch was 
introduced [1]. My main concern with the new threading model is that instead of 
solving root of the problem, it introduces more fragmentation with no clear 
benefit.

On top of that, mcfgthread library is way more invasive than it needs to be. It 
requires maintaining per-thread struct and reimplements a number of things 
instead of leveraging OS capabilities. Author also plans to make invasive 
changes to mingw-w64-crt, which go against it current approach of being 
agnostic to threading model.

Jacek

[1] https://sourceforge.net/p/mingw-w64/mailman/message/37719727/

Re: Adding a new thread model to GCC

2022-10-21 Thread LIU Hao via Gcc-patches 

在 2022/10/21 20:13, Jacek Caban 写道:


This is not true for past 15 years, CRITICAL_SECTIONS use something like 
RtlWaitOnAddress (an equivalent of futexes) since Vista, see Wine 
implementation for details:
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/sync.c#L190




Ah Jacek, nice to see you here.

I haven't dug into this too much, though. From my limited knowledge (mostly from reading 
disassembly) now CRITICAL_SECTION uses `NtWaitForAlertByThreadId` (and no longer keyed events or 
semaphores). As with `WaitOnAddress()`, there seems to be some global data structure, protected by a 
spin lock. It's just another undocumented syscall. Keyed events are still functional.



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-21 Thread LIU Hao via Gcc-patches 

在 2022/10/21 19:54, i.nix...@autistici.org 写道:


I have a questions:
1) wouldn't it be logical not to write yet another implementation of pthreads-wor-windows, but to 
make changes to the winpthreads library because it's already supported by GCC? (maybe I don’t know 
about some reasons why it wasn’t done ...)




While it is possible to rebuild winpthreads from scratch, I don't think it's 
worth:

  * There are many POSIX facilities that we don't support: rwlock,
cancellation, signals, etc.

  * GCC can choose to implement `std::thread` etc. on C11 ,
which libcxx already has, but I haven't tested it.
(mcfgthread also has a C11 header, but not one for libcxx.)


It seems to me the ideal and logical option is to make your implementation part of GCC, as suggested 
by Eric B.

the advantages are as follows:
1) we will get a high-quality native implementation.
2) there is no need to add another thread model for GCC.
3) with dynamic linking there is no need to ship another dll with the program. (Windows users really 
don't like this =))




Jacek Caban, who is also a mingw-w64 developer, expressed the same idea a few 
days ago.

While integrating mcfgthread into gcc is practically possible, my concerns are:

  * GCC never provides a threading library. It always depends on glibc,
musl, win32 APIs, winpthreads, etc.

  * Tampering with the win32 thread model in a dramatic way is not
acceptiable due to backwards compatibility. There are distributions
that have win32 as the default thread model, such as Debian.

  * I personally need more control for future development, for example,
re-implement pthread or adding libcxx support, which doesn't fit in
GCC.


--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-21 Thread Jacek Caban via Gcc-patches 
The problem about this approach is that, semaphores are valuable kernel objects, and the maximum 
number of HANDLEs that a process can open concurrently has a limit (like FDs on Linux), while 'many 
critical sections are used only occasionally (or never at all), meaning the auto-reset event often 
isn’t even necessary' [1], the semaphores are actually allocated on demand. This means that locking 
can fail. There is a story in article [1] which also explains the origination of keyed events; it's 
worth reading.


This is not true for past 15 years, CRITICAL_SECTIONS use something like 
RtlWaitOnAddress (an equivalent of futexes) since Vista, see Wine 
implementation for details:
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/sync.c#L190

Jacek

Re: Adding a new thread model to GCC

2022-10-21 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?


My proposal was to reimplement (and extend) the native thread model 
(win32)
instead of adding a new one, the advantage being that you don't need an 
extra

threading layer between GCC and Windows.


I agree!



best!

Re: Adding a new thread model to GCC

2022-10-21 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 11:36, LIU Hao wrote:

在 2022/10/21 18:09, i.nix...@autistici.org 写道:

On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?

It would be good if we can accept one of them for GCC 13, but I don't
know Windows well enough to determine which is better.


I had the same question...
I would like to understand what is the difference?
Moreover I would like to understand what is the difference with the 
already added support for the winpthreads library?


@LIU Hao, could you explain please?





Thank you for your interest. I'm glad to make an introduction of it.


I have read this patch before. Let's take the mutex as an example:

There are a lot of ways to implement a mutex on Windows. Basically, a
non-recursive mutex can be implemented with an atomic counter + a
binary semaphore / auto-reset event. This proposed patch contains a
`__gthr_win32_CRITICAL_SECTION` definition that I think is a duplicate
of the internal `CRITICAL_SECTION` structure, so should also work the
same way as it.

The problem about this approach is that, semaphores are valuable
kernel objects, and the maximum number of HANDLEs that a process can
open concurrently has a limit (like FDs on Linux), while 'many
critical sections are used only occasionally (or never at all),
meaning the auto-reset event often isn’t even necessary' [1], the
semaphores are actually allocated on demand. This means that locking
can fail. There is a story in article [1] which also explains the
origination of keyed events; it's worth reading.

And, since Vista we also have native win32 condition variables, also
implemented basing on keyed events.


The keyed events are undocumented and are only exposed via syscalls.
However, as with other documented syscalls, available from Windows
Drivers Kit, there are several advantages:

  * There is a global keyed event, which requires no initialization, 
but
can be utilized by all processes. Basing on that, mcfgthread 
provides
mutexs, condition variables, once flags, etc. that are all 
one-pointer

size structs, consume absolutely no additional resource, allow
constexpr initialization, and require no cleanup, much like on 
Linux.


  * The wait syscalls take a 64-bit integer, whose positive value 
denotes

the number of 10^-7 seconds since 1600-01-01 00:00:00 Z, and whose
negative value denotes a relative timeout. Hence it's much more 
simpler
to implement `__gthread_mutex_timedlock()` and 
`__gthread_cond_wait()`
which take absolute timeouts. On the other hand, Win32 APIs 
generally
take a 32-bit relative timeout in milliseconds, which not only 
requires
translation from an absolute timepoint argument, but can also 
easily

get overflown.

  * Building mutexes on top of syscalls allows a better designed 
algorithm

[2], and sometimes it can even outperform native `SRWLOCK`s [3].

  * mcfgthread also provides standard-conforming `__cxa_atexit()` and
`__cxa_thread_atexit()` functions, for working around some strange,
weird, and broken behaviors [4][5][6]. On Linux it's glibc that
provides them, so this as a whole requires a little modification in
mingw-w64. I am working on it however; hopefully we can land it 
soon.





thank you LIU Hao for the explanation!

I have a questions:
1) wouldn't it be logical not to write yet another implementation of 
pthreads-wor-windows, but to make changes to the winpthreads library 
because it's already supported by GCC? (maybe I don’t know about some 
reasons why it wasn’t done ...)


It seems to me the ideal and logical option is to make your 
implementation part of GCC, as suggested by Eric B.

the advantages are as follows:
1) we will get a high-quality native implementation.
2) there is no need to add another thread model for GCC.
3) with dynamic linking there is no need to ship another dll with the 
program. (Windows users really don't like this =))




best!

[1] 
http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/


[2] https://github.com/lhmouse/mcfgthread/blob/master/MUTEX.md
[3] https://github.com/lhmouse/mcfgthread#benchmarking

[4] https://sourceforge.net/p/mingw-w64/mailman/message/37268447/
[5] https://reviews.llvm.org/D102944
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816

Re: Adding a new thread model to GCC

2022-10-21 Thread Eric Botcazou via Gcc-patches 
> How does this compare with Eric B's proposal at
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?

My proposal was to reimplement (and extend) the native thread model (win32) 
instead of adding a new one, the advantage being that you don't need an extra 
threading layer between GCC and Windows.

-- 
Eric Botcazou

Re: Adding a new thread model to GCC

2022-10-21 Thread LIU Hao via Gcc-patches 

在 2022/10/21 18:09, i.nix...@autistici.org 写道:

On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?

It would be good if we can accept one of them for GCC 13, but I don't
know Windows well enough to determine which is better.


I had the same question...
I would like to understand what is the difference?
Moreover I would like to understand what is the difference with the already added support for the 
winpthreads library?


@LIU Hao, could you explain please?





Thank you for your interest. I'm glad to make an introduction of it.


I have read this patch before. Let's take the mutex as an example:

There are a lot of ways to implement a mutex on Windows. Basically, a non-recursive mutex can be 
implemented with an atomic counter + a binary semaphore / auto-reset event. This proposed patch 
contains a `__gthr_win32_CRITICAL_SECTION` definition that I think is a duplicate of the internal 
`CRITICAL_SECTION` structure, so should also work the same way as it.


The problem about this approach is that, semaphores are valuable kernel objects, and the maximum 
number of HANDLEs that a process can open concurrently has a limit (like FDs on Linux), while 'many 
critical sections are used only occasionally (or never at all), meaning the auto-reset event often 
isn’t even necessary' [1], the semaphores are actually allocated on demand. This means that locking 
can fail. There is a story in article [1] which also explains the origination of keyed events; it's 
worth reading.


And, since Vista we also have native win32 condition variables, also 
implemented basing on keyed events.


The keyed events are undocumented and are only exposed via syscalls. However, as with other 
documented syscalls, available from Windows Drivers Kit, there are several advantages:


  * There is a global keyed event, which requires no initialization, but
can be utilized by all processes. Basing on that, mcfgthread provides
mutexs, condition variables, once flags, etc. that are all one-pointer
size structs, consume absolutely no additional resource, allow
constexpr initialization, and require no cleanup, much like on Linux.

  * The wait syscalls take a 64-bit integer, whose positive value denotes
the number of 10^-7 seconds since 1600-01-01 00:00:00 Z, and whose
negative value denotes a relative timeout. Hence it's much more simpler
to implement `__gthread_mutex_timedlock()` and `__gthread_cond_wait()`
which take absolute timeouts. On the other hand, Win32 APIs generally
take a 32-bit relative timeout in milliseconds, which not only requires
translation from an absolute timepoint argument, but can also easily
get overflown.

  * Building mutexes on top of syscalls allows a better designed algorithm
[2], and sometimes it can even outperform native `SRWLOCK`s [3].

  * mcfgthread also provides standard-conforming `__cxa_atexit()` and
`__cxa_thread_atexit()` functions, for working around some strange,
weird, and broken behaviors [4][5][6]. On Linux it's glibc that
provides them, so this as a whole requires a little modification in
mingw-w64. I am working on it however; hopefully we can land it soon.


[1] 
http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/


[2] https://github.com/lhmouse/mcfgthread/blob/master/MUTEX.md
[3] https://github.com/lhmouse/mcfgthread#benchmarking

[4] https://sourceforge.net/p/mingw-w64/mailman/message/37268447/
[5] https://reviews.llvm.org/D102944
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816

--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-21 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 10:48, Jonathan Wakely wrote:

On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++
 wrote:


On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:
> How does this compare with Eric B's proposal at
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
>
> It would be good if we can accept one of them for GCC 13, but I don't
> know Windows well enough to determine which is better.

I had the same question...
I would like to understand what is the difference?
Moreover I would like to understand what is the difference with the
already added support for the winpthreads library?


Well that one's easy, you don't need to use winpthreads if there's a
native thread model, so you don't need to go through two abstraction
layers (gthreads and winpthreads), just one (gthreads).



sure!

nevertheless I would like to understand why we have two separate 
implementations (winthreads and mcfgthread)?

what is the difference?


best!

Re: Adding a new thread model to GCC

2022-10-21 Thread Jonathan Wakely via Gcc-patches 
On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++
 wrote:
>
> On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:
> > How does this compare with Eric B's proposal at
> > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
> >
> > It would be good if we can accept one of them for GCC 13, but I don't
> > know Windows well enough to determine which is better.
>
> I had the same question...
> I would like to understand what is the difference?
> Moreover I would like to understand what is the difference with the
> already added support for the winpthreads library?

Well that one's easy, you don't need to use winpthreads if there's a
native thread model, so you don't need to go through two abstraction
layers (gthreads and winpthreads), just one (gthreads).

The benefits of using the native thread model for the OS seems
obvious. The question is which patch to do that should we use.

Re: Adding a new thread model to GCC

2022-10-21 Thread i.nixman--- via Gcc-patches 

On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote:

How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?

It would be good if we can accept one of them for GCC 13, but I don't
know Windows well enough to determine which is better.


I had the same question...
I would like to understand what is the difference?
Moreover I would like to understand what is the difference with the 
already added support for the winpthreads library?


@LIU Hao, could you explain please?



best!



On Sat, 1 Oct 2022 at 19:35, LIU Hao via Libstdc++
 wrote:


Greetings.

After some years I think it's time to put on this topic again.

This patch series is an attempt to add a new thread model basing on 
the mcfgthread library
(https://github.com/lhmouse/mcfgthread), which provides efficient 
implementations of mutexes,

condition variables, once flags, etc. for native Windows.


The first patch is necessary because somewhere in libgfortran, 
`pthread_t` is referenced. If the

thread model is not `posix`, it fails to compile.

The second patch implements `std::thread::hardware_concurrency()` for 
non-posix thread models. This
would also work for the win32 thread model if `std::thread` would be 
supported in the future.


The third patch adds the `mcf` thread model for GCC and its libraries. 
A new builtin macro
`__USING_MCFGTHREAD__` is added to indicate whether this new thread 
model is in effect. This grants
`std::mutex` and `std::once_flag` trivial destructors; 
`std::condition_variable` is a bit
unfortunate because its destructor is non-trivial, but in reality no 
cleanup is performed.



I have been bootstrapping GCC with the MCF thread model for more than 
five years. At the moment, C,
C++ and Fortran are supported. Ada is untested because I don't know 
how to bootstrap it. Objective-C
is not supported, because threading APIs for libobjc have not been 
implemented.


Please review. If there are any changes that I have to make, let me 
know.



--
Best regards,
LIU Hao

Re: Adding a new thread model to GCC

2022-10-21 Thread Jonathan Wakely via Gcc-patches 
How does this compare with Eric B's proposal at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?

It would be good if we can accept one of them for GCC 13, but I don't
know Windows well enough to determine which is better.

On Sat, 1 Oct 2022 at 19:35, LIU Hao via Libstdc++
 wrote:
>
> Greetings.
>
> After some years I think it's time to put on this topic again.
>
> This patch series is an attempt to add a new thread model basing on the 
> mcfgthread library
> (https://github.com/lhmouse/mcfgthread), which provides efficient 
> implementations of mutexes,
> condition variables, once flags, etc. for native Windows.
>
>
> The first patch is necessary because somewhere in libgfortran, `pthread_t` is 
> referenced. If the
> thread model is not `posix`, it fails to compile.
>
> The second patch implements `std::thread::hardware_concurrency()` for 
> non-posix thread models. This
> would also work for the win32 thread model if `std::thread` would be 
> supported in the future.
>
> The third patch adds the `mcf` thread model for GCC and its libraries. A new 
> builtin macro
> `__USING_MCFGTHREAD__` is added to indicate whether this new thread model is 
> in effect. This grants
> `std::mutex` and `std::once_flag` trivial destructors; 
> `std::condition_variable` is a bit
> unfortunate because its destructor is non-trivial, but in reality no cleanup 
> is performed.
>
>
> I have been bootstrapping GCC with the MCF thread model for more than five 
> years. At the moment, C,
> C++ and Fortran are supported. Ada is untested because I don't know how to 
> bootstrap it. Objective-C
> is not supported, because threading APIs for libobjc have not been 
> implemented.
>
> Please review. If there are any changes that I have to make, let me know.
>
>
> --
> Best regards,
> LIU Hao

Re: Adding a new thread model to GCC

2022-10-19 Thread LIU Hao via Gcc-patches 

在 2022/10/20 03:53, Bernhard Reutner-Fischer 写道:


which has kernel32 twice, which might not be ideal for the speed of linking?
I'm not familiar with the content of ntdll so cannot judge if you'd put that in
MCFGTHREAD_SPEC and drop kernel32 there, though, and put the whole
MCFG spec simply before the kernel32 in the REAL_LIBGCC_SPEC.

i.e.
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lntdll "
...
+   -lmoldname -lmingwex -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 "

I hope this is constructive.
thanks,


NTDLL is the user-mode syscall library i.e. it mainly provides syscalls as 
functions.

Putting `-lmcfgthread` before `-lkernel32` was what I did in the beginning. However, I had an 
impression that NTDLL and KERNEL32 may both export some functions (I believe this is no longer the 
case now). Since MSVCRT in mingw-w64 is not a 'pure' import library and contains some functions that 
we implement on top of KERNEL32, the ideal solution would be


   ```
   #define MCFGTHREAD_SPEC  " -lmcfgthread "
   #define MCFGTHREAD_NTDLL_SPEC  " -lntdll "
 ...
   -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 " MCFGTHREAD_NTDLL_SPEC
   ```

(NTDLL is only necessary when linking against the shared library.)

The committed patch inserted MCFGTHREAD after KERNEL32 for simplicity, but if you do think we had 
better not repeat KERNEL32 twice, I can propose another patch.



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-19 Thread Bernhard Reutner-Fischer via Gcc-patches 
On Wed, 19 Oct 2022 at 15:56, Jonathan Yong via Gcc-patches
 wrote:

> Just pushed to master branch.

Wouldn't you want to cut down on the libs respectively refine the
order of the libs, though?
You've now got:
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lkernel32 -lntdll "
+#else
+#define MCFGTHREAD_SPEC  ""
+#endif
 #undef REAL_LIBGCC_SPEC
 #define REAL_LIBGCC_SPEC \
   "%{mthreads:-lmingwthrd} -lmingw32 \
" SHARED_LIBGCC_SPEC " \
-   -lmoldname -lmingwex -lmsvcrt -lkernel32"
+   -lmoldname -lmingwex -lmsvcrt -lkernel32 " MCFGTHREAD_SPEC

which has kernel32 twice, which might not be ideal for the speed of linking?
I'm not familiar with the content of ntdll so cannot judge if you'd put that in
MCFGTHREAD_SPEC and drop kernel32 there, though, and put the whole
MCFG spec simply before the kernel32 in the REAL_LIBGCC_SPEC.

i.e.
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lntdll "
...
+   -lmoldname -lmingwex -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 "

I hope this is constructive.
thanks,

Re: Adding a new thread model to GCC

2022-10-19 Thread Jonathan Yong via Gcc-patches 

On 10/14/22 09:39, Jonathan Yong wrote:

On 10/11/22 13:22, LIU Hao wrote:

在 2022-10-10 23:56, LIU Hao 写道:

在 2022-10-04 20:44, LIU Hao 写道:

Attached are revised patches. These are exported from trunk.



Revised further. The patch for libgfortran has been committed to 
trunk today, so I include only the other two.


   * In the second patch, a space character has been inserted after
 `(int)` for clearness.

   * The macro controlling how to build GCC itself has been renamed to
 `TARGET_USING_MCFGTHREAD` for consistency.

   * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a
 more friendly way.

   * When not using mcfgthread, NTDLL is no longer a default library.
 Although all recent Windows versions are based on the NT kernel,
 there could still be people who want to target 9x or CE; thus
 NTDLL is only added when it is potentially necessary, for example
 when linking against the static libgcc.




Attached is the (previous) third patch, with configure scripts 
regenerated.





Any more comments?


Just pushed to master branch.

Re: Adding a new thread model to GCC

2022-10-14 Thread Jonathan Yong via Gcc-patches 

On 10/11/22 13:22, LIU Hao wrote:

在 2022-10-10 23:56, LIU Hao 写道:

在 2022-10-04 20:44, LIU Hao 写道:

Attached are revised patches. These are exported from trunk.



Revised further. The patch for libgfortran has been committed to trunk 
today, so I include only the other two.


   * In the second patch, a space character has been inserted after
 `(int)` for clearness.

   * The macro controlling how to build GCC itself has been renamed to
 `TARGET_USING_MCFGTHREAD` for consistency.

   * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a
 more friendly way.

   * When not using mcfgthread, NTDLL is no longer a default library.
 Although all recent Windows versions are based on the NT kernel,
 there could still be people who want to target 9x or CE; thus
 NTDLL is only added when it is potentially necessary, for example
 when linking against the static libgcc.




Attached is the (previous) third patch, with configure scripts regenerated.




Any more comments?

Re: Adding a new thread model to GCC

2022-10-11 Thread LIU Hao via Gcc-patches 

在 2022-10-10 23:56, LIU Hao 写道:

在 2022-10-04 20:44, LIU Hao 写道:

Attached are revised patches. These are exported from trunk.



Revised further. The patch for libgfortran has been committed to trunk today, so I include only the 
other two.


   * In the second patch, a space character has been inserted after
     `(int)` for clearness.

   * The macro controlling how to build GCC itself has been renamed to
     `TARGET_USING_MCFGTHREAD` for consistency.

   * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a
     more friendly way.

   * When not using mcfgthread, NTDLL is no longer a default library.
     Although all recent Windows versions are based on the NT kernel,
     there could still be people who want to target 9x or CE; thus
     NTDLL is only added when it is potentially necessary, for example
     when linking against the static libgcc.




Attached is the (previous) third patch, with configure scripts regenerated.


--
Best regards,
LIU Hao

From c32690fa4878d8824a0e05e54f614a8dd9ed68b7 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sat, 16 Apr 2022 00:46:23 +0800
Subject: [PATCH 2/2] gcc: Add 'mcf' thread model support from mcfgthread

This patch adds the new thread model `mcf`, which implements mutexes
and condition variables with the mcfgthread library.

Source code for mcfgthread is available at 
.

config/ChangeLog:
* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
model

gcc/config/ChangeLog:
* i386/mingw-mcfgthread.h: New file
* i386/mingw32.h: Add builtin macro and default libraries for
mcfgthread when thread model is `mcf`

gcc/ChangeLog:
* config.gcc: Include 'i386/mingw-mcfgthread.h' when thread model
is `mcf`
* configure.ac: Recognize `mcf` as a valid thread model
* configure: Regenerate

libatomic/ChangeLog:
* configure.tgt: Add new case for `mcf` thread model

libgcc/ChangeLog:
* config.host: Add new cases for `mcf` thread model
* config/i386/gthr-mcf.h: New file
* config/i386/t-mingw-mcfgthread: New file
* config/i386/t-slibgcc-cygming: Add mcfgthread for libgcc DLL
* configure: Regenerate

libstdc++-v3/ChangeLog:
* libsupc++/atexit_thread.cc (__cxa_thread_atexit): Use
implementation from mcfgthread if available
* libsupc++/guard.cc (__cxa_guard_acquire, __cxa_guard_release,
__cxa_guard_abort): Use implementations from mcfgthread if
available
* configure: Regenerate
---
 config/gthr.m4  |  1 +
 gcc/config.gcc  |  3 +++
 gcc/config/i386/mingw-mcfgthread.h  |  1 +
 gcc/config/i386/mingw32.h   | 13 ++-
 gcc/configure   |  2 +-
 gcc/configure.ac|  2 +-
 libatomic/configure.tgt |  2 +-
 libgcc/config.host  |  6 +
 libgcc/config/i386/gthr-mcf.h   |  1 +
 libgcc/config/i386/t-mingw-mcfgthread   |  1 +
 libgcc/config/i386/t-slibgcc-cygming|  6 -
 libgcc/configure|  1 +
 libstdc++-v3/configure  | 13 ++-
 libstdc++-v3/libsupc++/atexit_thread.cc | 20 
 libstdc++-v3/libsupc++/guard.cc | 31 +
 15 files changed, 92 insertions(+), 11 deletions(-)
 create mode 100644 gcc/config/i386/mingw-mcfgthread.h
 create mode 100644 libgcc/config/i386/gthr-mcf.h
 create mode 100644 libgcc/config/i386/t-mingw-mcfgthread

diff --git a/config/gthr.m4 b/config/gthr.m4
index 4b937306ad08..11996247f150 100644
--- a/config/gthr.m4
+++ b/config/gthr.m4
@@ -22,6 +22,7 @@ case $1 in
 tpf)   thread_header=config/s390/gthr-tpf.h ;;
 vxworks)   thread_header=config/gthr-vxworks.h ;;
 win32) thread_header=config/i386/gthr-win32.h ;;
+mcf)   thread_header=config/i386/gthr-mcf.h ;;
 esac
 AC_SUBST(thread_header)
 ])
diff --git a/gcc/config.gcc b/gcc/config.gcc
index eec544ff1bac..1f6adea1ab9b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2091,6 +2091,9 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
if test x$enable_threads = xposix ; then
tm_file="${tm_file} i386/mingw-pthread.h"
fi
+   if test x$enable_threads = xmcf ; then
+   tm_file="${tm_file} i386/mingw-mcfgthread.h"
+   fi
tm_file="${tm_file} i386/mingw32.h"
# This makes the logic if mingw's or the w64 feature set has to be used
case ${target} in
diff --git a/gcc/config/i386/mingw-mcfgthread.h 
b/gcc/config/i386/mingw-mcfgthread.h
new file mode 100644
index ..7d4eda3ed494
--- /dev/null
+++ b/gcc/config/i386/mingw-mcfgthread.h
@@ -0,0 +1 @@
+#define TARGET_USING_MCFGTHREAD  1
diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
index d3ca0cd0279d..b5f31c3da0ac 100644
--- a/gcc/config/i386/mingw32.h
+++ b/gcc/config/i386/mingw32.h
@@

Re: Adding a new thread model to GCC

2022-10-10 Thread LIU Hao via Gcc-patches 

在 2022-10-04 20:44, LIU Hao 写道:

Attached are revised patches. These are exported from trunk.



Revised further. The patch for libgfortran has been committed to trunk today, so I include only the 
other two.


  * In the second patch, a space character has been inserted after
`(int)` for clearness.

  * The macro controlling how to build GCC itself has been renamed to
`TARGET_USING_MCFGTHREAD` for consistency.

  * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a
more friendly way.

  * When not using mcfgthread, NTDLL is no longer a default library.
Although all recent Windows versions are based on the NT kernel,
there could still be people who want to target 9x or CE; thus
NTDLL is only added when it is potentially necessary, for example
when linking against the static libgcc.



--
Best regards,
LIU Hao

From b371849927adba290d1e17e2a43866cc3465eb4c Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sun, 2 Oct 2022 00:57:08 +0800
Subject: [PATCH 1/2] libstdc++/thread: Implement `_GLIBCXX_NPROCS` for Windows

This makes `std::thread::hardware_concurrency()` return the number of
logical processors, instead of zero.

libstdc++-v3/ChangeLog:
* src/c++11/thread.cc (get_nprocs): Add new implementation
for native Windows targets
---
 libstdc++-v3/src/c++11/thread.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 707a4ad415b9..a54bc3e939a0 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -68,6 +68,15 @@ static inline int get_nprocs()
 #elif defined(_GLIBCXX_USE_SC_NPROC_ONLN)
 # include 
 # define _GLIBCXX_NPROCS sysconf(_SC_NPROC_ONLN)
+#elif defined(_WIN32)
+# include 
+static inline int get_nprocs()
+{
+  SYSTEM_INFO sysinfo;
+  GetSystemInfo();
+  return (int) sysinfo.dwNumberOfProcessors;
+}
+# define _GLIBCXX_NPROCS get_nprocs()
 #else
 # define _GLIBCXX_NPROCS 0
 #endif
-- 
2.37.3

From 5df9fa2b8d6ea3c357e7a9fcd42721811ea376ce Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sat, 16 Apr 2022 00:46:23 +0800
Subject: [PATCH 2/2] gcc: Add 'mcf' thread model support from mcfgthread

This patch adds the new thread model `mcf`, which implements mutexes
and condition variables with the mcfgthread library.

Source code for mcfgthread is available at 
.

config/ChangeLog:
* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
model

gcc/config/ChangeLog:
* i386/mingw-mcfgthread.h: New file
* i386/mingw32.h: Add builtin macro and default libraries for
mcfgthread when thread model is `mcf`

gcc/ChangeLog:
* config.gcc: Include 'i386/mingw-mcfgthread.h' when thread model
is `mcf`
* configure.ac: Recognize `mcf` as a valid thread model

libatomic/ChangeLog:
* configure.tgt: Add new case for `mcf` thread model

libgcc/ChangeLog:
* config.host: Add new cases for `mcf` thread model
* config/i386/gthr-mcf.h: New file
* config/i386/t-mingw-mcfgthread: New file
* config/i386/t-slibgcc-cygming: Add mcfgthread for libgcc DLL

libstdc++-v3/ChangeLog:
* libsupc++/atexit_thread.cc (__cxa_thread_atexit): Use
implementation from mcfgthread if available
* libsupc++/guard.cc (__cxa_guard_acquire, __cxa_guard_release,
__cxa_guard_abort): Use implementations from mcfgthread if
available
---
 config/gthr.m4  |  1 +
 gcc/config.gcc  |  3 +++
 gcc/config/i386/mingw-mcfgthread.h  |  1 +
 gcc/config/i386/mingw32.h   | 13 ++-
 gcc/configure.ac|  2 +-
 libatomic/configure.tgt |  2 +-
 libgcc/config.host  |  6 +
 libgcc/config/i386/gthr-mcf.h   |  1 +
 libgcc/config/i386/t-mingw-mcfgthread   |  1 +
 libgcc/config/i386/t-slibgcc-cygming|  6 -
 libstdc++-v3/libsupc++/atexit_thread.cc | 20 
 libstdc++-v3/libsupc++/guard.cc | 31 +
 12 files changed, 83 insertions(+), 4 deletions(-)
 create mode 100644 gcc/config/i386/mingw-mcfgthread.h
 create mode 100644 libgcc/config/i386/gthr-mcf.h
 create mode 100644 libgcc/config/i386/t-mingw-mcfgthread

diff --git a/config/gthr.m4 b/config/gthr.m4
index 4b937306ad08..11996247f150 100644
--- a/config/gthr.m4
+++ b/config/gthr.m4
@@ -22,6 +22,7 @@ case $1 in
 tpf)   thread_header=config/s390/gthr-tpf.h ;;
 vxworks)   thread_header=config/gthr-vxworks.h ;;
 win32) thread_header=config/i386/gthr-win32.h ;;
+mcf)   thread_header=config/i386/gthr-mcf.h ;;
 esac
 AC_SUBST(thread_header)
 ])
diff --git a/gcc/config.gcc b/gcc/config.gcc
index eec544ff1bac..1f6adea1ab9b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2091,6 +2091,9 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
if test x$enable_threads = xposix ; then

Re: Adding a new thread model to GCC

2022-10-04 Thread Xi Ruoyao via Gcc-patches 
On Tue, 2022-10-04 at 21:45 +0800, LIU Hao wrote:
> 在 2022-10-04 21:13, Xi Ruoyao 写道:
> > 
> > In GCC development we usually include the configure regeneration in the
> > patch because the scripts are also version controlled.
> > 
> 
> There is a reason for not doing that: Generated contents can't be reviewed.
> 
> In mingw-w64 we do the opposite: The person who commits a patch is 
> responsible for update configure, 
> Makefile.in, etc. The patch itself doesn't include generated contents.

The reviewer can simply skip the changes in configure.  But including
the configure allows the potential testers to test the change without
autoconf-2.69 installed.

Maybe we can make a compromise: put the line "configure: Regenerate." in
the ChangeLog, but do not actually include the change.  Now if the
committer forgot to regenerate it, the git hook will reject the push
immediately.

(Just my 2 cents.)
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Adding a new thread model to GCC

2022-10-04 Thread Bernhard Reutner-Fischer via Gcc-patches 
On 4 October 2022 10:06:00 CEST, LIU Hao  wrote:
>在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道:
>> 
>> No, sorry for my brevity.
>> Using __gthread_t like in your patch is correct.
>> 
>
>I see. In 'libgfortran/io/async.c' there is
>
>  ```
>async_unit *au = u->au;
>LOCK (>lock);
>thread_unit = u;
>au->thread = __gthread_self ();
>  ```
>
>so indeed `thread` should be `__gthread_t`.

Yes.

> By the way I reported this issue four months ago and haven't received any 
> response so far:
>
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764

So, ideally, you would mention this PR in your patch.

LGTM (obvious even) but I cannot formally approve it.
thanks,

Re: Adding a new thread model to GCC

2022-10-04 Thread LIU Hao via Gcc-patches 

在 2022-10-04 21:13, Xi Ruoyao 写道:


In GCC development we usually include the configure regeneration in the
patch because the scripts are also version controlled.



There is a reason for not doing that: Generated contents can't be reviewed.

In mingw-w64 we do the opposite: The person who commits a patch is responsible for update configure, 
Makefile.in, etc. The patch itself doesn't include generated contents.




It's better to include the ID in the subject and ChangeLog of the patch.
Like:

[PATCH 1/3] libgfortran: Use `__gthread_t` instead of `pthread_t` [PR 
105764]

It used to cause errors if a thread model other than `posix` was selected,

which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf.

libgfortran/ChangeLog:

	PR libgfortran/105764

* io/async.h (struct async_unit): Use `__gthread_t` instead
of `pthread_t`.



Yes I think this change is good.




And, from https://gcc.gnu.org/contribute.html#patches:

"It is strongly discouraged to post patches as MIME parts of type
application/whatever, disposition attachment or encoded as base64 or
quoted-printable."

Just try "git send-email", it will do the correct thing.  Mimicking its
behavior in a mail client is also possible but error-prune (the mail
client can destroy your patch by replacing your tabs with spaces, etc.)



It's 'discouraged'. It is not forbidden. I expect everywhere people who receive emails to accept 
attachments. Thunderbird has a nice feature to display text attachments inline, so there is no need 
to download it and open it with an external editor, or whatever.



And, I never get `git send-mail` work on my machine:

   ```
   Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y
   Unable to initialize SMTP properly. Check config and use --smtp-debug. VA
   LUES: server=smtp.126.com encryption=tls hello=localhost.localdomain port
   =465 at /usr/lib/git-core/git-send-email line 1684,  line 3.
   ```




--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-04 Thread Xi Ruoyao via Gcc-patches 
I don't really understand MinGW, but some "non-technical" things:

On Tue, 2022-10-04 at 20:44 +0800, LIU Hao via Gcc-patches wrote:
> After applying these patches, configure scripts in these
> subdirectories need to be regenerated:
> 
>    * gcc
>    * libgcc
>    * libatomic
>    * libstdc++-v3

In GCC development we usually include the configure regeneration in the
patch because the scripts are also version controlled.

> The patch for libgfortran fixes
> 
>* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764

It's better to include the ID in the subject and ChangeLog of the patch.
Like:

   [PATCH 1/3] libgfortran: Use `__gthread_t` instead of `pthread_t` [PR 105764]
   
   It used to cause errors if a thread model other than `posix` was selected,
   which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf.
   
   libgfortran/ChangeLog:
   
PR libgfortran/105764
* io/async.h (struct async_unit): Use `__gthread_t` instead
of `pthread_t`.

This allows a git hook to append a message into the PR 105764 entry in
bugzilla once the patch is committed into trunk.

Normally I leave an empty line after "ChangeLog:" but I'm not sure if
it's strictly needed.

> gcc/config/ChangeLog:
>   * i386/mingw-mcfgthread.h: New file
>   * i386/mingw32.h: Add builtin macro and default libraries for
>   mcfgthread when thread model is `mcf`

Normally I leave a "." for each ChangeLog entry, but I'm not sure if
it's strictly needed.  However there is no gcc/config/ChangeLog, use
gcc/ChangeLog instead.

And, from https://gcc.gnu.org/contribute.html#patches:

"It is strongly discouraged to post patches as MIME parts of type
application/whatever, disposition attachment or encoded as base64 or
quoted-printable."

Just try "git send-email", it will do the correct thing.  Mimicking its
behavior in a mail client is also possible but error-prune (the mail
client can destroy your patch by replacing your tabs with spaces, etc.)

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Adding a new thread model to GCC

2022-10-04 Thread LIU Hao via Gcc-patches 

Attached are revised patches. These are exported from trunk.


There is a change since my last message:

  * A new Makefile variable `SHLIB_MCFGTHREAD_LIBS` has been introduced, to keep
the other thread models from being affected.


After applying these patches, configure scripts in these subdirectories need to 
be regenerated:

  * gcc
  * libgcc
  * libatomic
  * libstdc++-v3


The patch for libgfortran fixes

  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764


I have successfully bootstrapped GCC 12 with these patches, on i686-w64-mingw32 (with MSVCRT) and 
x86_64-w64-mingw32 (with MSVCRT and UCRT). No errors have been observed so far.


Once these patches land in GCC, we can start the work in mingw-w64 basing on 
`__USING_MCFGTHREAD__`.



--
Best regards,
LIU Hao

From e1ab15fc95ac8180156feed410cacb64a41a9567 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Fri, 27 May 2022 23:12:48 +0800
Subject: [PATCH 1/3] libgfortran: Use `__gthread_t` instead of `pthread_t`

It used to cause errors if a thread model other than `posix` was selected,
which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf.

libgfortran/ChangeLog:
* io/async.h (struct async_unit): Use `__gthread_t` instead
of `pthread_t`.

---
 libgfortran/io/async.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgfortran/io/async.h b/libgfortran/io/async.h
index efd542a45e82..d57722a95e44 100644
--- a/libgfortran/io/async.h
+++ b/libgfortran/io/async.h
@@ -351,7 +351,7 @@ typedef struct async_unit
   struct adv_cond work;
   struct adv_cond emptysignal;
   struct st_parameter_dt *pdt;
-  pthread_t thread;
+  __gthread_t thread;
   struct transfer_queue *head;
   struct transfer_queue *tail;
 
-- 
2.37.3

From 0376949aae74b92a7ba327881672e038c3c0d825 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sun, 2 Oct 2022 00:57:08 +0800
Subject: [PATCH 2/3] libstdc++/thread: Implement `_GLIBCXX_NPROCS` for Windows

This makes `std::thread::hardware_concurrency()` return the number of
logical processors, instead of zero.

libstdc++-v3/ChangeLog:
* src/c++11/thread.cc (get_nprocs): Add new implementation
for native Windows targets

---
 libstdc++-v3/src/c++11/thread.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 707a4ad415b9..b39d9f4a9e29 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -68,6 +68,15 @@ static inline int get_nprocs()
 #elif defined(_GLIBCXX_USE_SC_NPROC_ONLN)
 # include 
 # define _GLIBCXX_NPROCS sysconf(_SC_NPROC_ONLN)
+#elif defined(_WIN32)
+# include 
+static inline int get_nprocs()
+{
+  SYSTEM_INFO sysinfo;
+  GetSystemInfo();
+  return (int)sysinfo.dwNumberOfProcessors;
+}
+# define _GLIBCXX_NPROCS get_nprocs()
 #else
 # define _GLIBCXX_NPROCS 0
 #endif
-- 
2.37.3

From d69cbaca07cd7b0e2d725574c8d5913b1c5e0bd5 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sat, 16 Apr 2022 00:46:23 +0800
Subject: [PATCH 3/3] gcc: Add 'mcf' thread model support from mcfgthread

This patch adds the new thread model `mcf`, which implements mutexes
and condition variables with the mcfgthread library.

Source code for mcfgthread is available at 
.

config/ChangeLog:
* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
model

gcc/config/ChangeLog:
* i386/mingw-mcfgthread.h: New file
* i386/mingw32.h: Add builtin macro and default libraries for
mcfgthread when thread model is `mcf`

gcc/ChangeLog:
* config.gcc: Include 'i386/mingw-mcfgthread.h' when thread model
is `mcf`
* configure.ac: Recognize `mcf` as a valid thread model

libatomic/ChangeLog:
* configure.tgt: Add new case for `mcf` thread model

libgcc/ChangeLog:
* config.host: Add new cases for `mcf` thread model
* config/i386/gthr-mcf.h: New file
* config/i386/t-mingw-mcfgthread: New file
* config/i386/t-slibgcc-cygming: Add mcfgthread for libgcc DLL

libstdc++-v3/ChangeLog:
* libsupc++/atexit_thread.cc (__cxa_thread_atexit): Use
implementation from mcfgthread if available
* libsupc++/guard.cc (__cxa_guard_acquire, __cxa_guard_release,
__cxa_guard_abort): Use implementations from mcfgthread if
available

---
 config/gthr.m4  |  1 +
 gcc/config.gcc  |  3 +++
 gcc/config/i386/mingw-mcfgthread.h  |  1 +
 gcc/config/i386/mingw32.h   | 11 -
 gcc/configure.ac|  2 +-
 libatomic/configure.tgt |  2 +-
 libgcc/config.host  |  6 +
 libgcc/config/i386/gthr-mcf.h   |  1 +
 libgcc/config/i386/t-mingw-mcfgthread   |  1 +
 libgcc/config/i386/t-slibgcc-cygming|  6 -
 libstdc++-v3/libsupc++/atexit_thread.cc | 20 
 libstdc++-v3/libsupc++/guard.cc | 31

Re: Adding a new thread model to GCC

2022-10-04 Thread LIU Hao via Gcc-patches 

在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道:


No, sorry for my brevity.
Using __gthread_t like in your patch is correct.



I see. In 'libgfortran/io/async.c' there is

  ```
async_unit *au = u->au;
LOCK (>lock);
thread_unit = u;
au->thread = __gthread_self ();
  ```

so indeed `thread` should be `__gthread_t`. By the way I reported this issue four months ago and 
haven't received any response so far:


  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764


--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-02 Thread Bernhard Reutner-Fischer via Gcc-patches 
On 2 October 2022 14:54:54 CEST, LIU Hao  wrote:
>在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
>> On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches 
>>  wrote:
>>> Greetings.
>> 
>>> The first patch is necessary because somewhere in libgfortran, `pthread_t` 
>>> is referenced. If the thread model is not `posix`, it fails to compile.
>> 
>> One of several shortcomings mentioned already on Sun, 02 Sep 2018 15:40:28 
>> -0700 in
>> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg196212.html
>> 
>
>Forgive me but I didn't get your point. Is the 'shortcoming' the fact that 
>`pthread_t` must be preferred to `__gthread_t`?

No, sorry for my brevity.
Using __gthread_t like in your patch is correct.

thanks,

>
>For non-posix thread models,  is not included, so `pthread_t` is 
>not declared. I haven't looked at other code in libgfortran, but changing 
>`pthread_t` to `__gthread_t` does allow libgfortran to build. I don't know how 
>to test it though, as I don't write Fortran myself.
>
>

Re: Adding a new thread model to GCC

2022-10-02 Thread LIU Hao via Gcc-patches 

在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:

On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches 
 wrote:

Greetings.



The first patch is necessary because somewhere in libgfortran, `pthread_t` is 
referenced. If the thread model is not `posix`, it fails to compile.


One of several shortcomings mentioned already on Sun, 02 Sep 2018 15:40:28 
-0700 in
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg196212.html



Forgive me but I didn't get your point. Is the 'shortcoming' the fact that `pthread_t` must be 
preferred to `__gthread_t`?


For non-posix thread models,  is not included, so `pthread_t` is not declared. I haven't 
looked at other code in libgfortran, but changing `pthread_t` to `__gthread_t` does allow 
libgfortran to build. I don't know how to test it though, as I don't write Fortran myself.



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding a new thread model to GCC

2022-10-01 Thread Bernhard Reutner-Fischer via Gcc-patches 
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches 
 wrote:
>Greetings.

>The first patch is necessary because somewhere in libgfortran, `pthread_t` is 
>referenced. If the thread model is not `posix`, it fails to compile.

One of several shortcomings mentioned already on Sun, 02 Sep 2018 15:40:28 
-0700 in
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg196212.html

Adding a new thread model to GCC

2022-10-01 Thread LIU Hao via Gcc-patches 

Greetings.

After some years I think it's time to put on this topic again.

This patch series is an attempt to add a new thread model basing on the mcfgthread library 
(https://github.com/lhmouse/mcfgthread), which provides efficient implementations of mutexes, 
condition variables, once flags, etc. for native Windows.



The first patch is necessary because somewhere in libgfortran, `pthread_t` is referenced. If the 
thread model is not `posix`, it fails to compile.


The second patch implements `std::thread::hardware_concurrency()` for non-posix thread models. This 
would also work for the win32 thread model if `std::thread` would be supported in the future.


The third patch adds the `mcf` thread model for GCC and its libraries. A new builtin macro 
`__USING_MCFGTHREAD__` is added to indicate whether this new thread model is in effect. This grants 
`std::mutex` and `std::once_flag` trivial destructors; `std::condition_variable` is a bit 
unfortunate because its destructor is non-trivial, but in reality no cleanup is performed.



I have been bootstrapping GCC with the MCF thread model for more than five years. At the moment, C, 
C++ and Fortran are supported. Ada is untested because I don't know how to bootstrap it. Objective-C 
is not supported, because threading APIs for libobjc have not been implemented.


Please review. If there are any changes that I have to make, let me know.


--
Best regards,
LIU Hao
From c522fa74c791ee8904b5906c6e18908b56071db5 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Fri, 27 May 2022 23:12:48 +0800
Subject: [PATCH 1/3] libgfortran: Use `__gthread_t` instead of `pthread_t`

It used to cause errors if a thread model other than `posix` was selected,
which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf.

libgfortran/ChangeLog:
* io/async.h (struct async_unit): Use `__gthread_t` instead
of `pthread_t`.
---
 libgfortran/io/async.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgfortran/io/async.h b/libgfortran/io/async.h
index efd542a45e82..d57722a95e44 100644
--- a/libgfortran/io/async.h
+++ b/libgfortran/io/async.h
@@ -351,7 +351,7 @@ typedef struct async_unit
   struct adv_cond work;
   struct adv_cond emptysignal;
   struct st_parameter_dt *pdt;
-  pthread_t thread;
+  __gthread_t thread;
   struct transfer_queue *head;
   struct transfer_queue *tail;
 
-- 
2.37.3

From fcae3b25b859a207152927797c5ebc520ef3d61a Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sun, 2 Oct 2022 00:57:08 +0800
Subject: [PATCH 2/3] libstdc++/thread: Implement `_GLIBCXX_NPROCS` for Windows

This makes `std::thread::hardware_concurrency()` return the number of
logical processors, instead of zero.

libstdc++-v3/ChangeLog:
* src/c++11/thread.cc (get_nprocs): Add new implementation
for native Windows targets
---
 libstdc++-v3/src/c++11/thread.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 707a4ad415b9..b39d9f4a9e29 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -68,6 +68,15 @@ static inline int get_nprocs()
 #elif defined(_GLIBCXX_USE_SC_NPROC_ONLN)
 # include 
 # define _GLIBCXX_NPROCS sysconf(_SC_NPROC_ONLN)
+#elif defined(_WIN32)
+# include 
+static inline int get_nprocs()
+{
+  SYSTEM_INFO sysinfo;
+  GetSystemInfo();
+  return (int)sysinfo.dwNumberOfProcessors;
+}
+# define _GLIBCXX_NPROCS get_nprocs()
 #else
 # define _GLIBCXX_NPROCS 0
 #endif
-- 
2.37.3

From d0f78f3f83d134d91b59e553b115521f8d67ef52 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Sat, 16 Apr 2022 00:46:23 +0800
Subject: [PATCH 3/3] gcc: Add 'mcf' thread model support from mcfgthread

This patch adds the new thread model `mcf`, which implements mutexes
and condition variables with the mcfgthread library.

Source code for mcfgthread is available at 
.

config/ChangeLog:
* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
model

gcc/config/ChangeLog:
* i386/mingw-mcfgthread.h: New file
* i386/mingw32.h: Add builtin macro and default libraries for
mcfgthread when thread model is `mcf`

gcc/ChangeLog:
* config.gcc: Include 'i386/mingw-mcfgthread.h' when thread model
is `mcf`
* configure.ac: Recognize `mcf` as a valid thread model

libatomic/ChangeLog:
* configure.tgt: Add new case for `mcf` thread model

libgcc/ChangeLog:
* config.host: Add new cases for `mcf` thread model
* config/i386/gthr-mcf.h: New file
* config/i386/t-mingw-mcfgthread: New file
* config/i386/t-slibgcc-cygming: Make CRT depend on threading
library, not vice versa

libstdc++-v3/ChangeLog:
* libsupc++/atexit_thread.cc (__cxa_thread_atexit): Use
implementation from mcfgthread if available
* libsupc++/guard.cc (__cxa_guard_acquire, __cxa_guard_release,
__cxa_guard_abort):