(Updated to fix -m32 build, otherwise unchanged.)

Any other comments?

On 07.02.23 23:51, Thomas Schwinge wrote:

> On 2023-02-06T12:52:11+0100, Tobias Burnus <tobias@codesourcery.com> wrote:
>> Seems as if I missed a GOMP_MAP_TO_PSET issue before. As nvptx is
>> XFAILed before, I only found it when testing on AMDGCN.
>>
>> For an array-descriptor 'ai' variable, omplower has:
>>     map(tofrom:MEM <integer(kind=4)[0:]> [(integer(kind=4)[0:] *)D.4346] [len: D.4345])
>>     map(to:ai [pointer set, len: 64])
>>     map(alloc:ai.data [pointer assign, bias: 0])
>>
>> The latter reaches GCC with the same address as 'ai' – i.e. the
>> one of the array descriptor. This then needs to be dereferenced
>> to get the address of the actual pointer.
>> The patch assumes (and asserts) that 'ai.data' is part of the 'ai'
>> such that I can use the host address of 'ai' to access the data.
>> If that's not guaranteed, we have to find another way (e.g. another
>> lookup). But so far it seems to hold and I have not seen a bias
>> other than 0.
>>
>> With that patch, libgomp.fortran/reverse-offload-5.f90 now works
>> with AMDGCN.
...
>> OK? Any comments to the attached patch?
...
> For x86_64-pc-linux-gnu '-m32' multilib:
...
> I suppose you'd do similar to what you already have a few lines above;
> that is, cast through 'uintptr_t':
>
>      devaddrs[j] = *(uint64_t *) (uintptr_t) (devaddrs[i] + sizes[j]);
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