Linking against a static library > 4GB with IPO results in the following error:

ipo: error #11062: BigLibrary.a is an archive, but has no symbols (this can happen if ar is used where xiar is needed)
icpc: error #10014: problem during multi-file optimization compilation (code 1)

The error is resolved with some refactoring to get the library under 4GB.

Is this an intrinsic limitation of the compiler or is there a workaround?

Using CentOS7 with icc (ICC) 19.0.4.243 20190416 and gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) from devtoolset-7

As shown in https://gcc.godbolt.org/z/_PjVDd icpc seems to be using 32-bit registers to do the offset calculation for an array that has less than 4G elements. If the array had 1B elements, that would be fine, but if it's larger than that, then we need 64-bit registers in order to access past 4GB of memory. The result is that we can get crashes as the repro in the above link shows.

I've confirmed this bug exists in icc 17 all the way to 19.0.245 (the most recent I can find). I've only tested this in Windows.

In case the above link doesn't work, here's the code:

void buggy(unsigned int count, int* a)
{
    // note that the index is 32-bit
    for (unsigned i = 0; i < count; ++i)
        *a++ = 123;
}

void good(unsigned int count, int* a)
{
    // note that the index is 64-bit
    for (unsigned long long i = 0; i < count; ++i)
        *a++ = 123;
}

int main(int argc, char** argv)
{
   const size_t array_size =
     argc == 123456 ? (size_t)argv : (1ULL << 31) + 1000; // prevent compiler optimizations
   printf("array_size == %zu\n", array_size); // double check we really did use the correct size
   int* out = new int[array_size];

   buggy(array_size, out);
   // good(array_size, out);

   printf("no crash!\n");

   return 0;
}

ignore this duplicate post

How do I get rid of these errors:

1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(487): error : expected a declaration
1>                  _VARIANT_BOOL bool;
1>                  ^
1>
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(502): error : expected a declaration
1>                  _VARIANT_BOOL *pbool;
1>                  ^

I see an old mention of this that it's related to the version the compiler is claiming to be via _MSC_VER but I haven't been able to sort it this way so far.

If I install ParallelStudio XE 2019.4 on a box running Amazon Linux in duplicate mode, I get the following output:

> sudo ./install.sh -d intel.config

> cat intel.config

ACCEPT_EULA=accept

CONTINUE_WITH_OPTIONAL_ERROR=yes

PSET_INSTALL_DIR=/opt/intel

CONTINUE_WITH_INSTALLDIR_OVERWRITE=yes

PSET_MODE=install

ACTIVATION_SERIAL_NUMBER=XXXXX-XXXXX

ACTIVATION_TYPE=serial_number

AMPLIFIER_SAMPLING_DRIVER_INSTALL_TYPE=build

AMPLIFIER_DRIVER_ACCESS_GROUP=vtune

AMPLIFIER_DRIVER_PERMISSIONS=666

AMPLIFIER_LOAD_DRIVER=no

AMPLIFIER_C_COMPILER=/usr/bin/gcc

AMPLIFIER_KERNEL_SRC_DIR=/lib/modules/4.14.133-88.105.amzn1.x86_64/build

AMPLIFIER_MAKE_COMMAND=/usr/bin/make

AMPLIFIER_INSTALL_BOOT_SCRIPT=no

AMPLIFIER_DRIVER_PER_USER_MODE=no

INTEL_SW_IMPROVEMENT_PROGRAM_CONSENT=no

ARCH_SELECTED=INTEL64

COMPONENTS=;intel-conda-index-tool__x86_64;intel-comp__x86_64;intel-comp-32bit__x86_64;intel-comp-doc__noarch;intel-comp-l-all-common__noarch;intel-comp-l-all-vars__noarch;intel-comp-nomcu-vars__noarch;intel-comp-ps-32bit__x86_64;intel-comp-ps__x86_64;intel-comp-ps-ss__x86_64;intel-comp-ps-ss-bec__x86_64;intel-comp-ps-ss-bec-32bit__x86_64;intel-openmp__x86_64;intel-openmp-32bit__x86_64;intel-openmp-common__noarch;intel-openmp-common-icc__noarch;intel-openmp-common-ifort__noarch;intel-openmp-ifort__x86_64;intel-openmp-ifort-32bit__x86_64;intel-tbb-libs-32bit__x86_64;intel-tbb-libs__x86_64;intel-idesupport-icc-common-ps__noarch;intel-conda-intel-openmp-linux-64-shadow-package__x86_64;intel-conda-intel-openmp-linux-32-shadow-package__x86_64;intel-conda-icc_rt-linux-64-shadow-package__x86_64;intel-icc__x86_64;intel-c-comp-common__noarch;intel-icc-common__noarch;intel-icc-common-ps__noarch;intel-icc-common-ps-ss-bec__noarch;intel-icc-doc__noarch;intel-icc-doc-ps__noarch;intel-icc-ps__x86_64;intel-icc-ps-ss-bec__x86_64;intel-ifort__x86_64;intel-ifort-common__noarch;intel-ifort-doc__noarch;intel-mkl-common__noarch;intel-mkl-core__x86_64;intel-mkl-core-rt__x86_64;intel-mkl-doc__noarch;intel-mkl-doc-ps__noarch;intel-mkl-gnu__x86_64;intel-mkl-gnu-rt__x86_64;intel-mkl-cluster__x86_64;intel-mkl-cluster-rt__x86_64;intel-mkl-common-ps__noarch;intel-mkl-core-ps__x86_64;intel-mkl-pgi__x86_64;intel-mkl-pgi-rt__x86_64;intel-conda-mkl-linux-64-shadow-package__x86_64;intel-conda-mkl-static-linux-64-shadow-package__x86_64;intel-conda-mkl-devel-linux-64-shadow-package__x86_64;intel-conda-mkl-include-linux-64-shadow-package__x86_64;intel-mkl-common-c__noarch;intel-mkl-core-c__x86_64;intel-mkl-common-c-ps__noarch;intel-mkl-cluster-c__noarch;intel-mkl-tbb__x86_64;intel-mkl-tbb-rt__x86_64;intel-mkl-pgi-c__x86_64;intel-mkl-gnu-c__x86_64;intel-mkl-common-f__noarch;intel-mkl-core-f__x86_64;intel-mkl-cluster-f__noarch;intel-mkl-gnu-f-rt__x86_64;intel-mkl-gnu-f__x86_64;intel-mkl-f95-common__noarch;intel-mkl-f__x86_64;intel-tbb-devel__x86_64;intel-tbb-common__noarch;intel-tbb-doc__noarch;intel-conda-tbb-linux-64-shadow-package__x86_64;intel-conda-tbb-devel-linux-64-shadow-package__x86_64;intel-imb__x86_64;intel-mpi-rt__x86_64;intel-mpi-sdk__x86_64;intel-mpi-doc__x86_64;intel-mpi-samples__x86_64;intel-conda-impi_rt-linux-64-shadow-package__x86_64;intel-conda-impi-devel-linux-64-shadow-package__x86_64;intel-icsxe__noarch;intel-mpi-psxe__x86_64;intel-psxe-common__noarch;intel-psxe-doc__noarch;intel-psxe-common-doc__noarch;intel-icsxe-doc__noarch;intel-psxe-licensing__noarch;intel-psxe-licensing-doc__noarch;intel-icsxe-pset

On a fresh box with no prior installation the input generated previously throws an error.

> sudo ./install.sh -s intel.config

COMPONENTS parameter in silent configuration file contains invalid values

I tried adding double quotes on the COMPONENTS, but that did not help either.

Hi,

When I execute following command(according to https://github.com/intel/caffe/wiki/Build-Caffe-with-Intel--Compiler )

pcie@pcie-cascade-lake:~/caffe$ sudo make all -j$(nproc)

it display these error messages: 
/home/pcie/caffe/boost_1_64_0/stage/lib/libboost_thread.so: undefined reference to `__builtin_is_constant_evaluated'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_stream_submit'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_memory_primitive_desc_equal'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_primitive_desc_query_memory_d'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_reorder_primitive_desc_create_v2'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_memory_primitive_desc_create'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_memory_desc_init'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_memory_primitive_desc_get_size'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_primitive_attr_set_int_output_round_mode'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_view_primitive_desc_create'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_primitive_at'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_primitive_desc_iterator_create_v2'
.build_release/lib/libcaffe.so: undefined reference to `mkldnn_primitive_desc_query_pd'
Makefile:866: recipe for target '.build_release/examples/ssd/ssd_detect.bin' failed
make: *** [.build_release/examples/ssd/ssd_detect.bin] Error 1

How to fix it?

My environments:
CPU :  Xeon 8270
ubuntu 18.04
icpc (ICC) 19.0.4.243 20190416
MKLDNN download is enabled by customized setting!
boost_1_64_0

This note applies to the Intel® Compilers for macOS* only.  

There are known issues with the Intel Compilers running under macOS* 10.15 Catalina and Xcode* 11 which are currently, as of 29 August 2019, still in beta.  We are advising macOS* customers to delay upgrading to macOS 10.15 Catalina until we are able to add support and validate our software against the "Gold" release of Catalina.   We intend to support macOS* 10.15 Catalina and Xcode* 11 in a future compiler update release.  Please wait or delay your macOS* and Xcode* upgrade until we deliver a future compiler release where we explicitly state support for macOS* 10.15 Catalina and Xcode* 11.  Visit the Release Notes for the list of officially supported OS and Xcode* combinations. 

DETAILS

Apple has implemented a new and addition process for developers intending to support the forthcoming macOS Catalina.  In the past, application developers such as Intel had to digitally sign (get a certificate for ) our installer applications with Apple to insure that the installer is from a known and trusted application developer.  The Intel Compilers and tools installers have included this digital signature for many years.  However, with Catalina application developers have a new step - developers must submit their apps to Apple's notarizing security process, allow Apple to scan the application for known security issues, and obtain from Apple a new  "Application Signature" or Notarization along with the existing digital certificate and include the certificate and notarization along with the applications. Without this new and additional notarization they will not run on Catalina.  Gatekeeper on Catalina will not allow current Intel installers ( all Intel® Parallel Studio XE Composer Edition for macOS* versions 2019 Update 4 and older) to run.  Thus, once you upgrade to Catalina you will no longer be able to run current ( 2019 Update 4 and older ) installers.  Intel will only begin suppling installers with this new notarization in a future release.  Existing releases do not have this notarization and we will not repackage and re-release existing packages to add this support.  We will add Catalina support with this new notarization in a future release.

If you do upgrade to Catalina at some point, keep in mind that you will be unable to install and hence run previous versions of the Intel Compilers for macOS* under Catalina.  

IF you have already installed Intel Compilers on your macOS* `10.14 or older and then upgrade to Catalina we believe the compilers will continue to run from the command line interface.  However, we have not officially validated our compilers and libraries and tools against Catalina.  There may be incompatibilities of older tools with Catalina.  Visit the Release Notes for the list of officially supported OS and Xcode* combinations. 

Xcode*:  Existing Xcode 10.x integrations will remain.  If you upgrade to Xcode* 11 you will lose Xcode integrations AND you will NOT be able to install the Xcode* 11 integrations since the current 2019 Update 4 and older installers will not run on Catalina. We have not validated our compiler integrations with Xcode* 11 Gold either.  Official support for Xcode* 11 is coming in a future release.
 

01The following code compiles and runs properly with gcc 8.2.0 (using -std=c++17).

02It also compiles with icc 19.0.1.144, but throws a 'Floating point exception' when trying to access 'map' in the constructor.

03 

04#include <iostream>

05#include <unordered_map>

06 

07struct A {

08    static inline std::unordered_map<int, int> map;

09    A(){

10        map[1] = 2;

11    }

12};

13 

14int main(){

15    A a;

16}

A similar code with a primitive or 'std::vector' in place of 'std::unordered_map' does appears to work.

Am I missing something or is this a problem with the compiler?

This is a nagging post.

Back in the 1990's, when a template would construct function based on the type and number of arguments. And when the same template would construct function based on the type and number of arguments in multiple source files, the Linker would note the function signature and .obj contents, and when the signature and contents matched would ignore the additional instantiations of that function. Only if the contents differed would an objection be raised.

Today, one must declare the functions with "static inline" which results in substantial code bloat. Omitting "static inline" results in duplicate symbol.

Can someone explain why the old way was abandoned?

Jim Dempsey

Good day,

I have the following simple question: with Intel C++ compiler (Intel Parallel Studio 2013), is it possible to use both C++ std::complex and C complex number (like double _Complex) in one source file? I didn't manage to do that. I tried to use both c++0x (I need it) and c99 options, but the first ovverides the second and the compiler does not recognize the _Complex type.

The reason for the question is as follows: I want to use the ARPACK package (written in Fortran) in C++. For that, I tried to use the

https://github.com/opencollab/arpack-ng

package. It supports the mixed-language programming, for that one needs the file

./ICB/arpack.hpp

which is a collection of C++ interfaces to ARPACK subroutines. But is uses both C++ and C complex numbers (like in lines 197-198, 205-207), and the code is not compiled.

Thank you in advance.

Hi all,

I'm using icc19.4 (gcc 8.3 compatibility) on Ubuntu18.10 to build a huge project.

The build process halts throwing the following errors.

**********************************************

ld: cannot find none: No such file or directory

FATAL ERROR: ld partial link command failed
icc: error #10014: problem during multi-file optimization compilation (code 1)

***********************************************

It seems that the linker cannot find something (some files? some symbols?)

but it doesn't point out what is missing.

So is there any help about how to find the root cause? And what is the meaning of this error?

Thanks!

Regards
yuandong

Hi, I just installed Intel Anaconda on Windows 10. Everything working fine. Numpy/Scipy/etc are nice and fast, linking to MKL, etc. Painless.

But (unrelated to python) now I need to create a DLL in order to create an external function that can be called by a 3rd party app (COMSOL).

I can think of lots of ways to make DLL's but they all seem to require a C compiler. Do I already have one installed somewhere as part of conda?

[This is conda version 4.7.11 if that makes a difference]

Thanks for any feedback, John

Hi,

I need to use Intel icc for my project. I am planning to buy one floating license for Intel Parallel Studio Composer Edition (Linux). I have a build script for my project. I need to build the project on different servers but I don't need to build simultaneously. Then is one floating license enough for my case? Is it going to generate a license acquire/release to the license server for every file or is the license token going to be kept for a period of time on the build server? Thank you very much.

Hello,

When I try to compile with the Intel compiler I got the error:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmmintrin.h|56|error #2277: invalid definition of __m128; use #include "xmmintrin.h" instead

If I understand correctly, the error occurs due to 'xmmintrin.h' being part of VC as well as Intel and thus in conflict. I've found the following solution, simply drop the VC include:

https://software.intel.com/en-us/articles/dont-explicitly-search-vc-incl...

But this raises the following catastrophic error: cannot open source file "iostream" (a.k.a. missing fundamental c++ libs?)

What am I missing here?

My compiler search directories:

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\compiler\include
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\mkl\include
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include

Hi,

want to use ZMM instead of YMM, need help in finding the counterparts of:

		YMMcmp = _mm256_cmpeq_epi8(YMMcurr, YMMclone);
		YMMsub = _mm256_sub_epi8(YMMzero, YMMcmp);
		YMMadd = _mm256_add_epi8(YMMand, YMMsub);
		YMMmax = _mm256_max_epu8(YMMmax, YMMadd);

Found only these in zmmintrin.h, but I need '8' not '64':

#define _mm512_cmpeq_epi64_mask(v1, v2) \
        _mm512_cmp_epi64_mask((v1), (v2), _MM_CMPINT_EQ)
extern __m512i __ICL_INTRINCC _mm512_sub_epi64(__m512i, __m512i);
extern __m512i __ICL_INTRINCC _mm512_add_epi64(__m512i, __m512i);
extern __m512i __ICL_INTRINCC _mm512_max_epu64(__m512i, __m512i);

Don't know how to emulate, is there an on-line resource on this?

Also, they have to work with the recently outed 10th gen mobile CPUs, does the AVX-512 extension support them, somewhere saw a review reporting AVX-512F.

Clean console project in Visual Studio

/Gs-

/NODEFAULTLIB

Error    LNK2019    unresolved external symbol ___intel_new_feature_proc_init referenced in function _main   

Errors

1>ipo: : warning #11021: unresolved _exit
1>        Referenced in libirc.lib(new_proc_init.obj)
1>ipo: : warning #11021: unresolved _strlen
1>        Referenced in libirc.lib(new_proc_init.obj)
1>        Referenced in libirc.lib(irc_msg_support.obj)
1>ipo: : warning #11021: unresolved _strncat
1>        Referenced in libirc.lib(new_proc_init.obj)
1>ipo: : warning #11021: unresolved _strncpy
1>        Referenced in libirc.lib(irc_msg_support.obj)
1>ipo: : warning #11021: unresolved _memset
1>        Referenced in libirc.lib(proc_init_utils.obj)
1>ipo: : warning #11021: unresolved _strcat_s
1>        Referenced in libirc.lib(intel_lib_vs_wrappers_init.obj)
1>ipo: : warning #11021: unresolved __errno
1>        Referenced in libirc.lib(intel_lib_vs_wrappers_init.obj)
1>ipo: : error #11023: Not all components required for linking are present on command line
1>ipo_699619obj3.obj : : error LNK2019: unresolved external symbol ___intel_new_feature_proc_init referenced in function _main

How to resolve this?

Passing a std::complex<float> constant to a function that takes a std::complex<double> argument receives the wrong real part inside the function.    Passing a std::complex variable produces the expected result.   Changing the function to accept a value rather than a const reference makes no difference.

#include <complex>
#include <iostream>

void f(const std::complex<double> &val)   // or void f(std::complex<double> val)
{
    std::cout << "In f1, val = "<< val << std::endl;
}

int main()
{

    f(std::complex<float>(1,2));   // Fails

    std::complex<float> b(1,2);
    f(b);  // Works
    

    return 0;
}

Produces the output:

In f1, val = (2,2)
In f1, val = (1,2)

This is with the Intel compiler 19.0.4.243.    GCC and clang give the expected results.

Referring to the problem in this thread regarding the use of "Default"

https://software.intel.com/en-us/forums/intel-c-compiler/topic/811512

This issue breaks CMake generation for CMake 3.15.1 Visual Studio 2019 using the Intel Compiler 2019 u4 toolset

The error shows in CMake as

$ cmake ../ -G"Visual Studio 16 2019" -T"Intel C++ Compiler 19.0"
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:3 (project):
  No CMAKE_C_COMPILER could be found.

Works fine for Visual Studio 2017

$ cmake ../ -G"Visual Studio 15 2017" -T"Intel C++ Compiler 19.0"
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
-- The C compiler identification is Intel 19.0.4.20190417
-- The CXX compiler identification is Intel 19.0.4.20190417

Digging deeper shows the cause of the error

 C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Platforms\x64\PlatformToolsets\Intel C++ Compiler 19.0\Toolset.targets(350,5): error : Element <LanguageStandard> has an invalid value of "Default".

[D:\dev\engine\build\vcxproj\CMakeFiles\CMakeTmp\cmTC_968ad.vcxproj]    

 C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Platforms\x64\PlatformToolsets\Intel C++ Compiler 19.0\Toolset.targets(350,5): error MSB6011: Invalid parameters passed to the Intel.Build.ICLTasks.ICL task. [D:\dev\engine\build\vcxproj\CMakeFiles\CMakeTmp\cmTC_968ad.vcxproj]

The following code fails to compile with Intel C++ 17.0 but compiles fine with MSVC & gcc. If I use a typedef instead of decltype, then it compiles OK.

#include <iostream>

template<class Sig, Sig Func> struct MyFunc;
template<class T, class... Args, void (T::*Func)(Args...) const>
struct MyFunc<void (T::*)(Args...) const, Func>
{
  static void execute(const T *obj)
  {
    (obj->*Func)();
  }
};
template<class T, class... Args, void (T::*Func)(Args...)>
struct MyFunc<void (T::*)(Args...), Func>
{
  static void execute(T *obj)
  {
    (obj->*Func)();
  }
};

#define MYFUNC(...) MyFunc<decltype(__VA_ARGS__), __VA_ARGS__>

struct A
{
  void func() const { std::cout << "in A::func() const"<< std::endl; }
  void func() { std::cout << "in A::func()"<< std::endl; }
};

int main()
{
  A a;
  MYFUNC(static_cast<void(A::*)() const>(&A::func))::execute(&a);
  MYFUNC(static_cast<void(A::*)()>(&A::func))::execute(&a);
};

Hi everyone, I recently came across a linking error when using explicit template instantiation of a non-pure virtual class (see code below).

// TemplateVirtualClass.hpp
#pragma once

template <class T>
class TemplateVirtualClass
{
public:
    TemplateVirtualClass() = default;
    TemplateVirtualClass(const TemplateVirtualClass& x) = default;
    TemplateVirtualClass(TemplateVirtualClass&& x) = default;
    virtual ~TemplateVirtualClass() = default;
    TemplateVirtualClass& operator=(const TemplateVirtualClass& x) = default;
    TemplateVirtualClass& operator=(TemplateVirtualClass&& x) = default;
};

extern template class TemplateVirtualClass<int>;

// TemplateVirtualClass.cpp
#include "TemplateVirtualClass.hpp"

template class TemplateVirtualClass<int>;

// main.cpp
#include "TemplateVirtualClass.hpp"

int main(int argc, char** argv)
{
    TemplateVirtualClass<int> tvc;
    return 0;
}

When compiling with icpc 19 I have this error message:

icpcptdjtl.o:(.data._ZTV20TemplateVirtualClassIiE[_ZTV20TemplateVirtualClassIiE]+0x18): undefined reference to `TemplateVirtualClass<int>::~TemplateVirtualClass()'

Do you have any idea why ? It compiles with g++-7.