OffTarget

Observed issues › harvest/gcc-c-strided-section-rejected

Appears not to supportRefused at compile time · C · OpenMP · Open

C array sections with a stride ([lower-bound:length:stride]) are rejected

Legality: not independently confirmed. No counted independent reading yet. How this is checked

OpenMP 5.0 added a stride to C array sections. GCC 16.2 rejects a strided section in a target update from clause ("expected ']' before ':' token") for both offload targets; GCC's documentation lists non-unit strides in C and C++ as not supported. AFAR runs the harvested programs correctly (and this file in copy mode; the file's check assumes separate memory).

Affected variants

CompilerMI300A 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.0fails another waycorrectunknown
not run
correctcorrectn/an/a
CCE 19.0.0fails another wayfails another wayunknown
not run
unknown
not run
unknown
not run
n/an/a
CCE 20.0.2fails another wayfails another wayunknown
not run
unknown
not run
unknown
not run
n/an/a
CCE 21.0.3fails another wayfails another wayunknown
not run
unknown
not run
unknown
not run
n/an/a
CCE 21.0.4fails another wayfails another wayunknown
not run
unknown
not run
unknown
not run
n/an/a
NVHPC 25.11n/an/an/an/an/afails another wayfails another way
NVHPC 26.9n/an/an/an/an/afails another wayfails another way
GCC 16.2.0not supportednot supportednot supportednot supportednot supportednot supportedn/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

ResultCompiler and GPUMessage
not supportedGCC 16.2.0, MI300A unified
GCC 16.2.0, MI300A copy
GCC 16.2.0, MI300X
GCC 16.2.0, MI350X
show
site-harvest--gcc-c-strided-section-rejected.c: In function ‘main’:
site-harvest--gcc-c-strided-section-rejected.c:57:37: error: expected ‘]’ before ‘:’ token
   57 | #pragma omp target update from(a[0:8:2])
      |                                     ^
      |                                     ]
site-harvest--gcc-c-strided-section-rejected.c:57:39: error: expected an OpenMP clause before ‘]’ token
   57 | #pragma omp target update from(a[0:8:2])
      |                                       ^
not supportedGCC 16.2.0, MI250X
GCC 16.2.0, A100 separate
show
site-harvest--gcc-c-strided-section-rejected.c: In function ‘main’:
site-harvest--gcc-c-strided-section-rejected.c:33:37: error: expected ‘]’ before ‘:’ token
   33 | #pragma omp target update from(a[0:8:2])
      |                                     ^
      |                                     ]
site-harvest--gcc-c-strided-section-rejected.c:33:39: error: expected an OpenMP clause before ‘]’ token
   33 | #pragma omp target update from(a[0:8:2])
      |                                       ^
fails another wayAFAR 24.3.0, MI300A unified
CCE 19.0.0, MI300A unified
CCE 19.0.0, MI300A copy
CCE 20.0.2, MI300A unified
CCE 20.0.2, MI300A copy
CCE 21.0.3, MI300A unified
CCE 21.0.3, MI300A copy
CCE 21.0.4, MI300A unified
CCE 21.0.4, MI300A copy
show
bad= 8
RESULT ran_on_host=0 check=fail
fails another wayNVHPC 25.11, A100 separate
NVHPC 25.11, A100 managed
NVHPC 26.9, A100 separate
NVHPC 26.9, A100 managed
show
"site-harvest--gcc-c-strided-section-rejected.c", line 33: error: expected a "]"
  #pragma omp target update from(a[0:8:2])
                                      ^
"site-harvest--gcc-c-strided-section-rejected.c", line 33: error: invalid text in pragma
  #pragma omp target update from(a[0:8:2])
                                      ^
2 errors detected in the compilation of "site-harvest--gcc-c-strided-section-rejected.c".

Reproduce

GCC 16.2.0, MI300A unified

export LD_LIBRARY_PATH=$GCC_16_2/lib64:/opt/rocm-7.2.1/lib
$GCC_16_2/bin/gcc -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx942 -O2 repro.c -o repro
HSA_XNACK=1 OMP_TARGET_OFFLOAD=mandatory ./repro

GCC 16.2.0, A100 separate

export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=$GCC_16_2/lib64
$GCC_16_2/bin/gcc -fopenmp -foffload=nvptx-none -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic -O2 repro.c -o repro
OMP_TARGET_OFFLOAD=mandatory ./repro

AFAR 24.3.0, MI300A copy (runs correctly)

