I am attempting to build a third-party application, https://github.com/idaholab/moose, using the instructions at http://www.mooseframework.org/getting-started/.

To adapt to our Intel Parallel Studio Cluster ed., the configure command in the main build script of this application (scripts/update_and_rebuild_libmesh.sh) was modified with these lines:

               --with-thread-model=tbb \
               --with-tbb=/nopt/intel/17.0.5/tbb \
               CC=mpiicc CXX=mpiicpc FC=mpiifort F77=mpif77 \
               CFLAGS="-axCORE-AVX2,AVX" \
               CXXFLAGS="-axCORE-AVX2,AVX" \
               FCFLAGS="-axCORE-AVX2,AVX" F77FLAGS="-axCORE-AVX2,AVX" \
               LDFLAGS="-Wl,-rpath-link,/nopt/intel/psxe2017u2/compilers_and_libraries_2017.5.239/linux/compiler/lib/intel64" \
               PETSC_DIR=$HOME/petsc-3.8 PETSC_ARCH=impi-intel \

I load the Intel environment on top of an Anaconda version 5 build environment, but the same thing happens on top of a standalone GCC 7.2 installation.

The build proceeds fine until:

...
  CXX      src/systems/libmesh_dbg_la-fem_context.lo
/nopt/nrel/apps/anaconda/5.0.1-cos7/bin/../x86_64-conda_cos6-linux-gnu/include/c++/7.2.0/ext/new_allocator.h(136): error: function "std::pair<_T1, _T2>::pair(const std::pair<_T1, _T2> &) [with _T1=const libMesh::FEType, _T2=std::unique_ptr<libMesh::FEAbstract, std::default_delete<libMesh::FEAbstract>>]" (declared at line 292 of "/nopt/nrel/apps/anaconda/5.0.1-cos7/bin/../x86_64-conda_cos6-linux-gnu/include/c++/7.2.0/bits/stl_pair.h") cannot be referenced -- it is a deleted function

I have tried adding to CFLAGS and CXXFLAGS "-no-gcc-include-dir -use-intel-optimized-headers", but the identical error is generated.

The developers claim that their tests with the same Intel compilers pass fine.

Questions,

1. Is there an obvious workaround that uses the same commands?
2. Is there a way to substitute Intel headers and avoid the GCC headers, in case there is an inconsistency?

Linux login4 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Thanks,

Chris

When using the Intel Math Library with Intel C++ 2018 and Visual C++ 2017 (15.5.7), there is a linker problem when using static linked runtime library because there is no debug version of the Intel Math libary for multithreaded static linking.

The question is whether the workaround (ignoring the libcpmt.lib) is robust

This sample code exposes the problem (when compiled with Debug Multi-threaded Static library (/MTd)

#include <iostream>

#include <vector>

#include <mutex>

#include <cstdlib>

#include <cmath>

// This application is build to expose a linker issue using the Intel 2018 C++ compiler on Windows

// using Debug build and static linked multi-thread runtime-library

//

// The issue is visible when using the Intel Math library and the Microsoft C++ run-time library

// An example of that is when using the std::sin (from the Intel Math Library) function and the std::mutex (from the Microsoft Runtime Library)

//

// From

//    https://software.intel.com/en-us/articles/libraries-provided-by-intelr-c...

// it is stated that there are no Intel Math Library for Debug Multi-Threaded (/MTd)

// Thus the Multi-threaded static Intel Math Library (/MT) (libmmt.lib) references the Microsoft Multi-threaded Static Release Library (libcpmt.lib),

// while the application references the Microsoft Multi-threaded static Debug Library (libcpmtd.lib)

//

// Thus there is a linker conflict.

//

// The linker errors are:

//   Error LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in ConsoleApplication3.obj ConsoleApplication3 c:\Users\mhn\source\repos\ConsoleApplication3\libcpmt.lib(ppltasks.obj) 1

//   Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in ConsoleApplication3.obj ConsoleApplication3 c:\Users\mhn\source\repos\ConsoleApplication3\libcpmt.lib(ppltasks.obj) 1

//   Error LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in ConsoleApplication3.obj ConsoleApplication3 c:\Users\mhn\source\repos\ConsoleApplication3\libcpmt.lib(excptptr.obj) 1

//   Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in ConsoleApplication3.obj ConsoleApplication3 c:\Users\mhn\source\repos\ConsoleApplication3\libcpmt.lib(excptptr.obj) 1

//

// The workaround is to add the library

//    libcpmt.lib

// to Ignore Specific Default Libraries

// But is this safe

// The muxtex sin_vector_mutex is redundant

// but it exposes a problem when building with the Intel 18 Compiler on Windows

std::mutex      sin_vector_mutex;

std::vector<double> sin( const std::vector<double>& values)

{

    std::lock_guard<std::mutex>     lock ( sin_vector_mutex );

    std::vector<double> result;

    for(const auto value : values)

    {

        result.push_back( std::sin(value) );

    }

    return result;

}

int main (int argc, char *argv[])

{

    if(argc < 2)

    {

        return EXIT_SUCCESS;

    }

    const std::vector<double>   values = [ argc, argv ]()

    {

        std::vector<double> result;

        for( int i = 1; argc != i; ++i)

        {

            const double    value = std::atof( argv[i] );

            if( 0.0f != value )

            {

                result.push_back( value );

            }

        }

        return result;

    }();

    for(const auto value : values)

    {

        std::cout << value << std::endl;

    }

}

Hi, I essentially need the profile guided optimizations, because without them the executables are huge and slower. I have ICC 2016 and I also tried ICC 2018, in both cases same results - while the normal build produces working executables (sames as all other compilers - MSVC and CLANG), profile guided generation executables crash (after compiling for hours and producing over 200MB executable, both 32bit and 64bit Windows).

Command line for compiler:

icl.exe /D "MNOPARAMETERCHECK" /D "MELDAPRODUCTIONAUDIOPLUGINKERNEL" /D "MELDAPRODUCTIONAUDIOPLUGINKERNELV11" /D "MVERSION=\"12.00a\"" /D "MVERSIONINT=0xC0000" /D "NDEBUG" /D "MLIBRARYDLL" /D "MPROJECTNAME=MeldaProductionAudioPluginKernelV11" /D "MPROJECTNAMESTRING=\"MeldaProductionAudioPluginKernelV11\"" /D "MENABLETBBxxx" /D "MINTELIPP_8" /D "MINTELIPP" /D "MUNICODE" /D "MENABLEDIRECTSOUND" /D "MENABLEASIO" /D "_SECURE_SCL=0" /D "_WINDOWS" /D "UNICODE" /D "_MBCS" /D "WIN32" /GR- /bigobj /Qrestrict /arch:SSE2 /Qprof-gen /Qprof-dir c:\PROFGEN\MeldaProductionAudioPluginKernelV11 /MT /TP /Fd"!temp/ReleaseReleaseIntelcompiler0/MeldaProductionAudioPluginKernelV11/vc70.pdb" /D_USRDLL /D_WINDLL /D_WINDOWS /DWIN32 /MP /Fo"!temp/ReleaseReleaseIntelcompiler0/MeldaProductionAudioPluginKernelV11/KERNEL.obj" /FR"!temp/ReleaseReleaseIntelcompiler0/MeldaProductionAudioPluginKernelV11/" /I "D:/programming/mlibrary" /I "D:/Programming/MDrummer/MDrummer" /I "C:/Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\ia32" /I "C:/Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include" /I "C:/Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\icc" /I "D:/programming/mlibrary/library/"  /I "C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018/windows/ipp/include" /I "C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018/windows/ipp/include" /I "C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018/windows/tbb/include" /D_MBCS /Wp64 /c /W3 /Gm- /Qstd=c++14 /Zc:forScope /nologo /Gd /GF /EHsc /fp:fast /GS- /Qdiag-disable:1292 /Qvc14 /Qm32 /O1 /Os /vec- MDrummer/KERNEL.cpp

Command line for linker:

icl.exe kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib wsock32.lib winmm.lib msimg32.lib psapi.lib opengl32.lib Glu32.lib freetype.lib zlib.lib libpng.lib libtiff.lib libjpeg.lib giflib.lib bzip2.lib libflac.lib vstsdk3.lib aax.lib asio.lib libmad.lib fcnn.lib ippsmt.lib ippvmmt.lib ippcoremt.lib ippimt.lib /link /MP /OUT:"D:/Programming/MDrummer/BINEffects/binkernel/MeldaProductionAudioPluginKernelV11.dll" /INCREMENTAL:NO /RELEASE /MACHINE:X86 /SUBSYSTEM:WINDOWS,5.01 /DYNAMICBASE /DLL /IMPLIB:"D:/Programming/MDrummer/!temp/ReleaseReleaseIntelcompiler0/MeldaProductionAudioPluginKernelV11.lib" /LIBPATH:"D:/programming/mlibrary/library" /LIBPATH:"D:/Programming/MDrummer" /LIBPATH:"D:/Programming/MDrummer/!temp/ReleaseReleaseIntelcompiler0" /LIBPATH:"D:/Programming/MDrummer/BINEffects/bin" /LIBPATH:"C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018/windows/ipp/lib/ia32" /LIBPATH:"C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018/windows/tbb/lib/ia32/vc12" /LIBPATH:"C:/Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\lib\ia32" /nologo /MANIFEST:NO /Gy /Qoption,link,/OPT:REF /OPT:REF /OPT:ICF

In case it would help, this is where it crashes (access violation):

1CBA6915  movq        xmm1,mmword ptr ds:[246684ACh]  
1CBA691D  movq        xmm0,mmword ptr ds:[2067DD60h]  
1CBA6925  paddq       xmm1,xmm0  
1CBA6929  movq        mmword ptr ds:[246684ACh],xmm1  
1CBA6931  mov         dword ptr [ebp],20h  
1CBA6938  cmp         dword ptr ds:[24008288h],0  
1CBA693F  je          1CBA755D  
1CBA6945  movq        xmm1,mmword ptr ds:[240082B8h]  
1CBA694D  movq        xmm0,mmword ptr ds:[2067DD60h]  
1CBA6955  paddq       xmm1,xmm0  
1CBA6959  movq        mmword ptr ds:[240082B8h],xmm1  
1CBA6961  cmp         dword ptr ds:[240084C4h],0  
1CBA6968  je          1CBA7544  
1CBA696E  push        dword ptr ds:[11990004h]  
1CBA6974  push        dword ptr ds:[11990000h]  
1CBA697A  push        5  
1CBA697C  movq        xmm1,mmword ptr ds:[240084E4h]  
1CBA6984  movq        xmm0,mmword ptr ds:[2067DD60h]  
1CBA698C  paddq       xmm1,xmm0  
1CBA6990  push        0DEECE66Dh  
1CBA6995  movq        mmword ptr ds:[240084E4h],xmm1  
1CBA699D  call        203DC4E0  
1CBA69A2  add         eax,0Bh  
1CBA69A5  movq        xmm1,mmword ptr ds:[240082A8h]  
1CBA69AD  adc         edx,0  
1CBA69B0  xor         ebx,ebx  
1CBA69B2  movq        xmm0,mmword ptr ds:[2067DD60h]  
1CBA69BA  movzx       edi,dx  
1CBA69BD  paddq       xmm1,xmm0  
>>>> 1CBA69C1  mov         dword ptr ds:[11990000h],eax  
1CBA69C6  mov         dword ptr ds:[11990004h],edi  
1CBA69CC  shr         eax,10h  
1CBA69CF  shl         edi,10h  
1CBA69D2  or          edi,eax  
1CBA69D4  movq        mmword ptr ds:[240082A8h],xmm1  
1CBA69DC  cmp         dword ptr ds:[24008620h],0  
1CBA69E3  je          1CBA752B  
1CBA69E9  movq        xmm0,mmword ptr ds:[24008640h]  
1CBA69F1  movq        xmm1,mmword ptr ds:[2067DD60h]  
1CBA69F9  movq        xmm2,mmword ptr ds:[240082B0h]  
1CBA6A01  paddq       xmm0,xmm1  
1CBA6A05  paddq       xmm2,xmm1  
1CBA6A09  movq        xmm3,mmword ptr ds:[2067DEC0h]  
1CBA6A11  mov         dword ptr [esp],2400822Ch  
1CBA6A18  mov         dword ptr [esp+4],7  
1CBA6A20  movq        mmword ptr ds:[24008640h],xmm0  
1CBA6A28  movq        mmword ptr ds:[240082B0h],xmm2  
1CBA6A30  movq        mmword ptr [esp+8],xmm3  
1CBA6A36  call        203BAC60  
1CBA6A3B  push        ebx  
1CBA6A3C  movq        xmm5,mmword ptr ds:[24668484h]  
1CBA6A44  movq        xmm4,mmword ptr ds:[2067DD60h]  
1CBA6A4C  push        0FFFFFFFFh  
1CBA6A4E  paddq       xmm5,xmm4  
1CBA6A52  push        ebx  
1CBA6A53  push        edi  

We have the following test case. It compiles and runs normally on CentOS7 with Intel PSXE 2018 and devtoolset-6/devtoolset-7. In PSXE 2018 Update1 or Update 2, the same code compiles, but is broken. If, in Update1 or Update2, the code is compiled with -O1, it no longer fails:

$ cat test.cpp 
#include <string>

std::string a() {
return "aaa";
}
std::string b() {
return std::string("bbbbbbbb") + std::string("c");
/* return std::string("bbbbbbb") + std::string("c"); */
}
int main( int argc, char *argv[] ) {
std::string s = a() + b();
return 0;
}

[ssilverman@scottc7virt icctest]$ icpc -v; icpc -o test.gcc485 test.cpp
icpc version 18.0.2 (gcc version 4.8.5 compatibility)
[ssilverman@scottc7virt icctest]$ scl enable devtoolset-6 "icpc -v; icpc -o test.gcc631 test.cpp"
icpc version 18.0.2 (gcc version 6.3.1 compatibility)

[ssilverman@scottc7virt icctest]$ scl enable devtoolset-7 "icpc -v; icpc -o test.gcc700 test.cpp"
icpc version 18.0.2 (gcc version 7.0.0 compatibility)

[ssilverman@scottc7virt icctest]$ ./test.gcc485 
[ssilverman@scottc7virt icctest]$ ./test.gcc631
*** Error in `./test.gcc631': double free or corruption (fasttop): 0x00000000018260a0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7f9dbe6af619]
./test.gcc631[0x400f7d]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f9dbe654c05]
./test.gcc631[0x400be9]
======= Memory map: ========
00400000-00404000 r-xp 00000000 fd:02 16728111                           /home/ssilverman/icctest/test.gcc631
00603000-00604000 r--p 00003000 fd:02 16728111                           /home/ssilverman/icctest/test.gcc631
00604000-00605000 rw-p 00004000 fd:02 16728111                           /home/ssilverman/icctest/test.gcc631
01826000-01847000 rw-p 00000000 00:00 0                                  [heap]
7f9db8000000-7f9db8021000 rw-p 00000000 00:00 0 
7f9db8021000-7f9dbc000000 ---p 00000000 00:00 0 
7f9dbe42f000-7f9dbe431000 r-xp 00000000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7f9dbe431000-7f9dbe631000 ---p 00002000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7f9dbe631000-7f9dbe632000 r--p 00002000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7f9dbe632000-7f9dbe633000 rw-p 00003000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7f9dbe633000-7f9dbe7eb000 r-xp 00000000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7f9dbe7eb000-7f9dbe9eb000 ---p 001b8000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7f9dbe9eb000-7f9dbe9ef000 r--p 001b8000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7f9dbe9ef000-7f9dbe9f1000 rw-p 001bc000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7f9dbe9f1000-7f9dbe9f6000 rw-p 00000000 00:00 0 
7f9dbe9f6000-7f9dbea0b000 r-xp 00000000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f9dbea0b000-7f9dbec0a000 ---p 00015000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f9dbec0a000-7f9dbec0b000 r--p 00014000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f9dbec0b000-7f9dbec0c000 rw-p 00015000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f9dbec0c000-7f9dbed0d000 r-xp 00000000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7f9dbed0d000-7f9dbef0c000 ---p 00101000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7f9dbef0c000-7f9dbef0d000 r--p 00100000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7f9dbef0d000-7f9dbef0e000 rw-p 00101000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7f9dbef0e000-7f9dbeff7000 r-xp 00000000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7f9dbeff7000-7f9dbf1f7000 ---p 000e9000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7f9dbf1f7000-7f9dbf1ff000 r--p 000e9000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7f9dbf1ff000-7f9dbf201000 rw-p 000f1000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7f9dbf201000-7f9dbf216000 rw-p 00000000 00:00 0 
7f9dbf216000-7f9dbf237000 r-xp 00000000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7f9dbf404000-7f9dbf40a000 rw-p 00000000 00:00 0 
7f9dbf435000-7f9dbf437000 rw-p 00000000 00:00 0 
7f9dbf437000-7f9dbf438000 r--p 00021000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7f9dbf438000-7f9dbf439000 rw-p 00022000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7f9dbf439000-7f9dbf43a000 rw-p 00000000 00:00 0 
7ffe3ce5b000-7ffe3ce7d000 rw-p 00000000 00:00 0                          [stack]
7ffe3cf10000-7ffe3cf12000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

[ssilverman@scottc7virt icctest]$ ./test.gcc700 
*** Error in `./test.gcc700': double free or corruption (fasttop): 0x000000000166a0a0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7fec8a577619]
./test.gcc700[0x400f5d]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fec8a51cc05]
./test.gcc700[0x400be9]
======= Memory map: ========
00400000-00404000 r-xp 00000000 fd:02 16728113                           /home/ssilverman/icctest/test.gcc700
00603000-00604000 r--p 00003000 fd:02 16728113                           /home/ssilverman/icctest/test.gcc700
00604000-00605000 rw-p 00004000 fd:02 16728113                           /home/ssilverman/icctest/test.gcc700
0166a000-0168b000 rw-p 00000000 00:00 0                                  [heap]
7fec84000000-7fec84021000 rw-p 00000000 00:00 0 
7fec84021000-7fec88000000 ---p 00000000 00:00 0 
7fec8a2f7000-7fec8a2f9000 r-xp 00000000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7fec8a2f9000-7fec8a4f9000 ---p 00002000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7fec8a4f9000-7fec8a4fa000 r--p 00002000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7fec8a4fa000-7fec8a4fb000 rw-p 00003000 fd:00 33780127                   /usr/lib64/libdl-2.17.so
7fec8a4fb000-7fec8a6b3000 r-xp 00000000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7fec8a6b3000-7fec8a8b3000 ---p 001b8000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7fec8a8b3000-7fec8a8b7000 r--p 001b8000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7fec8a8b7000-7fec8a8b9000 rw-p 001bc000 fd:00 33709255                   /usr/lib64/libc-2.17.so
7fec8a8b9000-7fec8a8be000 rw-p 00000000 00:00 0 
7fec8a8be000-7fec8a8d3000 r-xp 00000000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fec8a8d3000-7fec8aad2000 ---p 00015000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fec8aad2000-7fec8aad3000 r--p 00014000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fec8aad3000-7fec8aad4000 rw-p 00015000 fd:00 37251501                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fec8aad4000-7fec8abd5000 r-xp 00000000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7fec8abd5000-7fec8add4000 ---p 00101000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7fec8add4000-7fec8add5000 r--p 00100000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7fec8add5000-7fec8add6000 rw-p 00101000 fd:00 33780129                   /usr/lib64/libm-2.17.so
7fec8add6000-7fec8aebf000 r-xp 00000000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7fec8aebf000-7fec8b0bf000 ---p 000e9000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7fec8b0bf000-7fec8b0c7000 r--p 000e9000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7fec8b0c7000-7fec8b0c9000 rw-p 000f1000 fd:00 33608209                   /usr/lib64/libstdc++.so.6.0.19
7fec8b0c9000-7fec8b0de000 rw-p 00000000 00:00 0 
7fec8b0de000-7fec8b0ff000 r-xp 00000000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7fec8b2cc000-7fec8b2d2000 rw-p 00000000 00:00 0 
7fec8b2fd000-7fec8b2ff000 rw-p 00000000 00:00 0 
7fec8b2ff000-7fec8b300000 r--p 00021000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7fec8b300000-7fec8b301000 rw-p 00022000 fd:00 33699482                   /usr/lib64/ld-2.17.so
7fec8b301000-7fec8b302000 rw-p 00000000 00:00 0 
7ffec8c7f000-7ffec8ca1000 rw-p 00000000 00:00 0                          [stack]
7ffec8d11000-7ffec8d13000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

Hello,

I installed Intel® Parallel Studio XE 2018 both Update 1 and 2 under Debian Stretch and compiling with icc and icpc worked well. Then I upgraded my system to Debian Sid (Unstable) and then when trying to compile with both icc or icps I get the following error:  

/home/user/intel/compilers_and_libraries_2018.2.199/linux/compiler/include/math.h(1230): error: identifier "_LIB_VERSION_TYPE" is undefined
  _LIBIMF_EXTERN_C _LIB_VERSIONIMF_TYPE _LIBIMF_PUBVAR _LIB_VERSIONIMF;
                   ^

Then I installed Intel® Parallel Studio XE 2018 on the latest Arch Linux and the same code compilations went without problems.

During installation of Intel® Parallel Studio XE 2018 both Debian Sid and Arch Linux are unsupported OSs so perhaps there is a solution to make Intel Compilers work under Debian Sid? Any idea?

I am using the Intel C++ compiler within Visual Studio (Community 2017).  After a recent update (Parallel Studio XE 2018 Update 2 for Windows) when I try to build my C++ code I get 100 errors.  The errors are all from xtgmath.h.

Here is an example of a group of errors relating to a single line,

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : mismatched delimiters in default argument expression
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : expected a "," or ">"
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : argument list for alias template "std::enable_if_t" is missing
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : expected an expression
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : expected a "]"
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\xtgmath.h(74): error : expected a declaration
1>  _GENERIC_MATH1(acos, _CRTDEFAULT)
1>  ^

These error do not appear when I build my code from the command-line.  And they do not appear on a different machine where the update is not installed.

Hello,

I have tried to report this issue both here (https://software.intel.com/en-us/forums/intel-c-compiler/topic/642800) and by boost (https://svn.boost.org/trac10/ticket/13192, https://svn.boost.org/trac10/ticket/13502#ticket), but it still exists in last beta 1.67.

It would be nice, to have that fixed in the next release.

Sample code, compiled with last VS2017 + Intel 18:

#include <memory>

#include <boost/dll/alias.hpp>
#include <boost/dll/shared_library.hpp>

#include <boost/version.hpp>
#pragma message("Boost version: " BOOST_LIB_VERSION)

#if BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS)
#pragma message("BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS) == true")
#else
#pragma message("BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS) == false")
#endif

using namespace std;

struct Plugin
{
    static shared_ptr<Plugin> create()
    {
        return make_shared<Plugin>();
    }
};

BOOST_DLL_ALIAS(
    Plugin::create,
    CreatePlugin
)

int main()
{
    return 0;
}

and compiler output:

1>------ Build started: Project: BoostDLL, Configuration: Debug Win32 ------
1>Build started 29.03.2018 13:20:26.
1>Target InitializeBuildStatus:
1>  Touching "Debug\BoostDLL.tlog\unsuccessfulbuild".
1>Target MessageBuildingWithCompiler:
1>  Building with Intel(R) C++ Compiler 18.0
1>Target ClCompile:
1>  ***** ClCompile (Win32 - Intel C++)
1>  All outputs are up-to-date.
1>  BoostDLL.cpp
1>  Boost version: 1_67
1>  BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS) == false
1>  D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error #77: this declaration has no storage class or type specifier
1>    BOOST_DLL_ALIAS(
1>    ^
1>
1>  D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error : identifier "section" is undefined
1>    BOOST_DLL_ALIAS(
1>    ^
1>
1>  D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error : expected a ";"
1>    BOOST_DLL_ALIAS(
1>    ^
1>
1>  compilation aborted for BoostDLL.cpp (code 2)
1>Done building target "ClCompile" in project "BoostDLL.vcxproj" -- FAILED.
1>
1>Done building project "BoostDLL.vcxproj" -- FAILED.
1>
1>Build FAILED.
1>
1>D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error #77: this declaration has no storage class or type specifier
1>D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error : identifier "section" is undefined
1>D:\src\projects\____TEMP\BoostDLL\BoostDLL.cpp(30): error : expected a ";"
1>    0 Warning(s)
1>    3 Error(s)
1>
1>Time Elapsed 00:00:01.10
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Intel C++ compiler detection under Windows does not work properly, so I have to patch every version of boost.

The problem is in alias.hpp:39

#if BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS)

#define BOOST_DLL_SELECTANY __declspec(selectany)

#define BOOST_DLL_SECTION(SectionName, Permissions)                                             \
    BOOST_STATIC_ASSERT_MSG(                                                                    \
        sizeof(#SectionName) < 10,                                                              \
        "Some platforms require section names to be at most 8 bytest"                           \
    );                                                                                          \
    __pragma(section(#SectionName, Permissions)) __declspec(allocate(#SectionName))             \
    /**/

#else // #if BOOST_COMP_MSVC

because BOOST_COMP_MSVC || (BOOST_COMP_INTEL && BOOST_OS_WINDOWS) is false under Windows, as you can see in compiler output.

I'm currently fighting hard with the newest version of ICL. First the profile generated code crashes in Intel stuff (https://software.intel.com/en-us/forums/intel-c-compiler/topic/760787#co...) and now this:

- If I compile /fp:fast /OxAVX2, everything is fast, the executable is huge and I cannot make it smaller using profile based build (see the other post). And it runs only on AVX2 CPUs.

- If I compile /fp:fast /OxSSE2 /OaxAVX, everything is fast, less but still

- If I compile /fp:fast /OxSSE2 /OaxAVX,CORE-AVX2, it's superfast, actually faster than /OxAVX2 :), that itself is weird, and well, it doesn't work - some calculations just result in some nonsense, in the superhuge code I cannot really post any "minimum example" or anything.

- If I compile /fp:precise /OxSSE2 /OaxAVX,CORE-AVX2, it gets superslow and huge, but works :).

It's pretty obvious that some optimization makes things dysfunctional and since having alternative path to AVX2 is faster than compiling the whole thing directly for AVX2 (albeit not working correctly), something is not working as it should. For the record, it's audio processing, contains lots of vectorizable loops for crossmultiplication of buffers etc.

The Intel Parallel Studio XE 2018 (IPSXE2018) update 2 is released last week that contains the Intel compiler 18.0.2. This version of Intel compiler provides the fix for Spectre variant 2. Please refer to this article for more information -  https://software.intel.com/en-us/articles/using-intel-compilers-to-mitigate-speculative-execution-side-channel-issues.

Hi,

My environment is Centos 7.

I can to install ICC into docker container via bash manually, and then create one new image with icc support.

When installing icc via install script, there is user interface to choose some setup options.

Is there any method to install icc with only some bash command and without any user interface? Then, I can create new image with icc support via DockerFile.

how to install ICC into contain via DockerFile

Thanks!

Andrew

Dear all

I tried to compile the library QuantLib-1.12 (a library for quantitative finance, see www.quantlib.org) with icc 18.0.1 (and 18.0.2) on Ubuntu 17.04.
I followed the instructions
                 https://software.intel.com/en-us/articles/intel-c-compiler-for-linux-bui...
with some modifications (compiler option -xHOST instead of -xT).

Furthermore, I use Boost 1.66.0 (https://software.intel.com/en-us/articles/building-boost-with-intel-c-co...)

Unfortunately, I failed to compile the QuantLib library, getting the internal error below. When working with the Intel Compilers as of 2017, I didn't get any error at all.

Anyone else with this problem?

Kind regards, Paul

------------------------
Error message:
------------------------
/bin/bash ../../../libtool  --tag=CXX   --mode=compile icpc -DHAVE_CONFIG_H -I. -I../../../ql  -I../../.. -I../../.. -I/usr/local/boost_1_66_0/include  -O3 -xHOST -MT utilities.lo -MD -MP -MF .deps/utilities.Tpo -c -o utilities.lo utilities.cpp
libtool: compile:  icpc -DHAVE_CONFIG_H -I. -I../../../ql -I../../.. -I../../.. -I/usr/local/boost_1_66_0/include -O3 -xHOST -MT utilities.lo -MD -MP -MF .deps/utilities.Tpo -c utilities.cpp  -fPIC -DPIC -o .libs/utilities.o
": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.

icpc: error #10105: /opt/intel/compilers_and_libraries_2018.1.163/linux/bin/intel64/mcpcom: core dumped
icpc: warning #10102: unknown signal(-1412937904)
icpc: error #10106: Fatal error in /opt/intel/compilers_and_libraries_2018.1.163/linux/bin/intel64/mcpcom, terminated by unknown
compilation aborted for utilities.cpp (code 1)

I ran into a problem with the following code, which compiles fine with gcc and clang, but fails with icc 18.0.1:

struct S
{
    template< typename... Ts  >
    auto access( )
    -> int
    {
        return 1;
    }

    template< typename... Ts  >
    auto operator()( Ts&&... )
    -> decltype( access< Ts... >() )
    {
        return access< Ts... >();
    }
};

struct A {};
struct B {};

int main()
{
	S s;
	s( A(), B() );
}

Based on the types A and B the operator() of s shall call the access method of s. In my real world example the return value of access depends on the given template arguments, so I am using decltype to figure it out. However this does not work although it should or does the standard state something different and gcc and clang are just more friendly?

The error from the Intel compiler is:

test.cpp(24): error: no instance of function template "S::operator()" matches the argument list
            argument types are: (A, B)
            object type is: S
        s( A(), B() );
        ^
test.cpp(11): note: this candidate was rejected because at least one template argument could not be deduced
      auto operator()( Ts&&... )
           ^

compilation aborted for test.cpp (code 2)

Best regards,

Alexander Matthes

Hi,

I've been using Intel® C++ Composer XE 2013 Update 5 Integration for Microsoft* Visual Studio* 2010, Version 13.0.1211.2010 for 5 years. Howerver,  I recieved the following output message from April 1 2018 while I am trying to compile my project through Visual Studio 2010.

1>MessageBuildingWithCompiler:
 1>  Building with Intel(R) C++ Compiler XE 13.1
 1>ClCompile:
 1>  ***** ClCompile (Win32 - Intel C++)
 1>
 1>  Error: A license for CCompW could not be obtained (-1,359,2).
 1>
 1>  Is your license file in the right location and readable?
 1>  The location of your license file should be specified via
 1>  the $INTEL_LICENSE_FILE environment variable.
 1>
 1>  License file(s) used were (in this order):
 1>      1.  Trusted Storage
 1>      2.  C:\Program Files (x86)\Common Files\Intel\Licenses\*.lic
 1>      3.  C:\Program Files\Common Files\Intel\Licenses
 1>      4.  C:\PROGRA~2\Intel\COMPOS~1\bin\ia32\*.lic
 1>
 1>  Please visit http://software.intel.com/sites/support/ if you require technical assistance.
 1>
 1>icl : error #10052: could not checkout FLEXlm license

I logged in this website and I checked the support status was exprired from 07 SEP 2014. However, I have a Named-user commerical license on Intel® Parallel Studio XE Professional Edition for Fortran and C++ Windows*  and I thought there is no limit to the period of use. Is anyone could help me?

Thanks

Hello

I have been trying to compile code for AVX512 with -O2 and all the other optimizations. However stumbled upon a small problem.

When using the zmm registers before each arithmetic instruction such as vaddpd, vsubpd, vmulpd, fmaddpd move instructions pop out of the blue. Each time the data from the high zmm registers (16 - 31) is first moved to the low zmm registers and the the operation is being done...

Is this a hardware problem where the instructions only use the low registers or is it a compiler bug?

Best,
Thom

I am using lockfree queue from boost:

#include <boost/lockfree/queue.hpp>
#include <boost/atomic.hpp>

boost::lockfree::queue<int> queue(10000);

Works fine with GCC compiler, but not with Intel. I get the following error:

In file included from /usr/include/boost/lockfree/queue.hpp(24),
                 from /home/martin/projects/EGO/BLAS-join3/cmake/main.cpp(5):
/opt/gcc6.1.0/usr/local/bin/../include/c++/6.1.0/atomic(178): error: static assertion failed with "std::atomic requires a trivially copyable type"
        static_assert(__is_trivially_copyable(_Tp),
        ^
          detected during instantiation of class "std::atomic<_Tp> [with _Tp=boost::lockfree::detail::tagged_index]" at line 584 of "/usr/include/boost/lockfree/detail/freelist.hpp"

/opt/gcc6.1.0/usr/local/bin/../include/c++/6.1.0/atomic(178): error: static assertion failed with "std::atomic requires a trivially copyable type"
        static_assert(__is_trivially_copyable(_Tp),
        ^
          detected during:
            instantiation of class "std::atomic<_Tp> [with _Tp=boost::lockfree::detail::tagged_ptr<boost::lockfree::detail::freelist_stack<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node, std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>>::freelist_node>]" at line 244 of "/usr/include/boost/lockfree/detail/freelist.hpp"
            instantiation of class "boost::lockfree::detail::freelist_stack<T, Alloc> [with T=boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node, Alloc=std::allocator<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>]" at line 121 of "/usr/include/boost/lockfree/queue.hpp"
            instantiation of class "boost::lockfree::queue<T, A0, A1, A2> [with T=int, A0=boost::parameter::void_, A1=boost::parameter::void_, A2=boost::parameter::void_]" at line 38 of "/home/martin/projects/EGO/BLAS-join3/cmake/main.cpp"

/opt/gcc6.1.0/usr/local/bin/../include/c++/6.1.0/atomic(178): error: static assertion failed with "std::atomic requires a trivially copyable type"
        static_assert(__is_trivially_copyable(_Tp),
        ^
          detected during:
            instantiation of class "std::atomic<_Tp> [with _Tp=boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>]" at line 463 of "/usr/include/boost/lockfree/queue.hpp"
            instantiation of class "boost::lockfree::queue<T, A0, A1, A2> [with T=int, A0=boost::parameter::void_, A1=boost::parameter::void_, A2=boost::parameter::void_]" at line 38 of "/home/martin/projects/EGO/BLAS-join3/cmake/main.cpp"

compilation aborted for /home/martin/projects/EGO/BLAS-join3/cmake/main.cpp (code 2)
make[2]: *** [CMakeFiles/blasJoin.dir/main.cpp.o] Fehler 2
make[1]: *** [CMakeFiles/blasJoin.dir/all] Fehler 2
make: *** [all] Fehler 2

I am using the following flags in CMAKE:

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
  set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -march=knl -mtune=knl -fpic -ffast-math -DNDEBUG -O3 -DNDDEBUG -fopenmp -lmkl_core -lmkl_intel_lp64 -lmkl_intel_thread -liomp5 -lboost_system")
elseif ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel")
  set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -xmic-avx512 -qopenmp -DNDEBUG -O3 -lmkl_intel_thread  -liomp5 -lpthread -lmkl_core -lmkl_intel_lp64 -lboost_system")
endif()

OS: centos-release-7-4.1708.el7.centos.x86_64
Intel Compiler 18.0.2 20180210
GCC version: 6.1.0
Boost version: 1.66

Dear Intel-Community,

I’m having trouble compiling any project with std=c++17 on Mac with the latest Intel Compiler 18 Update 2. Even a fresh hello world console project gives me the error:

enum "std::align_val_t" was previously declared with a different base type
  enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
                              ^

Are there any additional flags that need to be set in order to compile it with the latest C++ language features?

System specs:
Intel Compiler 18 Update 2
Xcode 9.2 (9C40b)
Mac OS Sierra 10.12.6

Best regards,
Daniel

Just like the topic.

Thank you very much.

 Downloading the "free" intel compiler. Anyone know where the link to that is? I do not want the entire studio and junk, just the compiler for C++, thanks!

#include <iostream>

template <class T> class wrapper {
public:
  static T get() {
    static thread_local T thing(12);
    return thing;
  }
};

int main() {
  std::cout<<wrapper<int>::get()<<std::endl;  
}

And I get this, it compile and function as expected using clang++

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Courier; color: #4d2f2d; background-color: #dfdbc3}
span.s1 {font-variant-ligatures: no-common-ligatures}
span.Apple-tab-span {white-space:pre}

icpc -std=c++11  -g thread_local.cc

0  0x10b0cf2c0  __assert_rtn + 129

1  0x10b196eb3  ld::passes::tlvp::doPass(Options const&, ld::Internal&) + 1987

2  0x10b0d016b  main + 913

3  0x7fff70f9c015  start + 1

A linker snapshot was created at:

    /tmp/a.out-2018-03-19-204307.ld-snapshot

ld: Assertion failed: (0 && "wrong content type for target in tlv defs"), function doPass, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-351.8/src/ld/passes/tlvp.cpp, line 293.