6 aug 2015 kl. 12.46 skrev Rainer Emrich <[email protected]>:
> Using the x86_64 runtime and winpthread from 4th of August I get a lot of
> libgomp testsuite failures. Nearly all execution tests fail!!! That's a
> regression against older runtime/winpthread versions.
>
> I assume that's caused by the latest winpthread changes.
Sort of; it looks like a bug in libgomp that was tolerated by the old mutex
implementation.
The acc_device_lock mutex is initialized in initialize_env and used in
goacc_host_init, both which are declared __attribute__ ((constructor)). Such
constructors are not called in a very predictable order, and apparently we
weren't lucky this time.
The easy way is to make winpthread's mutex implementation more forgiving
(treating 0-filled memory as if it were PTHREAD_MUTEX_INITIALIZER). Patch:
diff --git a/mingw-w64-libraries/winpthreads/src/mutex.c
b/mingw-w64-libraries/wi
index fec341a..6e1b392 100644
--- a/mingw-w64-libraries/winpthreads/src/mutex.c
+++ b/mingw-w64-libraries/winpthreads/src/mutex.c
@@ -56,7 +56,10 @@ typedef struct {
static bool
is_static_initializer(pthread_mutex_t m)
{
- return (uintptr_t)m >= (uintptr_t)-3;
+ /* Treat 0 as a static initializer as well (for normal mutexes),
+ to tolerate sloppy code in libgomp. (We should rather fix that code!) */
+ intptr_t v = (intptr_t)m;
+ return v >= -3 && v <= 0;
}
/* Create and return the implementation part of a mutex from a static
Fixing libgomp is probably cleaner: either make sure the constructors are run
in the right order or initialize the acc_device_lock mutex statically.
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
