gcc-13-20221106 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20221106 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20221106/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision c56826d0f3b143a9cb64ee263707046f8073c1b6

You'll find:

 gcc-13-20221106.tar.xz   Complete GCC

  SHA256=52167bafadf042b809283f22c1ad65999667fc61f4da830a01158b8dceae0201
  SHA1=5ed42f1d12628661933fae4713487a1979839cfc

Diffs from 13-20221030 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

why does gccgit require pthread?

[LIU Hao via Gcc]

Greetings,

At the moment, there are references to pthread mutexes in 'gcc/jit/libgccjit.cc' and 
'gcc/git/jit-playback.cc'. The former was introduced by 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in 
2020, while the latter was introduced by 38771e4e1fdacfbdac5a14e50fcc0538577b1bdb in 2014.


Does this mean, GCC can't be built with JIT enabled, for some thread model other than `posix` (e.g. 
`win32`), where pthread isn't available?


Can those references to mutexes be replaced with `__gthread_mutex_*` instead? However I see no other 
references to  inside the 'gcc' subdirectory, so I suspect it isn't an option there?



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: why does gccgit require pthread?

[Andrew Pinski via Gcc]

On Sun, Nov 6, 2022 at 7:59 PM LIU Hao via Gcc  wrote:
>
> Greetings,
>
> At the moment, there are references to pthread mutexes in 
> 'gcc/jit/libgccjit.cc' and
> 'gcc/git/jit-playback.cc'. The former was introduced by 
> 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in
> 2020, while the latter was introduced by 
> 38771e4e1fdacfbdac5a14e50fcc0538577b1bdb in 2014.
>
> Does this mean, GCC can't be built with JIT enabled, for some thread model 
> other than `posix` (e.g.
> `win32`), where pthread isn't available?
>
> Can those references to mutexes be replaced with `__gthread_mutex_*` instead? 
> However I see no other
> references to  inside the 'gcc' subdirectory, so I suspect it isn't 
> an option there?

The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason not to move them over
to using C++11 threading code.

Thanks,
Andrew


Thanks,
Andrew Pinski

>
>
> --
> Best regards,
> LIU Hao

Re: why does gccgit require pthread?

[LIU Hao via Gcc]

在 2022-11-07 12:37, Andrew Pinski 写道:


The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason not to move them over
to using C++11 threading code.




Attached is the proposed patch.

The win32 thread model does not have `std::mutex`; but there is no `pthread_mutex_t` either, so it 
does not build either way.


Tested bootstrapping GCC on `{i686,x86_64}-w64-mingw32` with languages 
`c,lto,c++,fortran,objc,obj-c++` and with the `mcf` thread model; no errors observed. The built 
`libgccjit-0.dll` does not have imports from winpthread any more.


Please review.


--
Best regards,
LIU Hao

From ceb65f21b5ac23ce218efee82f40f641ebe44361 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Mon, 7 Nov 2022 13:00:12 +0800
Subject: [PATCH] gcc/jit: Use C++11 mutex instead of pthread's

This allows JIT to be built with a different thread model from `posix`
where pthread isn't available

gcc/jit/ChangeLog:

* jit-playback.cc: Use `std::mutex` instead of `pthread_mutex_t`
(playback::context::acquire_mutex): Likewise
(playback::context::release_mutex): Likewise
* jit-recording.cc: Remove the unused `INCLUDE_PTHREAD_H`
* libgccjit.cc: Use `std::mutex` instead of `pthread_mutex_t`
---
 gcc/jit/jit-playback.cc  | 9 +
 gcc/jit/jit-recording.cc | 1 -
 gcc/jit/libgccjit.cc | 8 
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index d227d36283a..17ff98c149b 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -19,7 +19,6 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
-#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "target.h"
@@ -51,6 +50,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "jit-w32.h"
 #endif
 
+#include 
+
 /* Compare with gcc/c-family/c-common.h: DECL_C_BIT_FIELD,
SET_DECL_C_BIT_FIELD.
These are redefined here to avoid depending from the C frontend.  */
@@ -2662,7 +2663,7 @@ playback::compile_to_file::copy_file (const char 
*src_path,
 /* This mutex guards gcc::jit::recording::context::compile, so that only
one thread can be accessing the bulk of GCC's state at once.  */
 
-static pthread_mutex_t jit_mutex = PTHREAD_MUTEX_INITIALIZER;
+static std::mutex jit_mutex;
 
 /* Acquire jit_mutex and set "this" as the active playback ctxt.  */
 
@@ -2673,7 +2674,7 @@ playback::context::acquire_mutex ()
 
   /* Acquire the big GCC mutex. */
   JIT_LOG_SCOPE (get_logger ());
-  pthread_mutex_lock (&jit_mutex);
+  jit_mutex.lock ();
   gcc_assert (active_playback_ctxt == NULL);
   active_playback_ctxt = this;
 }
