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

icc 17.0.1 miscompiles valid C code at -O3 on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O2 small.c; ./a.out; echo $?
8
$
$ icc -O3 small.c; ./a.out; echo $?
9
$
$ cat small.c
struct
{
  unsigned char f0;
} a, *b = &a, c, *e = &c;

int d, f;

int main ()
{
  for (f = 0; f < 2; f++)
    a.f0 = 0;
  for (; a.f0 != 8; a.f0 = (unsigned) a.f0 + 9)
    while (d)
      ;
  *e = *b;
  return c.f0;
}
$

 


icc 17.0.1 crashes on valid C code at -Os and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 -c small.c
$
$ icc -Os -c small.c": internal error: 0_76

compilation aborted for small.c (code 4)
$
$ cat small.c
int a, b;

void fn1 ()
{
  int c[4] = { 3 };
  for (; b; b++)
    {
      int i;
      c[a] = b ^ i;
    }
}
$ 

 

icc 17.0.1 miscompiles valid C code (compiled code segfaults) at -Os and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ cat small.c
struct
{
  int f0:24;
  volatile int f1;
} a = {-8, 0}, c[1];

volatile int b, g, i = -8;
int d, h;
unsigned int e;

int main ()
{
  if (!(d < 1 && a.f0 > b))
    g = a.f0;
  a.f0 = a.f0 && h;
  e = g - 5;
  b = i % e;
  if (b < d)
    c[120].f1;
  if (h)
    while (1)
      ;
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code (compiled code SIGFPE) at -Os and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 small.c; ./a.out
$
$ icc -Os small.c
$ ./a.out
Floating point exception (core dumped)
$
$ cat small.c
struct
{
  int f0:2;
  int f1:2;
} f = {0, 1};

int a = 3, b, d;
volatile unsigned int c;
char e, g;

int main ()
{
  for (; a; a--)
    {
      char h = ~1 ^ d;
      d = b >> 0 / h;
      int j;
      if (!(e || f.f0 > c))
        j = b;
      f.f0 = g = b = j;
    }
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code (compiled code SIGFPE) at -O1 and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O0 small.c; ./a.out
$
$ icc -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$
$ cat small.c
volatile struct S
{
  int f:4;
} b;

int a, c = 1, d;

int main ()
{
  for (; a < 2; a++)
    {
      for (; d < 1; d++)
        b.f = 1;
      b.f = 0 % b.f - 1;
      if (!(c && b.f < 0))
        b.f = 0;
    }
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code at -O3 on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O2 small.c; ./a.out; echo $?
1
$
$ icc -O3 small.c; ./a.out; echo $?
0
$
$ cat small.c
short a = 1, b, c;

void fn1 ()
{
  for (b = 5; b != -1; b -= 7)
    {
      while (c)
        c++;
      if (!b)
        return;
    }
  a = 0;
}

int main ()
{
  fn1 ();
  return a;
}
$

 

icc 17.0.1 miscompiles valid C code at -O1 and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O0 small.c; ./a.out
1
$
$ icc -O1 small.c; ./a.out
0
$
$ cat small.c
int printf (const char *, ...);

static long a;

int foo (int b)
{
  if (0)
    if (1)
      return a;
  return b;
}

int main ()
{
  printf ("%d\n", foo (1));
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code at -Os and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 small.c; ./a.out; echo $?
0
$
$ icc -Os small.c; ./a.out; echo $?
1
$
$ cat small.c
char a[1];

int main ()
{
  unsigned long b = ~0;
  if (!a[0])
    b = 0;
  if (a[0])
    while (1)
      if (a[b])
        break;
  return !a[0] && b;
}
$

 


icc 17.0.1 miscompiles valid C code at -O1 and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O0 small.c; ./a.out; echo $?
1
$
$ icc -O1 small.c; ./a.out; echo $?
0
$
$ cat small.c
struct
{
  int f:2;
} volatile a = { -1 };

int b = 1;

int main ()
{
  short c = 0;
  if (!(!b || a.f > 0))
    c = 1;
  return c;
}
$

 

icc 17.0.1 miscompiles valid C code at -O2 and -O3 on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -Os small.c; ./a.out; echo $?
1
$
$ icc -O2 small.c; ./a.out; echo $?
0
$ icc -O3 small.c; ./a.out; echo $?
0
$
$ cat small.c
struct S { char f; };

int a, b, *c = &b;

struct S foo ()
{
  struct S d = { 1 };
  for (; a < 1; a++)
    if (d.f)
      *c = 1;
  return d;
}

int main ()
{
  foo ();
  return b;
}
$

 

Memset/cpy slower in icpc-17 than icpc-12

$
0
0

Hi all,

   We've noticed some strange behaviour with the Intel C++ compiler that we cannot explain. Our project is currently compiled with the Intel Compiler 12.1.0258 and we are looking at making performance improvements. One area we have identified is memory intensive parts of the code, where memset and memcpy can become performance bottlenecks. We develop for Mac, Linux and Windows and are aware that due to the Mac's system architecture memcpy is typically slower on this platform than Linux. I have noticed some improvements in Mac OS with Intel 17, however some very odd behaviour with Linux.

Bellow is a CPP example for testing timing I have been using:

#include <iostream>
#include <sys/time.h>
#include <cstdlib>
#include <cstring>


#define N_BYTES 1073741824

typedef  long long ll;

long long current_timestamp() {
    struct timeval tv;
    gettimeofday(&tv, NULL); // get current time

    ll milliseconds = tv.tv_sec * 1000LL + tv.tv_usec / 1000;

    return milliseconds;
}

int main(int argc, char** argv)
{
	//Alloc some memory
	char* mem_location = (char*) malloc(N_BYTES);

	//'Warm' the memory
	memset(mem_location,1,N_BYTES);

	//Now time how long it takes to tset it to something else
	ll memset_begin = current_timestamp();
	memset(mem_location,0,N_BYTES);
	ll memset_time = current_timestamp() - memset_begin;

	std::cout << "Memset of "<< N_BYTES << " took "<< memset_time << "ms\n";

	return 0;
}

The output is as follows:

[after setting compilervars.sh]

$ icpc -v

icpc version 17.0.1 (gcc version 4.4.7 compatibility)

$ icpc MemsetTime.cpp -o MemsetTime-icpc17

$ ./MemsetTime-icpc17

Memset of 1073741824 took 143ms

$ g++ -v

[...]

gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)

$ g++ MemsetTime.cpp -o MemsetTime-gpp4.4.7

$ ./MemsetTime-gpp4.4.7

Memset of 1073741824 took 50ms

 

..and in a fresh shell, with Intel 12 (again sourcing relevant compilevars)

$icpc -v

$icpc version 12.1.0 (gcc version 4.4.7 compatibility)

$icpc MemsetTime.cpp -o MemsetTime-icpc12

$ ./MemsetTime-icpc12

Memset of 1073741824 took 50ms

 

So it would appear that in Linux, the Intel 17 compiler uses an implementation of memset that takes nearly 3 times as long to run as gcc and Intel 12! After looking in VTune, I see that Intel 12 is using '_intel_fast_memset' and Intel 17 is using '_intel_avx_rep_memset'. Something even stranger is that when I compile under icpc17 with -g, the timing goes down to 50ms, and uses _GI_memset.

 

Has anyone else experienced this? Is there something in my timing logic that is not accurately representing the time taken for memset? These examples are all on Linux, on MacOS the timings are consistently at around the 50ms point.

 

Thanks!

Alastair

Memory leak in ICC 17?

$
0
0

Today I decided to try ICC 2017 Update 1. Halfway into my project the build computer seemed to hang up. I figured out that icpc allocates all RAM (24 GB) even when running with one thread. I restarted the computer and tried again - still the same issue. The code compiles just fine with ICC 2013. I am running on Debian 8. When I killed the process, the following was printed on the command line:

*** Error in `/opt/intel/compilers_and_libraries_2017.1.132/linux/bin/intel64/icpc': double free or corruption (!prev): 0x0000000002001b20 ***

Has anybody else had this issue?

icc 17.0.1 miscompiles valid C code at -O1 and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O0 small.c; ./a.out
0
$
$ icc -O1 small.c; ./a.out
1
$
$
$ cat small.c
int printf (const char *, ...);

int a[1];
static char b = 1;

int foo ()
{
  while (0)
    while (1)
      return b;
  return a[0];
}

int main ()
{
  printf ("%d\n", foo ());
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code at -O1 and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O0 small.c; ./a.out
0
$
$ icc -O1 small.c; ./a.out
1
$
$ cat small.c
int printf (const char *, ...);

static char a = 1;
int b;

void fn1 () {}

int fn2 ()
{
  int d = 0;
  while (0)
    {
      fn1 ();
      return a;
    }
  return d;
}

int main ()
{
  printf ("%d\n", fn2 ());
  return 0;
}
$

 

icc 17.0.1 miscompiles valid C code at -Os and above on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O1 small.c; ./a.out; echo $?
0
$
$ icc -Os small.c; ./a.out; echo $?
255
$
$ cat small.c
short a = 2;

int main ()
{
  while (a)
    a -= 3;
  return a;
}
$

 


icc 17.0.1 miscompiles valid C code at -O3 on x86_64-linux-gnu

$
0
0

Compiler version and platform: 

Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005 

$ icc -O2 small.c; ./a.out
0
$
$ icc -O3 small.c; ./a.out
-1
$
$ cat small.c
int printf (const char *, ...);

int a, b, c, d = 1, e, f;

void foo ()
{
  for (c = 0; c < 2; c++)
    {
      if (d)
        {
          if (a && e)
            continue;
          b = c;
          c = b;
        }
      break;
    }
}

int main ()
{
  foo ();
  printf ("%d\n", c);
  for (f = 0; f < 2; f++)
    ;
  return 0;
}
$

 

Parallel Studio XE Installer PATH environment variable size has exceeded its limit.

$
0
0

I get the following error trying to install Parallel Studio

but my PATH looks like this

 

FFT Compilation Error

$
0
0

Hi .

I am trying to run benchfft with linking Intel-mkl but I am getting error with ” undefined reference to `zfft1d_'

System Details:

OS: Ubuntu 16.04

GCC: gcc version 5.4.0 20160609

ICC: icc version 17.0.0

Note: File benchfftw_test_mkl.c is attached with this report

source /opt/intel/mkl/bin/mklvars.sh intel64

gcc -lmkl_core  -ldl -lpthread -lm benchfftw_test_mkl.c

 

Error:

/tmp/ccsL8FHu.o: In function `main':

benchfftw_test_mkl.c:(.text+0xa): undefined reference to `zfft1d_'

collect2: error: ld returned 1 exit status

 

Contents of benchfftw_test_mkl.c is as follows

#line 10867 "configure"
/* confdefs.h.  */

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "benchfft"
#define VERSION "3.1"
#ifdef __cplusplus
#include <stdlib.h>
#endif
#define F77_FUNC(name,NAME) name ## _
#define F77_FUNC_(name,NAME) name ## _
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define HAVE_MALLOC_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_UNISTD_H 1
#define HAVE_STRING_H 1
#define HAVE_ALLOCA_H 1
#define HAVE_STDDEF_H 1
#define HAVE_LIBINTL_H 1
#define TIME_WITH_SYS_TIME 1
#define HAVE_ALLOCA_H 1
#define HAVE_ALLOCA 1
#define HAVE_STDLIB_H 1
#define HAVE_MALLOC 1
#define HAVE_VPRINTF 1
#define HAVE_LIBM 1
#define HAVE_GETTIMEOFDAY 1
#define HAVE_DRAND48 1
#define HAVE_HYPOT 1
#define HAVE_SQRT 1
#define HAVE_STRTOD 1
#define HAVE_MEMSET 1
#define HAVE_MEMALIGN 1
#define HAVE_DECL_DRAND48 1
#define HAVE_DECL_HYPOT 1
#define HAVE_LIBPTHREAD 1
#define HAVE_LIBDL 1
#define HAVE_FFTW3_H 1
/* end confdefs.h.  */

/* Override any gcc2 internal prototype to avoid an error.  */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
   builtin and then its argument prototype would still apply.  */
char zfft1d_ ();
#ifdef F77_DUMMY_MAIN
#  ifdef __cplusplus
     extern "C"
#  endif
   int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
zfft1d_ ();
  ;
  return 0;

}

Using Intel-compiled libraries in non-Intel-Compiled projects

$
0
0

Hi,

I have been given a few libraries for Windows and OSX that have been compiled using the Intel C++ compiler (both statically and dynamically linked versions are available).  I am using MSVC 2012 on Windows, and XCode 8 on OSX and I am trying to use those libraries in projects that are not using the Intel compiler.  I have only tried this on Windows so far, but even the statically linked libraries are trying to pull in additional dependencies (libmmt.lib).

Is it possible to use Intel compiled libraries this way, or does the whole tool-chain need to use the Intel compiler in order to work?

Thanks,

Charles

Thread Topic: 

Question

Intel(R) Parallel Studio XE 2017 emulator for linux (SDE)

$
0
0

Hi all,

I am a newbe for Parallel Studio,

I Trying to understand if there is a emulator that i can use and download that emulates the use of Xeon Phi Coprocessors.

As far as i know, I had found that there is a a SDE (sde-external-7.49.0-2016-07-07-lin.tar.bz2) that i can use.

Are there any pre requirements to this installation ?

What linux platform should i use ( or what is the most prefered by intel) ?

What does thhis SDE gives me ?

Is this SDE can emulate the use of multiple cores and the use of threads parallelism ?

And the last question, What is the best or prefered IDE that i can use ?

Thanks,

Nir Hadar

Zone: 

Viewing all 1175 articles
Browse latest View live


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