Copied from the GCC bug I reported, because it applies to Intel C++ as well.  At least, the version "18" on https://gcc.godbolt.org/.

Intel C++ expects the "override" keyword in an incorrect position in the C++ grammar:

#define MEOW 256
struct Base {
    virtual const char (&GetBuffer() const)[MEOW] = 0;
};
struct Derived : public Base {
    // Intel C++ requires this incorrect syntax...
    virtual const char (&GetBuffer() const override)[MEOW];
    // ...but the below is the correct syntax, which Intel C++ rejects.
    virtual const char (&GetBuffer() const)[MEOW] override;
};

In the C++ Standard, "override" is a virt-specifier in a virt-specifier-seq. virt-specifier-seq optionally goes after the declarator. After the optional virt-specifier-seq goes the optional pure-specifier.

I wish I had a small bit of code to demonstrate this, but unfortunately I don't. Wondering if anyone else has run into something similar, though.

I followed the instructions to link mkl_rt at https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compi.... I’m building/running on a Skylake with AVX-512, on a fresh install of RHEL/CentOS 7.4 with glibc-2.17-196.el7_4.2, and Intel Compiler 18 update 1. The compile finishes without errors, and R mostly works, but deadlocks under certain workloads—typically if a lot of computation has been done and then it forks. A guaranteed way to trigger it is running “make check-all” after compilation. MKL_THREADING_LAYER=intel deadlocks even on some very basic tests (during forks to system calls), =tbb gets around it most—but not all—of the time (tests involving the R parallel library fail), and =sequential (or setting OMP_NUM_THREADS=1 in the other two modes) passes all tests.

Here’s the relevant stack of deadlocked process:

#0  0x00007fae3d963945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fae3de53b77 in ___kmp_suspend_template_aux (th_gtid=<optimized out>, th=<optimized out>, flag=<optimized out>) at ../../src/z_Linux_util.cpp:1781
#2  __kmp_suspend_template (th_gtid=<optimized out>, flag=<optimized out>) at ../../src/z_Linux_util.cpp:1910
#3  __kmp_suspend_64 (th_gtid=635251012, flag=0x80) at ../../src/z_Linux_util.cpp:2019
#4  0x00007fae3dde2f13 in suspend (this=<optimized out>, th_gtid=<optimized out>) at ../../src/kmp_wait_release.h:731
#5  __kmp_wait_template (this_thr=<optimized out>, flag=<optimized out>, final_spin=<optimized out>, itt_sync_obj=<optimized out>) at ../../src/kmp_wait_release.h:343
#6  wait (this=<optimized out>, this_thr=<optimized out>, final_spin=<optimized out>, itt_sync_obj=<optimized out>) at ../../src/kmp_wait_release.h:742
#7  _INTERNAL_25_______src_kmp_barrier_cpp_ce635104::__kmp_hyper_barrier_release (bt=635251012, this_thr=0x80, gtid=1, tid=-1, propagate_icvs=635250944, itt_sync_obj=0x0) at ../../src/kmp_barrier.cpp:865
#8  0x00007fae3dde4556 in __kmp_fork_barrier (gtid=635251012, tid=128) at ../../src/kmp_barrier.cpp:2177
#9  0x00007fae3de1cc1f in __kmp_launch_thread (this_thr=0x7fae25dd2944) at ../../src/kmp_runtime.cpp:5768
#10 0x00007fae3de4fc00 in _INTERNAL_26_______src_z_Linux_util_cpp_c3d2e46c::__kmp_launch_worker (thr=0x7fae25dd2944) at ../../src/z_Linux_util.cpp:585
#11 0x00007fae3d95fe25 in start_thread () from /lib64/libpthread.so.0
#12 0x00007fae3d68d34d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fae3eef3780 (LWP 27709)):
#0  0x00007fae3d671e47 in sched_yield () from /lib64/libc.so.6
#1  0x00007fae3de530a4 in _INTERNAL_26_______src_z_Linux_util_cpp_c3d2e46c::__kmp_atfork_prepare () at ../../src/z_Linux_util.cpp:1531
#2  0x00007fae3d654232 in fork () from /lib64/libc.so.6
#3  0x00007fae3d601bbc in _IO_proc_open@@GLIBC_2.2.5 () from /lib64/libc.so.6
#4  0x00007fae3d601e4c in popen@@GLIBC_2.2.5 () from /lib64/libc.so.6
#5  0x00007fae3e756617 in do_system () from /tmp/rbuild/lib/libR.so