$AFAR/bin/amdclang -fopenmp --offload-arch=gfx942 -O2 repro.c -o repro
HSA_XNACK=0 OMP_TARGET_OFFLOAD=mandatory ./repro
Program (63 lines)
// # Finding (GCC 16.2, LLVM/AOMP harvest): C array sections with a stride are rejected ("expected ']' before ':' token")
//
// - toolchains: gcc_g90 (GCC 16.2.0, AMD Instinct MI250X gfx90a, Tioga) and gcc_sm80 (GCC 16.2.0, NVIDIA A100 sm_80, wingtip);
//   separate memory only; -O2
// - build: gcc -fopenmp -foffload=amdgcn-amdhsa -foffload-options=amdgcn-amdhsa=-march=gfx90a -O2 (gcc_g90); -foffload=nvptx-none
//   -foffload-options=nvptx-none=-march=sm_80 -foffload-options=nvptx-none=-latomic -O2 (gcc_sm80)
// - failure: rejected: expected ']' before ':' token
// - observed: `error: expected ']' before ':' token` at the stride of `a[0:8:2]` in the target update directive, on both targets
// - expected: compiles; prints `bad= 0` and `RESULT ran_on_host=0 check=pass` (only the even elements come back)
// - rule: in C, an array section is written `[ lower-bound : length : stride]` (5.2 §3.2.5 p.64 l.3-5; the stride form is OpenMP
//   5.0's).
// - GCC's documentation: libgomp.texi, OpenMP 5.0 table: "Array sections with non-unit strides in C and C++: N" (not supported,
//   documented).
// - other families: AFAR runs the harvested programs correctly (copy mode, MI300A and MI250X); CCE 19/20/21 and NVHPC fail them
//   (cce-c-strided-target-update.c: CCE behaves incorrectly; NVHPC rejects). The site's finding matrix runs this file on every
//   compiler: AFAR runs it correctly in copy mode and prints `bad= 8` in unified mode (HSA_XNACK=1), which this file's check
//   does not allow but the specification does ("The corresponding variable in the device data environment may share storage with
//   the original variable. Writes to the corresponding variable may alter the value of the original variable", 5.2 §1.4.2 p.28
//   l.12-13): the odd elements change too. The check holds for separate memory only, the memory GCC has.
// - harvested programs (50 cells (25 gcc_g90, 25 gcc_sm80); gate: confirmed 50; confirmer: compiler_bug (R11-compile-rejection) 28,
//   needs_human (R12b-compile-undecided) 22): hv-llvm-offloading-strided-update-strided-update-count-expression,
//   hv-llvm-offloading-strided-update-strided-update-from, hv-llvm-offloading-strided-update-strided-update-from-pointer,
//   hv-llvm-offloading-strided-update-strided-update-multidim-offset,
//   hv-llvm-offloading-strided-update-strided-update-multiple-arrays-variable-stride,
//   hv-llvm-offloading-strided-update-strided-update-multiple-from, hv-llvm-offloading-strided-update-strided-update-multiple-to,
//   hv-llvm-offloading-strided-update-strided-update-partial-from,
//   hv-llvm-offloading-strided-update-strided-update-ptr-multiple-from,
//   hv-llvm-offloading-strided-update-strided-update-ptr-multiple-to,
//   hv-llvm-offloading-strided-update-strided-update-ptr-partial-from,
//   hv-llvm-offloading-strided-update-strided-update-ptr-partial-to,
//   hv-llvm-offloading-strided-update-strided-update-ptr-variable-count-and-stride,
//   hv-llvm-offloading-strided-update-strided-update-ptr-variable-stride,
//   hv-llvm-offloading-strided-update-strided-update-struct-count-expression,
//   hv-llvm-offloading-strided-update-strided-update-struct-from,
//   hv-llvm-offloading-strided-update-strided-update-struct-multiple-from,
//   hv-llvm-offloading-strided-update-strided-update-struct-multiple-to,
//   hv-llvm-offloading-strided-update-strided-update-struct-partial-from,
//   hv-llvm-offloading-strided-update-strided-update-struct-partial-to, hv-llvm-offloading-strided-update-strided-update-struct-to,
//   hv-llvm-offloading-strided-update-strided-update-struct-variable-stride, hv-llvm-offloading-strided-update-strided-update-to,
//   hv-llvm-offloading-strided-update-strided-update-to-pointer,
//   hv-llvm-offloading-strided-update-strided-update-variable-stride-misc
// - legality: the pre-run check (offload.engine.prerun.check: the rules and AFAR's front end, two witnesses) accepts the harvested
//   programs. GCC is a compiler under test only and never a legality witness.
#include <stdio.h>
#include <omp.h>

int main(void) {
  int a[16], host_flag = 1, bad = 0;
  for (int i = 0; i < 16; i++) a[i] = -1;
#pragma omp target enter data map(to: a)
#pragma omp target map(tofrom: host_flag)
  {
    host_flag = omp_is_initial_device();
    for (int i = 0; i < 16; i++) a[i] = i;
  }
  /* every second element of the first 16: a[0], a[2], ..., a[14] */
#pragma omp target update from(a[0:8:2])
  for (int i = 0; i < 16; i++) bad += (i % 2 == 0) ? (a[i] != i) : (a[i] != -1);
#pragma omp target exit data map(delete: a)
  printf("bad= %d\n", bad);
  printf("RESULT ran_on_host=%d check=%s\n", host_flag, bad ? "fail" : "pass");
  return 0;
}

Source in the repository

Something to add? Dispute its legality · Report it fixed in a newer release · Report a mistake on this page

Expected and observed

Expected

check=pass

Observed where it behaves incorrectly

site-harvest--gcc-c-strided-section-rejected.c: In function ‘main’:
site-harvest--gcc-c-strided-section-rejected.c:57:37: error: expected ‘]’ before ‘:’ token
   57 | #pragma omp target update from(a[0:8:2])
      |                                     ^
      |                                     ]
site-harvest--gcc-c-strided-section-rejected.c:57:39: error: expected an OpenMP clause before ‘]’ token
   57 | #pragma omp target update from(a[0:8:2])
      |                                       ^

What the specification requires

The specification text this program relies on and the compiler is expected to support.

OpenMP 5.2 §3.2.5 p.64 l.3-5

OpenMP 5.2 §1.4.2 p.28 l.12-13

The corresponding variable in the device data environment may share storage with the original variable. Writes to the corresponding variable may alter the value of the original variable

Evidence

Other compilers run it correctly

AFAR 24.3.0

Reproducers of this issue