llvm-project/offload/test/offloading/target_update_strided_struct_from.c
Amit Tiwari 230b437d05
[Clang][OpenMP] Handle check for non-contiguous mapping in pointer-based array sections (#157443)
### 1. ElementType deduction for pointer-based array sections

Problem: Pointer-based array sections were previously ignored during
`ElementType` deduction, leading to incorrect assumptions about array
item types.

This often resulted in out-of-bounds access, as seen in the assertion
failure:
```
Assertion `idx < size()' failed.
llvm-project/llvm/include/llvm/ADT/SmallVector.h:292:
reference llvm::SmallVectorTemplateCommon<llvm::Value *>::operatorsize_type
[T = llvm::Value *]

```
Fix: Added a check in clang/lib/CodeGen/CGOpenMPRuntime.cpp to ensure
`ElementType` is correctly detected for cases involving non-contiguous
updates with a base pointer.
Impact: Resolves failures in OpenMP_VV (formerly sollve_vv) and other
offload/clang-OpenMP tests:

All tests under:

https://github.com/OpenMP-Validation-and-Verification/OpenMP_VV/tree/master/tests/5.0/target_update

test_target_update_mapper_from_discontiguous.c
test_target_update_mapper_to_discontiguous.c
test_target_update_to_discontiguous.c
test_target_update_from_discontiguous.c



### 2. Zero-dimension propagation in struct member mappings

Problem: A zero-dimension entry for struct members introduced
inconsistencies in complex mapping logic within OMPIRBuilder.cpp.

Placeholder zeros propagated to emitNonContiguousDescriptor(), breaking
reverse indexing logic and corrupting IR:

Loops assume `Dims[I] >= 1`. When `Dims[I] == 0`:

Reverse indexing still stores pointers to uninitialized allocas or
mismatched slots. Runtime interprets `ArgSizes[I]` (derived from
`Dims[I])` as dimensionality, causing size/offset calculations to
collapse to zero → results in `size=0` async copy and plugin interface
errors.

Fix: Prepend a synthetic dimension of size 1 instead of appending a
zero, preserving correctness in `targetDataUpdate()` for non-contiguous
updates.
Impact: Added dedicated test cases that previously failed on main.
2025-12-23 12:57:12 +05:30

87 lines
2.0 KiB
C

// RUN: %libomptarget-compile-run-and-check-generic
// This test checks that "update from" with user-defined mapper supports strided
// sections using fixed-size arrays in structs.
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
#define N 16
typedef struct {
double data[N];
size_t len;
} T;
#pragma omp declare mapper(custom : T v) map(to : v, v.len, v.data[0 : v.len])
int main() {
T s;
s.len = N;
for (int i = 0; i < N; i++) {
s.data[i] = i;
}
printf("original host array values:\n");
for (int i = 0; i < N; i++)
printf("%f\n", s.data[i]);
printf("\n");
#pragma omp target data map(mapper(custom), to : s)
{
// Execute on device with explicit mapper
#pragma omp target map(mapper(custom), tofrom : s)
{
for (int i = 0; i < s.len; i++) {
s.data[i] += i;
}
}
// Update strided elements from device: indices 0,2,4,6,8,10,12,14
#pragma omp target update from(s.data[0 : 8 : 2])
}
printf("from target array results:\n");
for (int i = 0; i < N; i++)
printf("%f\n", s.data[i]);
// CHECK: original host array values:
// CHECK-NEXT: 0.000000
// CHECK-NEXT: 1.000000
// CHECK-NEXT: 2.000000
// CHECK-NEXT: 3.000000
// CHECK-NEXT: 4.000000
// CHECK-NEXT: 5.000000
// CHECK-NEXT: 6.000000
// CHECK-NEXT: 7.000000
// CHECK-NEXT: 8.000000
// CHECK-NEXT: 9.000000
// CHECK-NEXT: 10.000000
// CHECK-NEXT: 11.000000
// CHECK-NEXT: 12.000000
// CHECK-NEXT: 13.000000
// CHECK-NEXT: 14.000000
// CHECK-NEXT: 15.000000
// CHECK: from target array results:
// CHECK-NEXT: 0.000000
// CHECK-NEXT: 1.000000
// CHECK-NEXT: 4.000000
// CHECK-NEXT: 3.000000
// CHECK-NEXT: 8.000000
// CHECK-NEXT: 5.000000
// CHECK-NEXT: 12.000000
// CHECK-NEXT: 7.000000
// CHECK-NEXT: 16.000000
// CHECK-NEXT: 9.000000
// CHECK-NEXT: 20.000000
// CHECK-NEXT: 11.000000
// CHECK-NEXT: 24.000000
// CHECK-NEXT: 13.000000
// CHECK-NEXT: 28.000000
// CHECK-NEXT: 15.000000
return 0;
}