A trivial program with an OMP'ed loop *inside* a pthread does crash at libgomp.h:380 where gomp_thread()->task becomes NULL->task. mingw32 on xp is (with my installation) an installation where TLS (thread local storage) is inop. Hence the pthread_get_specific() and family are used. I suspect there to be a problem.
Created attachment 19466 [details] The test case.
Created attachment 19467 [details] A GDB output.
Confirmed, I've encountered this bug in 64-bit Windows 7. I've used Qt Creator 1.3.1 (bundled with gc 4.4.0) for building a project which calls OpenMP functions from inside a pthread. If I call OpenMP function from main(), everything works fine.
This bug is also present in the latest TDM (http://www.tdragon.net/recentgcc/) builds. Using OpenMP fails when called from pthreads and Windows native threads.
I drafted a potential patch one can find at http://jdlraw.sourceforge.net/GompPatch.shtml
Any news on this?
Patches should be sent to gcc-patches. You may CC the libgomp maintainer jakub@redhat.com. See also http://gcc.gnu.org/contribute.html
Testsuite works just fine with MingW-W64(GCC 4.6.0) + WinPthreads: /mw64src $ g++ -m32 omp_test.c -o ./omptst.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst OMP : All looks good /mw64src $ g++ -m64 -static omp_test.c -o ./omptst64.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst64 OMP : All looks good
@Victor K. Are you using the MinGW or TDM version of GCC? TDM 4.5.0 passes the test cases on my machine. Seems the problem existed only in the 4.4.* branch of gcc.
Is this using mingw.org based GCC or mingw-w64 based GCC?
FWIW, using mingw.org's gcc-4.5.2 release, the test passes: $ g++ -fopenmp omp_test.c -o omp_test -lpthread $ ./omp_test.exe OMP : All looks good Relevant installation data: gcc-core-4.5.2-1-mingw32-bin gcc-c++-4.5.2-1-mingw32-bin libgcc-4.5.2-1-mingw32-dll-1 libstdc++-4.5.2-1-mingw32-dll-6 libgomp-4.5.2-1-mingw32-dll-1 mingwrt-3.18-mingw32-dll mingwrt-3.18-mingw32-dev w32api-3.17-2-mingw32-dev pthreads-w32-2.8.0-3-mingw32-dev libpthread-2.8.0-3-mingw32-dll-2 I believe this is because TLS support was added to the mingw(32) runtime in late Jan 2010, thanks to Kai's work: http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3550 (Although a full compiler suite, and mingw runtime, with TLS support was not officially released until March 2010)
(In reply to comment #11) > FWIW, using mingw.org's gcc-4.5.2 release, the test passes: > > $ g++ -fopenmp omp_test.c -o omp_test -lpthread > $ ./omp_test.exe > OMP : All looks good > > Relevant installation data: > gcc-core-4.5.2-1-mingw32-bin > gcc-c++-4.5.2-1-mingw32-bin > libgcc-4.5.2-1-mingw32-dll-1 > libstdc++-4.5.2-1-mingw32-dll-6 > libgomp-4.5.2-1-mingw32-dll-1 > mingwrt-3.18-mingw32-dll > mingwrt-3.18-mingw32-dev > w32api-3.17-2-mingw32-dev > pthreads-w32-2.8.0-3-mingw32-dev > libpthread-2.8.0-3-mingw32-dll-2 > > I believe this is because TLS support was added to the mingw(32) runtime in > late Jan 2010, thanks to Kai's work: > http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3550 > > (Although a full compiler suite, and mingw runtime, with TLS support was not > officially released until March 2010) I don't thinks so. Because mingw64 crt also contains TLS support written by Kai, but mingw64 crt also use the code to crash.
I experience the same problem with Android NDK. TLS is not supported into Android, so I observe the similar test crash: [New LWP 18636] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 18636] (gdb) bt #0 gomp_icv (write=<optimized out>) at /s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/libgomp.h:393 #1 0x0804a3d7 in omp_set_num_threads (n=4) at /s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/env.c:657 #2 0x08049e70 in _thread (Id=0x1) at omp_test.c:19 #3 0x0804d119 in __pthread_start (arg=0x8087270) at bionic/libc/bionic/pthread_create.cpp:153 #4 0x08055e1a in __start_thread (fn=0x804d0e0 <__pthread_start(void*)>, arg=0x8087270) at bionic/libc/bionic/clone.cpp:39 #5 0x0806b9b7 in __bionic_clone () at bionic/libc/arch-x86/bionic/__bionic_clone.S:42 I use android-ndk-r9d for x86 arch, gcc 4.8. Modified patch solves this issue.
Created attachment 33130 [details] Modified patch I will send this patch to gcc patches.
Created attachment 33131 [details] Correct patch
Question: There are ~98 calls to gomp_thread() which allocates struct gomp_thread when HAVE_TLS isn't defined, but only gomp_free_thread() frees this instance. Possible memory leak?
Is this fixed by https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218576 ?