> 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
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.
bootst
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 pl
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.
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,
fro
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,
fro
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,
fro
On 2022-12-23 23:59, Jonathan Yong wrote:
Done, pushed to master branch. Thanks Eric.
thank you Jonathan!
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
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 li
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++ par
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
separatel
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 pat
> 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
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
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
> 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, b
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, sql
> 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 fa
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
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 th
> 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
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
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
> 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
implementa
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
在 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 patc
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 reimple
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/
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 li
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
在 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
在 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
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
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
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 o
> 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
在 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 W
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 woul
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 th
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.
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:
在 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
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
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
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
在 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 i
在 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 clea
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
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 (&au->lock);
>
在 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
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
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 subd
在 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 (&au->lock);
thread_unit = u;
au->thread = __gthread_self ();
```
so i
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 thr
在 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 sh
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:
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, et
58 matches
Mail list logo
