Hello, everyone,

For Qt builds using ICC on Windows with C++14 support enabled got error:

Feature 'c++14' was enabled, but the pre-condition 'features.c++11 && tests.c++14' failed

After some investigations found, that ICC failed test:

#if __cplusplus > 201103L
#else
#  error "__cplusplus must be > 201103L (the value of C++11)"
#endif

during configuration. While mingw-w64 passes it successfully.

The source of error is value of '__cplusplus' definition, which is 199711L for ICC, while 201402L for mingw-w64.

Using '-Qstd=c++14' or '-D__cplusplus=201402L' compiler keys didn't solve this issue.

Since ICC 2017 declare support of C++14, it's expected, that '__cplusplus' definition contain appropriate value. As mingw-w64 do. Is it possible to set '__cplusplus' value according to declared ICC features? So there won't be needed to hack various sources in order to skip such C++14 compliance tests.

Environment:

• Windows 10 x64,
• IPSXE 2017 Update 4,
• VS 2015 Update 3,
• Qt-5.9.

Alexander

Dear All,

I am new to assembly language. Using, GCC on Windows 7 with Mingw. Using following command, using source file Hello.c, 

got the Disassembley on the Hello_asm.txt ( can see the assembly content..believe it is in Intel format).

objdump -M intel -S -d Hello.o >Hello_asm.txt

Fine. Now, another secnario,   if the use the Intel C++ compiler on my Windows 7 PC, Without  Visual studio environment, compile Hello.c and get the  Assembly file.. believe it will created with .asm  ( Hello.asm.).  My doubt :  Hello.asm ( Intel)  and Hello_asm.txt (GCC) will have same assembly language content for the x86  platform/Windows. Irrespective of whether an exe  file created or not  (from Obj file or  assembler)

Please advise. Am i missing any info.

Cheers!

Chandra 

Hello,

I have code, which looks more or less like this:

template<typename B>
struct A
{
    B &b;
    A(B &b) : b(b) {}
};

struct B {…};

void f(B b)
{
    A(b) a;
    int i = 0;
    /* more code using "a", but NOT "b". */
}

int main()
{
    B b{…};
    #pragma omp parallel
    {
        #pragma omp for
        for (int i = 0; i < 256; ++i)
            f(b);
    }
    return 0;
}

So I have a function "f", which is called multiple times in an OpenMP loop. This function is passed a class "B" by value. Inside this function, "b" is encapsulated in another class "A". After this encapsulation "b" is not used directly anymore, but over "a". However I noticed that although I make use of "a" a lot later in code, the (stack?) memory of the parameter "b" is reused. But as the data member "b" in "A" is a reference, this invalidates also my "a" variable.

Unfortunately this small code snippet does not reproduce the failing behaviour and my failing code is too big and too complex to show the behaviour. However as I noticed that the stack is reused I am curious whether I am able to disable this feature.

My code is running fine with -O1, but starts to fail for -O2. I tested the Intel C++ compiler version 17.0.0 and 17.0.2.

Thanks in advance and best regards,

Alexander Matthes

Dear Help,

I just realized that the fftwf_plan_guru_split_dft_r2c() functional call in Intel's C library simply returns a null. So instead of writing a wrapper to use the original library of FFTW, I thought it might be easier to directly use Intel's DFT functions. My problem is that I really want the complex output to be stored in two different arrays (e.g. rdata and idata for the real and imag, respectively). It is possible to configure a complex forward FT to use two split arrays for both the input and output data by setting DFTI_COMPLEX_STORAGE = DFTI_REAL_REAL, but I don't see how I can do the same thing for the complex output in a DFTI_REAL forward FT. I was hoping that DFTI_CONJUGATE_EVEN_STORAGE is useful to do what I want, but this does not seem to be the case. I am really puzzling why this cannot be done easily. Any suggestions on how I may do what fftwf_plan_guru_split_dft_r2c() in FFTW does are much appreciated!

Thanks!

Jinfa

Hi, Mr./Ms.

I installed Intel System Studio under the windows environment, and tried to integrate it into Eclipse, and used ICC to build under the Eclipse environment.

But now Find that there seems not to have Assembler so assembling files can't be built.

Is there any suggestion for the issue?

Thanks

freagle

