[all-commits] [llvm/llvm-project] f96feb: [flang][cuda] Share the managed companion pointer ...

[Kareem Ergawy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f96febaf2701fc5f1979a4e0b49bdd97cae3fdb6
      https://github.com/llvm/llvm-project/commit/f96febaf2701fc5f1979a4e0b49bdd97cae3fdb6
  Author: Kareem Ergawy <kergawy at nvidia.com>
  Date:   2026-09-24 (Thu, 24 Sep 2026)

  Changed paths:
    M flang/lib/Optimizer/Transforms/CUDA/CUFAddConstructor.cpp
    M flang/test/Fir/CUDA/cuda-constructor-2.f90
    M flang/test/Fir/CUDA/cuda-managed-descriptor-component.fir
    A flang/test/Fir/CUDA/cuda-managed-pointer-linkage.cuf

  Log Message:
  -----------
  [flang][cuda] Share the managed companion pointer across translation units (#225710)

A non-allocatable managed module variable is accessed through a
companion pointer in the `__nv_managed_data__` section, which the CUDA
runtime fills in with the unified memory address at module
initialization. Every translation unit referencing the variable emitted
its own internal pointer and registered it. The runtime populates only
the registration performed first for a given variable name (*), so every
other unit was left loading through a null pointer and crashed at run
time.

Emit a single pointer with external linkage instead. The unit defining
the variable emits the definition, zero-initialized and in
`__nv_managed_data__`, and registers it; a unit that only USEs the
variable emits a declaration and no registration, resolving to that
definition at link time.

(*) I verified this using the following reproducer:

`exp_mod.f90`:
```fortran
module m
  implicit none
  type :: t
    integer :: n
    real, allocatable, managed :: a(:)
  end type
  type(t) :: g
end module
```

`exp_use.f90`:
```fortran
program p
  use m
  allocate(g%a(4))
  g%n = 4
  print *, "n=", g%n, " size=", size(g%a)
end program
```
And the following sequence of events:
1. Compile each source individually to its `*.o` file.
2. Manually link the 2 object files: 2.1. If we link `exp_mod.o
exp_use.o` (object file that does actually use the global last), then we
get a seg fault because the companion global is not initialized. 2.2. If
we reverse the linking order `exp_use.o exp_mod.o`, the companion
pointer of the users object file get proper initialized and the binary
does not seg fault.

If we add uses to both files, then we get a seg fault regradless of the
linking order.



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