↧
empty
↧
List of optimization flags
Hi,
Is it possible to invoke individual optimizations separately with ICC? For eg: Can dead code elimination pass be invoked on source code? If possible, is there a document that lists the supported optimization flags?
Thanks,
Venkat
↧
↧
ECCN for OpenMP
Hi,
Would it possible to know the ECCN of "Intel openmp" in version 17.0.2
Thanks a lot !
Best regards,
Maxime
↧
internal error: assertion failed at: "shared/cfe/edgcpfe/lower_init.c", line 11220
Hi guys, Getting *multiple* compiler errors with C++17 for ICC 19.0.5. It prevents us from using ICC in the firm forcing to migrate from ICC to clang/gcc. Does 19.0.8 solve the error? Any advice? Sorry, can not figure out the error cause and don't have time to dig in it.
internal error: assertion failed at: "shared/cfe/edgcpfe/lower_init.c", line 11220
Host: Red Hat Enterprise Linux Server release 6.10 (Santiago), GCC 8.3
Same code is compiled fine with ICC 17.0.6 and C++14 mode. Gcc/clang also compile fine.
Thanks.
↧
C++ comliper 18.0
I want use VS2017 to write OpenMP,but i find some instruction can't use. if the version of OpenMP is 2.0,too low.So I install the intel C++ compiler 18.0,and OpenMP 4.5 C/C++ supported in version 17.0,18.0 and 19.0 compiler,and intel c++ compiler can be used in VS2017.But when i use the OpenMP in compiler,i find the version of OpenMP is still 2.0.So,i really don't konw what should i do.
↧
↧
C++ injected-class-name mishandled in templated class
Intel C++ Compiler (icpc (ICC) 19.1.0.166 20191121) seems to mishandle “injected-class-name” as described in (C++ 2014 Standard draft: 14.6.1). The compiler seems to pass type-name instead of template-name as a template template argument when instantiating method/function template from within template class itself (see code below). This seems to violate second bullet-point (see https://en.cppreference.com/w/cpp/language/injected-class-name#In_class_template), which states that the injected-class-name is treated as a template-name of the class template itself when: "it is used as a template argument that corresponds to a template template parameter".
Therefore following code fails to compile ("Foo" in "Bar<Foo>()" call seems to be handled as "Bar<Foo<int> >()" instead as template-name itself):
template<typename T>
class Foo {
public:
template<template<typename> class VT>
void Bar() {}
void Bar2() {
Bar<Foo>();
}
};
int main(int argc, char *argv[])
{
Foo<int> foo;
foo.Bar2();
return 0;
}This can be fixed as
template<typename T>
class Foo {
public:
template<template<typename> class VT>
void Bar() {}
void Bar2() {
Bar<::Foo>();
}
};
int main(int argc, char *argv[])
{
Foo<int> foo;
foo.Bar2();
return 0;
}or by aliasing "Foo" template as in
template<typename TA> using FooAlias = Foo<TA>; ... Bar<FooAlias>(); ...
↧
Internal Error
Hi,
The intel compiler generates this:
../simd/avx.hpp(50): internal error: assertion failed at: "shared/cfe/edgcpfe/decls.c", line 9448
static constexpr unary_value initialize = _mm256_set1_pd;
Here's how I generated the attached preprocessed file:
/compilers/intel/composer_xe_2019.3.199/compilers_and_libraries/linux/bin/intel64/icpc -std=c++14 -mavx2 -o junk.pp -c junk.cpp -E
Can someone try to reproduce this on Linux?
| Attachment | Size |
|---|---|
Download junk.pp_.gz | 142.45 KB |
↧
Asymmetry in non-temporal/streaming load/store intrinsics?
For streaming operations intrinsics offer both _mm256_stream_si256 and _mm256_stream_load_si256.
I found also _mm256_stream_ps but I cannot find its counterpart _mm256_stream_load_ps ... any reason for this asymmetry?
Thanks :)
-Roberto
↧
Error on Linux with icpc 19.0
Hi, The attached file generates this error on Linux with icpc 19.0:
../simd/avx.hpp(50): internal error: assertion failed at: "shared/cfe/edgcpfe/decls.c", line 9448
static constexpr unary_value initialize = _mm256_set1_pd;
Here's how I generated the attached preprocessed file:
/compilers/intel/composer_xe_2019.3.199/compilers_and_libraries/linux/bin/intel64/icpc -std=c++14 -mavx2 -o junk.pp -c junk.cpp -E
↧
↧
catastrophic error: Cannot open source file "stdio.h"(MacOS Catalina 10.15)
Hello all!
I'm super sorry if this is a redundant question asked many times. But I would really be thankful for some guidance.
I recently installed parallel studio 2020 update 1 on my Mac running macOS Catalina 10.15. I have icc/icpc compiler errors such as
- /Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h(107): catastrophic error: cannot open source file "stdio.h"
I made sure to perform source /opt/intel/bin/compilervars.sh intel64 as soon as I installed it. I also deleted and reinstalled Xcode command line tools.
I am a little lost as to what I can do next and it would really go a long way if anyone has any inputs/guidance. Thanks in advance.
Best regards,
Sanath
↧
Intel parallel studio 2020 error
I updated to version 2020.1 and got the following error recompiling my dll
Error MSB3073 The command "mkl_link_tool.exe -libs -c ms_c -a intel64 -l static 2> NUL" exited with code 9009. LNM_Lapack C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Platforms\x64\PlatformToolsets\v142\ImportBefore\Intel.Libs.MKL.v142.targets 64
line 64 in the Intel.Libs.MKL.v142.targets file corresponds to
<Exec ConsoleToMSBuild="true" EchoOff="true" StandardOutputImportance="low" Command="mkl_link_tool.exe $(MKLArguments) 2> NUL" WorkingDirectory="$(MKLProductDir)\mkl\tools"> <Output TaskParameter="ConsoleOutput" ItemName="_MKLLibraries" /> </Exec>
So VS is trying to start mkl_link_tool in the directory "$(MKLProductDir)\mkl\tools". The problem is that there is no such file in the directory. mkl_link_tool is located in the bin\ directory. Making a copy of the executable in the tool\ solves the problem.
↧
Recommended video: Intrinsic Functions
I came across a video on Intrinsic Functions that I find very instructional for learning the advantages of using intrinsic functions. This is targeted as an introductory presentation and is quite well done.
Jim Dempsey
↧
Help with Data structure types for vectorisation with long loops
Hello Forum
I am in the initial stage of a code I need to implement where I have to exploit vectorisation. In this thread I am really just looking for guidance on how my data structure should look like for certain things.
Firstly the function which I am looking to vectorise includes many calculations using certain arrays which are "const". For example, I need to use the face area projected in three directions (x,y,z). First question comes to my mind whether FaceArea[0:2][0:nfaces-1] or the reverse?
I would initially have said the reverse to be cache friendly like the snippet shown below.
The question is why I am asking then.
Well as I indicated the loop over faces can be quite long so I have seen many people splitting up the loop where they instead of having one big loop, they would have the face loop which within have a number of loops (shown below). Then, they would do FaceArea[0:2][nfaces]. Can somebody explain why this is sometimes preferred to the "long loop example".
Also, and most importantly how does cache and vector register work when we are dealing with long loops,
### LONG EXAMPLE##
for(int i=0;i<nfaces;i++)
{
var[0] = FaceArea[i][0]*vargrad[0]+ FaceArea[i][1]*vargrad[1]+FaceArea[i][2]*vargrad[2]
(....) And many more of this kindof calculations......
}
##SPLITTING EXAMPLE##
for(int i=0;i<nfaces;i+=VECLEN)
{
for(int iv = 0; iv< VECLEN; iv++)
{
aux_var[0][iv] = FaceArea[0][iv]*vargrad[0]+ FaceArea[1][iv]*vargrad[1]+FaceArea[2][iv]*vargrad[2]
// other aux_var
}
// Then you would have further loops like the above iv loop where we are using aux_var[0][:] for other calc.
}↧
↧
DR2233 not implemented
↧
GCCROOT in Practice and ICE Adventures! :)
Hi! :) I was getting an ICE with 2019.1, 2019.5, and 2020.1 while trying to compile OpenCV from source. System info:
$ uname -r 5.5.17-200.fc31.x86_64 $ gcc --version gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) $ ldd --version ldd (GNU libc) 2.30 $ ld --version GNU ld version 2.32-31.fc31
My system (Fedora 31, kernel/gcc/binutils/ld pinned [fedora defaults to rolling updates]) ships with an incompatible binutils and gcc version. Officially, it's unclear whether or not fc31 is valid (docs list it under -qnextgen, but not under main OS listings). So I compiled `gcc@8.4.0` and `binutils@2.29.1` from source. I was able to solve the ICE by compiling (almost) the full dependency stack via `gcc@8.4.0` and `binutils@2.29.1`. I was then able to compile python, numpy, and then OpenCV using Intel successfully (mostly including this information to inform any potential future readers that you don't necessarily need to compile the full stack with Intel, prioritize the ones that are important to you). To be clear, I don't think there's anything Intel can / should do on their end to resolve the ICE I ran into. I _believe_ what happened is that even though I was requesting OpenCV not build the GUI components, the system Qt was getting dragged in (I use KDE, so I can't remove it). At link time `mcpcom` was segfaulting, presumably because there's all these objects from both `gcc@9.3.1` and `gcc@8.4.0` flying around. I'm happy to label that a "usage error" on my end hehe :)
However, while investigating how to solve this I tried to wield GCCROOT. I'm working in the context of the `spack` package manager (was able to ICE building manually though), and one of the core goals of `spack` is to get the best possible build isolation we can. While playing with GCCROOT, I'm unsure how to actually be able to use it in practice. Consider a simple `hello_world.c`, if I load my `gcc@8.4.0` and `binutils@2.29.1` modules (or use `-gcc-name` etc):
$ icc -v hello_world.c
icc version 19.1.1.217 (gcc version 8.4.0 compatibility)
...
#include "..." search starts here:
#include <...> search starts here:
...
/usr/local/include
/usr/include
ld
...
-L/lib/../lib64
-L/lib/../lib64/
-L/usr/lib/../lib64
-L/usr/lib/../lib64/
...
-L/lib64
-L/lib/
-L/usr/lib64
-L/usr/libI'm highlighting the concerning entries, it seems like my underlying issue was (1) the OpenCV build system was picking up things I didn't want it to and (2) the `/usr/*` and `/lib*` entries are problematic in my scenario. If I export GCCROOT to the from-source `gcc@8.4.0` installation prefix, though:
$ icc -v hello_world.c
icc version 19.1.1.217 (gcc version 8.4.0 compatibility)
...
hello_world.c(1): catastrophic error: cannot open source file "stdio.h"
#include <stdio.h>
^
compilation aborted for hello_world.c (code 4)The `/usr/include` and `/usr/local/include` entries are not there (good!), but here's where things get really confusing to me. After comparing the custom and system install trees, I've noticed some seemingly significant differences. `stdio.h` is one of a number of header files that are not installed where Intel is expecting them (`syslimits.h` was another). I've been looking at our build scripts and the GCC compilation documentation, but am unable to discern how the linux packaging gurus do whatever they do to produce the installation tree. The removal of `/[usr]/include` and `/lib*` are quite desirable for us. Is there any in-depth documentation or advice for how we can get a from-source build of GCC to install in the way the Intel compilers are expecting? It seems to me that setting `GCCROOT`, `GXXROOT`, and `GCC_EXEC_PREFIX` would be the golden standard for us to get a truly isolated build via Intel's (magical) compilers :)
Thank you in advance for any suggestions / tips! I'm rather intrigued by the differences in the install trees and how to reconcile them if we can!
↧
Internal error: assertion failed at "shared/cfe/edgcpfe/lower_il.c"
We have the following problem which occurs with 19.0.5.281 and 19.1.1.217 on Linux. No issues with GCC 9.1, 9.2, 9.3, 10, Clang7.1/9.1 or PGI-19-10.
Internal error: assertion failed at: "shared/cfe/edgcpfe/lower_il.c", line 11913
struct make_shared_enabler: public table {
compilation aborted ... (code 4)
Compiler flags:
It fails with both:
#default
-Wall -Werror -std=c++14 -fopenmp
#production
-O2 -fp-model consistent -fimf-arch-consistency=true
#debug
-O0 -g
Code:
std::shared_ptr<table> make_table(){
struct make_shared_enabler : public table {
make_shared_enabler() = default;
};
return std::make_shared<make_shared_enabler>();
}
↧
internal error: 04010002_1670
I'm hitting an ICE with 19.1 20200306 on Linux. Here is a minimal reproducer (courtesy of c-reduce):
typedef float a;
struct b {
a c __attribute__((__vector_size__(sizeof(2))));
} f;
typedef struct {
struct b d[2];
} e;
void g() {
e h;
h.d[0] = f;
}$ icc -c -o test.o test.c
test.c(10) (col. 12): internal error: 04010002_1670
compilation aborted for test.c (code 4)
↧
↧