If you strace the parent, you see sched_yield() being called infinitely, and the CPU is pinned at 100% (seen a similar issue on here, but it’s related to v15 and was fixed in v16). I’ve recompiled probably near 100 times with different compiler options, but the result is always the same.  I’ve tried the entire process with the kernel from 7.3, as well, and that fails similarly—so I’m more inclined to think it’s something to do with the interaction between Intel’s OpenMP and glibc. clang builds against the system-provided OpenMP execute with threading fine. I haven’t had a chance to test on other distros or a different processor.

Any thoughts?

Dear all,

First of all I am not a programmer so please excuse me if I use some improper terms.

I am trying to compile the hdf5 libraries under ubuntu 16.04 with Intel Parallel Studio XE 2018, but whenever I configure them, in the configure output I read:

compiler 'icc' is Intel icc-18.0.1.163
compiler 'ifort' is Intel ifort-18.0.1.163
compiler 'icpc' is GNU g++-5.0.0

My environment variables are set up under /home/.bashrc and are as follows

source /opt/intel/parallel_studio_xe_2018.1.038/bin/psxevars.sh
source /opt/intel/compilers_and_libraries_2018.1.163/linux/bin/compilervars.sh intel64
export CC=icc
export CXX=icpc
export CPP='icc -E' 
export F77=ifort
export FC=ifort

Also this is the reply of the which command:

chertan@chertan-UX310UQ:~/Software/Installers/hdf5-1.10.1$ which icpc
/opt/intel/compilers_and_libraries_2018.1.163/linux/bin/intel64/icpc

I generally use cmake-gui to be sure to point to the correct compilers, but I cannot in this case, and I have to make sure that hdf is compiled with intel. Why does my environment sets icpc to g++? There's no environmental variable pointing to that!

Thanks!

Hi

I try to compile my program in windows platform installed Visual Studio and Intel C++ compiler.

But when I copy my exe. program to another computer without Intel C++ and VS. It failed. It asked several dll. files(libiomp5md.dll, libmmd.dll, msvcp120d.dll , msvcr120d.dll). We tried to have those files in the same folder, the program can run, but may have many errors sometimes.

How to solve this problem?

YZ

Steps to reproduce:

$ wget https://www.python.org/ftp/python/3.6.4/Python-3.6.4.tar.xz
$ tar -xaf Python-3.6.4.tar.xz
$ cd Python-3.6.4/
$ ./configure --with-icc
$ icc -I Include -I. -c Modules/_sha3/sha3module.c -o tmp.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.

compilation aborted for Modules/_sha3/sha3module.c (code 4)

I try to test if packages will continue function with this new distro. I had installed Parallel Studio XE 2016 update 4 (even though it is unsupported OS). Found it did not cooperate with gcc 7.3, and that latest version 2018 update 1 is needed. So I attempt to install the C++ compiler.

If complains about pre-requisites:

32-bit libraries not found on this system.
This product release requires the presence of 32-bit compatibility libraries
when running on Intel(R) 64 architecture systems. One or more of these libraries
could not be found:
    libstdc++ (including libstdc++6)
    glibc
    libgcc

I checked, and I had the 32-bit glibc and libgcc. So I installed 32-bit libstdc++ and started the install.sh again.

Unfortuately, it blocks with the same error.

Has anybody installed version 2018 on Leap 15?

Dear all

When I install C++ on my computer, there are the problem of path variables"  

PATH environment variable size has exceeded its limit.
Installation cannot continue because the length of your path is too long. 
 Suggestion: Exit the installation, eliminate unnecessary items in the PATH environment variable (you need to free more than 798 symbols) using Control Panel > System and Security > System > Advanced system settings > Advanced > Environment Variables and launch the installation again.

Could you tell me how can i solve it?

Thank you very much.

Zemin

I have a program that uses the following OpenMP directives together: taskloop and collapse. The program works fine when I compile with GCC 7.2, but it simply crashes when I compile with Intel compiler v 17.0.1. I investigated my code and I created a simple program that reproduces the cause of the crash. The code is below
int main ()
{
double * a=(double *) malloc(100*sizeof(double));
printf("1. a %x\n",a);
#pragma omp taskloop collapse(3) shared(a)
for(int i=0;i<1;i++)
{
for(int j=0;j<1;j++)
{
for (int k=0;k<1;k++)
{
printf("2. a %x\n",a);
double sum=0;
for(int l=0;l<5;l++)
{
sum+=1;
}
printf("%f\n",sum);
}
}
}
free(a);
}
For gcc, the output is correct
1. a 11610a0
2. a 11610a0 i 0 j 0 k 0
5.000000

For Intel v 17, the output is wrong
1. a d2e010

I compiled the same code with Intel version 18, the output is correct and similar to GCC.7.2
1. a 202f010
2. a 202f010 i 0 j 0 k 0
5.000000

In another complex code, I also found that the value of the pointers that are shared (like the Pointer "a" in the code above) are always changed to be zero also sometimes the indices (like i, j, k in the code above) of the collapsed loops have large negative numbers?
My question
Is there any fix for such bugs for version 17?

Dear Experts,

I have recently downloaded and installed the "Intel(R) Parallel Studio XE 2018 Update 1" which seems to lack "stdio.h"? 

For example, if i try to initiate the env with "psxevars.bat intel64", it shows no error:

Intel(R) Parallel Studio XE 2018 Update 1
Copyright (C) 2017 Intel Corporation. All rights reserved.

Intel(R) Compiler 18.0 Update 1 (package 156)

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.5.7
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

however if i try to build some program, for example https://software.intel.com/sites/default/files/openmp_samples_C_win_2017... , it fails with following message:

C:\Users\animeshs\Desktop\openmp_samples>build
icl /nologo /O2 /Qstd=c99 /Qopenmp /F256000000  /Forelease\ src\openmp_sample.c /link /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MANIFEST:NO  /out:release\openmp_sample.exe
openmp_sample.c
src\openmp_sample.c(54): catastrophic error: cannot open source file "stdio.h"
  #include <stdio.h>
                    ^

compilation aborted for src\openmp_sample.c (code 4)

Any ideas on how to proceed?

Best regards,

Ani

Running Windows 10, VS Community 2017 15.6.0 and Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.6.270 Build 20171215.

The following code does not compile:

#include <string>

int main()
{
	std::string s0("Initial string");
    return 0;
}

with the following two errors:

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration

1>  _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;

1>                             ^

1>          detected during:

1>            instantiation of "const bool std::_Is_iterator_v [with _Ty=char *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"

1>            instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=char, _Ty=int]" at line 554 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"

1>

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration

1>  _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;

1>                             ^

1>          detected during:

1>            instantiation of "const bool std::_Is_iterator_v [with _Ty=__wchar_t *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"

1>            instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=__wchar_t, _Ty=int]" at line 600 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"

Any help is very appreciated. 

I downloaded and built the latest version of the intel c/c++ compilers yesterday and have been trying to do some simple random number generation examples, but keep getting the compile error: 

icpc test.cpp -o test -lmkl_rt
>> test.cpp(40): error: identifier "VSL_METHOD_DGAUSSIAN_ICDF" is undefined
>>    errcode = vdRngGaussian( METHOD, stream, N, A, a, sigma );

My example code is given below. If I uncomment out the line redefining method to be 2, the constant from mkl_vsl_defines.h, the code compiles and runs as expected.

Does anybody know why this could be happening? And if in the meantime, is it possible to add a dynamically linked library to workaround not finding these constants.

#include <mkl.h> 
#include <iostream>
#define SEED 0
#define BRNG VSL_BRNG_MCG31
#define METHOD VSL_METHOD_DGAUSSIAN_ICDF
//#define METHOD 2

using namespace std;

int main(int argc, char **argv) { 
    const int N = 1000;
    double A[N] __attribute__((aligned(64))); 
    int status; 
    double a = 0, sigma = 1.0;
    
    VSLStreamStatePtr stream;
    int errcode;
    errcode = vslNewStream( &stream, BRNG, SEED );
    errcode = vdRngGaussian( METHOD, stream, N, A, a, sigma );
    errcode = vslDeleteStream( &stream );
    cout << errcode;

    return 0; 
} 

Dear Intel Experts,

I describe here an issue relative to control on math lib to be used by an application under Linux.

Situation:

1. When a compiled fortran code is executed, the computation time is T

2. When this same fortran code is transformed as a dynamic lib of a C++ application, the execution is 5*T.

It was identified that cos() calls in the fortran code were responsible for that performance downgrade:

in configuration 1, it is cos() of lib libimf.so ​that is called.

In configuration 2, is is cos() of lib libm.so.6 that is called

How to keep control on Library to be used in configuration 2? I make you note that there is neither #include <cmath> nor #include <mathimf>  in the C++ code.

Thanks for your help

Best regards,

Gael Couturier

ESI-Group

Hello everyone,

I am a doctoral student and I am working with ASPEN PLUS V10. Now I have to use an Intel Fortran Compiler and link it with the ASPEN PLUS V10 for a custom User model operation. Can you please help me and tell which version of the Intel Fortran Compiler is compatible?

Thanks a lot

I have a code example which originates from llvm source code but modified to clearly provide the issue.

It compiles fine with clang but fails with icl. Here's the code:

#include <type_traits>

template <typename E, typename Enable = void>
struct is_valid : std::false_type {};

template <typename E>
struct is_valid<E, typename std::enable_if<sizeof(E::EnumMember) >= 0>::type> : std::true_type {};

template <typename E, typename = typename std::enable_if<is_valid<E>::value>::type>
void function(const E &myEnum) {
  return;
}

