https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
cbcode at gmail dot com changed:
What|Removed |Added
CC||cbcode at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #18 from Stephan Tobies ---
+1 - I have a use case where a QuickThread is migrated from one pthread to
another. TLS would need to be re-fetched after this migration, but is not due
to CSE optimizations. Having a way to disable this op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Tor Myklebust changed:
What|Removed |Added
CC||tmyklebu at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #16 from Richard Biener ---
Implementing a switch that assumes that function calls (what about async
events??) can switch threads to the effect that the location of TLS variables
change would be a challenge. Basically you have to imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #15 from torvald at gcc dot gnu.org ---
From a ISO C/C++ conformance perspective, this is not a bug:
* Pre-C11/C++11, threading was basically undefined.
* Starting with C11 and C++11, "threads of execution" (as they're called in
C++1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
John Ousterhout changed:
What|Removed |Added
CC||ouster at cs dot stanford.edu
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Andy Robbins changed:
What|Removed |Added
CC||andy at miniciv dot com
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #11 from Giovanni Deretta ---
In the last few years it has been clear that threads are not enough and
coroutines have seen a resurgence in many languages. Go, which is directly
supported by GCC, make them a first class construct; boos
--- Comment #10 from dwood at sybase dot com 2010-08-24 03:31 ---
(In reply to comment #9)
I don't disagree with the thread local writeup however it is lacking in
clarity. A "flow of control" must be associated with an execution context.
The existance of getcontext/setcontext allows bo
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-23 21:19 ---
I think you should read:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/C99-Thread_002dLocal-Edits.html#C99-Thread_002dLocal-Edits
--- CUT ---
In GCC's case the thread is only can be created via pthread.
Note C++0x de
--- Comment #8 from dwood at sybase dot com 2010-08-23 21:13 ---
I believe this is a bug or a serious oversite in understanding the need for
support of >>>USER<<< thread local storage. There are two kinds of software
threads; a) kernel threads(AKA LWP's on Solaris) scheduled by the OS;
--- Comment #7 from gpderetta at gmail dot com 2009-03-19 12:14 ---
Hi, I'm the author of Boost.Coroutine (not yet part of boost, but one day...).
I have the exact same problem: gcc caches the address of TLS variables across
function calls which breaks when coroutines move from one thre
--- Comment #6 from yichen dot xie at gmail dot com 2006-02-25 01:55
---
(In reply to comment #5)
> ISO C is not your normal low level language any more. It actually tries to be
> a high level language.
>
> So this is not a bug.
>
I still don't think it's a good idea to treat thread
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-25 00:02 ---
ISO C is not your normal low level language any more. It actually tries to be
a high level language.
So this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from yichen dot xie at gmail dot com 2006-02-24 23:06
---
> Why not let the OS do its job? I still don't understand that idea.
It's a thread library that builds on top of pthreads, so yes, OS is doing its
job, and we're doing more on top of that. C is a natural choice f
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 22:38 ---
(In reply to comment #2)
> (In reply to comment #1)
> > It seems like you are trying to
> > deal with your own threading system instead of allowing the OS do its work.
> >
>
> This is indeed what I am trying to do,
--- Comment #2 from yichen dot xie at gmail dot com 2006-02-24 22:12
---
(In reply to comment #1)
> It seems like you are trying to
> deal with your own threading system instead of allowing the OS do its work.
>
This is indeed what I am trying to do, and C seems to be the perfect lang
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|c |middle-end
19 matches
Mail list logo
