Dear sir

I wrote code for solving complex linear  equation, for which i am using intel matrix multiplication subroutines. But my this matrix multiplication is not using all available cores in my cluster.

this is my compiling code

MKLROOT=../../intel/compilers_and_libraries/linux/mkl/
g++ main144.c -DMKL_ILP64 -I${MKLROOT}/include -Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_ilp64.a ${MKLROOT}/lib/intel64/libmkl_gnu_thread.a ${MKLROOT}/lib/intel64/libmkl_core.a -Wl,--end-group -fopenmp -lpthread -ldl -lm -g

Hi,

my Visual Studio is causing problems and I can't figure out what's going on. I am using Visual Studio 2017 and installed ICC18 and ICC19 including the IDE integration.

My project gets compiled with Intel Compiler 18.0.5.274 and Platform Toolset v141 but any translation unit fails to compile. To me it looks like ICC somehow picks up the MSVC header files. Does anyone know what could cause that?

Thanks!

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\type_traits(1562): error : expected a ">"
1>  	_INLINE_VAR constexpr bool _Is_specialization_v<_Template<_Types...>, _Template> = true;
1>  	                                                                ^
1>          detected during:
1>            instantiation of "const bool std::_Is_specialization_v [with _Type=std::char_traits<char>, _Template=std::char_traits]" at line 2108 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\xstring"
1>            instantiation of class "std::basic_string<_Elem, _Traits, _Alloc> [with _Elem=char, _Traits=std::char_traits<char>, _Alloc=std::allocator<char>]" at line 24 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\stdexcept"
1>
1>compilation aborted for ..\generated\hxx\register.cpp (code 2)

Hi,

when a program loads both libiomp and libomp with dlopen, calling an OpenMP function from one then from the other one can cause the program to terminate, depending on the order of the calls.

calling from libiomp first, then from libomp is fine. The issue is when calling from libomp first and then from libiomp.

Here is a reproducible example: test.c

#include <stdlib.h>
#include <dlfcn.h>

int main(int argc, char **argv){
    // load libomp and libiomp
    void *libomp_handle = dlopen("path/to/libomp.so", RTLD_NOW);
    void *libiomp_handle = dlopen("path/to/libiomp5.so", RTLD_NOW);
   
    // get "omp_get_max_threads" from each library
    int (*libiomp_get_max_threads)() = (int (*)()) dlsym(libiomp_handle, "omp_get_num_threads");
    int (*libomp_get_max_threads)() = (int (*)()) dlsym(libomp_handle, "omp_get_max_threads");

    // switch order of calls causes SIGABRT
    libomp_get_max_threads();
    libiomp_get_max_threads();

    return 0;
}

Compile and run:

    icc test.c -o test -ldl && ./test

Error Message:

OMP: Error #13: Assertion failure at z_Linux_util.cpp(2338). OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/.

Backtrace:

#0 0x00007ffff783e428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

#1 0x00007ffff784002a in abort () from /lib/x86_64-linux-gnu/libc.so.6

#2 0x00007ffff6f7b2c3 in __kmp_abort_process () at ../../src/kmp_runtime.cpp:481

#3 0x00007ffff6f66237 in __kmp_fatal (message=...) at ../../src/kmp_i18n.cpp:894

#4 0x00007ffff6f3a82c in __kmp_debug_assert (msg=0x76c5 <error: Cannot access memory at address 0x76c5>, file=0x76c5 <error: Cannot access memory at address 0x76c5>, line=6) at ../../src/kmp_debug.cpp:100

#5 0x00007ffff6fb57ee in __kmp_is_address_mapped (addr=0x76c5) at ../../src/z_Linux_util.cpp:2337

#6 0x00007ffff6f78f87 in __kmp_register_library_startup () at ../../src/kmp_runtime.cpp:6684

#7 0x00007ffff6f7a49b in _INTERNAL_25_______src_kmp_runtime_cpp_ddfed41b::__kmp_do_serial_initialize () at ../../src/kmp_runtime.cpp:6834

#8 _INTERNAL_25_______src_kmp_runtime_cpp_ddfed41b::__kmp_do_middle_initialize () at ../../src/kmp_runtime.cpp:7146

#9 __kmp_middle_initialize () at ../../src/kmp_runtime.cpp:7255

