* 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
[parent not found: <21655510.EfDdHjke4D@fomalhaut>]
[parent not found: <CACb0b4nhp89FmAHkuYEZs=nsL4Ge3oEV3G_gZ28FkDuud+Zxpg@mail.gmail.com>]
[parent not found: <2092961.OBFZWjSADL@fomalhaut>]
[parent not found: <45c84c01-74ca-3739-6482-2bbc94de0e9a@gmail.com>]
[parent not found: <00af136c637f5231670c0fb6f7906d42@autistici.org>]
[parent not found: <f454d3d7-3e70-6eb3-44d6-8213b6888a37@gmail.com>]
* 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).