Hi Prathamesh,
On 13.07.23 18:13, Prathamesh Kulkarni wrote:
The newly added tests in above commit -- alloc-11.c and alloc-12.c
seem to fail during execution on armv8l-unknown-linux-gnueabihf:
thanks for the report and sorry for the breakage. While being aware that
libnuma is potentially not available, the code actually did not properly
test for it. (That 200+ packages require libnuma on this system, did not
help with testing it without, though.)
I have committed the attached obvious patch as r14-2514-g407d68daed00e0,
which hopefully fixes all issues.
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 407d68daed00e040a7d9545b2a18aa27bf93a106
Author: Tobias Burnus <tob...@codesourcery.com>
Date: Fri Jul 14 09:14:37 2023 +0200
libgomp: Fix allocator handling for Linux when libnuma is not available
Follow up to r14-2462-g450b05ce54d3f0. The case that libnuma was not
available at runtime was not properly handled; now it falls back to
the normal malloc.
libgomp/
* allocator.c (omp_init_allocator): Check whether symbol from
dlopened libnuma is available before using libnuma for
allocations.
---
libgomp/allocator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libgomp/allocator.c b/libgomp/allocator.c
index b3187ab2911..90f2dcb60d6 100644
--- a/libgomp/allocator.c
+++ b/libgomp/allocator.c
@@ -377,8 +377,9 @@ omp_init_allocator (omp_memspace_handle_t memspace, int ntraits,
#ifdef LIBGOMP_USE_LIBNUMA
if (data.memkind == GOMP_MEMKIND_NONE && data.partition == omp_atv_nearest)
{
- data.memkind = GOMP_MEMKIND_LIBNUMA;
libnuma_data = gomp_get_libnuma ();
+ if (libnuma_data->numa_alloc_local != NULL)
+ data.memkind = GOMP_MEMKIND_LIBNUMA;
}
#endif
