> 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 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 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-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:
13 matches
Mail list logo
