| Message ID | CAAp9h92JrSYjicz1A2ysfNniXAVk2LkE9WsLNiGXQehgS2yKdQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Oct 01, 2014 at 08:44:59PM +0400, Varvara Rainchik wrote: > Ok, then here it is a new patch (tested and bootstrapped on linux). > > On linux with --disable-tls now all libgomp make check tests pass; for > Android I've patched toolchain and tried test from one of the > mentioned bugs, test passes too. > Is there some benchmark to check performance? There is SPEC OMP, http://www.spec.org/hpg/omp2001/ EPCC, http://www2.epcc.ed.ac.uk/computing/research_activities/openmpbench/openmp_index.html NAS, http://www.nas.nasa.gov/publications/npb.html http://phase.hpcc.jp/Omni/benchmarks/NPB/ Rodinia, https://www.cs.virginia.edu/~skadron/wiki/rodinia/index.php/Main_Page Now, I wonder on which OS and why does config/tls.m4 CHECK_GCC_TLS actually fail? Can you figure that out? If we get rid of HAVE_TLS code altogether, we might lose support of some very old OSes, e.g. some Linux distros with a recent gcc and binutils (so that emutls isn't used), but very old glibc (that doesn't support TLS or supports it incorrectly, think of pre-2002 glibc). So, if we get rid of !HAVE_TLS code in libgomp, it would be nice if config/tls.m4 detected it properly and we'd just fail at configure time. And if we don't, just make sure that on Android, Darwin and/or M$Win (or whatever other OS you had in mind which does support pthreads, but doesn't support native TLS) find out why HAVE_AS_TLS is not defined (guess config.log should explain that). > 2014-10-01 Varvara Rainchik <varvara.rainchik@intel.com> > > * libgomp.h (HAVE_TLS): Set to 1. Jakub
> Now, I wonder on which OS and why does config/tls.m4 CHECK_GCC_TLS > actually fail? Can you figure that out? > On Android check passes with --disable-tls (standard while building gcc for Android as TLS is not supported in bionic) and fails with --enable-tls (i686-linux-android/libgomp/conftest.c:32: undefined reference to `___tls_get_addr'). So, HAVE_TLS is not defined in both cases. > If we get rid of HAVE_TLS code altogether, we might lose support of > some very old OSes, e.g. some Linux distros with a recent gcc and binutils > (so that emutls isn't used), but very old glibc (that doesn't support > TLS or supports it incorrectly, think of pre-2002 glibc). So, if we get > rid of !HAVE_TLS code in libgomp, it would be nice if config/tls.m4 detected > it properly and we'd just fail at configure time. How can we check this in config/tls.m4? Can we just combine tests on TLS and emutls? E.g. check whether HAVE_TLS and USE_EMUTLS are both defined. > And if we don't, just make sure that on Android, Darwin and/or M$Win (or > whatever other OS you had in mind which does support pthreads, but doesn't > support native TLS) find out why HAVE_AS_TLS is not defined (guess > config.log should explain that). HAVE_AS_TLS is also not defined for Android as it depends on --enable-tls.
*Ping* 2014-10-13 14:48 GMT+04:00 Varvara Rainchik <varvara.s.rainchik@gmail.com>: >> Now, I wonder on which OS and why does config/tls.m4 CHECK_GCC_TLS >> actually fail? Can you figure that out? >> > > On Android check passes with --disable-tls (standard while building > gcc for Android as TLS is not supported in bionic) and fails with > --enable-tls (i686-linux-android/libgomp/conftest.c:32: undefined > reference to `___tls_get_addr'). So, HAVE_TLS is not defined in both > cases. > >> If we get rid of HAVE_TLS code altogether, we might lose support of >> some very old OSes, e.g. some Linux distros with a recent gcc and binutils >> (so that emutls isn't used), but very old glibc (that doesn't support >> TLS or supports it incorrectly, think of pre-2002 glibc). So, if we get >> rid of !HAVE_TLS code in libgomp, it would be nice if config/tls.m4 detected >> it properly and we'd just fail at configure time. > > How can we check this in config/tls.m4? Can we just combine tests on > TLS and emutls? E.g. check whether HAVE_TLS and USE_EMUTLS are both > defined. > >> And if we don't, just make sure that on Android, Darwin and/or M$Win (or >> whatever other OS you had in mind which does support pthreads, but doesn't >> support native TLS) find out why HAVE_AS_TLS is not defined (guess >> config.log should explain that). > > HAVE_AS_TLS is also not defined for Android as it depends on --enable-tls.
--- a/libgomp/libgomp.h +++ b/libgomp/libgomp.h @@ -45,6 +45,8 @@ # pragma GCC visibility push(hidden) #endif +#define HAVE_TLS 1 + /* If we were a C++ library, we'd get this from <std/atomic>. */ enum memmodel {
Ok, then here it is a new patch (tested and bootstrapped on linux). On linux with --disable-tls now all libgomp make check tests pass; for Android I've patched toolchain and tried test from one of the mentioned bugs, test passes too. Is there some benchmark to check performance? 2014-10-01 Varvara Rainchik <varvara.rainchik@intel.com> * libgomp.h (HAVE_TLS): Set to 1. -- 2014-09-30 18:40 GMT+04:00 Richard Henderson <rth@redhat.com>: > On 09/30/2014 02:52 AM, Jakub Jelinek wrote: >> On Tue, Sep 30, 2014 at 11:03:47AM +0400, Varvara Rainchik wrote: >>> Corrected patch: call pthread_setspecific (gomp_tls_key, NULL) in >>> gomp_thread_start if HAVE_TLS is not defined. >>> >>> 2014-09-19 Varvara Rainchik <varvara.rainchik@intel.com> >>> >>> * libgomp.h (gomp_thread): For non TLS case create thread data. >>> * team.c (non_tls_thread_data_destructor, >>> create_non_tls_thread_data): New functions. >> >> I actually wonder when we have emutls support in libgcc if it wouldn't >> be better to just define HAVE_TLS always to 1 (i.e. remove all the >> conditionals on it), then you wouldn't need to bother with this at all. >> >> I don't have an OS which doesn't support native TLS though, so somebody with >> such a system would need to test it and benchmark if it doesn't make things >> slower. >> >> Richard, thoughts on this? > > I like that idea better as well. > > > r~ >