bug report [icc version 12.1.3] extern inside openmp block

[Sergey_R_]

Hello,

Let's we have two files extern.cpp and main.cpp

extern.cpp:

---------------

double e;

--------------

main.cpp

----------------------------

#include <iostream>
using namespace std;

void set()
{
   extern double e;
   e = 10;
}

int main()
{
   set();
#pragma omp parallel for
   for (int i = 0 ; i < 10 ; i++)
     {
        extern double e;
        cout<<e<<endl;
     }
}

-------------------------

after compilation: icc main.cpp extern.cpp -openmp, program print zeros. For some reason e inside loop became equal 0.

Cheers,

Sergey

[SergeyKostrov]

Could you provide some additional information? That is: - Platform ( OS ) - Version of Intel C++ compiler and Update number - A complete command line to compile the test Thank you in advance.

[Sergey_R_]

platform - linux (Mageia release 2 (Official) for x86_64)

icc version - Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1.3.293 Build 20120212

compilation command - icc extern.cpp main.cpp -openmp

[Sergey_R_]

platform --- Mageia release 2 (Official) for x86_64

icc version ---  Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1.3.293 Build 20120212
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

compile --- " icc main.cpp extern.cpp -openmp" 

[Marián__VooDooMan__M]

Greetings,

IMO it is caused by optimization called "constant propagation", that is, when you set "e=0;" the compiler treats it as it is always zero, thus propagating constant. NB that this is compiler-specific, each compiler has its own algorithms for optimization. Since you set the 'e' to '10', I have suspicion that it is bug in ICC. Try to make declaration of "double e;" volatile, i.e. "volatile double e;", to let the compiler know that optimization should not be assumed and performed regarding to variable 'e'. Of course, you will get performance impact, sice compiler will not oprimize volatile variables.

Anyways, it seems to me that it is bug in ICC, and it assumes constant propagation optimization in a bad way.

Could you please test it under ICC 13 (most preferably "update 3" that is current and most recent version)? Maybe it has been fixed since then.