[llvm-bugs] [Bug 50135] New: Subtle behavior of OpenMP offload entries table

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50135

            Bug ID: 50135
           Summary: Subtle behavior of OpenMP offload entries table
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: vyacheslav.p.zakharin at intel.com
                CC: llvm-bugs at lists.llvm.org

Here is an example to demonstrate potential issue in the ordering of OpenMP
offload entries.  Since the host and the target compilations may be using
different linkers to link the host and device “object” files, I think the LLVM
OpenMP offload design should at least say something about this.

glob1.c:
#pragma omp declare target
int g1;
int g2;
#pragma omp end declare target

glob2.c:
#pragma omp declare target
int g3;
#pragma omp end declare target

glob3.c:
#include <stdio.h>

#pragma omp declare target
extern int g1, g2, g3;

void print() {
  printf("%d %d %d\n", g1, g2, g3);
}
#pragma omp end declare target

int main() {
  g1 = 1;
  g2 = 2;
  g3 = 3;
#pragma omp target update to(g1, g2, g3)
#pragma omp target
  print();

  return 0;
}

I compile it with: clang -fopenmp -fopenmp-targets=x86_64 glob1.c glob2.c
glob3.c
The output is: 1 2 3

So far so good.  I redirect the driver’s -### output to bld.sh.  The target
link command looks like this:
“gcc" "-shared" "-m64" "-o" "/tmp/glob1-0be2b6.out" "/tmp/glob1-b121d8.o"
"/tmp/glob2-f2cce9.o" "/tmp/glob3-c114b9.o"

To demonstrate the issue, I swap "/tmp/glob1-b121d8.o" and
"/tmp/glob2-f2cce9.o":
“gcc" "-shared" "-m64" "-o" "/tmp/glob1-0be2b6.out" "/tmp/glob2-f2cce9.o"
"/tmp/glob1-b121d8.o" "/tmp/glob3-c114b9.o"

I run bld.sh, and then run the new a.out.
The new output is: 2 3 1

Behavior changed, because the order of entries in the offload entries table has
changed:
1.      Host entries order: g1, g2, g3
2.      Original target entries order: g1, g2, g3
3.      New target entries order: g3, g1, g2

So with the new ordering, host_g1 maps to target_g3, host_g2 maps to target_g1
and host_g3 maps to target_g2, thus, when we print target_g*, we get 2, 3, 1.


P.S. The issue becomes even more serious on Windows, where MSVC host linker may
insert undocumented(?) 0 paddings within data sections (e.g. between two
offload entries).  And if a target toolchain uses llvm-link for linking the
target parts, it is hard to guarantee that the final structure of the target
offload entries table matches the host structure.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210427/2d263922/attachment.html>