[Bug libgomp/111024] libgomp: FAILs with oldish libnuma/libmemkind

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111024

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
My guess feeling that this fail is completely unrelated to the new commits,
except that only the new alloc-11.c / alloc-12.c test omp_atk_partition =
omp_atv_interleaved.

I now disabled libnuma calls by not defining LIBGOMP_USE_LIBNUMA (in
libgomp/config/linux/allocator.c).

Result: On a bionic system (nvidia-3a) it still fails.

Granted, other changes in the GCC commits could have caused this, but this
seems to be less likely.


On the other hand, while libmemkind v1.1.1 was released only 6 weeks after
v1.1.0, none of the fixes look related to interleave (directly or via jemalloc)
and I assume that their testsuite did cover interleave (already in v0.3 and the
next release v1.0.0).

Still: Given that v1.1.0 was released on May 23, 2016 and the current release
is v1.14.0 (13 major and 2 minor releases later), I am not sure whether
debugging helps with regards to libmemkind and jemalloc (+ their dependencies
like: Linux kernel, libnuma, ...).

* * *

Probably not surprising, but attached patch did not help (but should be still
be added for correctness reasons).

Crossref: I filed PR111044 for using additional memkind kinds and documenting
which memkind kinds libgomp actually uses.