On 11 Dec 2008, at 13:51, Jack Howarth wrote:
On Thu, Dec 11, 2008 at 12:38:11PM +0000, IainS wrote:
...
I have a hunch that this is, at least partially, the origin of
sporadic
failures in crayptr2 (which has been one of the very few tests
using tls
so far - because all the rest have been UNSUPPORTED by the fails
in dg
target supports).
...
No. The random failures in crayptr2 are due to multiple threads
reading
an offset value of 0 and is fixed by the proposed patch...
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879
actually, the deeper one digs ...
it seems that libgomp is not being built with tls emulation.
(for exactly the same reasons - the configure test fails with the
unresolved __emutls... symbol)
from libgomp/config.h
/* Define to 1 if the target assembler supports thread-local storage. */
/* #undef HAVE_CC_TLS */
....
/* Define to 1 if the target supports thread-local storage. */
/* #undef HAVE_TLS */
and libgomp/config.log
tchCS/gcc-440-install/powerpc-apple-darwin8.11.0/sys-include -o
conftest -g -O2 -pthread conftest.c >&5
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
___emutls_get_address
collect2: ld returned 1 exit status
configure:17892: $? = 1
configure: program exited with status 1
configure: failed program was:
| __thread int a; int b; int main() { return a = b; }
configure:18104: result: no
----
So, I guess, the libgomp tests should not be built with TLS
emulation ; and any test requiring TLS should be hidden behind a
{ dg-require-effective-target tls_runtime }
which was a proposal anyway ( http://gcc.gnu.org/ml/fortran/2008-12/
msg00155.html).
----
at least this will be consistent until such time as a general
solution to making the emulation available is agreed.
(and that means addressing the general issues I raised earlier).
Iain