#10 0x00007ffff6f5ad75 in __kmp_api_omp_get_max_threads () at ../../src/kmp_ftn_entry.h:366

#11 0x00000000004006ab in main ()

Some remarks:

- Loading libgomp instead of libomp does not raise the error

- Link libraries instead of dlopen does not raise the error

- I know it's bad practice to load different OpenMP runtimes simultaneously. And in fact I have to set KMP_DUPLICATE_LIB_OK=TRUE otherwise it does not work at all. But in the python ecosystem, you can easily install packages from pre-built binaries and we don't know in advance which compiler has been used. For instance if one package uses MKL and another one uses OpenMP and is built with clang.

Thanks for your help

hi everybody，

in debian os， I compiled  successfully by icc and get a so file in parallel_studio_xe_2018_update1_cluster_edition.

but when run the program and load so file compiled, the error occur just like the topic title.

Any clue on what is happening ?

thank you!

Hello Intel,

I am trying to run some of the CLBlast tests, they not only fail, but also return a very long human-unreadable back trace and memory log is written to the terminal.

When I try to manually compile some .cl files from the Intel-provided examples, they seem to work. clinfo and tools from Intel for checking the drivers and SDK installation seem to work and indicate no error. Any tips?

My processor is:
Intel Core i7-5557U CPU @ 3.10GHz
and I've been trying to run the tests on the integrated graphics card as well, which is:
Intel Iris Graphics 6100
and I am running Ubuntu 16.04 with the 4.7.0 kernel, patched with the Intel OpenCL drivers. uname -a gives me:
Linux printer3d-desktop 4.7.0.intel.r5.0 #1 SMP Tue Dec 5 13:28:40 CET 2017 x86_64 x86_64 x86_64 GNU/Linux

If some one can help me I will be very thankful to him. 

Best Regards,

Sam Martin

Researcher at https://writeessaytoday.com

I could not find a forum specific to the Intel Software Manager (please feel free to direct me elsewhere if necessary). I recently migrated my C++ compiler tools from 2018 to 2019 - having removed all older versions of the studio. However, ISM keeps trying to notify me that an update to 2018 is available. I'm not sure if it's polling some registry key left behind by the uninstaller and thinking the product is still present or if it is keying off some file(s) that didn't get deleted, but it's annoying to continually get a popup notification for an update that is not applicable.

If there's an easy solution to this problem, please advise, or perhaps you can forward this report to your ISM team for resolution.

Thanks.

Hi,

  I updated my operating system from Mac 10.14.6 and some of my codes are now failed to compile with the following error

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

** Segmentation violation signal raised. **

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

I have Xcode 10.3 and Intel® Parallel Studio XE Composer Edition 2019 (update 3).  If I change the flag -O3 to -O2.  The compilation can be completed successfully.

Any help on this will be appreciated.

phay

Any attempt to compile a .c ( not .cxx) file that includes <windows.h> in a Visual Studio 2019 16.3.5 project using Intel 2019.5 results in the following error

1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.23.28105\include\vcruntime_string.h(18): error : expected an attribute name
1>  _NODISCARD _Check_return_
1>  ^

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

void test()
{
    printf("Hello world\n");
}

workarounds are to compile the offending .c files with the Visual C++ compiler or "compile as C++"

The following code can not be compiled with the Intel C++ compiler and flag -Wshadow. The compilation gets stuck without any further error message. However, the code compiles fine with the Intel C++ compiler when neglecting the flag -Wshadow.

#include <boost/operators.hpp>

class C
   : boost::ordered_euclidian_ring_operators1< C
   , boost::ordered_euclidian_ring_operators2< C, int
   , boost::ordered_euclidian_ring_operators2< C, double
> > > 
{
   C (long i) {}
};

int main() {}

I have tested  and reproduced this issue with versions 13.1.3, 14.0.3, 16.0.4, 17.0.5, 18.0.4 and 19.0.4 of the Intel C++ compiler using boost versions 1.61.0 and 1.70.0.
In contrast, the same code compiles fine with flag -Wshadow with various versions of the GNU C++ compiler and the LLVM Clang C++ compiler.

The fold expression will generate the following error message only when the value is not used:
"internal error: assertion failed: node_has_side_effects: bad node kind ... "

(compiled with icc -std=c++17)

template<int... I>
void f1(int* a)
{
    auto x = (a[I] + ...);
}

template<int... I>
void f2(int* a)
{
    (a[I] + ...);
}

void g()
{
    int a[1];
    f1<0>(a); // ok
    f2<0>(a); // internal error
}

Is there any solution to this problem?

So this issue seems to come up from time to time but I've yet to see a response from Intel on what to do (other than "I'll talk to our product team about it" and never really get back).

What is the correct way to use the Intel Parallel Studio on public CI infrastructure (Travis, Circle CI, Azure Pipelines, etc.)?  When doing this for open source projects, the open source non commercial license only applies if you're esentialy doing it on your own free time.  If I'm an employee of a company working on an open source project then the non-commercial license doesn't apply to me since I'm getting pain for my work.  It doesn't really seem feasible to run a license server in the cloud that the CI builds then talk to.  I also don't want to put my license file directly on a public cloud machine that's accessible to any user submitting a github pull request.

So what then is the requirement that the compiler uses your specific license file, so long as you actually have a legit license?  I guess let me explain that a little better.  Say I generate a non-commercial license file and install that with the compiler in a container that runs CI builds on CircleCI triggered by GitHub pull requests.  Then say I purchase a named user license, but just don't install the file anywhere.  In that case, I have purchased a legit commercial use license for the compiler, can I then simply "assert" that the compiler's use in the CI is under the license I've purchased?  As far as I can tell from reading the license language this should be allowed since it doesn't actually say anywhere that your use of the compiler has to be with the specific file tied to your license, just that you need to have a license that covers your use.

Would this work then?

After testing c20 module support in VC2019, I got

1>icl: : warning #10006: ignoring unknown option '/module:stdIfcDir'
1>x86
1>Catastrophic error: cannot open source file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.23.28105\ifc\x86": Permission denied
1>
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Platforms\Win32\PlatformToolsets\Intel C++ Compiler 19.0\Toolset.targets(358,5): error MSB6006: "icl.exe" exited with code 4.
1>Done building project "ccmod.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
 

when converting to Intel C++(2019U5).

Is such possible yet or not?

export module cmod00;

export namespace cmod0 {
#define ANSWER 42
#pragma once
#define ASIZE (0x10000)
#pragma data_seg(".sdata")
export volatile int aix[ASIZE/sizeof(int)] = {0};
#pragma data_seg()
#pragma comment(linker, "/Section:.sdata,RWS")

   int f_internal() {
        return ANSWER;
   }
  
   export int aix_len = ASIZE;
   export int f() {
      return f_internal();
	}
   export int fs() {
	aix[3]+=4;
    return aix[3];
   }
}

When I try to load static libraries using icpc -std=c++17 I get unresolved symbols from C++. In particular

Undefined symbols for architecture x86_64:
  "__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE8max_sizeEv"

Can somebody tell me what is really going on here? When I try dynamic loading I get the message

ld: illegal text reloc in '__ZN10BasicUnitsC1EPKc' to '__ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1Ev' for architecture x86_64

This constructor uses a const char* as an argument.

Greetings - I'm trying to install intel parallel studio XE version 19.0.5 onto an ubuntu 18.04 OS.   

The full installation works fine.  My problem comes in when I try to install components.  I am doing this inside a docker container so I would like to limit the size of the container by omitting what I do not need.  Since I'm doing this in a container, I'm doing a silent install:

./install.sh --silent=silent.cfg

The silent.cfg file includes this line:

# List of components to install (use semicolon to separate the components), valid values are: {ALL, DEFAULTS, comppat}
COMPONENTS=intel-icc__x86_64;intel-ifort__x86_64;intel-mkl-core__x86_64

But when I run the install script, this is what comes out in /opt/intel:

root@434e914a1a04:/opt/intel# ls
advisor                  compilers_and_libraries             documentation_2019  inspector_2019             itac         mkl                            performance_snapshots_2019.6.0.602217  vtune_amplifier_2019.6.0.602217
advisor_2019             compilers_and_libraries_2019        ide_support_2019    inspector_2019.5.0.602103  itac_2019    mpirt                          pstl
advisor_2019.5.0.602216  compilers_and_libraries_2019.5.281  imb                 intel_sdp_products.db      itac_latest  parallel_studio_xe_2019        samples_2019
bin                      conda_channel                       impi                intelpython2               lib          parallel_studio_xe_2019.5.075  tbb
clck                     daal                                include             intelpython3               licenses     performance_snapshot           vtune_amplifier
clck_latest              debugger_2019                       inspector           ipp                        man          performance_snapshots          vtune_amplifier_2019

Regardless of what I put in the COMPONENT list, it is installing everything: advisor, vtune, inspector, dall tbb, 32-bit libraries, etc.  This is bloating the size of my Docker container to over 22 GB.

Any ideas why the install script is not processing the COMPONENT list?

Thanks for any insights you might have

I'm trying to link the mkl library that is included in the parallel studio xe 2019 package to a solution of a project using CMakeLists.txt, I'm getting the following error :

CMake Error at CMakeLists.txt:12 (find_package):
  By not providing "FindMKL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "MKL", but
  CMake did not find one

My CMakeLists.txt file looks like that:

cmake_minimum_required(VERSION 3.15)

project(untitled) set(CMAKE_CXX_STANDARD 14)

add_executable(untitled main.cpp)

set(MKL_DIR "/home/ali/intel/parallel_studio_xe_2019.5.075/compilers_and_libraries_2019/linux/mkl/") include_directories(SYSTEM ${MKL})

find_package(MKL REQUIRED)

if(MKL_FOUND)

include_directories(${MKL_INCLUDE_DIRS})

target_link_libraries(untitled ${MKL_CORE_LIBRARY})

else() message(WARNING "MKL libs not found")

endif()

Thank you

...and unable to submit support request due to... unusable support website; i've been going round in circles for an hour trying to sort the latter.

Details of the former:

- freshly downloaded license (also tried getting it sent by mail)

- newly updated license server

- fresh copy of parallel studio

- tried with the serial number, with the downloaded license, with the restarted license manager.

Online activation:

Activation rights do not allow this software to be installed. This could be due 
to expired subscription, incompatible serial number, or unavailable Intel(R)
Software License Manager.

My support is *not* expired (currently valid until December)

As I say, I've tried submitting a ticket, but as soon as I get to the OSC, it bounces me to:

https://www.intel.com/content/www/us/en/support.html?random=-297740462

and I'm back to square one...

Cheers,

JB

Dear all,

I am a very new beginner to the c/c++ programming. I wrote some C code and compiled it to a dll which is used as a plugin in another application. The problem I have now is that the dll compiled using the Intel C++ Compiler 19.0 loads fine to the application in my laptop where the dll is compiled, but it could not be loaded to the same application ("could not load the plugin") in two other Wintel machines. This happens even if I stripped off all machine-specific options in the compilation. On the other hand, the dll compiled using Visual C++ compiler can be loaded to multiple Wintel machines without problems. I much prefer the Intel version of the dll since the application runs much faster with it (when it works, that is). The followings are some details.

* programing language: C (not C++);
* environment: Microsoft Visual Studio 2017 Community Version + Intel Parallel Studio XE 2019;
* machine used to compile the dll: notebook, Win10 (64bit), Intel Core i7-8550U CPU (Kaby Lake R);
* machines to be tested: (1) desktop, Win7 (64bit), Intel Core i7-6700K CPU (Skylake); (2) desktop, Win10 (64bit), Intel Core i7-8700 CPU (Coffee Lake).

The code is compiled using either the Intel compiler or the MS Visual compiler, both are done in MS VS2017. I did not use command lines.

The compilation options are the follows.

/MP /GS- /TC /W3 /Zc:wchar_t- /Zi /Od /Fd"x64\Release\vc141.pdb" /fp:precise /D "NDEBUG" /D "MSLE8C_EXPORTS" /D "_WINDOWS" /D "_USRDLL" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /Zc:forScope- /MD /FC /Fa"x64\Release\" /nologo /Fo"x64\Release\" /Qprof-dir "x64\Release\" /Fp"x64\Release\msle8c.pch" 

I'll appreciate if anyone can share insights. Thanks in advance.

Henry

Hi,

I'm  working  on a complicated  project, that requires a parallel  calculations  in  order to achieve  good time performance.

