Hi!
On 2023-02-14T15:11:14+, Andrew Stubbs wrote:
> On 14/02/2023 12:54, Thomas Schwinge wrote:
>> On 2022-01-13T11:13:51+, Andrew Stubbs wrote:
>>> Updated patch: this version fixes some missed cases of malloc in the
>>> realloc implementation.
>>
>> Right, and as it seems I've run into
On 14/02/2023 12:54, Thomas Schwinge wrote:
Hi Andrew!
On 2022-01-13T11:13:51+, Andrew Stubbs wrote:
Updated patch: this version fixes some missed cases of malloc in the
realloc implementation.
Right, and as it seems I've run into another issue: a stray 'free'.
--- a/libgomp/allocator.
Hi Andrew!
On 2022-01-13T11:13:51+, Andrew Stubbs wrote:
> Updated patch: this version fixes some missed cases of malloc in the
> realloc implementation.
Right, and as it seems I've run into another issue: a stray 'free'.
> --- a/libgomp/allocator.c
> +++ b/libgomp/allocator.c
Re 'omp_real
Updated patch: this version fixes some missed cases of malloc in the
realloc implementation. It also reworks the unused variable workarounds
so that the work better with my reworked pinned memory patches I've not
posted yet.
Andrewlibgomp, nvptx: low-latency memory allocator
This patch adds s
On 06/01/2022 17:53, Tom de Vries wrote:
My current understanding is that this is a backend problem, and needs to
be fixed by defining atomic_store patterns which take care of this
peculiarity.
You mentioned on IRC that I ought to initialize the free chain using
atomics also, and that you are
On 1/6/22 10:29, Tom de Vries wrote:
At first glance, the above behaviour doesn't look like a too short timeout.
Using patch below, this passes for me, I'm currently doing a full build
and test to confirm.
Looks like it has to do with:
...
For sm_6x and earlier architectures, atom operations
On 1/5/22 15:36, Andrew Stubbs wrote:
On 05/01/2022 13:04, Tom de Vries wrote:
On 1/5/22 12:08, Tom de Vries wrote:
The allocators-1.c test-case doesn't compile because:
...
FAIL: libgomp.c/allocators-1.c (test for excess errors)
Excess errors:
/home/vries/oacc/trunk/source-gcc/libgomp/testsuit
On 05/01/2022 13:04, Tom de Vries wrote:
On 1/5/22 12:08, Tom de Vries wrote:
The allocators-1.c test-case doesn't compile because:
...
FAIL: libgomp.c/allocators-1.c (test for excess errors)
Excess errors:
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.c/allocators-1.c:7:22:
sorry
On 05/01/2022 11:08, Tom de Vries wrote:
The alloc-7.c execution test failure is a regression, AFAICT. It fails
here:
...
38 if uintptr_t) p) % __alignof (int)) != 0 || p[0] || p[1]
|| p[2])
39 abort ();
...
because:
...
(gdb) p p[0]
$2 = 772014104
(gdb) p p[1]
$3 = 0
(gdb
On 1/5/22 12:08, Tom de Vries wrote:
The allocators-1.c test-case doesn't compile because:
...
FAIL: libgomp.c/allocators-1.c (test for excess errors)
Excess errors:
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.c/allocators-1.c:7:22:
sorry, unimplemented: ' ' clause on 'require
On 12/20/21 16:58, Andrew Stubbs wrote:
This patch is submitted now for review and so I can commit a backport it
to the OG11 branch, but isn't suitable for mainline until stage 1.
The patch implements support for omp_low_lat_mem_space and
omp_low_lat_mem_alloc on NVPTX offload devices. The omp
This patch is submitted now for review and so I can commit a backport it
to the OG11 branch, but isn't suitable for mainline until stage 1.
The patch implements support for omp_low_lat_mem_space and
omp_low_lat_mem_alloc on NVPTX offload devices. The omp_pteam_mem_alloc,
omp_cgroup_mem_alloc a
12 matches
Mail list logo
