Using Ubuntu 19.10 or 18.04 LTS, when using the latest version of the Intel C++ Compiler issued in Parallel Studio XE 2020 (version 19.1.0.166 / 20191121), attempts to build UCX with the -ipo flag result in failure when compiling & linking sockaddr (sa); this appears to be an issue with Intel's Compiler rather than UCX because the 2018 and 2019 editions of Parallel Studio XE (versions 18.0.6.286 / 20190605 and 19.0.5.281 / 20190815, respectively) are able to compile and link it just fine. Using GCC and G++ with LTO enabled is also able to compile and link it without issue. Also attached are the entire config and build logs.

These are the symbols that are not found. Attempting to explicitly link with -lstdc++, using different C++ and GNU++ standards, etc., fail to fix the problem:

ipo: error #11021: unresolved _ZNSt14_Function_base12_M_max_alignE
        Referenced in /tmp/ipo_icpcYJnRpy.o
ipo: error #11021: unresolved _ZNSt14_Function_base11_M_max_sizeE
        Referenced in /tmp/ipo_icpcYJnRpy.o

These are the demangled symbols:

std::_Function_base::_M_max_align
std::_Function_base::_M_max_size

An extremely easily reproduceible example that will fail to build is given below:

1. git clone --recurse-submodules https://github.com/openucx/ucx.git&& cd ucx
2. ./autogen.sh
3. ./configure CC=icc CXX=icpc LD=xild AR=xiar CFLAGS="-ipo"
4. make -j$(nproc)

This is the open bug report on the UCX project (where it was stated to likely be a regression on Intel's part), detailing the same information covered here:

https://github.com/openucx/ucx/issues/4624

With the Microsoft compiler, compiling in C++ standard compliance mode of 2017 or later, I can use SIMD data types for example in std::vector without custom allocators. When trying to use Intel compiler from Visual Studio this does not seem to work. (I am new to using the Intel compiler, so I may just be missing some option, but I think I have tried the standard version settings etc)

I have attached example code at the bottom of this message. The memory allocations of course vary, and often produce aligned results, even if not set really set up correctly. The define (commented out) on the first line seems to be the one controlling the behavior in Microsoft header files, if it is used, then the code works also with Intel compilers. As the defined symbol is in"compiler namespace", I guess defining it as a user is not a clean solution.

There are some compatibility issues between Visual Studio 2019 and Intel compiler, so I have done my testing with Visual Studio 2017.

 Eero

//#define __cpp_aligned_new 1
#include <stdio.h>
#include <xmmintrin.h>
#include <vector>

struct Test_S{
  __m128 v;
  float b;
};

int main(){
  fprintf(stderr,"Alignment requirement = %d\n",alignof(Test_S));
#ifdef __cpp_aligned_new
  fprintf(stderr,"__cpp_aligned_new defined\n");
#else
  fprintf(stderr,"__cpp_aligned_new not defined\n");
#endif
  std::vector<Test_S> a;
  a.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(a[0].v));
  std::vector<Test_S> b;
  b.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(b[0].v));
  std::vector<Test_S> c;
  c.push_back(Test_S());
  fprintf(stderr,"addr=%p\n",&(c[0].v));
}

OS- Linux login1 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Compiler - intel parallel studio 19.5 with GCC 8.3.0

CUDA - 10.1

Application - Gromacs -2020 -  ftp://ftp.gromacs.org/pub/gromacs/gromacs-2020.tar.gz

Error- 

icpc: error #10106: Fatal error in /home/opt_ohpc_pub/intel/compilers_and_libraries_2019.5.281/linux/bin/intel64/mcpcom, terminated by floating point exception
compilation aborted for /home/samir/gromacs_2020/gromacs-2020/src/gromacs/pulling/pullutil.cpp (code 1)

Hi all,

I'm trying to compile R 3.4.2 from the source code following this guide:

https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux

However, I got the following error when building (see below). It builds using gcc without problems.  Do you have an idea of what could be happening?

Best,

Marko

icc -I../../src/extra  -I. -I../../src/include -I../../src/include  -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O2 -std=c99  -c arithmetic.c -o arithmetic.o
arithmetic.c(59): warning #274: declaration is not visible outside of function
  int matherr(struct exception *exc)
                     ^

arithmetic.c(61): error: pointer to incomplete class type is not allowed
      switch (exc->type) {
              ^

arithmetic.c(62): error: identifier "DOMAIN" is undefined
      case DOMAIN:
           ^

arithmetic.c(63): error: identifier "SING" is undefined
      case SING:
           ^

arithmetic.c(66): error: identifier "OVERFLOW" is undefined
      case OVERFLOW:
           ^

arithmetic.c(69): error: identifier "UNDERFLOW" is undefined
      case UNDERFLOW:
           ^

arithmetic.c(70): error: pointer to incomplete class type is not allowed
  	exc->retval = 0.0;
  	^

compilation aborted for arithmetic.c (code 2)
../../Makeconf:119: recipe for target 'arithmetic.o' failed

Hello,

I'm not sure why, but when I use Intels Optimized Headers(specifically valarray) the compiler will point out about 66 or so syntax errors. I'm unsure why this is happening.

I'm on Visual Studio 2019.4.1(enterprise) and Intel C++ Compiler version 19.1

Thanks

I hope this is the correct forum.  I just download the 30 day trial of parallel studio xe 2020 cluster edition (online) for linux to test out the intel c/c++ compiler.

When I run the install.sh I get an error saying

CPU is not supported.

Where can I find out what CPUs are supported?  

Also, is parallel studio the only way for me to get a copy of the compiler for testing?

Thanks, Ted

uname -a shows 

Linux vlbuild1 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

and /proc/cpuinfo shows

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : QEMU Virtual CPU version (cpu64-rhel6)
stepping        : 3
cpu MHz         : 2899.998
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm pni cx16 lahf_lm
bogomips        : 5799.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
 

As of year 2020 AD what is the best C++ version for the latest Intel CPU?

I am using 32 bit Microsoft Windows.

I chose, months ago, to learn C++11 and I am learning it via CODE::BLOCKS 17.12 . It seemed at the time that C++11 was the most widely compatible version and the most stable version in relation to common computer hardware. I am now checking if that is currently applicable to the latest and greatest Intel CPUs;

Whatever the latest and greatest Intel CPU that is available on the open market in the United States of America.

What is the latest version of C++ that will work very well with that CPU?

I am *not* asking about Microsoft Visual Studio for this.

I am *not* asking about ".net" versions of C++ for this.

Just straight C++ on the latest and greatest Intel CPU.

And, what is that Intel CPU? I have heard that there is to be a super multi-core Intel CPU out now. Maybe?

Thank you.

Visual Studio 14.9.19
Intel Parallel Studio XE 2020
Latest Windows 10

The following piece of code (VS project attached) fails to link with an error

1>ipo_1894819obj3.obj : : error LNK2019: unresolved external symbol wmemcmp referenced in function main

when built it in C++17 mode.

#include "stdafx.h"
#include <string>
#include <wchar.h>

int main()
{ 
	std::wstring a = L"Hallo";
	std::wstring b = L"Dulla";
	printf("%d\n", int(a == b));  // comment out this line and it will link fine
	printf("%d\n", wmemcmp(a.data(), b.data(), 5));
	return 0;
}

When I comment out the marked line, it links fine.

When I switch C++ standard to C++14 it builds fine, too.

As the line with the explicit call to "wmemcmp" does not cause any problems I have the impression that the wmemcmp used for the wstring comparison uses an erroneous function signature in C++17-mode only.

Regards, Frank

I'm currently evaluating the possibility to move from C++11 to C++17. I currently use VS 2017 and Intel Compiler 19.0.0 (Initial Release), and I got two questions:

⚫ Q1: Does IC 19.0.0 supports C++17 with VS 15.7 or older versions?

I checked the Visual Studio 2017 support article [1] and it says the following regarding VS 2017, IC 19.0.0 and C++17:

Microsoft Visual Studio 2017 version | Supported Intel Compiler Version
-------------------------------------|----------------------------------------------
15.8                                 | 19.0 but without the additional C++17 support
15.7                                 | 19.0
15.6, 15.5, 15.4                     | 19.0 Initial Release

[1]: https://software.intel.com/en-us/articles/intel-compilers-integration-su...

There is no note on C++17 support with VS 15.4 to 15.7, but there is an explicit note on the lack of support with 15.8, This gives me the impression that IC 19.0 would support C++17 on these older VS versions. I tried searching the FAQs, Release Notes and documentation as well as this forum, but I could not find any piece of information to confirm if C++17 is supported or not with those older VS 2017 minor versions.

Does anyone here knows if IC 19.0.0 supports compiling code in C++17 mode when used with VS 2017 minor versions 15.7 or older?

⚫ Q2: How can I tell compilervars.bat which VS 2017 toolset (minor version) it should use?

My VS 2017 install (15.9.19) has multiple VC toolsets (found in the VC\Tools\MSVC directory):

VC Toolset | `_MSC_VER` | VS 2017 version
-----------|------------|----------------
   14.13   |    1913    |      15.6
   14.14   |    1914    |      15.7
   14.16   |    1916    |      15.9

When calling compilervars.bat to set up the development environment, I couldn't find a way to tell it which VS 2017 toolset it should use. By compiling a simple program which outputs the _MSC_VER, it seems to be getting the latest one (VC 14.16, VS 15.9):

// version.cpp
#include <iostream>
int main() {
    std::cout << _MSC_VER << '\n';
}

> "C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\bin\compilervars.bat" intel64 vs2017
> icl.exe version.cpp
> version.exe
1916

Assuming that ICC 19.0.0 would support C++17 mode with VS 2017 15.7 or older, I would need to find a way to make compilervars.bat use another toolset version (e.g.: VC 14.13, VS 15.6). 

Is there any way to tell compilervars.bat which VS 2017 toolset (minor version) it should use among the ones installed?

Hello,

I've found that some codes compiled by the Intel compiler are significantly slower than those by GCC.
Here is a sample code.

https://github.com/kaityo256/compiler_test

This is a Monte Carlo simulation code of the Potts model which is one of the fundamental models in statistical physics.

Here is a benchmark result.

* Compile Options

g++ -O3 -march=native -Wall -Wextra -std=c++11  main.cpp -o gcc.out
icpc -O3 -xHOST -Wall -Wextra -std=c++11  main.cpp -o icpc.out

* Environment

CPU: Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
OS: CentOS Linux release 7.6.1810 (Core)
GCC: g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
icpc: icpc (ICC) 19.0.4.243 20190416

$ ./gcc.out
Magnetization : 0.891599
Elapsed : 305 [ms]

$ ./icpc.out
Magnetization : 0.891599
Elapsed : 880 [ms]

The two executables give the identical result, but the executable produced by Intel compiler is significantly slower than that by GCC.

I want to figure out what is happening here and write an article (maybe in Japanese). But I am afraid that the detailed analysis of optimization can be regarded as "reverse engineering" which is inhibited in EULA, since the investigation may reveal the limitations of optimization capabilities of the Intel compiler.

I am going to compare assembly codes produced by GCC and the Intel compiler, but I will not decompile the Intel compiler.

Does the above attempt violate EULA?

Thanks in advance.

Less of a bug report and more of a request to implement the ; the "-static-pie" flag is already available in most newer versions of GCC and Clang, but it is an unrecognized flag by icc/icpc, and -static -pie is not the same as -static-pie (because -static and -static-pie are mutually exclusive in GCC).

The implementation is fairly simple, with the largest change being that when linking to startfiles, it just needs to link to rcrt1.o for -static-pie and to grcrt1.o for -static-pie with PGO, instead of linking to Scrt1.o (PIE) or crt1.o(static lib). When linking to the end files, it would use crtbeginS.o instead of crtbeginT.o (as is usually used for static libs.)

Some relevant info/files:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu-user.h 

I'm getting a ton of invalid warnings from ICC about an __assume with side effects.  It turns out the "problem" is that I'm using a statement expr (which has no side effects).  Here is a reduced test case:

#include <stdint.h>

void foo(int *bar) {
  __assume((
	    ((uintptr_t) bar)
	    % 16) == 0);

  __assume((
	    (__extension__ ({ (uintptr_t) bar; }))
	    % 16) == 0);
}

Which triggers:

aa.c(8): warning #2261: __assume expression with side effects discarded
    __assume((
             ^

I've already tweaked my code to get rid of the statement expr, so no need to think of work-arounds on my behalf.  I just wanted to report the issue.

I am trying to compile the simulation software LAMMPS using CMake, and run into some trouble:
 

-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES) (found version "3.1")
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1")
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.16/Modules/FindMPI.cmake:1688 (find_package_handle_standard_args)
  CMakeLists.txt:180 (find_package)

I do have the latest intel parallel studio

$ icc -V
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

I'm on Archlinux, and the version of CMake I'm using is:

$ cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

My compilation options are:

-DCMAKE_C_COMPILER=mpiicc
-DCMAKE_C_FLAGS=-xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
-DCMAKE_CXX_COMPILER=mpiicpc
-DCMAKE_CXX_FLAGS=-fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high -qno-offload -fno-alias -ansi-alias -O2 -std=c++11 -DLMP_INTEL_USELRT -DLMP_USE_MKL_RNG -I${MKLROOT}/include
-DCMAKE_Fortran_COMPILER=mpiifort

Am I doing something wrong?

Apologies if the issue was already reported but have a look at the following code snippet

#include <variant>

std::variant<int, char*> foo()
{
    return 0xD;
}

This should compile by choosing the converting constructor overload of the variant whose definition is

template< class T >
constexpr variant(T&& t) noexcept(...);

but it does not compile as can be seen here.

Compiler flags used: -std=c++17 -O3 -Wall -Werror

Compiler version: v19.0.1

$ cat main.x.cpp 
#include <iostream>
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
int main()
{
    std::cout << "Current path is "<< fs::current_path() << '\n';
}

$ icpc main.x.cpp -lstdc++fs -std=c++14   # Works!


$ icpc main.x.cpp -lstdc++fs -std=c++14 -g   # Doesn't work
/spare/scratch/icpcNgdXiG.o: In function `std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::experimental::filesystem::v1::path::string<char, std::char_traits<char>, std::allocator<char> >(std::allocator<char> const&) const':
/spare/scratch/tmp-e31ZpjU-infra/gcc/5.4.0/include/c++/5.4.0/experimental/fs_path.h:822: undefined reference to `std::codecvt_utf8<char, 1114111ul, (std::codecvt_mode)0>::codecvt_utf8(unsigned long)'
/spare/scratch/tmp-e31ZpjU-infra/gcc/5.4.0/include/c++/5.4.0/experimental/fs_path.h:822: undefined reference to `std::codecvt_utf8<char, 1114111ul, (std::codecvt_mode)0>::~codecvt_utf8()'
/spare/scratch/tmp-e31ZpjU-infra/gcc/5.4.0/include/c++/5.4.0/experimental/fs_path.h:825: undefined reference to `std::codecvt_utf8<char, 1114111ul, (std::codecvt_mode)0>::~codecvt_utf8()'

$ icpc main.x.cpp -lstdc++fs -std=c++14 -g -mGLOB_opt_level=1  # Works!

This has been tested with Intel compilers 16 to 19 and the behavior is same.

I am working on an offline Linux machine and I am trying to use the Intel C Compiler (icc) but I am getting a license error (#10052) when I invoke it.

I have the INTEL_LICENSE_FILE variable point to the full license.

Should I be using the USE_SERVER license instead? If not, what else could cause this error?

Thanks in advance.

Hi, I am pretty new to Intel C++ compiler and am appreciated for your help.

I want to confirm which of the following is true during compile link process:

1. static openMP libiomp5mt.dll is not supported for Win 10

2. static openMP libiomp5mt.dll is not supported for Parallel Studio 2020 XE Intel Compiler 19.1

3 static openMP libiomp5mt.dll is supported for Parallel Studio 2020 XE on Win 10, I missed something so I don't have it.

Background info: When I compile on my Win 7 machine with Parallel Studio 2019, I always link to the static libiomp5mt.dll. I want to test whether compile works on win 10 machine, I install a trial version of Parallel Studio 2020 with Intel Compiler 19.1. I don't see static libiomp5mt.dll anymore in my C drive, instead I have to link to dynamic library libiomp5md.dll.

Is there any document can confirm that libiomp5mt.dll is not supported? Or it is still supported but I missed something.

I find libiomp5mt.dll is not supported for Intel Fortran compiler 19.0 in this release note:

https://software.intel.com/en-us/articles/intel-visual-fortran-compiler-...

I don't see it anywhere in the Intel C++ compiler release note. Thanks. 

I am trying to use the C Compiler (icc) on an offline linux machine but whenever I invoke the compiler I get error #10052.

I looked at the variable INTEL_LICENSE_FILE and it is looking at the right place but somehow it is still throwing the same error.

Is there a way to fix this?

Thanks in advance.

As discussed here: https://github.com/easybuilders/easybuild-easyconfigs/issues/8003 some codes don't compile using -xCORE-AVX512 if newer binutils are used (>=2.30, note that https://software.intel.com/en-us/articles/intel-c-compiler-191-for-linux-release-notes-for-intel-parallel-studio-xe-2020 says that up to 2.29 is supported, so perhaps Intel is aware already, but I could not find this documented anywhere else publically)

The issue is that Intel compilers generate instructions such as "vmovd %xmm16,%r10" which should really be with a "q", so "vmovq %xmm16,%r10". In this patch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=704a705d7aaab8041df76e2981e2a1efc014aad0;hp=605fd3c6590fbed834107a2e1d1df0ba58834576 H.J. Lu removed support for this syntax for xmm registers >15 as it's never generated by GCC.

This patch re-adds them to binutils:

https://raw.githubusercontent.com/easybuilders/easybuild-easyconfigs/8b699534fafeb7cc51ffb83cf0a1e8f739ab0a1d/easybuild/easyconfigs/b/binutils/binutils-2.32-readd-avx512-vmovd.patch

and then CGAL and some other packages can be compiled again.

I am putting this out here so people who run into similar issues can find it but Intel: can you please fix this issue in the compiler?

(Note that H.J. Lu works for Intel!)

Hi!

I've attached some driver code to explain the filesystem library issue I'm facing with my larger project:

Test Code (test.cpp):

#include <iostream>
#include <experimental/filesystem>

namespace fs = std::experimental::filesystem;

int main() {
    std::cout << fs::path("").extension() << std::endl;
    
    return 0;
}

Compilation commands (tried both):

icc test.cpp -lstdc++fs -std=c++17

icpc test.cpp -lstdc++fs -std=c++17

Here's what's spit out:

In function `main':
test.cpp:(.text+0x79): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_find_extension[abi:cxx11]() const'

ICC Version:

icc (ICC) 19.0.3.199 20190206

OS Version (as reported by cat /etc/issue):

Ubuntu 18.04.2 LTS

Could this be related to: https://software.intel.com/en-us/forums/intel-c-compiler/topic/844541 ??