Strange issue with omp parallel for with static schedule

[Waruna_R_]

Hello,

I found an strange issue with openmp parallel for with schedule clause which I believe is a bug.

I have attached the minimal code sample to reproduce the issue. 

#include <stdio.h>
#include <omp.h>

int main (int argc, char **argv) {
	int ti;
	#pragma omp parallel for private(ti) schedule(static ,1)
	for (ti = 0; ti < 10; ti+=2) {
		printf("[%d]\n", ti);
	}

	return 0;
}

Compiled with
icc icc_omp_issue.c -o icc_omp_issue -openmp  -O3 -Wall -Werror -xHost  -std=c99  -lm -lpthread -liomp5

To run

export OMP_NUM_THREADS=1; ./icc_omp_issue

The expected output of the program with one thread is 

[0]
[2]
[4]
[6]
[8]

But actual output is

[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]

Which is not correct. Also note that this happens only on a Sandy-Bridge CPU, on all the other architectures that we tried, it worked fine. The environmental information is provided below.

By changing the chunk size, we noticed that the above piece of code get compiled into following loop nest, where "CHUNK_SIZE" is the chunk size of the static schedule, "STEP" is the increment of the original loop at each iteration and "N" is the upper bound of the original loop. (NB: again this only happens on one machine with a Sandy-Bridge CPU)

  for (int x = 0; x < N; x+=CHUNK_SIZE) {
    int ub = min(x+(STEP*CHUNK_SIZE),N);
    for (int y = x; y < ub; y+=STEP) {
      printf("[%d] ", y);
    }
  }

I can reproduce the issue in this machine consistently. Let me know if anyone needs more information.

Environment information.

icc -V
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

uname -a
Linux crunch1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 GNU/Linux

CPU: 4 x Intel(R) Xeon(R) CPU E5-4620 0 @ 2.20GHz

ldd icc_omp_issue
    linux-vdso.so.1 (0x00007ffd0d388000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6ac2474000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6ac2257000)
    libiomp5.so => /local/cpernet/builds/lib/xkaapi/libiomp5.so (0x00007f6ac2044000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6ac1e2e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6ac1a85000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6ac1881000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6ac2775000)
    libkomp.so.1 => /local/cpernet/builds/lib/libkomp.so.1 (0x00007f6ac1675000)
    libkaapi.so.0 => /local/cpernet/builds/lib/libkaapi.so.0 (0x00007f6ac144e000)
    libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f6ac1243000)

[Martyn_C_Intel]

Hi,

     I have tried to reproduce this on a Sandy Bridge system with the same compiler that you use, so far without success. Can you tell me which version of gcc you have installed? (I had gcc 4.4.3). I don't currently have access to a system running Debian, but issues depend on gcc or glibc more often than on the actual OS.

I see that your executable has 3 dependencies that mine does not have: libkomp.so, libkaapi.so, libnuma.so. Can you tell me the origin/purpose of these? What happens if you link without them, or at least, without libkomp ? Multiple OpenMP runtimes seems like a possible source of confusion.

If you believe the difference is due to compiled code, then perhaps attach the assembly code, (compile with -S), so that I can compare to what I see?

[Waruna_R_]

Martyn Corden (Intel) wrote:

Hi,

     I have tried to reproduce this on a Sandy Bridge system with the same compiler that you use, so far without success. Can you tell me which version of gcc you have installed? (I had gcc 4.4.3).

I don't currently have access to a system running Debian, but issues depend on gcc or glibc more often than on the actual OS.

I see that your executable has 3 dependencies that mine does not have: libkomp.so, libkaapi.so, libnuma.so. Can you tell me the origin/purpose of these? What happens if you link without them, or at least, without libkomp ? Multiple OpenMP runtimes seems like a possible source of confusion.

Thanks alot for the response. As soon as I removed the libkomp.so, it worked fine. my mistake.