Problem : 

I observe that when I compiled the following test case using default flag, its working properly. When I disabled optimization using flag -O0, it working for array size 10000, but unfortunately its giving segmentation fault error for size 100000.

$ cat mytest1.c
// mytest1.c

#include <sys/time.h>
#include <time.h>
#include<stdio.h>

#define SIZE 1024 // Size = 1G
int main(int argc, char *argv[])
{
     float *a; //DB Init

     long i,size=0,j;
     float sum=0;
     int k=0;
     int return_value;


     sscanf(argv[1], "%ld", &size);
     printf("\n Size before Allocation = %ld\n",size);
     a=(float *) malloc (sizeof(float)* (size+128));

     printf("Value of return from malloc = %d",return_value);

     if (a == NULL){
         printf("\n\n ERROR: Memory Allocation not possible\n\n");
         exit(-1);
     }
     else
     {
         printf("Value of return pointer after memory allocation = %ld",a);
         printf("\n\n probing a[0]\n");
         a[0] = 0.;
         printf("probing a[%ld]\n", size-1);
         a[size-1] = 0.;
         printf("probing succeeded\n");
         return 0;
    }

    for(i=0;i< size; i++){
        sum+=a[i];
    }
    printf("\n Addition Complete, # of Element= %ld\n", size);
    free((void *)a);
    return 0;
}


$ icc -O0 mytest1.c
$ ./a.out 100000

Size before Allocation = 100000
Value of return pointer after memory allocation = -1788305392

probing a[0]
Segmentation fault

$ icc mytest1.c
$ ./a.out 100000

Size before Allocation = 100000
Value of return pointer after memory allocation = 182895288336

probing a[0]
probing a[99999]
probing succeeded


Environment : 

Intel C++ compiler, Linux x86_64

Root Cause : 

Implicitly declared malloc() returns improper address pointer and the application crashes. The compiler must know the function signature to handle it properly.

Resolution : 

Implicitly declared malloc() returns improper address pointer. The malloc() declaration in stdlib.h is as given below:

void * malloc ( size_t size );

The compiler must know the function signature to handle it properly. If we do not provide declaration to compiler, the compiler assumes that the value returned by the function is integer. This is called implicit declaration.

The implicit declaration will force void pointer returned from malloc() to integer, the integer is converted again to float pointer. These conversions results in improper value for returned memory address and the application crashes.

Problem : 

I am using the Intel® compiler and openMP* to parallelize some work as follows:

#pragma omp parallel num_threads(4)
{
DoWork();
}

I would d like to experiment with Intel's thread affinity feature for OpenMP but I a unsure of exactly how to use the environment variable (for example, where do I place the environment statement in my code?).

Could you give a little example showing proper usage and where to place the statement ?


Environment : 
Intel C++ compiler, Linux*, Mac OS* X, Windows*

Resolution : 


Intel thread affinity environment variable KMP_AFFINITY for openMP is explained in Compiler Intel® compiler user guide topic “Thread Affinity Interface (Linux* and Windows*)”. You may review the topic for detailed information.

There are many ways to set the thread affinity using KMP_AFFINITY. I am providing an example below. In the example I am mapping OpenMP threads 0, 1, 2 and 3 to OS processor 3, 2, 1 and 0 respectively.

$ cat tstcase.cpp
// tstcase.cpp
// Thread afinity interface
//


#include <omp.h>
#include <iostream>
using namespace std;

#define N 1000

int main ()
{
cout << "Starting openmp test." << endl;

int i;
float a[N], b[N], c[N], d[N];

/* Some initializations */
for (i=0; i < N; i++)
{
a[i] = i * 1.5;
b[i] = i + 22.35;
}

#pragma omp parallel shared(a,b,c,d) private(i)
{

#pragma omp sections nowait
{

// Section #1
//
#pragma omp section
{
cout << "Section #1." << endl;
for (i=0; i < N; i++)
c[i] = a[i] + b[i]; // End of section #1
a[0] = 3.45;
}

// Section #2
//
#pragma omp section
{
cout << "Section #2." << endl;
for (i=0; i < N; i++)
d[i] = a[i] * b[i]; // End of section #2
a[1] = 5.67;
}

} // End of sections

} // End of parallel

cout << "Exiting openmp test." << endl;
return 0;
}

