230b437d05
### 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.
87 lines
1.9 KiB
C
87 lines
1.9 KiB
C
// RUN: %libomptarget-compile-run-and-check-generic
|
|
// This test checks that #pragma omp target update from(s.data[0:2:3]) correctly
|
|
// updates every third element (stride 3) from the device to the host
|
|
// using a struct with fixed-size array member.
|
|
|
|
#include <omp.h>
|
|
#include <stdio.h>
|
|
#include <stdlib.h>
|
|
|
|
#define LEN 11
|
|
|
|
typedef struct {
|
|
double data[LEN];
|
|
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 = LEN;
|
|
|
|
// Initialize struct data on host
|
|
for (int i = 0; i < LEN; i++) {
|
|
s.data[i] = i;
|
|
}
|
|
|
|
printf("original host array values:\n");
|
|
for (int i = 0; i < LEN; i++)
|
|
printf("%.1f\n", s.data[i]);
|
|
printf("\n");
|
|
|
|
#pragma omp target data map(mapper(custom), to : s)
|
|
{
|
|
// Execute on device with mapper
|
|
#pragma omp target map(mapper(custom), tofrom : s)
|
|
{
|
|
for (int i = 0; i < s.len; i++) {
|
|
s.data[i] = 20.0; // Set all to 20 on device
|
|
}
|
|
}
|
|
|
|
// Modify specific elements on device (only first 2 stride positions)
|
|
#pragma omp target map(mapper(custom), tofrom : s)
|
|
{
|
|
s.data[0] = 10.0;
|
|
s.data[3] = 10.0;
|
|
}
|
|
|
|
// indices 0,3 only
|
|
#pragma omp target update from(s.data[0 : 2 : 3])
|
|
}
|
|
|
|
printf("device array values after update from:\n");
|
|
for (int i = 0; i < LEN; i++)
|
|
printf("%.1f\n", s.data[i]);
|
|
printf("\n");
|
|
|
|
// CHECK: original host array values:
|
|
// CHECK-NEXT: 0.0
|
|
// CHECK-NEXT: 1.0
|
|
// CHECK-NEXT: 2.0
|
|
// CHECK-NEXT: 3.0
|
|
// CHECK-NEXT: 4.0
|
|
// CHECK-NEXT: 5.0
|
|
// CHECK-NEXT: 6.0
|
|
// CHECK-NEXT: 7.0
|
|
// CHECK-NEXT: 8.0
|
|
// CHECK-NEXT: 9.0
|
|
// CHECK-NEXT: 10.0
|
|
|
|
// CHECK: device array values after update from:
|
|
// CHECK-NEXT: 10.0
|
|
// CHECK-NEXT: 1.0
|
|
// CHECK-NEXT: 2.0
|
|
// CHECK-NEXT: 10.0
|
|
// CHECK-NEXT: 4.0
|
|
// CHECK-NEXT: 5.0
|
|
// CHECK-NEXT: 6.0
|
|
// CHECK-NEXT: 7.0
|
|
// CHECK-NEXT: 8.0
|
|
// CHECK-NEXT: 9.0
|
|
// CHECK-NEXT: 10.0
|
|
|
|
return 0;
|
|
}
|