[all-commits] [llvm/llvm-project] 0d8179: [flang][cuda] Back ALLOCATABLE components with man...

[Kareem Ergawy via All-commits]

  Branch: refs/heads/users/ergawy/managed-allocatable-components
  Home:   https://github.com/llvm/llvm-project
  Commit: 0d817921dd3e5fabc4d0001a9389689c7966d040
      https://github.com/llvm/llvm-project/commit/0d817921dd3e5fabc4d0001a9389689c7966d040
  Author: ergawy <kareem.ergawy at gmail.com>
  Date:   2026-09-11 (Fri, 11 Sep 2026)

  Changed paths:
    M flang/lib/Lower/Allocatable.cpp
    A flang/test/Lower/CUDA/cuda-gpu-managed-components.cuf

  Log Message:
  -----------
  [flang][cuda] Back ALLOCATABLE components with managed memory under -gpu=mem:managed

Under -gpu=mem:managed, resolve-names implicitly gives every unattributed
ALLOCATABLE/POINTER a Managed CUDA data attribute, so it is allocated from the
managed allocator. That sweep runs over the enclosing scope in
FinishSpecificationPart, so it never reaches ALLOCATABLE/POINTER components:
those live in the derived type's own scope. Allocating such a component
therefore fell to the inlined allocmem path, which is a plain host malloc, and
a kernel reading the component's data hit an illegal address.

Select the managed allocator index at the ALLOCATE site for these, reusing the
branch #210149 added for -gpu=unified. Components are exactly what is left once
the attributed entities are excluded: those already carry the managed allocator
index, so the existing kDefaultAllocator test filters them out.

Deliberately not fixed by attributing the component symbol in resolve-names:
IsDeviceAllocatable() would then report the component as device-allocatable, so
needCUDAAlloc() would place every object of the containing derived type in
managed memory, including its non-allocatable components.

Unlike unified, managed applies only when CUDA Fortran is enabled. Selecting
the managed allocator makes the runtime look kManagedAllocatorPos up in the
allocator registry, which is only populated when the CUDA Fortran runtime is
linked in, so a non-CUDA-Fortran translation unit must keep plain host
allocatables.

The two descriptor-creation sites that #210149 introduced in ConvertVariable.cpp
are left alone: under managed, resolve-names has already attributed every
symbol those sites see, so a redirect there would be unreachable.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications