I am facing error while trying to compile fftw3 with intel compiler for mpi+openmp configuration.
i configured using:

CC=$MPIC_COMP CXX=$MPICXX_COMP F77=$MPIF77_COMP CFLAGS="-fPIC " FFLAGS="-fPIC " LDFLAGS="" LIBS="-lifcore -lifport  -lmpi" ./configure --prefix=$ROOT_DIR/common_dependencies --enable-openmp --enable-mpi --enable-single
where:-
MPIC_COMP=mpiicc
CXX=mpiicpc
F77=mpiifort
configure succeeds , but during make i get:

mpicc -fopenmp -fPIC -o mpi-bench mpi_bench-mpi-bench.o mpi_bench-fftw-bench.o mpi_bench-hook.o  ./.libs/libfftw3f_mpi.a ../threads/.libs/libfftw3f_omp.a /home/puneet/NAMD_BUILD/fftw-3.3.4/.libs/libfftw3f.a ../.libs/libfftw3f.a ../libbench2/libbench2.a -lm -lifcore -lifport -lmpi -fopenmp
../threads/.libs/libfftw3f_omp.a(libfftw3f_omp_la-openmp.o): In function `fftwf_spawn_loop':
openmp.c:(.text+0x5c): undefined reference to `__kmpc_global_thread_num'
openmp.c:(.text+0x6e): undefined reference to `__kmpc_ok_to_fork'
openmp.c:(.text+0xae): undefined reference to `__kmpc_fork_call'
openmp.c:(.text+0xc6): undefined reference to `__kmpc_serialized_parallel'
openmp.c:(.text+0x11b): undefined reference to `__kmpc_end_serialized_parallel'
openmp.c:(.text+0x205): undefined reference to `__kmpc_for_static_init_4'
openmp.c:(.text+0x275): undefined reference to `__kmpc_for_static_fini'
/home/puneet/NAMD_BUILD/fftw-3.3.4/.libs/libfftw3f.a(trig.o): In function `fftwf_mktriggen':
trig.c:(.text+0x5cf): undefined reference to `__svml_sincos2'
trig.c:(.text+0x77f): undefined reference to `__svml_sincos2'
trig.c:(.text+0xa5a): undefined reference to `__svml_sincos2'
trig.c:(.text+0xc71): undefined reference to `__svml_sincos2'

this issue might be due to default openmp flag (-fopenmp). Now When i specify intel's openmp flag in configure , configure fails!
CC=$MPIC_COMP CXX=$MPICXX_COMP F77=$MPIF77_COMP CFLAGS="-fPIC -openmp" FFLAGS="-fPIC -openmp" LIBS="-lifcore -lifport  -lmpi" ./configure --prefix=$ROOT_DIR/common_dependencies --enable-openmp --enable-mpi --enable-single

checking whether to build static libraries... yes
checking for ocamlbuild... no
checking for mpicc... mpicc
checking for MPI_Init... no
checking for MPI_Init in -lmpi... no
checking for MPI_Init in -lmpich... no
configure: error: could not find mpi library for --enable-mpi

so when i supply -openmp flag , the compiler choses mpicc instead of mpiicc. what might be the reason for this behaviour,
any help / hint will be very fruitful.

Eagerly awaiting your reply.

Hi friends,

In my windows,I compile the code link with mkl,but it still not work.

>"C:\Program Files (x86)\Intel\Composer XE 2015\bin\compilervars.bat" intel64

>"C:\Program Files (x86)\Intel\Composer XE 2015\mkl\bin\mklvars.bat" intel64

>icl mycode.cpp /Qmkl

.........cannot find fftw3.h.......................

most according to to this page:https://software.intel.com/en-us/articles/intel-mkl-111-getting-started

I used the mkl 11.2

thanks.

Hi everyone how could I uninstall the parallel studio xe 2015 and all his components for osx?

I came across following code while going through intel's  Auto vectorization tutorial,

for (int i=0; i<length; i++) {
float s = b[i]*b[i] - 4*a[i]*c[i];
if ( s >= 0 ) {
s = sqrt(s) ;
x2[i] = (-b[i]+s)/(2.*a[i]);
x1[i] = (-b[i]-s)/(2.*a[i]);
}
else {
x2[i] = 0.;
x1[i] = 0.;
}

“if” statements are allowed if they can be implemented as masked assignments, which is usually the case.
so how exactly does the masked assignments work ? I think i have a little grasp on the masked assignment concept from here.
are these bit vectors are calculated via compilers by applying some heuristics or at run time ( BPU) ?

i understand that bit vectors with TRUE value are clubbed together and viceversa for FALSE & both of them are executed altogether.
but how exactly the mechanism works with intel machine ?

also what will be the scenario if code is non-straight line;
i.e.
 

for(i=0;i<lengthA;i++)
 for(j=0;j<lengthB;j++)
   {
 float s = a[i][j]*b[j][i];
if ( s >= 0 ) {
c[i][j] = sqrt(s) ;
}
else {

c[i][j] = 0.01 ;

}
}

A simplified/tutorialized explanation will be very fruitful .Eagerly awaiting your reply ,
 
 

Hi,

the do-while loop in the following code segment won't terminate in release mode.

(Windows 7, Visual Studio 2013, ICL version 15.0.3.208 Build 20150407)

unsigned short arr[256];
signed char index = SCHAR_MIN;
do {
	arr[(unsigned char)index] = (unsigned short)index;
} while(index++ < SCHAR_MAX);

Compiled in release mode with:

/GS /W3 /Gy /Zc:wchar_t /Zi /O2 /Ob2 /Fd"x64\Release\vc120.pdb" /Quse-intel-optimized-headers /D "_HAS_EXCEPTIONS=0" /D "_WIN64" /D "NDEBUG" /D "_CONSOLE" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Qipo /Zc:forScope /arch:AVX /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Qprof-dir "x64\Release\" /Fp"x64\Release\testing.pch"

In debug mode everything goes fine. Debug mode compiler arguments:

/GS /W3 /Zc:wchar_t /Zi /Od /Fd"x64\Debug\vc120.pdb" /D "_HAS_EXCEPTIONS=0" /D "_WIN64" /D "_DEBUG" /D "_CONSOLE" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Zc:forScope /RTC1 /arch:AVX /MDd /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Qprof-dir "x64\Debug\" /Fp"x64\Debug\testing.pch"

When inserting a print statement after the array access the issue is gone.

Thank you.

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

ASM Code:

Release:

signed char index = SCHAR_MIN;
000000013F481049  xor         eax,eax
	do {
		arr[(unsigned char)index] = (unsigned char)index;
000000013F48104B  vpshufd     xmm0,xmm0,0
000000013F481050  vpaddb      xmm5,xmm1,xmm0
000000013F481054  vpaddb      xmm8,xmm5,xmm0
000000013F481058  vpaddb      xmm11,xmm8,xmm0
	unsigned short arr[256];
	signed char index = SCHAR_MIN;
000000013F48105C  add         eax,0FFFFFF80h
	do {
		arr[(unsigned char)index] = (unsigned char)index;
000000013F48105F  vpaddb      xmm14,xmm11,xmm0
000000013F481063  vpaddb      xmm2,xmm14,xmm0
000000013F481067  vpaddb      xmm5,xmm2,xmm0
000000013F48106B  vpaddb      xmm8,xmm5,xmm0
000000013F48106F  vpaddb      xmm1,xmm8,xmm0
000000013F481073  jmp         main+50h (013F481050h)  

Release with print statement:

signed char index = SCHAR_MIN;
000000013F8D106E  mov         ebx,0FFFFFF80h
	do {
		arr[(unsigned char)index] = (unsigned char)index;
		std::cout << index << std::endl;
000000013F8D1073  mov         edx,ebx
000000013F8D1075  mov         rcx,qword ptr [__imp_std::cout (013F8DF0A0h)]
000000013F8D107C  call        std::operator<< (013F8D2B30h)
000000013F8D1081  mov         rcx,rax
000000013F8D1084  lea         rdx,[std::endl (013F8D6850h)]
000000013F8D108B  call        qword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (013F8DF150h)]
	} while(index++ < SCHAR_MAX);
000000013F8D1091  movsx       rax,bl
000000013F8D1095  inc         ebx
000000013F8D1097  cmp         eax,7Fh
000000013F8D109A  jl          main+73h (013F8D1073h)  

Debug:

signed char index = SCHAR_MIN;
000000013FCF2B0D  mov         byte ptr [rbp],80h
	do {
		arr[(unsigned char)index] = (unsigned char)index;
000000013FCF2B11  movsx       eax,byte ptr [rbp]
000000013FCF2B15  movsx       rax,al
000000013FCF2B19  movzx       eax,al
000000013FCF2B1C  lea         rdx,[arr]
000000013FCF2B23  movsx       ecx,byte ptr [rbp]
000000013FCF2B27  movsx       rcx,cl
000000013FCF2B2B  movzx       ecx,cl
000000013FCF2B2E  imul        rcx,rcx,2
000000013FCF2B32  add         rdx,rcx
000000013FCF2B35  mov         word ptr [rdx],ax
	} while(index++ < SCHAR_MAX);
000000013FCF2B38  movsx       eax,byte ptr [rbp]
000000013FCF2B3C  movsx       rax,al
000000013FCF2B40  mov         dword ptr [rbp+4],eax
000000013FCF2B43  movsx       eax,byte ptr [rbp]
000000013FCF2B47  mov         edx,1
000000013FCF2B4C  add         eax,edx
000000013FCF2B4E  mov         byte ptr [rbp],al
000000013FCF2B51  mov         eax,dword ptr [rbp+4]
000000013FCF2B54  cmp         eax,7Fh
000000013FCF2B57  jl          main+0C9h (013FCF2B11h)  

Hi,
I am using the pointer checker feature as documented (including chkp.h and compiling with flag /Qcheck-pointers:rw, also refer to https://software.intel.com/en-us/node/522704) in a C++ application on Win 8.1.
The pointer checker works perfectly fine and reports a buffer overrun if I use stack memory or unaligned heap memory (using malloc).
The pointer checker however does not report any overrun if I use aligned heap memory (using mkl_malloc or _aligned_malloc)

Sample code:

int _tmain(int argc, _TCHAR* argv[])
{
     __chkp_report_control(__CHKP_REPORT_LOG, 0);

    //char buf[5];                                        // OK, reports buffer overrun
    // __declspec(align(32)) char buf[5];                // OK, reports buffer overrun
    //char *buf = (char *) malloc(5);                    // OK, reports buffer overrun
    char *buf = (char *) mkl_malloc(5, 32);                // NOK, does not report buffer overrun
    //char *buf = (char *) _aligned_malloc(5, 32);        // NOK, does not report buffer overrun
    for (int i=0; i<=5;i++) {
        buf[i] = 'A' + i;
    } 
}

How can I enable pointer checking for aligned memory?

Thanks,

Lars

c:\>icl demo.cpp

...    

LNK2019: error cannot resolve the external symbol ___intel_new_feature_proc_init,

Why?

Only "icl /Od demo.cpp" is OK，that is option /O1 and /O2 and /O3 are compiled incorrectly; What happend to it?Why all options of cl compiler are correct?

My computer's intel processor:

The third generation of Intel core i5-3210M processor core @ 2.50GHz

Step E1

Speed 2.50 GHz (100 x MHz 25)

Number of processors core number: 2 / thread number: 4

Core code Bridge Ivy

Production process 22 nm

H2 Socket (LGA 1155).

First level data cache 2 KB 32 8-Way, byte, 64 lines X

Level 1 code cache 2 KB 32 x, 8-Way, 64 lines byte

Two level cache 2 x 256 KB, 8-Way, 64 lines byte

Three level cache 3 12-Way, MB, 64 lines byte

SSE, SSE2,, SSE3, SSSE3, SSE4.1, SSE4.2, HTT,, EM64T, EIST, Boost, MMX, Turbo

After installing Visual C++ 2015 my Intel C++ 15 compiles started failing. It looks like Intel C++ is automatically picking up (incompatible) headers from the latest Visual C++.

Is there a way to force Intel C++ to use specific Visual C++ headers?

Do we have assurances that Intel C++ 2016 will be compatible with Visual C++ 2015?

Thanks,
Stuart

Just installed the latest Composer edition on windows to test it out. Have VS 2012 Pro, but installed 2015 Community for the new headers (can't intel supply their own headers? sheesh). getting some bizarra behavoir, like:

... error : identifier "not" is undefined

1>                if (not dataArray.isStorageContiguous()) {

Seriously?And several times, I get:

1>": : error : ** The compiler has encountered an unexpected problem.

1>  ** Segmentation violation signal raised. **

1>  Access violation or stack overflow. Please contact Intel Support for assistance.

But, if I just hit "build" again, that usually goes away. Is the windows distribution buggy or what?

Hello,

I just "upgraded" my Windows 8.1 Pro computer to Windows 10 Pro (x64) and immediately noticed a very significant slow-down of compilation (computer: 2x Xeon X5690 3.47GHz, 24 GB RAM, NVidia GTX 580, Intel SSD 540 Series).

It can be seen in both Visual Studio 2013 Pro and Visual Studio 2015 Community IDEs.

I have Beta version of Intel 2016 (update 2) compiler installed.

Before the upgrade in Windows 8.1 Pro (x64) everything worked just fine.

I already completely disable UAC in Windows 10, completely disabled Windows Defender using Group Policy. It made no difference at all. In all cases I see a huge delay right after starting compiling any Intel-enabled project (about 1 - 1.5 minutes before the first file in the project is processed!).

Also is I switch to Microsoft C++ compiler, everything again starts to work quickly enough, so I suspect something is related to Intel integration with VS.

Is it a known issue? Does anybody else see it? Any workaround?

Regards,

    Michael

I'm running on Linux and I got a library (.a) which was compiled by Intel compiler.

I'm trying to link against this static library (I'm using g++) and getting link error:

undefined reference to intel_fast_memcpy

I requested to get the library as a shared library (.so) which was compiled by intel compiler too, and I got the same error.

How can I use libraries which were compiled by Intel compiler, when I'm using gcc?

//  test.cpp
#include <tuple>

int main()
{
auto t = std::make_tuple(1, 1.2);
return 0;
}

icpc -v

icpc version 15.0.3 (gcc version 5.1.0 compatibility)

OS X 10.10 - If using " icpc -std=c++11 test.cpp ", it's OK. But if using " icpc -std=c++14 test.cpp ", it prompts

error: namespace "std" has no member "make_tuple"

  auto t = std::make_tuple(1, 1.2);

I tested this code on a linux machine, and both cases passed. So what could cause this problem on OS X?

Greetings,

I have non-commercial project which is fine-tuned for ICC, but Travis-CI only supports GCC, due to license of ICC which is free only for non-commercial projects on Linux.

See this thread: https://github.com/travis-ci/travis-ci/issues/4604

best, vdm.

Hi Folks,

I don't know if this is the right place to post this issue, if not please let me know where it would be more appropriate to post it?
I'm having the following problem, using icpc 15.0.3, but I don't think this depeneds on the compiler bur rather on the CPU architecture.
Consider the following code in C++:

struct Tuple{
  size_t _a;
  size_t _b;
  size_t _c;
  size_t _d;
  size_t _e;
  size_t _f;
  size_t _g;
  size_t _h;
};


void
deref_A(Tuple& aTuple, const size_t& aIdx) {
  aTuple._a = A[aIdx];
}

void
deref_AB(Tuple& aTuple, const size_t& aIdx) {
  aTuple._a = A[aIdx];
  aTuple._b = B[aIdx];
}

....

void
deref_ABCDEFG(Tuple& aTuple, const size_t& aIdx) {
  aTuple._a = A[aIdx];
  aTuple._b = B[aIdx];
  aTuple._c = C[aIdx];
  aTuple._d = D[aIdx];
  aTuple._e = E[aIdx];
  aTuple._f = F[aIdx];
  aTuple._g = G[aIdx];
}

Note that A, B, C, ..., G are simple arrays (declared globally). Arrays are filled with integers.

The methods "deref_*", simply assign some values from arrays to the given struct parameter "aTuple". So I first start by assigning to a single field of the given struct, and continue all the way to all fields. That is, each method assigns one more field than the previous one.  The methods "deref_*" are called with index (aIdx) ranging from 0, to MAX size of the arrays (arrays have the same size by the way).

Now, consider the graph attached, which depicts the performance for array sizes starting with 20 million (size_t = 8 bytes) integers, up to 24 m.

When the arrays contain 21 million integers (size_t), the performance degrades for the methods touching at least 5 different arrays (i.e., deref_ACDE...G), therefore you will see peaks in the graph. I'm wondering why this is happening? This is happening only when I'm testing on a server with CPU:  Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz, but not with Haswell, i.e., v3. Clearly this is a known issue to Intel and has been resolved, but I don't know what it is, and how to improve the code for v2.

I would highly appreciate any hint from your side.

To even better illustrate the problem, consider the second graph, which depicts the running time for three different CPUs. This time, it is tested by 8 array accesses (i.e., only the method deref_ABCDEFG) for different array size. X-axes shows array size as power of 2, i.e., exponents of 2.

Compiling in Visual Studio 2015 with the Visual Studio 2013 platform toolset is not working because of some Intel composer platform files. The Intel configuration is preventing me of compiling legacy applications because of it.

1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\PlatformToolsets\v120\ImportBefore\Intel.Libs.MKL.v120.targets(44,5): error MSB6003: The specified task executable "cmd.exe" could not be run. The working directory "mkl\tools" does not exist.

Compiling the same configuration in Visual Studio 2013 IDE is working. 

Applications installed on my system (related):
- Intel Composer XE 2013
- Intel Composer XE 2013 SP1
- Visual Studio 2013
- Visual Studio 2015

Here are the steps taken to easily reproduce the error.
- Create a new Visual Studio C++ Win32 project.
- Project is set to VS2015 toolset (compilation works).
- Change the platform toolset to Visual Studio 2013 (Project / Properties / Configuration Properties / General -> Platform Toolset).
- Compile and get the results above.

Side note : I have the same results when choosing Visual Studio 2012 but no error when using Visual Studio 2010 toolset.

Choosing Intel Compiler XE 14.0 is not working either, altough I am not expecting it to work because it is not yet integrated for Visual Studio 2015.

1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\PlatformToolsets\Intel C++ Compiler XE 14.0\Toolset.targets(123,5): error : Could not expand ICInstallDir variable. Platform toolset may be set to an invalid version number.

What I am not happy tough is that the installation of Intel Composer is preventing me from compiling VS2013 applications inside VS2015 which is preventing me of using VS2015 for some projects.

Is there any way of preventing this error? Is there any configuration in Visual Studio 2015 that could be set in order for the target files to be parsed properly? Uninstalling Intel Composer 2013 SP1 is not an option since it is being used in other projects/solutions.

Thanks
Sébastien

The following code will not compile with icpc 15.0.2:

#include <algorithm>
#include <array>
#include <numeric>

template<typename T>
T const & (*maxer) (T const &, T const &) = std::max<T>;

int main(void) {
    std::array<float, 8> data;
    std::iota(data.begin(), data.end(), 0.0f);
    if (std::accumulate(data.begin(), data.end(), 0.0f, maxer<float>) == 7.0f) {
        return 0;
    } else {
        return 1;
    }
}

Here is the output:

$ icpc -std=c++14 -Wall -Wextra max.cc
max.cc(6): error: "maxer" is not a function or static data member
  T const & (*maxer) (T const &, T const &) = std::max<T>;
              ^

max.cc(11): error: identifier "maxer" is undefined
      if (std::accumulate(data.begin(), data.end(), 0.0f, maxer<float>) == 7.0f) {
                                                          ^

max.cc(11): error: type name is not allowed
      if (std::accumulate(data.begin(), data.end(), 0.0f, maxer<float>) == 7.0f) {
                                                                ^

max.cc(11): error: expected an expression
      if (std::accumulate(data.begin(), data.end(), 0.0f, maxer<float>) == 7.0f) {
                                                                      ^

compilation aborted for max.cc (code 2)

This code compiles successfully under clang++ and g++. As far as I can tell it is completely standards complaint. I suspect this is just a bug. I can work around it in the meantime by removing the template and hard-coding a type.

Hello,

I have VS2013 Pro, VS 2015 Community, and Intel 2016 Upd 2 (Beta) installed. Since there are some problems with new Windows 10 run-time support, I would like to compile my targets against older (v120) toolset in order to use VS2013 run-time dlls.

In the case of Visual Studio compiler this can be done quite easily: by selecting "Platform Toolset" option = v120.

In the case of Intel C++ we have additional choices, like "Base Platform Toolset":

It is logical to expect that when "v120" option is selected, Intel Compiler will use VS 2013 run-times, etc. Nevertheless it looks like the selection of "Base Platform Toolset" has no influence on compilation results, in all cases Windows 10 run-time is used.

Is it a bug? Should I submit it to support?

Regards,

    Michael

I am trying to compile namd(with smp) on centos 6.4 with intel 2015 for intel xeon phi , and i am getting following error:

MPIR_Thread: TLS definition in libmpi_mt.so section .tbss mismatches non-TLS definition in libmpi.so.12
section .bss could not read symbols: Bad value

attached :

• namdmic.log : compilation error log
• namd_build_smp.sh: namd compilation script

I tried this solution but then i got:

Adding file obj/psfplugin.o...
OpenMP support enabled
charmc> ----------- Module dependency search ------------
charmc> ----------- Module dependency search complete ------------
Adding registration for module NeighborLB
Adding registration for module HybridLB
Adding registration for module RefineLB
Adding registration for module GreedyLB
Adding registration for module CkMulticast
charmc: Executing mpicxx -m64 -fPIC -D_REENTRANT -D__CHARMC__=1 -DCMK_OPTIMIZE=1 -Iinc -Isrc -Ofast -fomit-frame-pointer -fp-model fast=2 -xHost -qopenmp -mt_mpi -offload-option,mic,compiler,-vec -offload-option,mic,compiler,-restrict -U_FORTIFY_SOURCE -fno-stack-protector -fopenmp -c moduleinit6026.C -o moduleinit6026.o
g++: fast=2: No such file or directory
g++: unrecognized option '-qopenmp'
g++: language Host not recognized
g++: language Host not recognized
Fatal Error by charmc in directory /home/puneet/NAMD_BUILD/NAMD_2.10_Source/Linux-x86_64-icc
   Command mpicxx -m64 -fPIC -D_REENTRANT -D__CHARMC__=1 -DCMK_OPTIMIZE=1 -Iinc -Isrc -Ofast -fomit-frame-pointer -fp-model fast=2 -xHost -qopenmp -mt_mpi -offload-option,mic,compiler,-vec -offload-option,mic,compiler,-restrict -U_FORTIFY_SOURCE -fno-stack-protector -fopenmp -c moduleinit6026.C -o moduleinit6026.o returned error code 1
charmc exiting...
rm -f moduleinit6026.C moduleinit6026.o
make: *** [namd2] Error 1

Eagerly awaiting your reply,

errors::~runtime_error，

errors::runtime_error，

errors::~system_error,

errors::system_error,

how can I solve the error in the program?

Thanks!

Hey,

I've installed the latest version of the Intel Parallel Studio XE -Cluster-Edition- 2015 Update 3 and found a minor bug:
After installation I've tried to source the psxevars.sh which worked for all features (Vtune, Amplifier, etc,) except the Intel compilers and MPI-Variables.

The reason: psxevars.sh tries to load the compilervars.sh. (see attached extract of source code)

Unfortunately there is no directory "composerxe". Typically this is a symbolic link to the original directory to hide the version number, e.g.:
composer_xe -> /workspace/tools/intel/parallel_studio_xe_2015/composer_xe_2015.3.187/

This link is missing and should be created using ln -s.
To stick to the naming of other Intel products, you might change $SCRIPTPATH/composerxe/bin/compilervars.sh to $SCRIPTPATH/composer_xe/bin/compilervars.sh in the psxevars.sh, too.

Same problem applies to the mpivars.sh. The psxevars.sh points to "impi_latest" which also does not exist by default. Thus adding a symbolic link named impi_latest pointing to the impi/VERSION directory in your installdir will help. Then mpirun etc. will be correctly sourced by psxevars.sh.

Cheers
Sebastian