Hi,

   template <typename T, decltype(T::a)* = nullptr>
   bool DoCheck1(T t) { return false; }

   template <typename T, decltype(T::b)* = nullptr>
   bool DoCheck1(T t) { return false; }

   template <typename T, typename std::enable_if<true, decltype(T::a)>* = nullptr>
   bool DoCheck2(T t) { return false; }

   template <typename T, typename std::enable_if<true, decltype(T::b)>* = nullptr>
   bool DoCheck2(T t) { return false; }

Both above versions should have same behaviour, but icc 16.0.4 on Linux gives the following compilation error for DoCheck2 -

error: redefinition of default argument
     template <typename T, typename std::enable_if<true, decltype(T::b)>* = nullptr>

Is this expected behaviour or a bug?

Regards,

Tarun

The Intel release notes aren't clear on gcc compatibility:

https://software.intel.com/en-us/articles/intel-c-compiler-170-for-linux-release-notes-for-intel-parallel-studio-xe-2017

The page says:

gcc versions 4.3 - 6 supported

I'm not sure whether this means 4.3 - 6.x, or 4.3 - 4.6.

The page also says:

GCC 6.0 is not supported

...

Error #3802: Version 16.0 Update 2 is incompatible with GNU versions greater than or equal to 6.0

It's not clear whether 6.0 is incompatible with just Intel 2016, or also with Intel 2017.  It's also not clear if 6.0 is incompatible, but maybe 6.3 is compatible.

Compiling code using AVX 512 intrinsics with processor specific optimization set to AVX2, results in AVX 512 instructions (looking at generated assembly) using only zmm0-zmm15.
So only 16 registers are used instead of 32.

With processor specific optimization set to AVX512 core, all 32 zmm registers are used.
(I need to compile with processor specific to AVX2, else the AVX2 code path does no run.)

Is this a known issue that can be fixed ?

Hi, something seems not right with the functioning of in intel's valarray implementation. I tried using both the previous compilers as well as the most recent 2017 version of icpc. For instance, when we compile with icpc, we find that 0.1 - 0.05 = -0.05, instead of 0.1-0.05 = 0.05. g++ works fine though. Please find attached an example C++ file, and the makefile. Note that the makefile has a .txt extension that needs to be removed, or copy paste its contents in the terminal.

I am participating in the beta program for the 2018 compiler release. When I try to compile for the KNC with -mmic option, the compiler tells me that the option is not supported anymore. What is the replacement? Where can I learn more?

Hi,

I am getting the following error while compiling a project using Intel compiler (parallel studio 2017 rev 4)

"old for-init compatibility mode cannot be used with C++11 mode"

The project is compiling fine when using c++ compiler 2015.

Any idea on what i can do to correct this issue?

Hello, All!

I am not sure if this is the right place to write about this but I would like to share a piece of information regarding a potential problem one might face when using Intel C compiler with a self-built gcc.

Assume we have two gccs on our system. The first one (system gcc, e.g. gcc 4.9) came along with our Linux distribution and the second one (self-built gcc, e.g. gcc 6.2.0) is built from sources by ourselves. Now, we want to compile a hello-world C program that includes stdio.h (which, several levels of recursion later, includes sys/cdefs.h). On some Linux distributions (e.g. Debian 8) the latter file resides in /usr/include/x86_64-linux-gnu.

We start with making sure that our program can be compiled with both system and self-built gccs (both system and self-built GNU preprocessors know that they should look into /usr/include/x86_64-linux-gnu).

We also don't (we shouldn't) have problems compiling it with icc when it's configured to work with the system gcc (either by making sure that it's the first gcc in the PATH or by specifying the -gcc-name flag of icc). But if we try to compile with icc in conjunction with the self-built gcc we might get an error:

/usr/include/features.h(374): catastrophic error: cannot open source file "sys/cdefs.h"

If you run icc -dryrun hello.c you'll see that /usr/include/x86_64-linux-gnu is not among --sys_include directories.

So, I wrote a wrapper script for gcc and cpp to store the arguments they are called with to a text file to find out how icc gets information on the environment from them. I expected to see that icc calls something like 'cpp -v' to get the list of the system include directories but it didn't do that. In fact, icc does not call cpp at all (well, in this case) but tries to guess what should be on the list by analysing the output of 'gcc -### dummyfile.c' (just FYI, the dummyfile contains only one string: void foo();).

It looks like the reason for the problem is that the self-built gcc was built without explicit specification of the target and if you do not specify the target explicitly gcc's configure script uses whatever the config.guess script returns. In my case, it's 'x86_64-pc-linux-gnu'. My assumption is that since 'x86_64-linux-gnu' is not equal to 'x86_64-pc-linux-gnu', icc does not look into /usr/include/x86_64-linux-gnu.

I decided that it was fair enough (although it's not a problem for GNU cpp and it would make sense to ask it for the list) and recompiled gcc adding the following arguments to the configure script: --target=x86_64-linux-gnu --host=x86_64-linux-gnu --build=x86_64-linux-gnu. It helped: icc included the necessary path on the list and managed to compile the program.

That would be it but I checked one more thing. Instead of giving the same value to all three --target --host and --build flags, it should be OK to specify the value only for --build, since the flags --host and --target inherit the value from --build (if not specified otherwise). To my surprise, icc 17.0.1 could not handle it, which already looks like a bug to me. Let's hope this will be fixed some day but for now,  make sure that you provide gcc's configure script with all three flags. And all of them should get the same value as your system compiler's target.

Hello, All!

I am sorry if this is not the right place for this but probably somebody will find this useful.

As far as I understand, Intel C compiler 17.0.2 uses 'cpp' and 'as' when processing assembly files (.S). It's possible that they reside in different directories: /path/to/gcc/bin and /path/to/binutils/bin. If we want to use that specific 'cpp' and that specific 'as' we can just add them to PATH before compiling. Unfortunately, it's not very good to modify PATH variable for my workflow in particular. So, I tried to use icc's command line flags:
icc -gnu-prefix=/path/to/binutils/bin/ file.S

and got the following error:
icc: error #10001: could not find directory in which /path/to/binutils/bin/g++ resides

Fair enough but shouldn't it complain about gcc? I even created a symlink to g++ in that directory and still got the same error. Looks like a bug to me.

Ok, let's give icc the right path to the gcc that want to use:
icc -gcc-name=/path/to/gcc/bin/gcc -gnu-prefix=/path/to/binutils/bin/ file.S

and the error is:
/path/to/binutils/bin/cpp: No such file or directory

Looks like we can't tell icc what we want using just command line arguments. Let's try to set GCC_EXEC_PREFIX, which icc takes into account when looking for 'as' and 'ld':

export GCC_EXEC_PREFIX=/path/to/binutils/bin/
icc -gcc-name=/path/to/gcc/bin/gcc file.S

It worked but I still wish icc used the cpp from /path/to/gcc/bin/ for preprocessing, but not the one it finds in the PATH. Maybe there are ways to get what I want without modifying PATH but I have not found them yet.

However, it would be really nice to be able to specify all necessary paths to applications with just command line arguments. Unfortunately, it looks like icc doesn't currently allow that.

It would also be nice if icc accounted for '--with-as' and '--with-ld' configuration flags of gcc, which hardcode the paths to 'as' and 'ld'. The better solution might be to call 'gcc - print-prog-name=as' but that would require additional calls to gcc while the configuration flags are parsed by icc anyway. On the other hand, this feature would probably introduce additional confusion sometimes.

Hello,

     I was getting syntax errors when trying to use OpenMP array reductions in icpc 17.0.4. After reducing the problem, it seems that array reductions might not be supported inside templated functions. Here's an example of what I'm seeing:

// This is OK.
void test1(int n) {
    double *a;

    #pragma omp parallel for reduction(+: a[:n])
    for (int i = 0; i < n; ++i) { }
}


// This fails to compile -- "error: syntax error in omp clause"
template <typename T>
void test2(int n, T /*unused*/) {
    T *a;

    #pragma omp parallel for reduction(+: a[:n])
    for (int i = 0; i < n; ++i) { }
}

template void test2(int, double);


// This also fails to compile, with the same error
template <typename T>
void test3(int n, T) {
    double *a;

    #pragma omp parallel for reduction(+: a[:n])
    for (int i = 0; i < n; ++i) { }
}

template void test3(int,double);

Is this a known issue, or did I make a mistake somewhere? Thanks!

Peter

Hi,

  I want to use code coverage tool, but when I run codecov, I get 

bash: codecov: command not found.

  My icc is icc.13.0.0.2.016b.x86_64-linux (gcc version 4.4.7 compatibility).

  What should I do?

Kind regards,

Having trouble with the error message

Command-line error: old for-init compatibility mode cannot be used with C++11 mode

We are moving an existing application compiled for win32 on an XP box with ver 11.1.067 to win10 with ver 2017.1.143

The icproj file copied across and converted on opening - apparently sucessfully

but NOTHING will compile - we just get the above error message.

Any assistance would be appreciated

=G=

Hi All,

We are using MS Visual Studio 2015 and Intel C++ Compiler 2017. All of our code is built using Intel compiler. We provide this code to others in form of dll files and associated lib that are  expected to be dynamically linked in their application. These applications are not built using Intel Compiler. When dynamically linking the application, we get an error that libmmd.lib is required. The application of course does not explicitly linked with libmmd.lib nor is it built using Intel compiler. 

Is the libmmd.lib required for the application or are we missing anything here?

If yes, the .lib files are of course not included in Intel redistributables. Are we required to provide them if somebody wants to dynamically link with dll files generated using Intel compiler?

What are the distribution licenses for these libs as far as Intel is concerned?

More information. 

We use the /MD switch for code generation. Using the Multi threaded static library this leads to errors.

Detailed design

basicfunctionality.lib written by us, generated using Intel compiler.

consolidatedfunctionality.dll written by us, links with basicfunctionality.lib and is generated using Intel compiler. consolidatedfunctionality.lib is also generated. 

thirdparty.exe written by others, expected to dynamically link with consolidatedfunctionality.dll. consolidatedfunctionality.lib is explicitly specified in linked libraries input. thirdparty.exe is not generated using Intel compiler, rather it uses MSVC. While building thirdparty.exe, we get an error message libmmd.lib not found. Why is it looking for libmmd.lib when libmmd.dll is already present as runtime library? I can understand consolidatedfunctionality.dll requiring libmmd.dll at runtime but cannot understand why the .lib file is required for building thirdparty.exe. Are we missing something or is this by design.

Hi, 

The Intel manuals in Visual Studio open in the default browser, which for me is Google Chrome.

Since the latest release, these now show blank pages.

I am guessing that they set 3rd party cookies, which are blocked in my browser settings.

How can I whitelist the Intel manuals without allowing 3rd party cookies from all sites?

I am using Intel Compiler 17.0 in VS 2017 Community in Windows 10.

Hi guys,

I compiled and statically linked binaries from the SPEC CPU 2017 benchmark suite. But there are three fprate benchmarks always giving strange segmentation faults. They are '503.bwaves_r', '521.wrf_r' and '527.cam4_r', and the following is the 503.bwaves_r error message. Could anyone shed light on the root cause of the issue and how it can be resolved?

The ICC version is 17.0.4. The flags that I used for compilation and linking are as follows: 

• LDCFLAGS        = -static -mkl -static-intel
• SSE            = -xCORE-AVX2
• OPTIMIZE       = $(SSE) -static -ipo -O3 -no-prec-div -qopt-prefetch -auto-p32 -ansi-alias

Thanks a bunch!

Don

ubuntu@1p2650v4-9:/bmark/xeon-1p2650v4-specrate-spec/0/benchspec/CPU/503.bwaves_r/run/run_base_refrate_x86_64_icc_mkl-m64.0023$ ../run_base_refrate_x86_64_icc_mkl-m64.0000/bwaves_r_base.x86_64_icc_mkl-m64 bwaves_1 < bwaves_1.in

 BI-CGSTAB & symmetric difference scheme
 3D  Laminar shock wave propagation
 Re:   100000.000000    Pr:        0.720000
 grid size is:     63    63    64
 CFL:  2.000   nuim:  0.100  nuex2:  0.100 nuex4:  0.050
 Implicit scheme is working
 Cubic initial configuration
 Number of Time Steps:     80

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
bwaves_r_base.x86  0000000000417B74  Unknown               Unknown  Unknown
bwaves_r_base.x86  00000000004AE6B0  Unknown               Unknown  Unknown
bwaves_r_base.x86  00000000004024F8  Unknown               Unknown  Unknown
bwaves_r_base.x86  0000000000401DE6  Unknown               Unknown  Unknown
bwaves_r_base.x86  000000000040112E  Unknown               Unknown  Unknown
bwaves_r_base.x86  00000000004AD034  Unknown               Unknown  Unknown
bwaves_r_base.x86  00000000004AD166  Unknown               Unknown  Unknown
bwaves_r_base.x86  0000000000401016  Unknown               Unknown  Unknown

I am participating in the beta program for the 2018 compiler release. When I try to compile for the KNC with -mmic option, the compiler tells me that the option is not supported anymore. What is the replacement? Where can I learn more?