$ icc -openmp tstcase.cpp
$ export KMP_AFFINITY="verbose,proclist=[3,2,1,0]"
$ ./a.out
OMP: Warning #63: KMP_AFFINITY: proclist specified, setting affinity type to "explicit".
Starting openmp test.
OMP: Info #149: KMP_AFFINITY: Affinity capable, using global cpuid instr info
OMP: Info #154: KMP_AFFINITY: Initial OS proc set respected: {0,1,2,3}
OMP: Info #156: KMP_AFFINITY: 4 available OS procs
OMP: Info #157: KMP_AFFINITY: Uniform topology
OMP: Info #159: KMP_AFFINITY: 2 packages x 2 cores/pkg x 1 threads/core (4 total cores)
OMP: Info #160: KMP_AFFINITY: OS proc to physical thread map ([] => level not in map):
OMP: Info #168: KMP_AFFINITY: OS proc 0 maps to package 0 core 0 [thread 0]
OMP: Info #168: KMP_AFFINITY: OS proc 2 maps to package 0 core 1 [thread 0]
OMP: Info #168: KMP_AFFINITY: OS proc 1 maps to package 3 core 0 [thread 0]
OMP: Info #168: KMP_AFFINITY: OS proc 3 maps to package 3 core 1 [thread 0]
OMP: Info #147: KMP_AFFINITY: Internal thread 0 bound to OS proc set {3}
OMP: Info #147: KMP_AFFINITY: Internal thread 1 bound to OS proc set {2}
OMP: Info #147: KMP_AFFINITY: Internal thread 2 bound to OS proc set {1}
OMP: Info #147: KMP_AFFINITY: Internal thread 3 bound to OS proc set {0}
Section #1.
Section #2.
Exiting openmp test.

Problem : 

During installation, an error message of "Error while copying license file. Please make sure you have write permission to the license folder" will result if the user does not have write permission to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.

Environment : 

Mac OS X, Intel Compiler 11.1

A related article pertaining to Mac OS X, Intel Compiler 9.1, 10.1, 11.0 can be found here.


Root Cause : 

The error "Error while copying license file. Please make sure you have write permissions to the license folder." will appear if the user does not have write permission to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.

This directory by default has write permission enabled, however, installation of other third party products such as Adobe products might change the permission for this directory. This change in permission will result in an error during installation of Intel(R) Compiler Products because the installer can not create a license file in this directory.

Even if the user provide their own license file instead of a serial number, the error will still occur if the installer can not copy the license to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.



Resolution : 

Assuming that you have a valid serial number or product license, the solution is to enable write permission for the directory Users/Shared/Library/Application\ Support/Intel/Licenses.

Problem : 
A question on the setup scripts of the Intel 11.0.064 compiler.

If one sets up the Intel compile by sourcing /opt/intel/Compiler/11.0/064/bin/iccvars.csh intel64 then can one do a 32bit build with this setup if the compile line has arch i386 or -m32 in it? Is the Intel compiler behaves like gcc? Can it do both 32 bit and 64 bit builds from the same compiler setup ?

What about the other way. If one sets up the the 11.0/064/bin/iccvars.csh ia32 compiler, can it do 64 bit builds with -m64 or -arch x86_64.

Is there a difference in the ia32 and intel64 compilers ?


Environment : 

Linux, MAC OS, Intel C++ compiler


Resolution : 

The Intel C++ compiler 11.0 is a native Intel 64 application on Intel 64 Linux. The older versions used to be a 32-bit cross compiler in the past. The compiler can generate native Intel64 code and cross compile 32-bit code. The Intel C++ compiler on ia32 Linux is the classic 32-bit which installs and runs on both 32-bit and Intel64 systems and can generate 32-bit code and cross compile Intel64 code.

Users were asking for native Intel64 compilers on Intel64 systems to handle larger binaries to meet their needs, so Intel created the native Intel64 compiler.

Problem : 
I encounter an error when compiling "parameter of abstract class type "type" is not allowed", as described in http://software.intel.com/en-us/articles/cdiag646/. Does anybody know why and how to fix it?

Environment : 
Windows, Linux, Mac and Intel C++ compiler.


Resolution : 


The problem is you are trying to declare a parameter that has the type of an abstract base class.

Abstract classes are designed to be only interfaces to real classes because they have one or
more pure virtual functions, i.e.:
class abstract {
virtual void foo() = 0; // pure virtual function since it is declared with = 0
};
void foo(abstract); // not allowed since the class is abstract

The workaround would be to only use pointers or references to the abstract class as parameters, or change the type to a non-abstract class that is derived from the abstract class or change the class so it is no longer abstract, i.e. define the virtual functions instead of declaring them pure virtual.

Problem : 

The Intel® C++ compiler for Linux compiles the code on the m/cs with gcc 4.1.3 but fails on m/cs with gcc 4.3. On the latest gcc it needs a header
#include <locale>

Without this, using the locale methods is in error, apparently.


Environment :  Linux*, MacOS X*


Resolution : 
The Intel C++ compiler uses the gcc development environment in use. If you set the environment to use gcc 4.1 then icc will use headers from gcc 4.1. If you set gcc 4.3 development environment, icc will use gcc 4.3 headers.

Intel compiler is matching the behavior of the active gcc from which it inherits the headers and library.

The following code when compiled under gcc 4.1.2 development environment using Intel C++ compiler 11.0.083 compiles without any problem. When compiling the same under gcc 4.3.2 development environment the Intel C++ compiler gives error. When we use “#include <locale>” l header it works. The gcc also exhibit same behavior.

// tst_locale.cpp

#include <iostream>
#include <sstream>
#include <time.h>

#ifdef NEED_LOCALE_HEADER
#include <locale>
#endif


using namespace std;

class DateTime {
public:
DateTime();
virtual ~DateTime() {}
operator tm() const;
protected:
long i;
};

class EpsBufr {
public:
EpsBufr();
virtual ~EpsBufr() {};
void doit();
protected:
DateTime base_;
};

DateTime::operator tm() const
{
struct tm tm_date = tm();
return tm_date;
}

void EpsBufr::doit() {

ostringstream out;
tm convert = base_;
locale loc("");
const std::time_put<char>& tfac = use_facet<time_put<char> >(loc);
string format = "Forecast VT %A %e %B %Y %H UTC";
tfac.put(out, out, ' ', &convert, format.c_str(), format.c_str()+format.length());
}

$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/spdtools/compiler/ia32e/gcc-4.3.2 --with-gcc --enable-languages=c,c++
Thread model: posix
gcc version 4.3.2 (GCC)

$ icc -V
Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.0 Build 20090318 Package ID: l_cproc_p_11.0.083
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$icc -c tst_local.cpp
tst_local.cpp(45): error: incomplete type is not allowed
tfac.put(out, out, ' ', &convert, format.c_str(), format.c_str()+format.length());
^

/net/spd64/opt/spdtools/compiler/ia32e/gcc-4.3.2/bin/../include/c++/4.3.2/bits/locale_classes.tcc(112): error: incomplete type is not allowed
const size_t __i = _Facet::id._M_id();
^
detected during instantiation of "const _Facet &std::use_facet<_Facet>(const std::locale &) [with _Facet=std::time_put<char, std::ostreambuf_iterator<char, std::char_traits<char>>>]" at line 43 of "tst_local.cpp"

