I'm using Intel Parallel Studio XE 2018 Update 5 Cluster Edition in MS Visual Studio Pro 2015 Update 3 (Ver.14.0.25420.01) under Windows 7.
Here I attached mpi sample code but failed to build with several lnk2019 errors.
Please let me know how to resolve this.
| Attachment | Size |
|---|---|
Download impi_sample.zip | 181.53 KB |
Hi,
Does anyone here able to compile or develop, at least HelloWorld, for EFI shell app in C++?
I have no issues when written in C code, but our project need to be in C++.
--Henry
[Makefile]
GCC = /usr/local/bin/g++
CC = /opt/intel/bin/icpc
INC = -I/usr/boost_1_68_0
COMPILE_OPTION = -std=c++1y
all:; $(CC) $(INC) $(COMPILE_OPTION) main.cpp
[main.cpp]
#include <iostream>
#include <boost/unordered_map.hpp>
using namespace std;
int main()
{
cout<<"hello!"<<endl;
return 0;
}
I'm using intel c++ compiler 16.0.1 which is in parallel studio 2016 update 1 package.
If the option -std=c++11 exists, the compile is failed with error as follows:
boost/unordered/unordered_map.hpp(2201): error: exception specification is incompatible with that of previous function "boost::unordered::unordered_multimap<K, T, H, P, A>::swap" (declared at line 1317)
BOOST_NOEXCEPT_IF(value_allocator_traits::is_always_equal::value&&boost::is_nothrow_swappable<H>::value&&boost::is_nothrow_swappable<P>::value)
If the option -std=c++11 is omitted, the compile succeeds. I think it might be a compile bug because g++(4.8.2) doesn't fail the compile.
The first of all, the license is expired. So, I cannot compile the test code with newer version of intel compiler.
Can I know whether this circumstance is bug or not?
Dear License support team,
Our team try to install Intel Parallel Studio XE Cluster edition success with trial key. but when try to install purchase license key it can't not install license as attached image.
Please help me verify what's issue?
BR,
Jumpol T.
See This example on CompilerExplorer Function foo() and bar() generate the same few assembly instructions with GCC or Clang, but with ICPC (19.0.0), the function baz() is much larger and more complex. In particular, it has loops. icpc -O2 -std=c++17 -Wall -Werror #include <algorithm> int foo(int a, int b, int c) { return std::min(std::min(a,b), c); // this is correctly optimized } int bar(int a, int b, int c) { return std::min({a,b,c}); // this should be optmized down to what's in foo() } int main(int, char **) { return foo(1,2,3); }
foo(int, int, int):
cmp esi, edi #4.12
cmovl edi, esi #4.12
cmp edi, edx #4.12
cmovl edx, edi #4.12
mov eax, edx #4.12
ret #4.12
bar(int, int, int):
mov DWORD PTR [-24+rsp], edi #8.22
lea rcx, QWORD PTR [-12+rsp] #79.37
mov DWORD PTR [-8+rcx], esi #8.24
lea rax, QWORD PTR [-24+rsp] #5619.14
mov DWORD PTR [8+rax], edx #8.26
cmp rax, rcx #5591.22
je ..B3.7 # Prob 5% #5591.22
lea rdx, QWORD PTR [-20+rsp] #5588.5
cmp rdx, rcx #5594.27
je ..B3.7 # Prob 50% #5594.27
xor edx, edx #5594.7
jmp ..B3.9 # Prob 100% #5594.7
..B3.4: # Preds ..B3.12
cmp rcx, 2 #5594.7
jae ..B3.7 # Prob 1% #5594.7
lea rcx, QWORD PTR [-20+rsp+rdx*8] #43.17
mov edx, DWORD PTR [rcx] #43.17
cmp edx, DWORD PTR [rax] #5596.4
cmovl rax, rcx #5596.4
..B3.7: # Preds ..B3.1 ..B3.2 ..B3.4 ..B3.5
mov eax, DWORD PTR [rax] #8.12
ret #8.12
..B3.9: # Preds ..B3.3 ..B3.11
mov ecx, DWORD PTR [rax] #43.26
cmp ecx, DWORD PTR [-20+rsp+rdx*8] #43.26
jle ..B3.11 # Prob 50% #43.26
lea rax, QWORD PTR [-20+rsp+rdx*8] #5594.16
mov ecx, DWORD PTR [rax] #43.26
..B3.11: # Preds ..B3.10 ..B3.9
cmp ecx, DWORD PTR [-16+rsp+rdx*8] #5596.4
lea rsi, QWORD PTR [-16+rsp+rdx*8] #5594.16
cmovg rax, rsi #5596.4
inc rdx #5594.7
cmp rdx, 1 #5594.7
jb ..B3.9 # Prob 64% #5594.7
lea rcx, QWORD PTR [rdx+rdx] #5595.2
jmp ..B3.4 # Prob 100% #5595.2
Hello,
I'm sorry if this is not the correct forum for this issue but I couldn't find another one that seemed to pertain to it. I've been using various versions of Parallel Studio XE for C/C++ development on Windows for several years using an academic floating license good for 3 seats. Each time I have to install a new version I waste more time and frustration than I've ever spent installing any other product just trying to stumble through what I view as the most convoluted and non-intuitive licensing procedure I've ever encountered. I believe the size of the licensing FAQ itself speaks for itself in this regard and I am obviously too dense to comprehend it. This is always a real humbling experience to say the least.
One of my computers recently crashed and when I tried to install a license on its replacement it kept telling me that the serial number was already in use, and when I tried to upload a license file it said it was not valid. I'll take a wild guess and assume that somehow all three of my seats are already in use, although I think I actually only used two. I haven't found a way to check this type of thing. At this point I'd simply like to wipe out all active seats and start over, but I can find no mention of how to do this. If I must actually uninstall the application to free a seat, how do I do it from a crashed computer?
I apologize for all the venting and I would appreciate some suggestions other than what I've already stumbled through in the FAQ.
Thanks,
Using the following command:
grep -F env.cfg <(strace -feopenat icpc 2>&1) <(strace -feopenat icc 2>&1)
I get
/proc/self/fd/11:[pid 17115] openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/.icpc_env.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
/proc/self/fd/15:[pid 17116] openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/.icc_env.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
What is this ".ic[p]c_env.cfg" file that is trying to be read? What can I put in it?
From `grep -A5 'icc"'<(strace -eopenat icc 2>&1)`
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/icc", O_RDONLY) = 3
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/mcpcom", O_RDONLY) = 3
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/mcpcom", O_RDONLY) = 3
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/as", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/profmerge", O_RDONLY) = 3
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/icc.cfg", O_RDONLY) = 3
...
Key line:
openat(AT_FDCWD, "/opt/intel/compilers_and_libraries_2019.1.144/linux/bin/intel64/as", O_RDONLY) = -1 ENOENT (No such file or directory)
Why is icc looking for `as` and what is it for?
Hi,
I'm a system integrator and supporting one particular customer.
I believe I installed intel parallel studio in 2014 on the customer's system.
Now, when I try to start icc, the following message is displayed.
Error: A license for CCompL could not be obtained
Your license has expired.
License file(s) used were (in this order):
1. Trusted Storage
** 2. /opt/intel/licenses/COM_L___CPDZ-XXXXXXXX.lic
** 3. /opt/intel/composer_xe_2013_sp1.0.080/Licenses
** 4. /root/intel/licenses
** 5. /Users/Shared/Library/Application Support/Intel/Licenses
** 6. /opt/intel/composer_xe_2013_sp1.0.080/bin/intel64/*.lic
Please visit http://software.intel.com/sites/support/ to obtain license renewal information.
This is not an evaluation license, and it should have been valid when I installed back then.
The date shown in the license file is 2015.0131, so it should be valid for parallel studio 2014.
Why does it expire?
I would appreciate if someone could help me solve this problem.
Best regards,
Hiroshi
I have an R package available here: https://github.com/jsilve24/mongrel/tree/develop
I have started linking this to MKL using following R makevars parameters:
PKG_CPPFLAGS = -I../inst/include/ -DMONGREL_USE_MKL PKG_CXXFLAGS = -I/opt/intel/compilers_and_libraries_2019.1.144/mac/mkl/include -qopenmp PKG_LIBS = -L/opt/intel/compilers_and_libraries_2019.1.144/mac/mkl/lib -Wl,-rpath,/opt/intel/compilers_and_libraries_2019.1.144/mac/mkl/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl
However whenever I add the -qopenmp flag as I do above everything compiles but R crashes whenever I try to run the program. This never happened when I was using Clang. I am now using icc (ICC) 19.0.1.144 20181018.
I don't know where to even begin debugging this problem. I would like to use my own omp pragmas but without that flag I don't believe I can (unless I am mistaken).
Thank you!
Justin
Hello all,
I have installed intel parallel studio successfully and when I type "icc -v", it shows:
icc version 18.0.2 (gcc version 4.8.5 compatibility)
and when I type "which icc", it shows:
/opt/intel/compilers_and_libraries_2018.2.199/linux/bin/intel64/icc
But when I tried to use icc to compile something "icc hello.c -o test.o", it is saying that I don't have icc.
icc: command not found
I will appreciate any help. Thanks.
I'm running into a very annoying compiler optimization issue that's causing crashes on older systems (CPU, OS). I'm just using an example here to demonstrate the issue:
switch (codepath)
{
case AVX:
__m256 bla = _mm256_setzero_ps();
*x = bla;
break;
case SSE2:
__m128 bla = _mm_setzero_ps();
*x = bla;
break;
default:
float bla = 0;
*x = bla;
break;
}
The problem is, that for some reason the compiler "thinks" that it's a good idea to move certain instructions outside of the switch() statement. So, in assembly code, it can do a _mm256_setzero_ps() before checking for CPU type - I'm guessing that it works for both the AVX and SSE2 case here because half of the register is shared. Also, in the SSE2 code, probably due to the fact that I'm also using AVX code in the same function, movps instructions are replaced by vmovps.
What I want:
In debug mode everything works as expected, and in release mode, it appears to work fine for 42 of the 44 places where I'm doing this. But those other two are causing crashes, and I obviously don't want to have code that might break on each new compiler version.
Using the dispatch-behavior doesn't really work because it doesn't appear to work for AMD, and I can't overrule it when I run the binary.
Using #if __AVX__ as was suggested elsewhere in this forum doesn't work either, because the #if is parsed once for the entire build (not per code path, and it evaluates to 0, cannot be changed during runtime and probably having multiple code paths won't work well for AMD either).
Hello,
I am trying to install the parallel studio in a mac pro (10.11) but I have an error in the very beginning.
After ./install.sh I got this (2019-up1)
./install.sh: line 557: 758 Segmentation fault: 11 "$pset_engine_binary" --tmp_dir "$user_tmp" --TEMP_FOLDER "$temp_folder" --download_dir "$download_tmp" $params $root_nonroot 2> /dev/null
I have tried with 2018, 2017, 2016 and 2015 but I always have the same error.
I searched on the forum but I didn't find the answer.
:-) Thanks!
Dear all,
the following code:
#include <iostream>
#include <unistd.h>
#include <pthread.h>
class Test {
public:
Test() : fDone(false) { }
~Test() {}
bool IsDone() const { return fDone; }
void SetDone() { fDone = true; }
private:
bool fDone;
};
void* run(void* data) {
// input data
Test* t = static_cast<Test*>(data);
// sleep for 1 second
usleep(1000*1000);
// thread is done
t->SetDone();
std::cout << t->IsDone() << std::endl;
std::cout << "Thread finished"<< std::endl;
return 0;
}
int main(int argc, char** argv) {
Test t;
pthread_t thread;
pthread_create(&thread, NULL, &run, &t);
while (!t.IsDone()) {
usleep(100*1000);
}
std::cout << "never reached"<< std::endl;
void* status;
pthread_join(thread, &status);
return 0;
}
Does not run as expected with Intel Compiler 2019, Update 1 on Linux x86_64. The loop in the main function never finishes, even though the auxiliary thread sets 't.IsDone()' to true after 1 second.
The code is compiled using:
icpc -O2 -g -fPIC -pthread -o bug bug.cc
The bug does not occur if compiled with -00 or -O1. It also doesn't occur when the loop is modified as follows:
while (!t.IsDone()) {
std::cout << "..."<< std::endl;
usleep(100*1000);
}The loop in question is actually translated by the compiler into this piece of assembly:
Dump of assembler code for function main: 0x0000000000401280 <+0>: push %rbp 0x0000000000401281 <+1>: mov %rsp,%rbp 0x0000000000401284 <+4>: and $0xffffffffffffff80,%rsp 0x0000000000401288 <+8>: sub $0x80,%rsp 0x000000000040128f <+15>: xor %esi,%esi 0x0000000000401291 <+17>: mov $0x3,%edi 0x0000000000401296 <+22>: callq 0x4013d0 <__intel_new_feature_proc_init> 0x000000000040129b <+27>: stmxcsr 0x8(%rsp) 0x00000000004012a0 <+32>: xor %esi,%esi 0x00000000004012a2 <+34>: lea (%rsp),%rdi 0x00000000004012a6 <+38>: orl $0x8040,0x8(%rdi) 0x00000000004012ad <+45>: lea 0x10(%rsp),%rcx 0x00000000004012b2 <+50>: lea 0x57(%rip),%rdx # 0x401310 <run(void*)> 0x00000000004012b9 <+57>: ldmxcsr -0x8(%rcx) 0x00000000004012bd <+61>: movb $0x0,(%rcx) 0x00000000004012c0 <+64>: callq 0x4010a0 <pthread_create@plt> 0x00000000004012c5 <+69>: cmpb $0x0,0x10(%rsp) 0x00000000004012ca <+74>: jne 0x4012d8 <main+88> 0x00000000004012cc <+76>: mov $0x186a0,%edi 0x00000000004012d1 <+81>: callq 0x401130 <usleep@plt> => 0x00000000004012d6 <+86>: jmp 0x4012cc <main+76> 0x00000000004012d8 <+88>: lea 0x1d25(%rip),%rsi # 0x403004 0x00000000004012df <+95>: mov 0x4cd2(%rip),%rdi # 0x405fb8 0x00000000004012e6 <+102>: callq 0x4010c0 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt> 0x00000000004012eb <+107>: mov %rax,%rdi 0x00000000004012ee <+110>: mov 0x4cbb(%rip),%rsi # 0x405fb0 0x00000000004012f5 <+117>: callq 0x4010d0 <_ZNSolsEPFRSoS_E@plt> 0x00000000004012fa <+122>: mov (%rsp),%rdi 0x00000000004012fe <+126>: lea 0x8(%rsp),%rsi 0x0000000000401303 <+131>: callq 0x401070 <pthread_join@plt> 0x0000000000401308 <+136>: xor %eax,%eax 0x000000000040130a <+138>: mov %rbp,%rsp 0x000000000040130d <+141>: pop %rbp 0x000000000040130e <+142>: retq 0x000000000040130f <+143>: nop
In particular, note the infinite loop marked in bold, which never checks the status of IsDone() at all and just runs usleep forever.
This bug was not present in older Intel Compiler releases, I think 2019 is the first release that introduced this issue, but I am not 100% sure.
I've recently decided to switch from C++ AMP to OpenMP. After installing the ICC I'm getting an error "could not checkout FLEXlm license". I googled for a solution but there doesn't seem to much recommended. I tried registering the Parallel Studio in hopes that would install the license file correctly. Any suggestions? Thanks in advance!
So I've been under the impression that `ipo` and `ipo-c` ultimately produce identical results, barring the fact that ipo-c *should* produce 1 object file.
I say *should* because I've had instances where it produces <i>more than</i> 1 object file; for instance, while compiling the Debian protobuf source package, I found ipo_out1.o, ipo_out2.o, and etc. (not a ton more, but perhaps a few more IIRC). Why?
BTW, as an aside, the Intel C++ Compiler produces HUGE resulting libraries for protobuf. At least one resulting static library was very close to 1GB, and the corresponding shared library I believe was around 600MB.
A quick `dpkg-query -Wf '${Installed-Size}\t${Package}\n'</span>` produces:
643184 libprotobuf-dev
940875 libprotoc-dev
But onto the real question--why doesn't ipo and ipo-c produce identical or even close to identical results? ipo-c seems to consistently produce smaller final products.
If I use ipo-c with numerous C sourcle files to produce a single ipo_out.o, and then use xiar crv libz.o, I get a smaller libz.a than with seperate -ipo -c compilations and a xiar crv libz.a [object files].
Does using ipo-c allow for a "better" (more optimized/faster) result than plain ipo? Are there other benefits to using ipo-c besides creating less intermediate objects?
Hello,
I am using Intel Compiler to compile a code.
I use the following flags for creating the code paths:
/arch:SSE3 /QaxAVX2
I follow the documentation as written in Intel C++ Compiler 19.0 Developer Guide and Reference:
What I expect the code to do is work on any CPU with SSE3 (Be Intel / AMD or any other x86-x64 with SSE3 support).
If the CPU has AVX2 support as well here will be an optimized code path fro that as well.
Since I used the /arch flag the AVX2 code path won't be limited to Intel CPU Only as it says:
If you specify both the -ax and -march options (Linux and macOS*), or the /Qax and /arch options (Windows), the compiler will not generate Intel-specific instructions.
I must say the documentation is very not clear. As I think when it says Intel Specific Instructions it means the code path won't require Intel CPU but only feature (AVX2).
Anyhow, the problem is I'm trying to run the code on AMD CPU with SSE3 (Phenom II) and the code crashes.
I expect it to see this CPU has SSE3 (Though no AVX2) and chose that code path.
Any idea?
Hi,
My project includes "ipp.h" and compiles with ICC 18.4.
I use -Wall flag.
When I try to upgrade to version 19 (19.0.1.144 20181018) I fail due to:
parallel_studio/compilers_and_libraries_2019.1.144/linux/ipp/include/ippcv_l.h(483): error #9: nested comment is not allowed
Couldn't find a way to disable this warning.
I use Skia as a dependency and build it as part of my project in C++17 mode.
Unfortunately, the Intel C++ compiler 2019 Update 1 in combination with GCC 8.2.1's libstdc++ fails to compile it.The original error is and command is:
/opt/intel/composerxe/linux/bin/intel64/icpc -DSKIA_IMPLEMENTATION=1 -DSK_HAS_PNG_LIBRARY -I/usr/include/freetype2 -I/home/ruben/Development/skui/3rdparty/libpng -I/home/ruben/Development/skui/3rdparty/zlib -I/home/ruben/Development/skui/3rdparty/libexpat -I/home/ruben/Development/skui/3rdparty/giflib -I/home/ruben/Development/skui/3rdparty/libjpeg-turbo -isystem /home/ruben/Development/skui/3rdparty/skia/include/private -isystem /home/ruben/Development/skui/3rdparty/skia/src/atlastext -isystem /home/ruben/Development/skui/3rdparty/skia/src/codec -isystem /home/ruben/Development/skui/3rdparty/skia/src/core -isystem /home/ruben/Development/skui/3rdparty/skia/src/fonts -isystem /home/ruben/Development/skui/3rdparty/skia/src/gpu -isystem /home/ruben/Development/skui/3rdparty/skia/src/image -isystem /home/ruben/Development/skui/3rdparty/skia/src/images -isystem /home/ruben/Development/skui/3rdparty/skia/src/lazy -isystem /home/ruben/Development/skui/3rdparty/skia/src/opts -isystem /home/ruben/Development/skui/3rdparty/skia/src/pathops -isystem /home/ruben/Development/skui/3rdparty/skia/src/pdf -isystem /home/ruben/Development/skui/3rdparty/skia/src/ports -isystem /home/ruben/Development/skui/3rdparty/skia/src/sfnt -isystem /home/ruben/Development/skui/3rdparty/skia/src/shaders -isystem /home/ruben/Development/skui/3rdparty/skia/src/shaders/gradients -isystem /home/ruben/Development/skui/3rdparty/skia/src/sksl -isystem /home/ruben/Development/skui/3rdparty/skia/src/utils -isystem /home/ruben/Development/skui/3rdparty/skia/src/utils/win -isystem /home/ruben/Development/skui/3rdparty/skia/src/xml -isystem /home/ruben/Development/skui/3rdparty/skia/third_party/gif -isystem /home/ruben/Development/skui/3rdparty/skia/third_party/skcms -isystem /home/ruben/Development/skui/3rdparty/skia/include/atlastext -isystem /home/ruben/Development/skui/3rdparty/skia/include/codec -isystem /home/ruben/Development/skui/3rdparty/skia/include/config -isystem /home/ruben/Development/skui/3rdparty/skia/include/core -isystem /home/ruben/Development/skui/3rdparty/skia/include/effects -isystem /home/ruben/Development/skui/3rdparty/skia/include/encode -isystem /home/ruben/Development/skui/3rdparty/skia/include/gpu -isystem /home/ruben/Development/skui/3rdparty/skia/include/gpu/gl -isystem /home/ruben/Development/skui/3rdparty/skia/include/gpu/mock -isystem /home/ruben/Development/skui/3rdparty/skia/include/gpu/mtl -isystem /home/ruben/Development/skui/3rdparty/skia/include/gpu/vk -isystem /home/ruben/Development/skui/3rdparty/skia/include/pathops -isystem /home/ruben/Development/skui/3rdparty/skia/include/ports -isystem /home/ruben/Development/skui/3rdparty/skia/include/svg -isystem /home/ruben/Development/skui/3rdparty/skia/include/utils -isystem /home/ruben/Development/skui/3rdparty/skia/include/utils/mac -isystem /home/ruben/Development/skui/3rdparty/skia/include/views -ffunction-sections -fdata-sections -std=c++17 -MD -MT 3rdparty/skia/CMakeFiles/skia.dir/src/core/SkOpts.cpp.o -MF 3rdparty/skia/CMakeFiles/skia.dir/src/core/SkOpts.cpp.o.d -o 3rdparty/skia/CMakeFiles/skia.dir/src/core/SkOpts.cpp.o -c /home/ruben/Development/skui/3rdparty/skia/src/core/SkOpts.cpp /home/ruben/Development/skui/3rdparty/skia/src/opts/SkRasterPipeline_opts.h(2070) (col. 1): internal error: 04010026_1450
Running icpc -std=c++17 SkOpts.cpp.i -c -o SkOpts.cpp.o reproduces the error.
| Attachment | Size |
|---|---|
| DownloadSkOpts.cpp.i | 2.07 MB |
% g++-8.2 --version
g++-8.2 (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% icpc --version
icpc (ICC) 19.0.1.144 20181018
Copyright (C) 1985-2018 Intel Corporation. All rights reserved.
% cat test.cpp
#include <memory>
int main(int argc, char** argv)
{
return 0;
}
% icpc -gcc-name=gcc-8.2 -gxx-name=g++-8.2 -fno-exceptions -std=c++17 -o test test.cpp
In file included from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr_base.h(54),
from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr.h(52),
from /usr/local/gcc-8.2/include/c++/8.2.0/memory(81),
from test.cpp(1):
/usr/local/gcc-8.2/include/c++/8.2.0/bits/refwrap.h(102): error: class template "std::_Mem_fn_traits" has already been defined
_GLIBCXX_MEM_FN_TRAITS(noexcept, true_type, true_type)
^
In file included from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr_base.h(54),
from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr.h(52),
from /usr/local/gcc-8.2/include/c++/8.2.0/memory(81),
from test.cpp(1):
/usr/local/gcc-8.2/include/c++/8.2.0/bits/refwrap.h(103): error: class template "std::_Mem_fn_traits" has already been defined
_GLIBCXX_MEM_FN_TRAITS(& noexcept, true_type, false_type)
^
In file included from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr_base.h(54),
from /usr/local/gcc-8.2/include/c++/8.2.0/bits/shared_ptr.h(52),
from /usr/local/gcc-8.2/include/c++/8.2.0/memory(81),
from test.cpp(1):
/usr/local/gcc-8.2/include/c++/8.2.0/bits/refwrap.h(104): error: class template "std::_Mem_fn_traits" has already been defined
_GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, true_type)
^
compilation aborted for test.cpp (code 2)