Hi! On 2022-10-20T12:05:28+0200, I wrote: > On 2022-10-14T13:38:55+0000, Julian Brown wrote: >> The GCN backend uses a heuristic to determine whether to use FLAT or >> GLOBAL addressing in a particular (offload) function: namely, if a >> function takes a pointer-to-scalar parameter, it is assumed that the >> pointer may refer to "flat scratch" space, and thus FLAT addressing must >> be used instead of GLOBAL. >> >> I came up with this heuristic initially whilst working on support for >> moving OpenACC gang-private variables into local-data share (scratch) >> memory. The assumption that only scalar variables would be transformed in >> that way turned out to be wrong. For example, [...] >> Fortran compiler-generated temporary structures were treated >> as gang private and moved to LDS space, typically overflowing the region >> allocated for such variables. [...] >> there may be other cases of structs moving to LDS >> space now or in the future that this patch may be needed for. When I (back then) had looked into PR105421 "GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'", I had been experimenting with different test codes, that all didn't exhibit this problem. Now I understand that 'struct' (as implied by PR105421's Fortran 'write', for example) was the crucial thing there (that is, 'AGGREGATE_TYPE_P (TREE_TYPE (TREE_VALUE (arg)))' in context of the previous code). With... > pushed to master branch commit 7c55755d4c760de326809636531478fd7419e1e5 > "amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421]" ... that addressed, I've now pushed to master branch commit c7ebee2378426eeca425ca5406af213a926f154c "Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421]", see attached. Grüße Thomas ----------------- 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