On Fri, Jul 07, 2006 at 10:56:08PM -0400, Robert Dewar wrote:
> That's not true, thread local storage can be done simply by mapping
> hardware on some machines, where you swap maps on a context switch.
Not with the semantics we have for __thread, which asserts
that its address is valid in all thre
* Richard Henderson:
> You're kidding, right? *All* targets have to generate different
> code for thread-local storage. If it didn't, it wouldn't be
> thread-local, would it?
The local/non-local distinction could be encoded as a flag in the load
instruction, set by the linker according to the d
Richard Henderson wrote:
On Sun, Jul 02, 2006 at 12:23:34PM -0700, Gary Funck wrote:
In my view, this is implementation-defined, and generally can vary
depending upon the underlying linker and OS technology. Further,
there is at least one known platform (IA64) which seems to not impose
this res
On Sun, Jul 02, 2006 at 12:23:34PM -0700, Gary Funck wrote:
> In my view, this is implementation-defined, and generally can vary
> depending upon the underlying linker and OS technology. Further,
> there is at least one known platform (IA64) which seems to not impose
> this restriction.
You're ki
On 7/3/06, Gary Funck <[EMAIL PROTECTED]> wrote:
...
Operations on UPC's shared objects have different semantics than
regular "C". Array indexing and pointer operations span threads.
Thus A[i] is on one thread but A[i] will (by default) take you to
the next (cyclic) thread. Since the semant
Seongbae Park wrote:
> In UPC, anything that's not TLS (or in UPC term, "private")
> is marked explicitly as "shared". So it's NOT trasparent in
> any sense of the word.
> See, you have two choices - either
> 1) make every global variable TLS by default and mark only
> non-TLS (UPC) or
> 2) vice
On 7/3/06, Gary Funck <[EMAIL PROTECTED]> wrote:
Seongbae Park wrote:
> As I said, you're welcome to implement a new option
> (either a runtime option or a compile time configuration option)
> that will allow mixing TLS vs non-TLS.
In a way, we've already done that -- in an experimental dialact
Seongbae Park wrote:
> As I said, you're welcome to implement a new option
> (either a runtime option or a compile time configuration option)
> that will allow mixing TLS vs non-TLS.
In a way, we've already done that -- in an experimental dialact of "C"
called UPC. When compiled for pthreads, al
On 7/2/06, Gary Funck <[EMAIL PROTECTED]> wrote:
...
More to the point, I think it is rather too bad that the
extern has to have the __thread attribute at all, and would
have hoped that the linker and OS could have collaborted to
make this transparent, in the same way that data can arranged
in se
Pinski wrote:
> What about the following two sources:
> char t;
> ---
> extern int t;
> What should happen? According to the C standard this is invalid code but
> the compiler does not need to diagnose the problem.
Yup. Certainly a great way to re-use space across separately compiled
"C" source
On Jul 2, 2006, at 1:58 PM, Gary Funck wrote:
The fact that one current generally available platform doesn't require
the __thread attribute on the extern should be enough to at least
question whether an *error* should be diagnosed. Also, consider
that compiler can't check for consistency across
Seongbae Park wrote:
> That's the only platform I know of that doesn't require different
> sequence.
> Should we make the language rules such that
> it's easy to implement on one platform but not on the others,
> or should we make it such that it's easy to implement in almost
> all platforms ?
On 7/2/06, Gary Funck <[EMAIL PROTECTED]> wrote:
...
Seongbae Park wrote:
> Because the compiler has to generate different code
> for accesses to __thread vs non __thread variable
In my view, this is implementation-defined, and generally can vary
depending upon the underlying linker and OS techn
On Jul 2, 2006, at 12:23 PM, Gary Funck wrote:
(Btw, personally, I'd prefer that a propoasl to extend the "C"
language use something other than a keyword beginning
with __ as a way of doing that. For example, a compound keyword
such as "thread local" would read better and is unlikely to clobbe
Andrew Pinski wrote:
> I would have hoped people actually read:
> http://gcc.gnu.org/onlinedocs/gcc/C99-Thread_002dLocal-Edits.html
>
> Which actually describes the edits to the C99 standard to how
> __thread is supposed to behave.
Thanks for the reference. Per that proposal, __thread is a
st
On Jul 2, 2006, at 5:00 AM, Dave Korn wrote:
Perhaps we should regard __thread as being like a type-qualifier
of some
kind?
I would have hoped people actually read:
http://gcc.gnu.org/onlinedocs/gcc/C99-Thread_002dLocal-Edits.html
Which actually describes the edits to the C99 standard t
On 02 July 2006 08:15, Seongbae Park wrote:
> On 7/1/06, Gary Funck <[EMAIL PROTECTED]> wrote:
> ...
>> What are the technical reasons for the front-end enforcing this
>> restriction, when apparently some linkers will handle the TLS linkage
>> fine? If in fact it is required that __thread be adde
On 7/1/06, Gary Funck <[EMAIL PROTECTED]> wrote:
...
What are the technical reasons for the front-end enforcing this restriction,
when apparently some linkers will handle the TLS linkage fine? If in fact
it is required that __thread be added to the extern, is the compiler simply
accommodating a
Mike Stump wrote:
>
> This sounds like a bug that should be fixed. You should only need
> __thread on the extern if there was not a previous declaration for it.
>
The compiler seems pretty determined to enforce this restriction. Same
result
with 'const' instead of _thread:
int const x;
int mai
On Jul 1, 2006, at 11:23 AM, Gary Funck wrote:
To further complicate matters, if the program is rewritten into a
single
file as follows:
int __thread x;
int main() {
extern int x;
x = 5;
}
it will fail at compile-time with gcc 4.1:
This sounds like a bug that should be fixed. You shou
Consider the following program made up of two separate files:
==> file1.c <==
extern int x;
int main() {
x = 5;
}
==> file2.c <==
int __thread x = 10;
This will compile, link, and run on the IA64, but will fail at link time on
AMD64:
% gcc file2.c file1.c
/usr/bin/ld: x: TLS definition in /tm
21 matches
Mail list logo
