This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: multiple defs. of TLS common symbols?


On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
> Otherwise TLS variables are generated as definitions rather than as
> common variables. 
> 
> Why do you want them to be common?

For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process, and these processes might
be distributed across a network.  2) Each UPC thread is implemented as
an OS thread (ie, pthread), and they are created by a single process
and execute within its address spec.

In the "process model", "int x;" has the usual semantics.  It is
defined as a common symbol.  In the "pthread model", each file scoped
variable is "localized" and becomes thread local; this is implemented
by defining the variable using TLS relocation.

Intermixing previously compiled C code that refers to file scoped
variables with GCC/UPC compiled "pthread mode" files will likely not
work well.  But if the C code is compiled with the GCC/UPC compiler in
"pthread mode" all file scoped symbols will be localized and everything
should work as expected.

The "process model" is the more natural and preferred way to compile
UPC programs.  The pthread model can offer some efficiencies and can
make it easier to debug the program.

Given the above, the goal of compiling in pthreads mode is to be able
to compile regular "C" code as is, with the same behavior as when it
was compiled in the normal process model.  Thus, we want to translate
all file scoped variables into localized TLS variables with the fewest
surprises and differences.

> Personally I tend to think that that is a good
> thing.  Treating uninitialized variables as common variables is a
> non-standard extension even for C90.  We can't get rid of them for
> existing code, but __thread code is by definition new.

I agree with your statement above, but for our purposes things
will work better if we do create commonized TLS symbols.

Maybe we can use GOMP's method for creating commonized
TLS variables.  Thanks for pointing it out.

Do you/others on this list have a reference that supports
the statement: "Treating uninitialized variables
as common variables is a non-standard extension even for C90."?
(I did see a thread on this list, late April 1999, that
discussed some of the issues, but nothing definitive.)

thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]