This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: The issue of libgomp on MIC
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Stephen Wang <wangyichao at sjtu dot edu dot cn>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, gcc-help at gcc dot gnu dot org, Ilya Verbin <iverbin at gmail dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Tue, 23 Jun 2015 11:42:02 +0200
- Subject: Re: The issue of libgomp on MIC
- Authentication-results: sourceware.org; auth=none
- References: <8304FC26AD82478C946010B38B1C2025 at sjtu dot edu dot cn> <874mlydg4l dot fsf at kepler dot schwinge dot homeip dot net> <31C7D3DF20374838B226333538010765 at sjtu dot edu dot cn>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jun 23, 2015 at 05:33:09PM +0800, Stephen Wang wrote:
> Hi Thomas,
>
> Thanks a lot for your quick response :-)
>
> The attachment is the kernel benchmark I used.
You invoke undefined behavior. See OpenMP 4.0, page 82, lines 9-10:
"If the corresponding list item is not present in the device data
environment, the behavior is unspecified."
That is the case, while the base variables of the array sections are mapped,
the array sections themselves are not mapped.
I bet you or the testcase author meant to use
#pragma omp target data map(to:rowStart[0:(r+2)], matVal[0:(nnz+2)], col[0:(nnz+2)], vecVal[0:(r+2)], r, s, t) map(from: retVal[0:(r+2)])
instead of the:
#pragma omp target update to(rowStart[0:(r+2)], matVal[0:(nnz+2)], col[0:(nnz+2)], vecVal[0:(r+2)], r, s, t) from(retVal[0:(r+2)])
Jakub