在 2022-11-19 19:27, Jonathan Wakely 写道:
I rebased the patch and re-tested with those options, and all tests
passed again:
=== jit Summary ===
# of expected passes15081
The patch is OK for trunk if you have favorable answers for the above
two questions.
Thanks
On Tue, 15 Nov 2022 at 19:01, Jonathan Wakely wrote:
>
> On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
> >
> > [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
> >
> > On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > > On Mon, 7 Nov 2022 at 13:51, Jonathan
On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
>
> [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
>
> On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> > >
> > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote
[Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> >
> > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > >
> > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > I
On Fri, 11 Nov 2022 at 17:16, Jonathan Wakely wrote:
>
> On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> >
> > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > >
> > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > It would be a lot nicer if playback::context met the C++ Lockable
> > > > requ
or which I don't have time to look
into right now.
commit 5dde4bd09c4706617120a42c5953908ae39b5751
Author: Jonathan Wakely
Date: Fri Nov 11 12:48:29 2022
jit: Use std::mutex instead of pthread_mutex_t
This allows JIT to be built with a different thread model from posix
where p
On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
>
> 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > It would be a lot nicer if playback::context met the C++ Lockable
> > requirements, and playback::context::compile () could just take a
> > scoped lock on *this:
> >
> >
>
> Yeah yeah that makes a lot of sen
在 2022-11-07 20:57, Jonathan Wakely 写道:
It would be a lot nicer if playback::context met the C++ Lockable
requirements, and playback::context::compile () could just take a
scoped lock on *this:
Yeah yeah that makes a lot of sense. Would you please just commit that? I don't have write access t
On Mon, 7 Nov 2022 at 06:51, LIU Hao via Gcc 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_* functio
在 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 ha
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 we
在 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 r
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
> 63b2923dc6f57e74d964a9cf14f4ba5
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 38771e4e1fdacfbdac5a14e50fcc0538577b
- determining threadedness with weak symbols is broken for dynamic
loading and static linking as well (dlopened library can pull in pthread
dependency at runtime, and with static linking a symbol does not indicate
the availability of another)
- using symbols through weak references at runtime is wrong
> a libstdc++ bug, and can be solved by making libstdc++.a use strong
> > references to pthread symbols from std::thread::join() (and perhaps
> > other objects that provide c++ thread support, if there are such).
>
> It's the std::thread constructor template that needs p
On 24 September 2013 13:45, Jakub Jelinek wrote:
> On Tue, Sep 24, 2013 at 01:34:52PM +0100, Jonathan Wakely wrote:
>> On 24 September 2013 13:24, Jakub Jelinek wrote:
>> > On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote:
>> >> It's the std::thread constructor template that needs pt
On Tue, Sep 24, 2013 at 01:34:52PM +0100, Jonathan Wakely wrote:
> On 24 September 2013 13:24, Jakub Jelinek wrote:
> > On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote:
> >> It's the std::thread constructor template that needs pthread_create.
> >> std::thread::join() needs pthread_j
On 24 September 2013 13:24, Jakub Jelinek wrote:
> On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote:
>> It's the std::thread constructor template that needs pthread_create.
>> std::thread::join() needs pthread_join.
>
> Are any references to that needed in libstdc++.so.6, or just in
libstdc++.a use strong
> > references to pthread symbols from std::thread::join() (and perhaps
> > other objects that provide c++ thread support, if there are such).
>
> It's the std::thread constructor template that needs pthread_create.
> std::thread::join() needs pthread_join.
Ar
On 24 September 2013 02:22, Alan Modra wrote:
>
> Try compiling that testcase with -static rather than -Wl,--as-needed.
> You'll hit std::system_error just like you do here. I believe that is
> a libstdc++ bug, and can be solved by making libstdc++.a use strong
> reference
long int *c=&a;
> std::thread t1(factorial,15,c);
> t1.join();
> return 0;
> }
> $ ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.23.2
> $ g++ -Wl,--as-needed -pthread thread.cpp -std=c++11 -o thread && ./thread
>
> $ ld -
$ g++ -Wl,--as-needed -pthread thread.cpp -std=c++11 -o thread && ./thread
$ ld --version
GNU ld (GNU Binutils for Debian) 2.23.52.20130828
$ g++ -Wl,--as-needed -pthread thread.cpp -std=c++11 -o thread && ./thread
terminate called after throwing an instance of 'std::system
On Jun 6, 2012 2:14 PM, "Florian Weimer" wrote:
>
> On 06/06/2012 03:09 PM, Dave Korn wrote:
>>>>
>>>> I am not sure, but AFAICT, -pthread is Linux-specific.
>>>
>>>
>>> No, it's the canonical multi-os option to enable
On 06/06/2012 03:09 PM, Dave Korn wrote:
I am not sure, but AFAICT, -pthread is Linux-specific.
No, it's the canonical multi-os option to enable pthreads, as
generic as it gets.
According to the manual(*), it's a machine-dependent option for RS6000 and
Solaris 2 only!
And the
, then I get several unexpected errors due to:
>>>
>>> gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
>>> '-pthread'
>>> gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option
>>> '-pthread'
>>>
&
On Fri, 18 May 2012, Ian Lance Taylor wrote:
> Joel Sherrill writes:
>
> > On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
> >> Ralf Corsepius writes:
> >>
> >>> I am not sure, but AFAICT, -pthread is Linux-specific.
> >> It's not prop
On Fri, 18 May 2012, Joel Sherrill wrote:
> I don't mind having -pthread be a noop but the leap
> from a having a header file to having a specific gcc
> option is a stretch IMO. Unless EVERY gcc target with
> pthread support is required by gcc to have that option.
> Is t
e/gcc/gcc.log:xgcc: error: unrecognized command line option
> > '-pthread'
> > gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option
> > '-pthread'
> >
> > The -pthread option is not necessary in RTEMS for the pthread API. I
> >
On 18 May 2012 16:53, Joel Sherrill wrote:
> You didn't mention Cygwin in your list
> but otherwise, it is pretty complete.
According to the libstdc++ testsuite, cygwin doesn't require -pthread
I think HPUX does need it, and IIRC when it was supported Tru64 did.
Joel Sherrill writes:
> I agree with you on this one. Would it be a good general
> rule that on a system with pthreads, -pthread should be
> accepted by gcc?
Yes, I think so.
Ian
On 05/18/2012 10:50 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepiuswrites:
I am not sure, but AFAICT, -pthread is Linux-specific.
It'
Joel Sherrill writes:
> On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
>> Joel Sherrill writes:
>>
>>> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
>>>> Ralf Corsepius writes:
>>>>
>>>>> I am not sure, but AFAICT, -pthread is
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including So
Joel Sherrill writes:
> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
>> Ralf Corsepius writes:
>>
>>> I am not sure, but AFAICT, -pthread is Linux-specific.
>> It's not properly documented, but -pthread works on a number of hosts,
>> including Solar
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
Ian.. Is it better to make it a
Ralf Corsepius writes:
> I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
Ian
On 05/18/2012 09:24 AM, Sebastian Huber wrote:
Hi,
if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
target, then I get several unexpected errors due to:
gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
'-pthread'
gcc/testsuite/g++
Hi,
if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
target, then I get several unexpected errors due to:
gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
'-pthread'
gcc/testsuite/g++/g++.log:g++: error: unrecognized command l
Hi,
I have found the solution i.e. the developers of GCC have found it. The latest
version of GCC 4.6.3 can be used with Helgrind. See here for more detail
http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races
Best Regards
Salvatore
Hi,
thank you for your reply. So I cannot use the Helgrind tool without disabling
the futexes. Do you know if exist a open source thread analyzer?
Thank you
On Tue, Feb 21, 2012 at 04:50:58PM +0100, erotavlas_tu...@libero.it wrote:
> Nobody can answer to my question?
You can configure gcc not to use futexes in libgomp (--disable-linux-futex),
but the default is to use them for performance reasons.
Jakub
Nobody can answer to my question?
Thank you
Salvatore Frandina
In the latest version of GCC, is this still true or now the OpenMP uses the
> > standard POSIX pthread?
> >
>
> Do you have a specific OS family in mind?
>
>
> --
> Tim Prince
>
Yes, I'm talking about the UNIX OS (Linux, MacOSx). The tool valgrind is only
available for these systems.
Salvatore Frandina
mp.so) constructs its own synchronisation
primitives using combinations of atomic memory instructions and the futex syscall, which
causes total chaos since in Helgrind since it cannot "see" those.
In the latest version of GCC, is this still true or now the OpenMP uses the
standard POSIX pth
using combinations of atomic memory instructions and
the futex syscall, which causes total chaos since in Helgrind since it cannot
"see" those.
In the latest version of GCC, is this still true or now the OpenMP uses the
standard POSIX pthread?
Thank you
ernel.
your example there is
#include
pthread_mutex_t count_mutex;
long long count;
void increment_count()
{ pthread_mutex_lock(&count_mutex);
count = count + 1;
pthread_mutex_unlock(&count_mutex);
}
As far as I know, there is nothing special in GCC to compile su
Hi,
My name is Edmon Begoli and I am a graduate student in computer science.
I am writing a graduate research paper on how are concurrent routines complied
in different languages. I want to start with a sort of a base case showing how
are Mutexes and thread initiation routines in C compiled by GC
On Tue, 4 May 2010, Ian Lance Taylor wrote:
> On GNU/Linux, you need to use -pthread or -D_REENTRANT at compilation
> time, and you need to use -pthread or -lpthread at link time.
_REENTRANT does essentially nothing (enables getlogin_r when the rest of
POSIX.1:1996 is disabled). See
> On GNU/Linux, you need to use -pthread or -D_REENTRANT at compilation
> time, and you need to use -pthread or -lpthread at link time.
? gcc mailing list certainly worth reading for users. I always thought
that -lpthread at link time is enough.
Alexey
> I agree that this really ought to be documented.
There is an old PR about this: http://gcc.gnu.org/PR16519
--
Eric Botcazou
Magnus Fromreide writes:
> I recently ended up in a discussion about the -pthread flag at work and
> when looking at the documentation I noticed that it is defined onlt for
> SPARC and RS/6000/PowerPC.
>
> Additionally -fopenmp and -ftree-parallelize-loops say they are only
I recently ended up in a discussion about the -pthread flag at work and
when looking at the documentation I noticed that it is defined onlt for
SPARC and RS/6000/PowerPC.
Additionally -fopenmp and -ftree-parallelize-loops say they are only
supported on targets where -pthread are available.
Now
On 3 May 2010 10:37, Klaus Rudolph wrote:
>
> g++ -static -O2 main.cpp /usr/lib/libpthread.a -o linux
You could try -static -pthread instead of specifying the static lib
Please take any follow up questions to the gcc-help list, your
question is not appropriate for this list.
Thanks,
Jonathan
Hi all,
I tried to link a pthread application with -static and run into a segfault on
x86, same on powerpc.
I tried gcc 4.4.2 (linux/x86) and 4.0.2 for powerpc-unknown-linux-gnu
For the x86 linux example I got in gdb:
(gdb) bt
#0 0x in ?? ()
#1 0x08094d49 in __cxa_guard_release
Ian Lance Taylor wrote:
"John Maddock" <[EMAIL PROTECTED]> writes:
The crux of the issue is this: if gcc/g++ is configured with the
pthread threading model, then are object files always binary
compatible irrespective of whether they are compiled with the
-pthread command li
"John Maddock" <[EMAIL PROTECTED]> writes:
> The crux of the issue is this: if gcc/g++ is configured with the pthread
> threading model, then are object files always binary compatible irrespective
> of whether they are compiled with the -pthread command line option
Hi there,
Over at the Boost C++ libraries project we're trying to decide what is the
correct thing to do when code is compiled with -pthread or not.
The crux of the issue is this: if gcc/g++ is configured with the pthread
threading model, then are object files always binary compa
Hi Ian,
Thanks for your reply.
This question is appropriate for [EMAIL PROTECTED], not for
[EMAIL PROTECTED] Please send any follow-ups to gcc-help. Thanks.
I will send to gcc-help.
Cheers
Maggie
Maggie <[EMAIL PROTECTED]> writes:
> I try to generate cross-compiler to support -pthread in command line
> with gcc-4.1.1. I build my compiler using the following configuration.
>
> ./configure --enable-threads=posix --target=our-cpu
>
> After I generate cc1, it
Hi all,
I try to generate cross-compiler to support -pthread in command line
with gcc-4.1.1. I build my compiler using the following configuration.
./configure --enable-threads=posix --target=our-cpu
After I generate cc1, it doesn't support -pthread command, could anyone
give me some a
Lothar Werzinger-2 wrote:
>
> balazs wrote:
>
>> Hi - I start a simple pthread and the program consumes about 10 Mbytes of
>> virtual memory. If I start 10 threads, it consumes 100 Mbytes.
>
> That's off topic, but the answer is that the default stack size
balazs wrote:
> Hi - I start a simple pthread and the program consumes about 10 Mbytes of
> virtual memory. If I start 10 threads, it consumes 100 Mbytes.
That's off topic, but the answer is that the default stack size for a thread
on your machine seems to be 10M. If you know you don&
On Sep 22, 2006, at 3:51 PM, balazs wrote:
Hi - I start a simple pthread and the program consumes about 10
Mbytes of
virtual memory.
And why do you think that sending email to this list would be a good
idea?
View this message in context: http://www.nabble.com/simple-pthread-
consumes
Hi - I start a simple pthread and the program consumes about 10 Mbytes of
virtual memory. If I start 10 threads, it consumes 100 Mbytes. I don't know
why this is happening to me. I tried it on two Debian and a 64 bit Ubuntu
machines and the same thing happened to me. Thanks in advance fo
Moreover, removing the first test makes libgomp build on targets (as
Tru64) where the -pthread option is required to include pthread.h.
Commited after approval by Alexandre Oliva on IRC. The exact patch
commited is attached.
FX
libgomp.diff
Description: Binary data
Hi all,
libgomp currently doesn't configure well on Tru64 (PR
bootstrap/26161), because the configury is testing the usability of
pthread.h system headers, while on Tru64 this can only work when the
compiler is used with the -pthread option.
While this flag could be added on a per-target
67 matches
Mail list logo