Our  company  bought  for  this purpose  intel xeon platinum 8168  processor (96 CORES - name 96).  Also, we have a  computer  with intel core i9 7960x processor(16 CORES - name 16). 

I'm  using  "omp  pragma  for"  directive,  as all  calculations  happen in  FOR  loops. And at this point i got strange results.

I'm running  my code  on  16  PC,  with number of iterations in FOR loop  less than 16. That's mean, that number of threads & number of CORES  that are  used  less than 16. At this point, I got almost same time results(I mean, 5 iterations, 10 iterations, and 15 iterations  complete with almost same time). And this is correct, since NOT ALL CPU  power was  used.

At this point, I try  and run SAME  code  on  96. And I see strange time performance results. If I run 40 iterations(see 40 threads), the time is almost twice against 1 iteration. And if I run 90 iterations(still, NOT full power!!),  time increase almost 4 times. 

My questions is, does it have some issue to this specific processor (intel xeon platinum 8168  processor)  working with IPP libraries ? 

What could be the possible reason for such a time complexity increase?  I am aware about dynamic memory allocations , we have some,  and time needed to create large number of threads, but still  that's seem  not the real reason.

Thanks   

Hi,

I am working with complicated algorithm, that requires a lot of computations. For this purpose, Intel Xeon Platinum 8168 CPU  was puchased - with 96 Cores(name  96). Besides, we already have Intel Core i9 -7960X CPU with 16 Cores(name 16). 

I'm  running "omp pragma parallel for" directive on  FOR  loop in  order to get  parallel calculations. First, I tried this approach on 16 PC, with 5, 10  and 15  iterations on that  FOR  loop, and got almost  same  results for all three cases (and that is correct, since not all CPU power was used).

Next step, I ran same code on 96 PC. I also have tried  different number of iterations ,and I see an constantly increasing  time in total execution.

On 40 iterations, total time increased almost twice, and on 90 iterations it increased in 3.5 times(still, NOT full power of CPU as it have 96 cores!!).

I'm aware of threading pool, and time needed to create such amount of threads but still, that seems not working well at all.  Does omp have specific problems with   Intel Xeon Platinum processors, that I not aware of it? Maybe something about it's architecture, that not complied with omp.

* It is not a problem of cooling hardware, since tests are running about 3 minutes.

* It is not a problem of allocations or memory copy, since there is exactly same amount of memory allocated and memory copied. 

Could you think of a possible problems, because I have run out of ideas.

Thanks

Here is the sample:

~$ cat lib.h
#ifndef LIB_H_
#define LIB_H_
void foo();
#endif
~$ cat lib.cpp
#include <iostream>
#include "lib.h"
void foo() {
    std::cout << "Hello, world!"<< std::endl;
}
~$ cat main.cpp
#include "lib.h"
int main() {
    foo();
    return 0;
}
~$ icpc -fPIC -c lib.cpp
~$ icpc -fuse-ld=lld -shared -o libmylib.so lib.o
ld.lld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gxx_personality_v0 in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in /usr/lib/gcc/x86_64-linux-gnu/7/libstdc++.so
>>> referenced by lib.cpp
>>>               lib.o:(.gnu.linkonce.d.DW.ref.__gxx_personality_v0+0x0)
~$ icpc -fuse-ld=lld -shared -o libmylib.so lib.o -Wl,-z,notext
~$ icpc main.o -L . -lmylib
~$ ./a.out 
Segmentation fault (core dumped)
~$ gdb a.out core
[New LWP 50478]
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2ffdbe7526 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007f2ffdbe7526 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007f2ffdbe7ba8 in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007f2ffdbe8027 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007f2ffe07f0f4 in foo() () from ./libmylib.so
#4  0x0000000000400ddf in main ()
~$ g++ -c -fPIC lib.cpp
~$ icpc -fuse-ld=lld -shared -o libmylib.so lib.o
~$ ./a.out
Hello, world!
~$

LLD does not link the object file produced by ICPC, even I just compiled the object file with -fPIC option present. If I add -Wl,-z-notext option to linker as prompted by LLD, it links, but the generated libmylib.so library does not work and segfaults in libstdc++. But if I compile the object file with G++ and all other things remain the same, it works.