topic I had already gone through it in Software Archive

segmentation fault

chavhan__hitesh — Mon, 17 Feb 2014 11:53:07 GMT

I am working on a openmp enabled code . whenever I make a native run there is segmentation fault on MIC but code runs fine on XEON .

Arrays are 64 byte aligned and using #pragma vector aligned in a for loop interestingly this pragma causes seg fault .

Removing the pragma resolves the problem but want to know why is it happening ,I an also using __assume_aligned inside function containg the for loop and memory is allocated using _mm_malloc .

You're probably aware of the

TimP — Mon, 17 Feb 2014 12:22:00 GMT

You're probably aware of the idz article on segfaults in general and that the most common MIC causes are low stack limit or too many threads.

http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors

several of the sections apply equally well to c or c++.

I had already gone through it

chavhan__hitesh — Tue, 18 Feb 2014 08:03:55 GMT

I had already gone through it but the problem retained. Also this problem is a combination of restrict keyword for pointers in function along with

#pragma vector aligned . Eliminating any one of them resolves the issues.

Pragma vector aligned asserts

TimP — Tue, 18 Feb 2014 12:09:40 GMT

Pragma vector aligned asserts that the first element of each array accessed in the for begins a new cache line. Segfault is expected on mic when you promise this but don't deliver. Compile without the pragma with -vec-report6 to see which references the compiler provides for unaligned. __assume_aligned assertions provide for individual alignments.

Thanks for the reply

chavhan__hitesh — Wed, 19 Feb 2014 06:37:42 GMT

Thanks for the reply

I worked out as you suggested by removing the pragma vector aligned and going through the vec report . Vec report suggests that all the refrences inside that particular loop are somehow now unaligned .

FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has unaligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: reference (unknown) has aligned access
FD_Scheme_block.c(148): (col. 10) remark: vectorization support: unaligned access used inside loop body

The compiler must assume

TimP — Wed, 19 Feb 2014 16:26:00 GMT

The compiler must assume unaligned where it doesn't have information to the contrary. I don't know whether adding debug symbols would help to resolve the (unknown) notations. The compiler can align one reference by peeling the loop for alignment, probably so that a stored array section is aligned (unless you set #pragma vector unaligned).

If you believe the arrays are aligned, you could add __assume aligned() assertions one at a time to find out which one is failing alignment at run time.