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.