enum MyEnum {
  EnumMember = 0
};

int main() {
  MyEnum myEnum;
  function(myEnum);
}

Intel Compiler XE 2018, Windows

I'm wondering why the following doesn't produce an error:

$ icc -mavx512f -Werror test.c && echo ok
icc: command line warning #10159: invalid argument for option '-m'
ok

This is with version 2018.1 on linux.

I installed Intel Parallel studio and before that the Microsoft Visual Studio.

When I try to use ifort from command line, I get the error

error: can't open file moduls.obj for write

I have tried changing all kinds of permissions, but no success. Did anyone also face similar problem ?

Dear Experts,

I have recently downloaded and installed parallel_studio_xe_2018_update1_cluster_edition for a single user on my linux environment (Debian 9.1). The installation was successful however when i try to set variables in the command line with:

 $HOME/intel/bin/iccvars.sh intel64

I get the following error:

Syntax: source daalvars.sh <arch>
Where <arch> is one of:
  ia32      - setup environment for IA-32 architecture
  intel64   - setup environment for Intel(R) 64 architecture

If the arguments to the sourced script are ignored (consult docs for
your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE or DAALVARS_ARCHITECTURE to pass
<arch> to the script.

ERROR: Architecture is not defined. Accepted values: ia32, intel64
ERROR: Architecture is not defined. Accepted values: ia32, intel64

ERROR: architecture is not defined. Accepted values: ia32, intel64

Syntax:
  source mklvars.sh <arch> [MKL_interface] [mod]

   <arch> must be one of the following
       ia32         : Setup for IA-32 architecture
       intel64      : Setup for Intel(R) 64 architecture

   mod (optional) - set path to Intel(R) MKL F95 modules

   MKL_interface (optional) - Intel(R) MKL programming interface for intel64
                              Not applicable without mod
       lp64         : 4 bytes integer (default)
       ilp64        : 8 bytes integer

If the arguments to the sourced script are ignored (consult docs for
your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE or MKLVARS_ARCHITECTURE to pass
<arch> to the script, MKLVARS_INTERFACE to pass <MKL_interface> and
MKLVARS_MOD to pass <mod>

ERROR: architecture is not defined. Accepted values: ia32, intel64
Syntax: ippvars.sh <arch> [-arch <arch>] [-platform <platform>]

  <arch> must be one of the following:
      ia32           : Set up for IA-32 target.
      intel64        : Set up for Intel(R)64 target.
  <platform> must be of the following:
      linux          : Set to Linux target.
      mac            : Set to Mac target.
      android        : Set to Android target.

If the arguments to the sourced script are ignored (consult docs
for your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE to pass <arch> to the script
and COMPILERVARS_PLATFORM to pass <platform>
/home/animeshs/intel/bin/iccvars.sh: 42: [: =: unexpected operator
/home/animeshs/intel/bin/iccvars.sh: 50: [: =: unexpected operator
/home/animeshs/intel/bin/iccvars.sh: 159: [: =: unexpected operator
/home/animeshs/intel/bin/iccvars.sh: 171: [: =: unexpected operator

Kindly help me know how to proceed?

Best regards,

Ani

Hi All,

Just wondering if anyone using ICC18 has successfully upgraded VS2017 to 15.6.x without issue? I've experienced an unusually high number of failure cases with the Intel compiler moving from one point-release of VS2017 to another. Hoping not to shoot myself in the foot this time :)

J

The ability to set a Intel  "Base Platform Toolset" older than the latest version seems to have got broken/lost with the Visual Studio 2017 integration in ICC 2017 Update 4.It only shows v141 and v141_xp (v141 is the VS 2017 toolset)

This seems to be a Visual Studio 2017 integration issue, if I open the same project in VS 2015, the Intel "Base Platform Toolset" shows a full list of possible options back to the oldest version of VS installed on my computer.

This is a very annoying problem as one of the great features of Visual Studio (2017) is the ability to non-destructively open older projects and build them using the older toolsets. This is now broken if the project is an Intel Compiler project.

I am using Intel Parallel Studio 18 with Latest Visual Studio 2017(15.6.2) version
I am trying to use std::variant but I couldn't compile and there is no compiler option to set standard c++ version to latest.
Here is some images:

Please help on this matter. I recently update Visual Studio 2017 to latest version and  Intel Parallel Studio Xe 2018 to update 1.
I disable C++11 support and added /Qstd=c++17 and -std=c++17 compiler options in visual studio under C/C++ -> CommandLine
,but issue still persist.
https://software.intel.com/en-us/articles/c17-features-supported-by-intel-c-compiler

• Also If you someone can mentioned how to enable latest C11 features too.. it;s really appreciated