compilation aborted for tst_local.cpp (code 2)

$ icc -c -DNEED_LOCALE_HEADER tst_local.cpp

Problem : 

I was looking for "fasm-blocks" decription in "Intel C++ Compiler User & Reference Guide" (304968-022US) which seems to be the latest document with release of ICC-v11.0. The agnostic about it is "fasm-blocks" works with ICC-11.0 on Linux x86_64 but the descriptions about "fasm-blocks" is missing.

Could Intel describe it's meaning, uses, also demonstrate with an example currently and latter incorporate in it's feature forthcoming ICC documents.

Can I have Intel Assembler latest documents or it's links to download w.r.t Intel 64 on Linux x86_64 where one can understand and analyze Intel Assembly language?


Environment : 

Linux* and MacOS X*

Resolution : 


Intel C++ compiler uses gcc development environment on Linux and MAC. It supports GNU inline style assembly.

Intel C++ compiler also supports Microsoft style inline assembly format in Linux. You can use -use-msasm to tell the compiler. The -fasm-blocks is also seems to be working.

The -fasm-blocks option is provided on MAC for Microsoft style inline assembly.

These options are described in Intel C++ compiler documentation, Document number: 304968-022US. There is small description of the inline assembly implementation in Intel C++ compiler in "Inline Assembly" topic.

I am providing the code sample from the Intel C++ compiler documentation below for easy reference:

---------------------------------------- gnu style inline assembly ------------------
$ cat tstcase_gnu.cpp
// inline assembly
// tstcase_gnu.cpp

#ifdef _WIN64
#define INT64_PRINTF_FORMAT "I64"
#else
#define __int64 long long
#define INT64_PRINTF_FORMAT "L"
#endif
#include <stdio.h>
typedef struct {
__int64 lo64;
__int64 hi64;
} my_i128;
#define ADD128(out, in1, in2) \
__asm__("addq %2, %0; adcq %3, %1" :\
"=r"(out.lo64), "=r"(out.hi64) : \
"emr" (in2.lo64), "emr"(in2.hi64), \
"0" (in1.lo64), "1" (in1.hi64));
extern int main()
{
my_i128 val1, val2, result;
val1.lo64 = ~0;
val1.hi64 = 0;
val2.hi64 = 65;
ADD128(result, val1, val2);
printf("0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
val1.hi64, val1.lo64);
printf("+0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
val2.hi64, val2.lo64);
printf("------------------------------------\n");
printf("0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
result.hi64, result.lo64);
return 0;
}


---------------------------------------- Microsoft style inline assembly ------------------

$ cat tstcase_msasm.cpp
// inline assembly
// tstcase_msasm.cpp

#ifdef _WIN64
#define INT64_PRINTF_FORMAT "I64"
#else
#define __int64 long long
#define INT64_PRINTF_FORMAT "L"
#endif
#include <stdio.h>
typedef struct {
__int64 lo64;
__int64 hi64;
} my_i128;
#define ADD128(out, in1, in2) \
{ \
__asm mov rax, in1.lo64 \
__asm mov rdx, in1.hi64 \
__asm add rax, in2.lo64 \
__asm adc rdx, in2.hi64 \
__asm mov out.lo64, rax \
__asm mov out.hi64, rdx \
}

extern int main()
{
my_i128 val1, val2, result;
val1.lo64 = ~0;
val1.hi64 = 0;
val2.hi64 = 65;
ADD128(result, val1, val2);
printf("0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
val1.hi64, val1.lo64);
printf("+0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
val2.hi64, val2.lo64);
printf("------------------------------------\n");
printf("0x%016" INT64_PRINTF_FORMAT "x%016" INT64_PRINTF_FORMAT "x\n",
result.hi64, result.lo64);
return 0;
}

You would need -use-msasm compiler option to compile tstcase_msasm.cpp. The -fasm-blocks is also seems to be working on Linux but this is intended for MAC OS.