@@ -2687,7 +2688,7 @@ playback::context::release_mutex ()
   JIT_LOG_SCOPE (get_logger ());
   gcc_assert (active_playback_ctxt == this);
   active_playback_ctxt = NULL;
-  pthread_mutex_unlock (&jit_mutex);
+  jit_mutex.unlock ();
 }
 
 /* Callback used by gcc::jit::playback::context::make_fake_args when
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index f78daed2d71..6ae5a667e90 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -19,7 +19,6 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
-#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index ca862662777..a5105fbc1f9 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -19,7 +19,6 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
-#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "timevar.h"
@@ -30,6 +29,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "jit-recording.h"
 #include "jit-result.h"
 
+#include 
+
 /* The opaque types used by the public API are actually subclasses
of the gcc::jit::recording classes.  */
 
@@ -4060,7 +4061,7 @@ gcc_jit_context_new_rvalue_from_vector (gcc_jit_context 
*ctxt,
Ideally this would be within parse_basever, but the mutex is only needed
by libgccjit.  */
 
-static pthread_mutex_t version_mutex = PTHREAD_MUTEX_INITIALIZER;
+static std::mutex version_mutex;
 
 struct jit_version_info
 {
@@ -4068,9 +4069,8 @@ struct jit_version_info
  guarded by version_mutex.  */
   jit_version_info ()
   {
-pthread_mutex_lock (&version_mutex);
+std::lock_guard g (version_mutex);
 parse_basever (&major, &minor, &patchlevel);
-pthread_mutex_unlock (&version_mutex);
   }
 
   int major;
-- 
2.38.1



OpenPGP_signature
Description: OpenPGP digital signature

Re: why does gccgit require pthread?

[Andrew Pinski via Gcc]

On Sun, Nov 6, 2022 at 10:51 PM LIU Hao  wrote:
>
> 在 2022-11-07 12:37, Andrew Pinski 写道:
> >
> > The original code which used pthread was added in GCC 5 way before GCC
> > moved to being written in C++11 which was only in the last 3 years.
> > pthread_* functions were the best choice at the time (2014) but now
> > GCC is written in C++11, I don't see any reason not to move them over
> > to using C++11 threading code.
> >
> >
>
> Attached is the proposed patch.
>
> The win32 thread model does not have `std::mutex`; but there is no 
> `pthread_mutex_t` either, so it
> does not build either way.
Oh, but I would assume it will later on right?

Also I think you might need to change some more than you did.
That is:
-#define INCLUDE_PTHREAD_H
 #include "system.h"

You must likely have a macro, INCLUDE_MUTEX, and define that and
include mutex in system.h like it was done for pthread.h.
GCC loves to poison identifiers while lexing to make sure those
identifiers are not used inside GCC and the include of mutex should be
done early.

Thanks,
Andrew

>
> Tested bootstrapping GCC on `{i686,x86_64}-w64-mingw32` with languages
> `c,lto,c++,fortran,objc,obj-c++` and with the `mcf` thread model; no errors 
> observed. The built
> `libgccjit-0.dll` does not have imports from winpthread any more.
>
> Please review.
>
>
> --
> Best regards,
> LIU Hao
>

Re: why does gccgit require pthread?

[LIU Hao via Gcc]

在 2022/11/7 15:03, Andrew Pinski 写道:


The win32 thread model does not have `std::mutex`; but there is no 
`pthread_mutex_t` either, so it
does not build either way.

Oh, but I would assume it will later on right?



There has been effort on C++11 threading support for win32 thread model, but I have a negative 
attitude on that.


Another solution is to use `__gthread_mutex_t` instead of `pthread_mutex_t`, which is also available 
in the win32 thread model. Actually I prefer this approach as it keeps code structure like what we 
have at this moment.




Also I think you might need to change some more than you did.
That is:
-#define INCLUDE_PTHREAD_H
  #include "system.h"

You must likely have a macro, INCLUDE_MUTEX, and define that and
include mutex in system.h like it was done for pthread.h.
GCC loves to poison identifiers while lexing to make sure those
identifiers are not used inside GCC and the include of mutex should be
done early.



Well I am not familiar with such behavior. Feel free to amend the patch, until it looks good to you. 
I hope we can check this in before GCC 13 RC.




--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature