Quantcast
Channel: Intel® Software - Intel® C++ Compiler
Viewing all 2797 articles
Browse latest View live

Bandwidth tests

$
0
0

Hi,

I am playing with some programs to compute "bandwidth" on my system which is a Dual-Xeon Skylake Gold 6140 (2 sockets of 18 cores) with 12 DIMMS (6 per socket) of RAM at 2666 MHz for a total of 96 GB. I wrote my own "stream" benchmark, and I am surprised by some results. On this platform, Intel Advisor (the roofline) claims 207 GB/s of memory bandwidth. The Intel Memory Latency Checker gives exactly the same result for the bandwidth. Here are the results given by my program.

Bandwidth, sum += a[i] * b[i]        : 182.698 Gb/s
Bandwidth, a[i] = 0.0                : 103.311 Gb/s
Bandwidth, a[i] = 2 * a[i]           : 128.075 Gb/s
Bandwidth, a[i] = b[i]               : 136.004 Gb/s
Bandwidth, a[i] = 2 * b[i]           : 102.294 Gb/s
Bandwidth, a[i] += 2 * b[i]          : 101.337 Gb/s
Bandwidth, a[i] = 2 * b[i] + 3 * c[i]: 114.601 Gb/s
Bandwidth, a[i] = b[i] + 3 * c[i]    : 114.525 Gb/s

I have a few questions:

1/ Is there a way to reach the peak performance of 207 GB/s with the reduction (sum += a[i] * b[i]) ? Can we tune prefetching to do so?

2/ Why is the bandwidth for setting a to 0.0 so low? Can we make it faster?

Best regards

 

PS: The following code has been compiled with

icpc -g -std=c++11 -O3 -xCORE-AVX512 -qopenmp -DNDEBUG main.cpp -o main

and launched with thread pinning with 1 thread per core.

export OMP_PLACES=cores
export OMP_PROC_BIND=spread
export OMP_NUM_THREADS=36
./main

Here is the full listing

#include <chrono>
#include <iostream>

int main() {
  const std::ptrdiff_t n = 1024 * 1024 * 1024;
  double *a = new double[n];
  double *b = new double[n];
  double *c = new double[n];
#pragma omp parallel for
  for (std::ptrdiff_t i = 0; i < n; ++i) {
    a[i] = 0.0;
    b[i] = 0.0;
    c[i] = 0.0;
  }

  const std::ptrdiff_t nb_times = 20;
  double sum = 0.0;
  auto point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for reduction(+ : sum)
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      sum += a[i] * b[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
  }
  auto point_end = std::chrono::high_resolution_clock::now();
  double time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, sum += a[i] * b[i]        : "<< (2 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = 0.0;
    }
    asm volatile("" : : "g"(a) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = 0.0                : "<< (1 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = 2 * a[i];
    }
    asm volatile("" : : "g"(a) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = 2 * a[i]           : "<< (2 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = b[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = b[i]               : "<< (2 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = 2 * b[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = 2 * b[i]           : "<< (2 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] += 2 * b[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] += 2 * b[i]          : "<< (2 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = 2 * b[i] + 3 * c[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
    asm volatile("" : : "g"(c) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = 2 * b[i] + 3 * c[i]: "<< (3 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;

  point_begin = std::chrono::high_resolution_clock::now();
  for (std::ptrdiff_t k = 0; k < nb_times; ++k) {
#pragma omp parallel for
    for (std::ptrdiff_t i = 0; i < n; ++i) {
      a[i] = b[i] + 3 * c[i];
    }
    asm volatile("" : : "g"(a) : "memory");
    asm volatile("" : : "g"(b) : "memory");
    asm volatile("" : : "g"(c) : "memory");
  }
  point_end = std::chrono::high_resolution_clock::now();
  time = 1.0e-9 * std::chrono::duration_cast<std::chrono::nanoseconds>(
                             point_end - point_begin)
                             .count();

  std::cout << "Bandwidth, a[i] = b[i] + 3 * c[i]    : "<< (3 * n * sizeof(double) * nb_times) /
                   (time * 1024 * 1024 * 1024)<< " Gb/s"<< std::endl;
  std::cout << "Check: "<< sum << std::endl;

  delete[] c;
  delete[] b;
  delete[] a;

  return 0;
}

 


gcc-6 vs icc 18.0 performance (seeing no gain)

$
0
0

Does anyone have any anecdotal data on what are the realistic gains that could be seen between gcc-6 and icc 18.0 compiler ? After some painstaking effort, I tried on couple of open source projects and found no gain. I used -02 -axAVX,SSE2,SSE4.1 etc [actually all instructions set] and used auto dispatch. It looks like ICC might work best for loopy code versus branchy code that may not have nice loops with large data set. Is that a reasonable assumption ?

internal error: assertion failed: remove_from_routines_list: routine not found on list (shared/cfe/edgcpfe/il.c, line 16415)

$
0
0

Hello, everyone,

For Boost.Python builds using ICC on Windows got error:

libs\python\src\object\enum.cpp(47): internal error: assertion failed: remove_from_routines_list: routine not found on list (shared/cfe/edgcpfe/il.c, line 16415)

          object auto_free(handle<>(mod));
                 ^

compilation aborted for libs\python\src\object\enum.cpp (code 4)

(original 'enum.cpp' and its ICC-preprocessed version added in attachment).

 

Reproduced for:
  - Boost 1.66.0.b1.rc2 builds using ICC,

not reproduced for:
  - Boost 1.65.1 builds using ICC,
  - Boost 1.66.0.b1.rc2 builds using mingw-w64 and MSVC.

 

Environment:

  • Windows 10 x64,
  • ICC 2018 Update 1,
  • MSVC 2017 15.4.1,
  • Windows SDK 10.0.16299.15,
  • mingw-w64 x86_64 7.2.0,
  • Boost 1.66.0.b1.rc2.

 

Best,

Alexander

 

AttachmentSize
Downloadapplication/zipenum.zip293.33 KB

Compile a Linux application under windows

$
0
0

Hello,

Is it possible ?
We want to use intel compiler (run by v.s 2017) to compiler and build a linux application. 
Is there an Intel compiler that can run under windows and compile a code for linux ?

It seems icc searches a gcc exceutable which we have only under linux. 

Thank you,
Zvika 

compile timing

$
0
0

Hi from germany

i miss the the information about compilation time with the 2018 compiler

How can i activate that

 

thanks in advance

Peter

 

Runtime error with the libirng.so (undefined symbol: _intel_avx_rep_memcpy) for icpc of Intel Parallel Studio 2018.1.163

$
0
0

On Ubuntu Virtualbox, I can generate a '.so' file without problem using the 'icpc' command of Intel Parallel Studio 2018.1.163. However, when I run the program linked with the '.so' file, there is an error saying:

symbol lookup error: /opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libirng.so: undefined symbol: __intel_avx_rep_memcpy

Does anyone know how I can fix this? Is it related to LD_LIBRARY_PATH or anything else?

My 'LD_LIBRARY_PATH' is shown below:

/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/mic/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/debugger_2018/iga/lib:/opt/intel/debugger_2018/libipt/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/mic/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/debugger_2018/iga/lib:/opt/intel/debugger_2018/libipt/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/mic/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/debugger_2018/iga/lib:/opt/intel/debugger_2018/libipt/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/mpi/mic/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/ipp/lib/intel64:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/opt/intel/debugger_2018/iga/lib:/opt/intel/debugger_2018/libipt/intel64/lib:/opt/intel/compilers_and_libraries_2018.1.163/linux/daal/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/daal/../tbb/lib/intel64_lin/gcc4.4::/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/lib/x86_64-linux-gnu:/lib64

 

Problem with OpenMP Locks

$
0
0

I encounter a segmentation fault when I compile the following code with the intel compiler.

The code works fine with gnu compiler. What could be the possible reason behind this error.

The error occur at locking or unlocking but mostly occur at unlocking the openmp lock.

 

#include <omp.h>
#include <iostream>

int main (int argc, char* argv[])
{
  int x, y, z;
  x = 0;  y = 0;  z = 0;
  double N = 60.0;

  omp_lock_t lck;
  omp_init_lock (&lck);

#pragma omp parallel shared(lck) default(shared)
  {
    double stime = omp_get_wtime();
    double etime = omp_get_wtime();

    int tid = omp_get_thread_num();

    while((etime - stime) < N)
      {
	if(tid == 2)
	  {
	    omp_set_lock (&lck);
	    y++;
	    omp_unset_lock (&lck);
	  }

	if(tid == 0)
	  {
	    omp_test_lock (&lck);
	    z--;
	    omp_unset_lock (&lck);
	  }
	etime = omp_get_wtime();
      }
  }
  omp_destroy_lock (&lck);
  return 0;
}

 

Missing of quotation in `compilervars_arch.sh`

$
0
0

Hello, My name is Hao,

I am using centos and I installed parallel studio for student.

In `/opt/intel/compilers_and_libraries_2017/linux/pkg_bin/compilervars_arch.sh`, line 54, it write:

```for a in 9 10 11 12 13 14 15 16 17 18 19 21 L 23 24; do```

I don't know what is the meaning of this sentence but if I alias "L" before source `iccvars.sh` in the shell(I am using zsh), it may throw error.

So, maybe one more quotation is better...


License activation of product Intel® C++ Studio XE for Windows.

$
0
0

Hello,

This is regarding the license activation of product Intel® C++ Studio XE for Windows.  

Recently the machine where the product was installed is formatted and migrated to a new domain. Due to which the existing product activation key is no more working.

Our serial number is expired and we need the license file for installation. Can you please help?

 

Regards,

Mr. Jyotipriya Das

jyotipriya.das@gmail.com

609-216-0958

 

Floating license on multiple OS

$
0
0

Hello,

in the department where I work there is a number of floating licenses for Parallel Studio in use under Linux. Is it possible to use one of these floating licenses additionally under Windows (so for both OS)?

If this is possible in principle but not by default, what is to be done?

Thanks in advance,

TJ

Universal Windows Driver - OneCore linking problem - Visual Studio 2015

$
0
0

I wanted to rebuild existing solution to make it Universal API compliant. The story is that when I added linking to onecoreuap.lib Visual Studio returns many errors about "unresolved external symbol" to some functions I am using. Yet, I found those functions in the UniversalDDIs.xml so I guess that this API should be supported. Below you'll find the specifics:

Project A:

- Lang: C++

- Target Platform Version: 10.0.15063.0

- Configuration Type: Static Library (.lib)

- Platform Toolset: Visual Studio 2015 (v140)

- Additional Dependencies: $(WindowsSDK_LibraryPath)\$(Platform)\OneCoreUAP.lib

- Ignore Specific Default Libraries: kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;

- Output: ProjectA.Lib

Project B:

- Lang: C++

- Target Platform Version: 10.0.15063.0

- Configuration Type: Dynamic Library (.dll)

- Platform Toolset: Visual Studio 2015 (v140)

- Additional Dependencies: $(WindowsSDK_LibraryPath)\$(Platform)\OneCoreUAP.lib; ProjectA.Lib

- Ignore Specific Default Libraries: kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;

- Output: ProjectB.dll

 

Sample output:

When I try to build the solution I get the below errors:

Error LNK2001 unresolved external symbol __imp_PathIsRelativeA (ProjectA.lib)

Error LNK2001 unresolved external symbol __imp_PathAppendW (ProjectA.lib)

Error LNK2001 unresolved external symbol __imp_PathRemoveFileSpecA (ProjectA.lib)

These 3 funcs are part of Shlwapi.dll and I found in UniversalDDIs.xml that in UWD they are supported from api-ms-win-core-shlwapi-legacy-l1-1-0.dll

 

Possible solution

I'll be truly thankful if you could tell me, what am I doing wrong or what else should I do or link to to make it work :)

 

Boost 1.65.1 with Intel C++ 18.0 on Windows with Visual Studio 15.4.5

$
0
0

Did anyone manage to compile Boost 1.65.1 with Intel C++ 18.0 and Visual Studio 15.4.5? I somehow successfully compiled 1.65.1 with prior versions of VS2017 but now it fails.

More specifically, when launching "b2 address-model=64 toolset=intel-18.0-vc14 cxxflags=/Qstd=c++17 --build-type=complete link=static --with-coroutine --with-filesystem --with-context --with-log stage" build process doesn't find "icl" while it's accessible from the same console.

Any help is appreciated.

compilation problem

$
0
0

Dear All,

I stumbled upon the compilation problem.

platform: Ubuntu 16.04

icpc version 16.0.2 (gcc version 5.0.0 compatibility)

Problem: there is a package which I would like to compile with the intel compilers and it produces the error /usr/include/glib-2.0/glib/gtypes.h(423): error: identifier "__builtin_uaddll_overflow" is undefined

I found that the problem is related to gtk+-2.0 and when I tried to compile simple program

#include <gtk/gtk.h>

int main( int   argc,
          char *argv[] )
{
    GtkWidget *window;
    
    gtk_init (&argc, &argv);
    
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    gtk_widget_show  (window);
    
    gtk_main ();
    
    return 0;
}

with icpc test.c -o test `pkg-config --cflags --libs gtk+-2.0`

I got the same error:

In file included from /usr/include/glib-2.0/glib/galloca.h(32),
                 from /usr/include/glib-2.0/glib.h(30),
                 from /usr/include/glib-2.0/gobject/gbinding.h(28),
                 from /usr/include/glib-2.0/glib-object.h(23),
                 from /usr/include/glib-2.0/gio/gioenums.h(28),
                 from /usr/include/glib-2.0/gio/giotypes.h(28),
                 from /usr/include/glib-2.0/gio/gio.h(26),
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h(30),
                 from /usr/include/gtk-2.0/gdk/gdk.h(32),
                 from /usr/include/gtk-2.0/gtk/gtk.h(32),
                 from test.c(1):
/usr/include/glib-2.0/glib/gtypes.h(418): error: identifier "__builtin_uadd_overflow" is undefined
    return !__builtin_uadd_overflow(a, b, dest); }
            ^

In file included from /usr/include/glib-2.0/glib/galloca.h(32),
                 from /usr/include/glib-2.0/glib.h(30),
                 from /usr/include/glib-2.0/gobject/gbinding.h(28),
                 from /usr/include/glib-2.0/glib-object.h(23),
                 from /usr/include/glib-2.0/gio/gioenums.h(28),
                 from /usr/include/glib-2.0/gio/giotypes.h(28),
                 from /usr/include/glib-2.0/gio/gio.h(26),
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h(30),
                 from /usr/include/gtk-2.0/gdk/gdk.h(32),
                 from /usr/include/gtk-2.0/gtk/gtk.h(32),
                 from test.c(1):
/usr/include/glib-2.0/glib/gtypes.h(420): error: identifier "__builtin_umul_overflow" is undefined
    return !__builtin_umul_overflow(a, b, dest); }
            ^

In file included from /usr/include/glib-2.0/glib/galloca.h(32),
                 from /usr/include/glib-2.0/glib.h(30),
                 from /usr/include/glib-2.0/gobject/gbinding.h(28),
                 from /usr/include/glib-2.0/glib-object.h(23),
                 from /usr/include/glib-2.0/gio/gioenums.h(28),
                 from /usr/include/glib-2.0/gio/giotypes.h(28),
                 from /usr/include/glib-2.0/gio/gio.h(26),
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h(30),
                 from /usr/include/gtk-2.0/gdk/gdk.h(32),
                 from /usr/include/gtk-2.0/gtk/gtk.h(32),
                 from test.c(1):
/usr/include/glib-2.0/glib/gtypes.h(423): error: identifier "__builtin_uaddll_overflow" is undefined
    return !__builtin_uaddll_overflow(a, b, (unsigned long long *) dest); }
            ^

In file included from /usr/include/glib-2.0/glib/galloca.h(32),
                 from /usr/include/glib-2.0/glib.h(30),
                 from /usr/include/glib-2.0/gobject/gbinding.h(28),
                 from /usr/include/glib-2.0/glib-object.h(23),
                 from /usr/include/glib-2.0/gio/gioenums.h(28),
                 from /usr/include/glib-2.0/gio/giotypes.h(28),
                 from /usr/include/glib-2.0/gio/gio.h(26),
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h(30),
                 from /usr/include/gtk-2.0/gdk/gdk.h(32),
                 from /usr/include/gtk-2.0/gtk/gtk.h(32),
                 from test.c(1):
/usr/include/glib-2.0/glib/gtypes.h(425): error: identifier "__builtin_umulll_overflow" is undefined
    return !__builtin_umulll_overflow(a, b, (unsigned long long *) dest); }
            ^

compilation aborted for test.c (code 2)

Not to mentioned that it is no problem to compile it with g++.

 

Best regards,

Ketiw

 

 

 

 

 

ICC version for Denverton

$
0
0

What is the latest compiler version for Denverton (C3000 SoC)? Does ICC 13.0.2.016b support Denverton (C3000 SoC)?

"Incomplete installation of Microsoft Visual Studio* 2017 is detected."

$
0
0

Incomplete installation of Microsoft Visual Studio* 2017 is detected.
Installation can continue; however, Intel® C++ and Fortran Compilers will not be integrated into Microsoft Visual Studio* 2017 Professional edition during installation. Please, contact customer support (http://www.intel.com/software/products/support).

Intel Parallel Studio 2018 Update 1 installer.

What???


"inline namespace" broken with /Qvc** in ICPC 18.0 + Visual Studio 2017

$
0
0

The headers "chrono", "string" and "complex" shipped with Visual Studio 2017 (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include) are currently broken with "Intel C++ Compiler 18.0".

Microsoft has switched these headers to make use of "inline namespace", and icpc fails parsing these when operating in MSVC compatbility mode (/Qvc14).

It does not emit the warnings it would have when operating in a pre-C++11 standard ("inline can only be used on ..."), but fails straight out with a parser error ("identifier expected" on the "namespace" keyword).

The headers for "std::experimental" shipped with VS2017 make even heavier use of the "inline namespace" feature and are essentially all broken.

Choice of gcc - MacOS

$
0
0

Dear all,

I am currently encountering problems of detecting the "right gcc" to pick up by my intel compiler.
I installed a gcc compiler alongside of the given clang compiler (by CommandLineTools).
I also created a symlink so that the command 'gcc' is linked to my custom gcc compiler.

However, I keep having includes problem since using icc, it keeps looking for clang includes instead of gcc ones. For example, it looks in the following folder: /Library/Developer/CommandLineTools/usr/include/c++/v1

How can I force it to run with my custom gcc (-gcc-name etc are not available on macOS)?

Thank you for you help.
Best

 

ICC 17 Update 5: Access Violation After Upgrading to VS2017 15.5.0

$
0
0

Just upgraded my VS2017 from 15.4.4 to 15.5.0 and now the Intel Compiler (17 update 5) crashes with numerous access violations on multiple solutions/projects (seemingly at random).

Wondering if anyone else has experienced the same?

1>------ Rebuild All started: Project: sstask, Configuration: Release x64 ------
1>log.cpp
1>main.cpp
1>src\app.h(20): error : access violation
1>     class app_t : public thread_t, public threadable_t
1>           ^
1>
1>syncobj.cpp
1>taskdispatcher.cpp
1>src\taskdispatcher.h(71): error : access violation
1>              return FetchCompletedTasks([&]()
1>                     ^
1>
1>thread.cpp
1>src\thread.cpp(325): error : access violation
1>        m_target = (t_obj ? &(*t_obj) : null);
1>                               ^
1>
1>threadpool.cpp
1>src\app.h(20): error : access violation
1>     class app_t : public thread_t, public threadable_t
1>           ^
1>
1>timer.cpp
1>src\timer.h(24): error : access violation
1>     class timer_t
1>           ^
1>

Bug: _DecimalXXX not defined in dfp754.h with /Qintel-extensions-

$
0
0

In Intel 2018 Update 1 under VS2017 15.5.0:

Setting /Qintel-extensions- (disable Intel extensions) caused a flood of errors related to decimal floating point values referenced in dfp754.h:

Error        identifier "_Decimal32" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    55    
Error        identifier "_Decimal64" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    56    
Error        identifier "_Decimal128" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    57    
Error        identifier "_Decimal32" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    58    
Error        identifier "_Decimal64" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    59    
Error        identifier "_Decimal128" is undefined    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    60    
Error        "_Decimal32" is not a type name    sstask    C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2018\windows\compiler\include\dfp754.h    63    

This file is #included at the bottom of <math.h> which is a general purpose #include that should not be predicated upon the presence of Intel intrinsics and extensions. Many standard headers implicitly pull in math.h.

This behavior is new to ICC 18 and does not occur in prior releases.

The source of the error appears to be this preprocessor directive in dfp754.h:

#if (((defined __cplusplus) && ((defined(_GLIBCXX_DECIMAL)) || ((defined(__INTEL_COMPILER)) && ((defined(_WIN32)) || (defined(_WIN64)))))) || ((!defined __cplusplus) && (defined __STDC_WANT_DEC_FP__) && (defined __STDC_DEC_FP__)))

This clause "((defined(__INTEL_COMPILER)) && ((defined(_WIN32)) || (defined(_WIN64))))))" universally qualifies the inclusion of this header for all Windows targets.

Workaround:

Add /D__DFP754_H_INCLUDED to suppress inclusion of this header or enable Intel intrinsics and extensions.

 

OpenMP untied task and taskyield does not work as expected

$
0
0

Hi,

I tried to implement untied OpenMP tasks that yield when a modeled idle time due to synchronization is encountered. The code is available at stack overflow: https://stackoverflow.com/questions/47658571/how-to-yield-resume-openmp-untied-tasks-correctly

It turns out that icc 18.0.1 supports yielding for non-master threads, icc 17.0.4 did not. However, tasks still seem to be tied, since the allocated thread always resumes its suspended tasks. There is no task migration! Furthermore, I noticed that tied tasks, i.e. when you remove the "untied" option from the code, do not yield at all, but I think they should.
Actually, I would expect the "tied" code to behave exactly like the given "untied" one does with the present compiler. The expected "untied" behavior cannot be achieved.

Are there any restrictions in the OpenMP runtime? Where are they documented? Or is this a bug?

Best regards

Georg Geiser

Viewing all 2797 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>