Observed issues › stress/nvhpc-acc-derived-type-component-not-copied
nvfortran -acc: derived-type variable without a data clause is not copied back from a serial region
Legality: independently confirmed. 2 independent readings find the program legal and the result required. How this is checked
Affected variants
| Compiler | MI300A gfx942 unified memory (XNACK 1) | MI300A gfx942 copy (XNACK 0) | MI250X gfx90a copy (XNACK 0) | MI300X gfx942 copy (XNACK 0) | MI350X gfx950 copy (XNACK 0) | A100 sm_80 separate memory | A100 sm_80 managed memory |
|---|---|---|---|---|---|---|---|
| AFAR 24.3.0 | n/a | n/a | n/a | n/a | n/a | n/a | n/a |
| CCE 19.0.0 | correct | correct | unknown not run | unknown not run | unknown not run | n/a | n/a |
| CCE 20.0.2 | correct | correct | unknown not run | unknown not run | unknown not run | n/a | n/a |
| CCE 21.0.3 | correct | correct | unknown not run | unknown not run | unknown not run | n/a | n/a |
| CCE 21.0.4 | correct | correct | unknown not run | unknown not run | unknown not run | n/a | n/a |
| NVHPC 25.11 | n/a | n/a | n/a | n/a | n/a | behaves incorrectly | behaves incorrectly |
| NVHPC 26.9 | n/a | n/a | n/a | n/a | n/a | behaves incorrectly | behaves incorrectly |
| GCC 16.2.0 | correct | correct | correct | correct | correct | correct | n/a |
"behaves incorrectly" / "not supported": this issue, confirmed in up to four environments (another build directory, another node, a repeat). "fails another way": a different failure, not counted as this issue. "unknown": not run there, or the runs disagree.
Messages
| Result | Compiler and GPU | Message |
|---|---|---|
| behaves incorrectly | NVHPC 25.11, A100 separate NVHPC 25.11, A100 managed NVHPC 26.9, A100 separate NVHPC 26.9, A100 managed | showc1= 101 |
Reproduce
NVHPC 25.11, A100 separate
export LD_LIBRARY_PATH=$NVHPC_25_11/compilers/lib nvfortran -acc=gpu -gpu=cc80 -gpu=mem:separate -O2 repro.f90 -o repro ./repro
NVHPC 26.9, A100 separate
export LD_LIBRARY_PATH=$NVHPC_26_9/compilers/lib nvfortran -acc=gpu -gpu=cc80 -gpu=mem:separate -O2 repro.f90 -o repro ./repro
CCE 19.0.0, MI300A unified (runs correctly)
module load cce/19.0.0 craype-accel-amd-gfx942 rocm/6.4.3 module unload cray-mpich ftn -h acc -O2 repro.f90 -o repro HSA_XNACK=1 ./repro
Program (29 lines)
! # Finding: NVHPC OpenACC does not copy back a derived-type variable
! # written through a component in a serial construct
!
! - compilers: NVHPC nvfortran 25.11 and 26.9, A100 (sm_80), -acc=gpu -gpu=cc80, separate and
! managed memory, -O2
! - expected: c1= 203. xc has an exposed access in the serial construct and no visible data clause;
! in that case "An aggregate variable will be treated as if it appears either: ... In a copy
! clause otherwise" (OpenACC 3.4 §2.6.2 p.41 l.1388-1391). The access to xc%c1 is an access to xc (§2.6.2 l.1374), and a
! derived type is a composite type, hence an aggregate (glossary p.159 l.5792-5796, 5807-5811)
! - actual: c1= 101 on both releases and both memory modes
! - control (same compiler): serial copy(xc) (data/reports/fuzz-stress-audit/r5-acc-component-control.f90):
! 203 on both releases and modes
! - other families: CCE 19/20/21 (ftn -h acc) give 203 on this program (MI300A HSA_XNACK 1 and 0, MI250X)
! - legality: legal by reading: serial runs one gang, one worker, one vector lane; xc is a local
! variable of the main program
! - evidence: results/stress/audit/runs-nvhpc.jsonl. The confirmer gave needs_human (R22, no
! cross-machine witness); the audit counts the MI300A results
program acc_component
implicit none
type :: t
integer(8) :: c1
end type t
type(t) :: xc
xc%c1 = 101
!$acc serial
xc%c1 = 2 * xc%c1 + 1
!$acc end serial
print '(a,i0)', 'c1= ', xc%c1
end program acc_component
Something to add? Dispute its legality · Report it fixed in a newer release · Report a mistake on this page
Expected and observed
Expected
c1= 203
Observed where it behaves incorrectly
c1= 101
What the specification requires
The specification text this program relies on and the compiler is expected to support.
OpenACC 3.4 §2.6.2 p.41 l.1388-1391
An aggregate variable will be treated as if it appears either: ... In a copy clause otherwise
OpenACC 3.4 §2.6.2
Evidence
Same compiler, one change
- serial copy(xc): CCE 19.0.0: correct; CCE 20.0.2: correct; CCE 21.0.3: correct; CCE 21.0.4: correct; NVHPC 25.11: correct; NVHPC 26.9: correct
Control program
program acc_component implicit none type :: t integer(8) :: c1 end type t type(t) :: xc xc%c1 = 101 !$acc serial copy(xc) xc%c1 = 2 * xc%c1 + 1 !$acc end serial print '(a,i0)', 'c1= ', xc%c1 end program acc_component
Other compilers run it correctly
CCE 19.0.0, CCE 20.0.2, CCE 21.0.3, CCE 21.0.4, GCC 16.2.0