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. > I'm still seeing > FAIL: libgomp.c/for-5.c (internal compiler error) > FAIL: libgomp.c/for-5.c (test for excess errors) > FAIL: libgomp.c++/for-13.C (internal compiler error) > FAIL: libgomp.c++/for-13.C (test for excess errors) > which is some LTO ICE. I've never seen such ICEs before... -- Ilya
