* Re: Adding a new thread model to GCC
[not found] <0f1f223a-3756-1da3-bd1d-b87edd34e1f9@126.com>
@ 2022-10-01 20:02 ` Bernhard Reutner-Fischer
2022-10-02 12:54 ` LIU Hao
[not found] ` <21655510.EfDdHjke4D@fomalhaut>
1 sibling, 1 reply; 13+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-10-01 20:02 UTC (permalink / raw)
To: LIU Hao, LIU Hao via Gcc-patches, gcc-patches, libstdc++; +Cc: fortran
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches <gcc-patches@gcc.gnu.org> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-10-01 20:02 ` Adding a new thread model to GCC Bernhard Reutner-Fischer
@ 2022-10-02 12:54 ` LIU Hao
2022-10-03 5:03 ` Bernhard Reutner-Fischer
0 siblings, 1 reply; 13+ messages in thread
From: LIU Hao @ 2022-10-02 12:54 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, LIU Hao via Gcc-patches; +Cc: fortran
[-- Attachment #1.1: Type: text/plain, Size: 936 bytes --]
在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
> On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches <gcc-patches@gcc.gnu.org> 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, <pthread.h> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-10-02 12:54 ` LIU Hao
@ 2022-10-03 5:03 ` Bernhard Reutner-Fischer
2022-10-04 8:06 ` LIU Hao
0 siblings, 1 reply; 13+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-10-03 5:03 UTC (permalink / raw)
To: LIU Hao, LIU Hao via Gcc-patches; +Cc: fortran
On 2 October 2022 14:54:54 CEST, LIU Hao <lh_mouse@126.com> wrote:
>在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
>> On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches <gcc-patches@gcc.gnu.org> 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, <pthread.h> 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.
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-10-03 5:03 ` Bernhard Reutner-Fischer
@ 2022-10-04 8:06 ` LIU Hao
2022-10-04 19:45 ` Bernhard Reutner-Fischer
0 siblings, 1 reply; 13+ messages in thread
From: LIU Hao @ 2022-10-04 8:06 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, LIU Hao via Gcc-patches; +Cc: fortran
[-- Attachment #1.1: Type: text/plain, Size: 558 bytes --]
在 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 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-10-04 8:06 ` LIU Hao
@ 2022-10-04 19:45 ` Bernhard Reutner-Fischer
0 siblings, 0 replies; 13+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-10-04 19:45 UTC (permalink / raw)
To: LIU Hao, LIU Hao via Gcc-patches; +Cc: fortran
On 4 October 2022 10:06:00 CEST, LIU Hao <lh_mouse@126.com> 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);
> 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,
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
[not found] ` <f454d3d7-3e70-6eb3-44d6-8213b6888a37@gmail.com>
@ 2022-12-24 5:58 ` NightStrike
2022-12-24 6:27 ` i.nixman
2022-12-24 13:50 ` i.nixman
0 siblings, 2 replies; 13+ messages in thread
From: NightStrike @ 2022-12-24 5:58 UTC (permalink / raw)
To: Jonathan Yong, fortran; +Cc: i.nixman, libstdc++, gcc-patches
On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On 12/22/22 12:28, i.nixman@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,
| ^~~~~~~
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 5:58 ` NightStrike
@ 2022-12-24 6:27 ` i.nixman
2022-12-24 13:50 ` i.nixman
1 sibling, 0 replies; 13+ messages in thread
From: i.nixman @ 2022-12-24 6:27 UTC (permalink / raw)
To: NightStrike; +Cc: Eric Botcazou, fortran, libstdc++, 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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 5:58 ` NightStrike
2022-12-24 6:27 ` i.nixman
@ 2022-12-24 13:50 ` i.nixman
2022-12-24 15:42 ` i.nixman
1 sibling, 1 reply; 13+ messages in thread
From: i.nixman @ 2022-12-24 13:50 UTC (permalink / raw)
To: NightStrike; +Cc: fortran, i.nixman, libstdc++, 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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 13:50 ` i.nixman
@ 2022-12-24 15:42 ` i.nixman
2022-12-24 15:57 ` i.nixman
0 siblings, 1 reply; 13+ messages in thread
From: i.nixman @ 2022-12-24 15:42 UTC (permalink / raw)
To: Jonathan Yong; +Cc: fortran, libstdc++, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On 2022-12-24 13:50, i.nixman@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!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cc_none-in-libgfortran-conflict.patch --]
[-- Type: text/x-diff; name=cc_none-in-libgfortran-conflict.patch, Size: 574 bytes --]
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 <windows.h>
-/* 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;
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 15:42 ` i.nixman
@ 2022-12-24 15:57 ` i.nixman
2022-12-24 21:22 ` i.nixman
0 siblings, 1 reply; 13+ messages in thread
From: i.nixman @ 2022-12-24 15:57 UTC (permalink / raw)
To: Jonathan Yong; +Cc: fortran, libstdc++, gcc-patches
On 2022-12-24 15:42, i.nixman@autistici.org wrote:
> fixed and tested.
>
> Jonathan Yong, could you please apply the attached patch too?
>
>
>
> kings regards!
oh no...
please wait.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 15:57 ` i.nixman
@ 2022-12-24 21:22 ` i.nixman
2022-12-25 1:10 ` Jonathan Yong
2023-01-09 21:56 ` Eric Botcazou
0 siblings, 2 replies; 13+ messages in thread
From: i.nixman @ 2022-12-24 21:22 UTC (permalink / raw)
To: Jonathan Yong; +Cc: fortran, libstdc++, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
On 2022-12-24 15:57, i.nixman@autistici.org wrote:
> On 2022-12-24 15:42, i.nixman@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!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cc_none-in-libgfortran-conflict.patch --]
[-- Type: text/x-diff; name=cc_none-in-libgfortran-conflict.patch, Size: 811 bytes --]
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 <windows.h>
-/* 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 <windows.h>
+#undef CC_NONE
__GTHREAD_WIN32_INLINE int
__gthread_detach (__gthread_t __thr)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 21:22 ` i.nixman
@ 2022-12-25 1:10 ` Jonathan Yong
2023-01-09 21:56 ` Eric Botcazou
1 sibling, 0 replies; 13+ messages in thread
From: Jonathan Yong @ 2022-12-25 1:10 UTC (permalink / raw)
To: i.nixman; +Cc: fortran, libstdc++, gcc-patches
On 12/24/22 21:22, i.nixman@autistici.org wrote:
> On 2022-12-24 15:57, i.nixman@autistici.org wrote:
>> On 2022-12-24 15:42, i.nixman@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Adding a new thread model to GCC
2022-12-24 21:22 ` i.nixman
2022-12-25 1:10 ` Jonathan Yong
@ 2023-01-09 21:56 ` Eric Botcazou
1 sibling, 0 replies; 13+ messages in thread
From: Eric Botcazou @ 2023-01-09 21:56 UTC (permalink / raw)
To: Jonathan Yong; +Cc: gcc-patches, fortran, libstdc++, gcc-patches, i.nixman
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-01-09 21:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <0f1f223a-3756-1da3-bd1d-b87edd34e1f9@126.com>
2022-10-01 20:02 ` Adding a new thread model to GCC Bernhard Reutner-Fischer
2022-10-02 12:54 ` LIU Hao
2022-10-03 5:03 ` Bernhard Reutner-Fischer
2022-10-04 8:06 ` LIU Hao
2022-10-04 19:45 ` Bernhard Reutner-Fischer
[not found] ` <21655510.EfDdHjke4D@fomalhaut>
[not found] ` <CACb0b4nhp89FmAHkuYEZs=nsL4Ge3oEV3G_gZ28FkDuud+Zxpg@mail.gmail.com>
[not found] ` <2092961.OBFZWjSADL@fomalhaut>
[not found] ` <45c84c01-74ca-3739-6482-2bbc94de0e9a@gmail.com>
[not found] ` <00af136c637f5231670c0fb6f7906d42@autistici.org>
[not found] ` <f454d3d7-3e70-6eb3-44d6-8213b6888a37@gmail.com>
2022-12-24 5:58 ` NightStrike
2022-12-24 6:27 ` i.nixman
2022-12-24 13:50 ` i.nixman
2022-12-24 15:42 ` i.nixman
2022-12-24 15:57 ` i.nixman
2022-12-24 21:22 ` i.nixman
2022-12-25 1:10 ` Jonathan Yong
2023-01-09 21:56 ` Eric Botcazou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).