<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Subtle behavior of OpenMP offload entries table"
href="https://bugs.llvm.org/show_bug.cgi?id=50135">50135</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Subtle behavior of OpenMP offload entries table
</td>
</tr>
<tr>
<th>Product</th>
<td>OpenMP
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Runtime Library
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vyacheslav.p.zakharin@intel.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>