Hey,
>> There is only a little bit of code in
src/sys/threadcomm/impls/openmp/tcopenmp.c
src/sys/threadcomm/impls/openmp/tcopenmpimpl.h
in addition to the registration of OpenMP functionality in
src/sys/threadcomm/interface/threadcommregi.c
I really don't see how this could affect the execution of GPU code if
the threadcomm-default 'nothread' is used.
There is a bunch of conditional compilation guarded by the
(nonconforming style) PETSC_THREADCOMM_ACTIVE. Seems to me it's more
likely that something bad happens in one of those blocks than that
-fopenmp causes the compiler to misbehave.
I should have been more precise: If we configure PETSc to use OpenMP
through threadcomm, then we run into issues. OpenMP and OpenCL code per
se, i.e. without any PETSc-code involved, is not causing troubles (and
is a common build with ViennaCL). If I configure
--with-openmp
but without
--with-threadcomm --with-pthreadclasses
then execution is fine. Conversely, configuring
--with-threadcomm --with-pthreadclasses
but without
--with-openmp
also works. If all three options are supplied, wrong results are
obtained. Weird. I'll keep it on my list, but will focus on other items
first.
Best regards,
Karli
