On Fri, Jul 17, 2015 at 05:43:09PM +0300, Ilya Verbin wrote:
> On Fri, Jul 17, 2015 at 15:54:13 +0200, Jakub Jelinek wrote:
> > These tests had a thinko, computation performed on the offloaded copy of the
> > a variable, but then tested on the host side, without #pragma omp target
> > update or similar.
> > Fixed thusly.
>
> In my testing linear-2.C still causes SIGSEGV on target in f1<int>:
>
> 0x7ffff6fc3872 <_Z2f1IiEvRT_._omp_fn.29(void)>: push %rbp
> 0x7ffff6fc3873 <_Z2f1IiEvRT_._omp_fn.29(void)+1>: mov %rsp,%rbp
> 0x7ffff6fc3876 <_Z2f1IiEvRT_._omp_fn.29(void)+4>: push %rbx
> 0x7ffff6fc3877 <_Z2f1IiEvRT_._omp_fn.29(void)+5>: sub $0x48,%rsp
> 0x7ffff6fc387b <_Z2f1IiEvRT_._omp_fn.29(void)+9>: mov
> %rdi,-0x48(%rbp)
> 0x7ffff6fc387f <_Z2f1IiEvRT_._omp_fn.29(void)+13>: lea
> -0x34(%rbp),%rax
> 0x7ffff6fc3883 <_Z2f1IiEvRT_._omp_fn.29(void)+17>: mov
> %rax,-0x18(%rbp)
> 0x7ffff6fc3887 <_Z2f1IiEvRT_._omp_fn.29(void)+21>: mov
> -0x48(%rbp),%rax
> 0x7ffff6fc388b <_Z2f1IiEvRT_._omp_fn.29(void)+25>: mov (%rax),%rax
> 0x7ffff6fc388e <_Z2f1IiEvRT_._omp_fn.29(void)+28>: mov (%rax),%rax
> => 0x7ffff6fc3891 <_Z2f1IiEvRT_._omp_fn.29(void)+31>: mov (%rax),%edx
>
> (gdb) x $rax
> 0x7fff537fc1ec: Cannot access memory at address 0x7fff537fc1ec
>
> Probably something wasn't mapped.
Yeah, I've noticed too. Most likely this is about the implicit
map(tofrom:i) where i is int &.
I think it boils down to:
#pragma omp declare target
void use (int &);
#pragma omp end declare target
void
foo (int &p)
{
#pragma omp target map(tofrom:p)
{
use (p);
}
}
where we map the reference (i.e. the pointer), rather than what it points
to plus pointer translate the reference to the new copy.
Guess I'll ask on omp-lang.
Jakub
