Hi!
I've been working on a library for HPC. So, I have enabled O2 and Qipo flags.
Compiling my library in Visual Studio using icc 18.0 I got this message:
ipo-2: : warning #11031: disabling user-directed function packaging (COMDATs)
Do you have any idea why this happen?
Hello,
I have just installed 2019 version 4 of Intel® Parallel Studio XE Composer Edition for C++ macOS. I am trying to build a program (Szip 2.1.1) and have the following issue
conftest.c(11): catastrophic error: cannot open source file "stdio.h"
#include <stdio.h>
^
compilation aborted for conftest.c (code 4)
configure:3543: $? = 4
configure:3550: ./conftest
./configure: line 3552: ./conftest: No such file or directory
configure:3554: $? = 127
configure:3561: error: in `/Users/brianturnquist/Downloads/szip-2.1.1':
configure:3563: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.It appears the installer has not included the header files that come with CommandLineTools. However, I thought the initialization with
source /opt/intel/bin/compilervars.sh intel64
would cover that issue. How do I fix this and make sure I am linking to all necessary header files?
Thank you. Also, the entire config.log is posted below.
Brian
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by SZIP configure 2.1.1, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --prefix=/usr/local/Intel-compiled/szip-2.1.1 --enable-shared --enable-static
## --------- ##
## Platform. ##
## --------- ##
hostname = Brians-MacBook-Pro-2.local
uname -m = x86_64
uname -r = 18.7.0
uname -s = Darwin
uname -v = Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
/usr/bin/uname -p = i386
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = Mach kernel version:
Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
Kernel configured for up to 8 processors.
4 processors are physically available.
8 processors are logically available.
Processor type: x86_64h (Intel x86-64h Haswell)
Processors active: 0 1 2 3 4 5 6 7
Primary memory available: 16.00 gigabytes
Default processor set: 414 tasks, 1751 threads, 8 processors
Load average: 1.29, Mach factor: 6.69
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /Library/Frameworks/Python.framework/Versions/3.7/bin
PATH: /usr/local/openmpi-4.0.1/bin
PATH: /Library/Frameworks/Python.framework/Versions/3.6/bin
PATH: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
PATH: /usr/bin
PATH: /opt/local/sbin
PATH: /opt/local/bin
PATH: /usr/local/openmpi-4.0.1/bin
PATH: /bin
PATH: /usr/bin
PATH: /usr/local/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2330: checking for a BSD-compatible install
configure:2398: result: /usr/bin/install -c
configure:2409: checking whether build environment is sane
configure:2464: result: yes
configure:2615: checking for a thread-safe mkdir -p
configure:2654: result: bin/install-sh -c -d
configure:2661: checking for gawk
configure:2691: result: no
configure:2661: checking for mawk
configure:2691: result: no
configure:2661: checking for nawk
configure:2691: result: no
configure:2661: checking for awk
configure:2677: found /usr/bin/awk
configure:2688: result: awk
configure:2699: checking whether make sets $(MAKE)
configure:2721: result: yes
configure:2750: checking whether make supports nested variables
configure:2767: result: yes
configure:2894: checking whether to enable maintainer-specific portions of Makefiles
configure:2903: result: no
configure:2921: checking build system type
configure:2935: result: x86_64-apple-darwin18.7.0
configure:2955: checking host system type
configure:2968: result: x86_64-apple-darwin18.7.0
configure:3030: checking for config x86_64-apple-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config x86_64-apple-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config apple-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config apple-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config x86_64-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config x86_64-darwin18.7.0
configure:3038: result: no
configure:3030: checking for config x86_64-apple
configure:3038: result: no
configure:3030: checking for config darwin18.7.0
configure:3038: result: no
configure:3030: checking for config darwin18.7.0
configure:3038: result: no
configure:3030: checking for config apple
configure:3038: result: no
configure:3030: checking for config x86_64
configure:3038: result: no
configure:3095: checking for gcc
configure:3122: result: icc-19.0.4.233
configure:3351: checking for C compiler version
configure:3360: icc-19.0.4.233 --version >&5
icc-19_0_4_233 (ICC) 19.0.4.233 20190416
Copyright (C) 1985-2019 Intel Corporation. All rights reserved.
configure:3371: $? = 0
configure:3360: icc-19.0.4.233 -v >&5
icc-19.0.4.233 version 19.0.4.233 (gcc version 4.9.0 compatibility)
configure:3371: $? = 0
configure:3360: icc-19.0.4.233 -V >&5
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.4.233 Build 20190416
Copyright (C) 1985-2019 Intel Corporation. All rights reserved.
configure:3371: $? = 0
configure:3360: icc-19.0.4.233 -qversion >&5
icc-19_0_4_233: command line warning #10006: ignoring unknown option '-qversion'
icc-19_0_4_233: command line error: no files specified; for help type "icc-19_0_4_233 -help"
configure:3371: $? = 1
configure:3391: checking whether the C compiler works
configure:3413: icc-19.0.4.233 conftest.c >&5
configure:3417: $? = 0
configure:3465: result: yes
configure:3468: checking for C compiler default output file name
configure:3470: result: a.out
configure:3476: checking for suffix of executables
configure:3483: icc-19.0.4.233 -o conftest conftest.c >&5
configure:3487: $? = 0
configure:3509: result:
configure:3531: checking whether we are cross compiling
configure:3539: icc-19.0.4.233 -o conftest conftest.c >&5
conftest.c(11): catastrophic error: cannot open source file "stdio.h"
#include <stdio.h>
^
compilation aborted for conftest.c (code 4)
configure:3543: $? = 4
configure:3550: ./conftest
./configure: line 3552: ./conftest: No such file or directory
configure:3554: $? = 127
configure:3561: error: in `/Users/brianturnquist/Downloads/szip-2.1.1':
configure:3563: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_build=x86_64-apple-darwin18.7.0
ac_cv_env_CC_set=set
ac_cv_env_CC_value=icc-19.0.4.233
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_LT_SYS_LIBRARY_PATH_set=
ac_cv_env_LT_SYS_LIBRARY_PATH_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-apple-darwin18.7.0
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=awk
ac_cv_prog_ac_ct_CC=icc-19.0.4.233
ac_cv_prog_make_make_set=yes
am_cv_make_support_nested_variables=yes
## ----------------- ##
## Output variables. ##
## ----------------- ##
ACLOCAL='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/missing aclocal-1.15'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='$${TAR-tar}'
AM_BACKSLASH='\'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
AM_DEFAULT_VERBOSITY='1'
AM_V='$(V)'
AR=''
AUTOCONF='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/missing autoconf'
AUTOHEADER='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/missing autoheader'
AUTOMAKE='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/missing automake-1.15'
AWK='awk'
CC='icc-19.0.4.233'
CCDEPMODE=''
CFLAGS=''
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
DLLTOOL=''
DSYMUTIL=''
DUMPBIN=''
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
EGREP=''
EXEEXT=''
FGREP=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIPO=''
LN_S=''
LTLIBOBJS=''
LT_SYS_LIBRARY_PATH=''
MAINT='#'
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE='#'
MAKEINFO='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/missing makeinfo'
MANIFEST_TOOL=''
MKDIR_P='bin/install-sh -c -d'
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OTOOL64=''
OTOOL=''
PACKAGE='szip'
PACKAGE_BUGREPORT='help@hdfgroup.org'
PACKAGE_NAME='SZIP'
PACKAGE_STRING='SZIP 2.1.1'
PACKAGE_TARNAME='szip'
PACKAGE_URL=''
PACKAGE_VERSION='2.1.1'
PATH_SEPARATOR=':'
RANLIB=''
SED=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
VERSION='2.1.1'
ac_ct_AR=''
ac_ct_CC='icc-19.0.4.233'
ac_ct_DUMPBIN=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__nodep=''
am__quote=''
am__tar='$${TAR-tar} chof - "$$tardir"'
am__untar='$${TAR-tar} xf -'
bindir='${exec_prefix}/bin'
build='x86_64-apple-darwin18.7.0'
build_alias=''
build_cpu='x86_64'
build_os='darwin18.7.0'
build_vendor='apple'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='x86_64-apple-darwin18.7.0'
host_alias=''
host_cpu='x86_64'
host_os='darwin18.7.0'
host_vendor='apple'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='${SHELL} /Users/brianturnquist/Downloads/szip-2.1.1/bin/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='$(MKDIR_P)'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr/local/Intel-compiled/szip-2.1.1'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## ----------- ##
## confdefs.h. ##
## ----------- ##
/* confdefs.h */
#define PACKAGE_NAME "SZIP"
#define PACKAGE_TARNAME "szip"
#define PACKAGE_VERSION "2.1.1"
#define PACKAGE_STRING "SZIP 2.1.1"
#define PACKAGE_BUGREPORT "help@hdfgroup.org"
#define PACKAGE_URL ""
#define PACKAGE "szip"
#define VERSION "2.1.1"
configure: exit 1
Hi there,
Just to let you know, I've been working with the author of an upcoming standard that will be in C++20. The library is {fmt/fmtlib}. Unfortunately, this library worked with all major compilers, but it threw a compile error with the Intel Compiler v19.0.
Traced the problem to the Intel Compiler v19.0 not accepting the [[deprecated]] element on some elements that the MSVC compiler accepts it on. All other compilers (including MSVC) accept their equivalent of [[deprecated]] on this element (some in different form, e.g. GCC).
See: https://github.com/fmtlib/fmt/issues/1273
To reproduce the issue:
1. Check out v6.0.0 of said library from: https://github.com/fmtlib/fmt/tree/6.0.0
2. Compile it, it will throw four errors, as the [[deprecated]] tag is accepted by MSVC on some elements, but rejected by the Intel Compiler.
3. Check out master, with the fix 744302a: https://github.com/fmtlib/fmt/commit/744302add085f30120c57f73cddbcb826cc...
4. Compile, it will work perfectly under both MSVC and Intel.
Thank you.
p.s. I emailed this issue to parallel.studio.support@intel.com, as per the instructions, but received a wall of silence in response. So I am posting to this forum in the hope that it will reach the relevant people.
The Intel Compiler v19.0 has a bug where it fails to link in pre-compiled header mode, unless Interprocedural Optimization: Multi-File (/Qipo) is switched on. This bug is not present in MSVC.
https://github.com/fmtlib/fmt/issues/1295
If you wish, I can provide a sample project if you cannot reproduce the issue.
VS2017 just crashed.
What I did:
- Right clicked on solution
- Selected "Memory Error Analysis / Detect Leaks".
- Bang.
- VS2017 GUI disappeared, but the process was still there in task manager.
See attached crash report. If the report is as comprehensive as I hope, it should have all the diagnostics info you need, including all the versions of whatever I was running on my system.
BTW, the auto-send of email didn't work. So I had to write this email to you.
| Attachment | Size |
|---|---|
Download crash_info.txt | 343.47 KB |
Hi,
I encountered below error while I was trying to build my exe 'mktrack'
hidden symbol `_PGOPTI_Prof_Div_64_VP' in /home/gaurav/libs/lib64/libipgo.a(pgopti.o) is referenced by DSO
Even though the symbol is present in libipgo.a and not hidden when I checked:
bash-4.1$ nm libipgo.a | grep _PGOPTI_Prof_Div_64_VP 0000000000000ea0 T _PGOPTI_Prof_Div_64_VP
My library name is libovp20.lib and I am encountering err while linking my library with executable 'mktrack'
libovp20.so was created with following command:
gcc -o /home/gaurav/libs/lib64/libovp20.so -shared -z noexecstack -Wl,--disable-new-dtags -L/home/gaurav/libs/lib64/ --whole-archive /home/gaurav/libs/lib64/libovp20.a -Wl,--no-whole-archive <other_libs> -lirc -lipgo bash-4.1$ nm libovp20.so | grep _PGOPTI_Prof_Div_64_VP 0000000000597650 t _PGOPTI_Prof_Div_64_VP
I am encountering error while trying to execute below command:
/usr/local/packages/icc_remote/12.0.5.226/bin/icc -o /home/gaurav/bin/mktrack -m64 -z noexecstack -Wl,--disable-new-dtags -L/home/gaurav/libs/lib64/ -lovp20 -lrt -lresolv -ldl -lm
Please help. I am stuck
Thanks,
-Gaurav
P.S.
libipgo.a placed at the location: /home/gaurav/libs/lib64/ is same as placed in /usr/local/packages/icc_remote/12.0.5.226/lib/intel64/
Hi There,
I have an old license.
When I click on the license url, I can get to the page with the according list. I follow the download link
For the latest version I can see the message:
The support period for your license has expired. To download this product update, you will need to purchase renewal licenses to extend your support from your expiration date () to the build date of this product update (). Note that support for new renewal licenses will begin on .
Of course, this is the expectation, but when I click an earlier version (2018 update 3) that does not display this message:
With Serial Number the output is:
--------------------------------------------------------------------------------
Please type a selection or press "Enter" to accept default choice [1]:
Please type your serial number (the format is XXXX-XXXXXXXX):
--------------------------------------------------------------------------------
Checking serial number...
--------------------------------------------------------------------------------
Product support for your Intel(R) Parallel Studio XE 2018 Update 3 Composer
Edition for C++ Linux* license has expired. Please refer to
https://software.intel.com/en-us/faq/purchasing-renewing-upgrading#suppo...
ation for more information.
--------------------------------------------------------------------------------
With License file
--------------------------------------------------------------------------------
Please type a selection or press "Enter" to accept default choice [1]: 1
Please type the full path to your license file(s):
/path/to/lic
The license file(s) you provided is not valid for this product.
--------------------------------------------------------------------------------
Is this expected (and why) or is there a problem somewhere ?
Thanks in advance for your feedback !
Ludo
I am using
icpc (ICC) 19.0.4.235 20190416
Is there anyway I can disable error #858?
Hi
I trying to compile in intel sytem stuido 19 iam facing the catastropic error in one header file. how to solve this
With the latest C++ compiler 2019.5.281, I get a linkage error upon compiling this simple program,
#include <iostream>
int main () {
std::clog << "C++ version "<< __cplusplus << std::endl;
return 0;
}
> icpc -std=c++11 test.cc
Undefined symbols for architecture x86_64:
"__ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1Emc", referenced from:
_main in icpcjsInXA.o
ld: symbol(s) not found for architecture x86_64
Mac OSX 10.14.6
icpc (ICC) 19.0.5.281 20190816
/opt/intel/system_studio_2019/bin/icpc -rdynamic -std=c++17 -g -fpic -fno-strict-aliasing -rdynamic -I./include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/cbase/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/msg/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/utl/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/sock/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/utils/include -IopensslMarker -Wreturn-type -Wno-deprecated -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized -wd858 -Werror -O2 -DPLATFORM_AS3 -DPLATFORM_AS4 -DPLATFORM_AS5 -DPLATFORM_AS5_64 -DPLATFORM_AS6 -DPLATFORM_AS6_64 -DPLATFORM_AS7 -DUSE_FLEX_ONE_API -DFOR_UNIX -DFOR_LINUX -DFOR_DONGLE -D_GNU_SOURCE -DUSE_NSS -DUSE_GTK -Dft_ext_h_ -D__STL_PTHREADS -DRMS_US_RELEASE -DUSEOLDDEPTHSYM -DUSELONGEXECTAGS -D_REENTRANT -c CHtmlConn.cpp -o AS7/CHtmlConn.o
CRemoteFile.cpp:590: warning: Possible null pointer dereference: output
CRemoteFile.cpp:597: error: Object pointed by an 'auto_ptr' is destroyed using operator 'delete'. You should not use 'auto_ptr' for pointers obtained with operator 'new[]'.
This is my old lib file and I am not supposed to change the code to get rid of auto_ptr. Is there any way to keep auto_ptr and continue? Or should I use C++14 for example.
Dear Intel community,
I am trying to compile OpenMPI 2.1.2 with Intel parallel studio 2018 update1 as follows:
source /soft/intel_parallel_studio_xe_2018_update1/bin/compilervars.sh -arch intel64 -platform linux
CC=icc CXX=icpc FC=ifort LDFLAGS="-Wc,-static-intel" CFLAGS="-D_Float128=__float128" ./configure --prefix=/home/CC_DIPC/OPENMPI-intel
Configure fails with the following message:
============================================================================
== Compiler and preprocessor tests
============================================================================
*** C compiler and preprocessor
checking for gcc... (cached) icc
checking whether we are using the GNU C compiler... (cached) yes
checking whether icc accepts -g... (cached) yes
checking for icc option to accept ISO C89... (cached) none needed
checking whether icc understands -c and -o together... (cached) yes
checking for icc option to accept ISO C99... unsupported
configure: WARNING: Open MPI requires a C99 compiler
configure: error: Aborting.
I have also tried the -std=c99 option with no success.
According to the forum (https://software.intel.com/en-us/forums/intel-c-compiler/topic/791108) our version of binutils and OS could not be supported by Intel 2018 (OS: Ubuntu 8.04.2 LTS, binutils: 2.30-21ubuntu1~18.04.2). In fact, having a look at the Release Notes, it is clear they are not.
Has somebody succeeded to install OpenMPI with Intel 2018 update 1?
Any help will be appreciated.
Regards,
Belén
Hello,
I am seeing some surprising performance with OpenMP task support with Intel C++ 19.0 Update 5 that I don't get with GCC 9.2. In the demo app below I expect the in-loop taskwait or the alternative taskgroup to cause it to have a single thread load and run about the same speed as the serial application. GCC gives this but Intel C++ gives 100% CPU load and a 1.8x slowdown. More importantly for our real application, we get the same slowdowns instead of speedups using a set of tasks within a taskgroup or followed by a taskwait.
// Demo for Intel C++ 19.0 Update 5 OpenMP performance issues
// Serial speed of Intel C++ is ~3.3x slower than GCC 9.2.0
// With only taskwait after while loop on quad-core Haswell CPU:
// Intel C++: 2.8x speedup
// GCC: 3.5x speedup
// Both use 100% CPU as expected
// With taskwait in while loop:
// Intel C++: 100% CPU usage and give 1.8x slowdown
// GCC: 1 CPU/thread used and no slowdown as expected
// This taskwait is not needed here but the same issue is seen in real application with multiple tasks followed by a taskwait
// Same behavior seen with a taskgroup around the one task instead of this taskwait
// icl /Qstd=c++11 /DNOMINMAX /DWIN32_LEAN_AND_MEAN /DNDEBUG /Qopenmp /O3
#include <atomic>
#include <cstddef>
#include <iostream>
#include <omp.h>
int
main()
{
#pragma omp parallel
{
#pragma omp single
{
bool run( true );
std::size_t i( 0 );
std::atomic_size_t sum( 0u );
double const wall_time_beg( omp_get_wtime() );
while ( run ) {
// #pragma omp taskgroup // Same behavior as the in-loop taskwait
{
#pragma omp task shared(sum)
{
std::size_t loc( 0u );
for ( std::size_t k = 0u; k < 2000000000u; ++k ) loc += k/2;
sum += loc;
} // omp task
} // omp taskgroup
#pragma omp taskwait // GCC gives expected 1 CPU/thread usage: Intel C++ gives 100% CPU and 1.8x slowdown!
if ( ++i > 50u ) run = false;
}
#pragma omp taskwait
std::cout << "sum = "<< sum << ''<< omp_get_wtime() - wall_time_beg << ''<< i << std::endl;
} // omp single
} // omp parallel
}
Can anyone shed light on this? Looks like a buggy task implementation but maybe there is more to it.
Thanks,
Stuart
My class :
template <typename Key, typename T, typename CharClass = Printable>
class TMap
{
//... Dummy Declaration, allow only pointer specialization ...//
};
template <typename Key, typename T, typename CharClass>
class TMap <Key*,T*,CharClass>
{
private:
typedef TNode<T,CharClass> Node;
......
public:
class iterator
{
private:
size_t m_Indx;
const TMap* m_pTMap;
public:
iterator()
{
m_pTMap = NULL;
m_Indx = 0;
}
......
}
friend class TMap <Key*,T*,CharClass>::iterator;
TMap()
{
m_NodePool.Init();
m_NodePool.SetDPoolName("FtMap_DPOOL");
}
}
But when I compile it with -std=c++11, I got this error:
/opt/intel/system_studio_2019/bin/icpc -rdynamic -std=c++11 -g -fpic -fno-strict-aliasing -rdynamic -I./include -I../include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/AS7 -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/cbase/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/mktutil/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/symbase/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/depth/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/csock/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/msg/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/utl/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/utils/include -I/fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/svrutils/include -Wreturn-type -Wno-deprecated -Wall -Wno-maybe-uninitialized -wd858 -Werror -O2 -DPLATFORM_AS3 -DPLATFORM_AS4 -DPLATFORM_AS5 -DPLATFORM_AS5_64 -DPLATFORM_AS6 -DPLATFORM_AS6_64 -DPLATFORM_AS7 -DUSE_FLEX_ONE_API -DFOR_UNIX -DFOR_LINUX -DFOR_DONGLE -D_GNU_SOURCE -DUSE_NSS -DUSE_GTK -Dft_ext_h_ -D__STL_PTHREADS -DRMS_US_RELEASE -DUSEOLDDEPTHSYM -DUSELONGEXECTAGS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D__STL_PTHREADS -c MXDataFeed.cpp -o AS7/MXDataFeed.o In file included from ./include/MXCache.h(10), from MXCache.cpp(4): /fs02/home/jenkins/workspace/Rel-15-1-54_INTEL/utils/include/FtMap.h(292): error #135: class template "FtMap::TMap<Key *, T *, CharClass>" has no member "iterator" friend class TMap <Key*,T*,CharClass>::iterator; ^
Hello,
I'm using Intel Parallel Studio XE 2019 with the latest updates.
I have an application that uses tbb, mkl and openmp. If I build this application in release mode, I can run it from within visual studio as well as from powershell (and the VS command line).
However, if I build it in debug mode, it runs fine from within VS but not on the command prompt. I get no output at all. Any ideas what I may be missing?
Things that I've tried:
Any idea what is going on? Are there any tools / commands I can use to get more information?
A related question:
I find tbb.dll, tbbmalloc.dll and tbb_preview.dll, but not their debug versions. When I try to run this application in Intel Advisor, I get a message saying "tbb_debug.lib" not found. Is my installation missing something?
Many thanks,
Shrirang
I want to get clarified about the compiler limits of icc 19.0.
What I specifically want to get informed from the compiler limits is "Nesting levels of compound statements, iteration control structures, and selection control structures" in ICC.
In MSVC 2019, it is specified that "generally 100-110" is a recommended upper bound.
In ISO C++11 standard, it says "256" as a minimal upper bound.
There are compiler limits for MSVC and Intel Fortran Compiler specifications available at :
1. MSVC: https://docs.microsoft.com/ko-kr/cpp/cpp/compiler-limits?view=vs-2019
2. Intel Fortran Compiler: https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-compiler-limits
Likewise, is there any specification for Intel C++ Compiler?
Otherwise, does the ICC conforms to the ISO C++98 standard as described in the website?
Thank you.
Hello, I have a project that compiles both in Ubuntu and g++ 7.4 and Visual Studio 2019. However, when I use Visual Studio I am stuck with a really old OpenMP version (200203). I am trying the intel c++ compiler to see if using it I can compile the project using a newer version of OpenMP (5.0). My project is CMake-based and I configure it using the following command to compile using intel c++ compiler 19.0 in visual studio:
cmake [Various options to locate all libraries] .. -T "Intel C++ Compiler 19.0"
and then compile using
cmake --build . --config Release
which produces
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\include\pplwin.h(93): error: access violation [PATH TO MY PROJECT]
static ::std::shared_ptr<scheduler_interface> * _S_scheduler_address;
^Any ideas on what might be happening? It's my first time getting an access violation error during compilation.
The same error happens with Debug builds.
I am trying to use a library that makes use of the string_view header. This is a header introduced in C++17. However, it seems that even with the -std=c++17 the c++ compiler gives a "catastrophic error" message, saying that the header is missing. This is with Intel 19.3 compiler series.
Is there some replacement for this, or am I missing more compiler flags? Also, in general, what is the time-line for full C++17 compatibility, including of the standard library?
Hi all!
Although this code has many features that are strictly forbidden by the C standard I think most of them are supported as Intel extensions.
#include <stdlib.h>
#include <stdio.h>
#if defined(RANK)
#define IRANK RANK
#else
#define IRANK 0
#endif
#define MSTRUCT(r) struct{int dim[r];}
int main(int argc, char **argv){
int n = IRANK;
MSTRUCT(n) s;
printf("%zu, %zu\n", sizeof(s), sizeof(MSTRUCT(n)));
return EXIT_SUCCESS;
}
I would expect the code to print two identical numbers.
Using -ftrapuv changes the value printed, -O0 had the same effect on a more complicated variation.
Thank you very much.
Best regards,
José Rui
Hello,
I got a strange error while using weak_ptr built with Intel Parallel Studio XE C++ 2019 update 4 and 5 embedded in VS2019.
Here is a sample of the code I use to reproduce the bug:
#include <iostream>
#include <memory>
using namespace std;
int main( int argc, char* argv[] )
{
shared_ptr<int> sp = make_shared<int>( 42 );
cout << *sp << endl;
weak_ptr<int> wp = sp;
cout << *wp.lock() << endl;
wp.reset();
cout << *sp << endl;
return 0;
}
The first cout outputs "42" from the shared_ptr as expected;
the second cout outputs "42" from the weak_ptr as expected;
the third cout outputs 0xDDDDDDDD (or decimal equivalent...) rather than "42" showing that the shared_ptr was corrupted by the weak_ptr reset().
I observed this "phenomenon" in 64 bit/Debug only. It works fine in Release and in either Debug or Release in 32 bit. I also noticed that it worked correctly with our old Intel 2018 C++ compiler.
Does someone observe the same thing?