Reference Number : DPD200178014


Version : IDB for Mac OS* X 10.7 Lion, v12.1 ( Updates 6, 7, 8, and possible future updates)


Product : Composer XE 2011 for Mac OS* X


Operating System : Mac OS* X 10.7


Problem Description : IDB debugger does not load default images produced by IFORT or ICC/ICPC:
"Could not start process for ...
No image loaded ... Recovering ... "



Resolution Status :

Mac OS* X Lion, by default, defaults to building executables with Position Independent Executable (PIE) code.  However, the Intel IDB debugger does not currently (as of Composer XE 2011 Updates 6, 7, 8, and 9) support debugging of PIE executables. 

To work around this, IFORT and ICC/ICPC can be directed to produce non-PIE executables.  The following options are required to produce an executable that IDB can process:

-g -save-temps -fpic -Wl,-no_pie

This affects the Intel Composer XE 2011 compilers running on Mac OS* X 10.7 Lion ONLY.  Users of Mac OS* X 10.6 (Snow Leopard) or 10.5 (Leopard) are not affected and need only the -g -save-temps options for creation of debuggable executables.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Introduction : The Intel C++ and Fortran compilers for Windows* and Linux* provide 'legacy' and 'compatibility' implementations of the OpenMP THREADPRIVATE directive (-Qopenmp-threadprivate:[compat | legacy], -openmp-threadprivate [compat | legacy]).  The 'compat' option should not be used when everything is compiled by Intel compilers. Doing some may result in application crashes or incorrect results. In this case, the 'legacy' option (which is the default) should be used.  The 'compat' option should only be used when some of the objects in an application have been compiled by a compatible Microsoft* or GNU* compiler.

Version : 11.x, 12.x


Application Notes : -Qopenmp-threadprivate:legacy (-openmp-threadprivate legacy) is the default when -Qopenmp (-openmp) is specified.  This setting does not provide compatibility with the THREADPRIVATE implementation used by other compilers. -Qopenmp-threadprivate:compat (-openmp-threadprivate compat) can be used when some of the objects in an application have been compiled by a compatible Microsoft* or GNU* compiler.  This setting provides compatibility with the implementation provided by the Microsoft* and GNU* compilers.


Building the Application : -Qopenmp (-openmp) must be given when using -Qopenmp-threadprivate (-openmp-threadprivate), or the compiler will not recognize the OpenMP THREADPRIVATE directive (warning #161: unrecognized #pragma).


Known Issues or Limitations : On Mac OS* X systems, 'legacy' is the only type of THREADPRIVATE implementation supported. Option '-openmp-threadprivate' is not recognized by the compiler.

Problem : I compile a program on a Mac OS X 10.6 system, but run the binary on an older Mac OS X system such as 10.5 or 10.4.  The program aborts immediately without starting with error "dyld:  unknown required load command 0x80000022"


Environment : Mac OS X, mixed OS versions.  Intel Fortran Compiler for Mac OS X, Intel C++ Compiler for Mac OS X


Root Cause :
Generally, if you are targeting your applicaiton to run on multiple versions of Mac OS X, you should use the 'least common denominator' approach of developing on the older OS version.  This is because newer version may have extended the base OS API but generally newer versions will maintain backwards compatibility.

Resolution :
Although there is no guarantee for backwards compatibility, if you have a newer version of Mac OS X as your development platform, follow these guidelines:

compile and link with option   -static-intel   ( for older compilers, -i-static )
Pass linker option:     -Wl,-macosx_version_min,10.4
so
ifort -static-intel -Wl,-macosx_version_min,10.4   ...other options...
icc -static-intel -Wl,-macosx_version_min,10.4   ...other options...
icpc -static-intel -Wl,-macosx_version_min,10.4   ...other options...

The -static-intel will statically link all Intel compiler runtime libraries into your executable so that you will not need these DYLD libraries on the target computer.

The -Wl,-macosx_version_min,10.4  passes the argument  -macosx_version_min 10.4

to your ld linker.  This tells the linker to create headers and sections for the executable that are backwards compatible to Mac OS X 10.4.  Another option might be 10.5.  Please read your 'ld' man page or documentation for allowed options.

EXCEPTION:  the linker provided with Xcode 4.0.1 on Snow Leopard is rejecting the -macosx_version_min option, although it is documented in the 'ld' man page.  We believe this is a recent bug in the Apple linker and hope that it is addressed shortly ( Apr 2011 )

Reference Number : dpd200139115,  dpd200138937  (documentation).


Version : 2011, (compiler version 12);  compiler pro versions 10 and 11


Product : Intel(R) Composer XE; Intel(R) Compiler Pro


Operating System : Windows*, Linux*, Mac OS* X

Problem Description : 
If the switch /Qftrapuv (-ftrapuv) for run-time detection of uninitialized local scalar variables is used in conjunction with optimization flags such as /O2 (-O2), it may lead to unexpected floating-point exceptions that are not related to uninitialized variables.

Explanation : 
The switch /Qftrapuv (-ftrapuv)  sets local, scalar variables that are not otherwise initialized to an "unusual" initial value such as 0xCCCCCCCC. When the main program is compiled with this switch, it also unmasks the "INVALID" floating-point exception. so that exceptions may be raised when the "unusual" values are used in floating-point operations. The switch also changes the default optimization level from /O2 to /Od (from -O2 to -O0). This is so that exceptions will not be raised as a result of speculated floating-point operations or other optimizations. If the new default optimization level of /Od (-O0) is explicitly overridden, optimizations such as floating-point speculation associated with masked vector operations may result in INVALID exceptions that would not otherwise have been raised.


Solution:
Either:  Do not override the default /Od (-O0) optimization level when using /Qtrapuv (-ftrapuv).   (Sometimes, it may be sufficient to use /Qfp-speculation:safe (-fp-speculation safe) in conjunction with -O2).
or (Fortran only):   Use the switch /check:uninit (-check uninit)  in preference to /Qtrapuv (-ftrapuv) for the run-time detection of uninitialized, local scalar variables. This uses a different mechanism for uninitialized variable detection that is less likely to produce unrelated floating-point exceptions.

Intel(R) Inspector XE, a component of Intel(R) Parallel Studio XE,  may also be used for the detection of some instances of uninitialized variables.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Message

To parallelize the loop at line 123, annotate the routine "foo" with "__declspec(const)". [VERIFY] Make sure the routine satisfies the semantics of this annotation. [ALTERNATIVE] A weaker annotation that can achieve a similar effect is "__declspec(concurrency_safe(profitable))". [VERIFY] Make sure the routine satisfies the semantics of this annotation.

Description

If the loop contains a call to a function, the compiler cannot parallelize the loop without more information about the function being called.

However, if the function being called in the loop is a const function (C/C++), or an elemental function (F2003), or a concurrency-safe function, then the call does not inhibit parallelization of the loop.

This message advises you to provide information about the functions being called that helps parallelization.

Example (in C language)

#define N 10000
double A[N], B[N];
int bar(int);
void foo(){
  int i;
  for (i=0;i<N;i++){
    A[i] = B[i] * bar(i);
  }
}

In this case, the compiler does not parallelize the loop because it is not safe to do so without further information about routine bar being called. The C/C++ compiler generates a message of this form:

id30526.c(6): remark #30526: (PAR) To parallelize the loop at line 6, annotate the routine "bar" with "__declspec(const)". [VERIFY] Make sure that the routine satisfies the semantics of this annotation. [ALTERNATIVE] A weaker annotation that can achieve a similar effect is "__declspec(concurrency_safe(profitable))". [VERIFY] Make sure that the routine satisfies the semantics of this annotation.

If you decide it is safe, the src-code can be modified as follows:

#define N 10000
double A[N], B[N];
__declspec(const) int bar(int);
void foo(){
  int i;
  for (i=0;i<N;i++){
    A[i] = B[i] * bar(i);
  }
}

The following is another way the code can be modified if it is safe to do so:

#define N 10000
double A[N], B[N];
__declspec(concurrency_safe(profitable)) int bar(int);
void foo(){
  int i;
  for (i=0;i<N;i++){
    A[i] = B[i] * bar(i);
  }
}

Verify

Make sure the routine satisfies the semantics of this annotation. A weaker annotation that can achieve a similar effect is __declspec(concurrency_safe(profitable)).

Message

Add "__declspec(const)" to the declaration of routine "foo" in order to parallelize the loop at line 123. Alternatively, adding "__declspec(concurrency_safe(profitable))" achieves a similar effect. [VERIFY] Make sure that the routine satisfies the semantics of this declaration. [ALTERNATIVE] Yet another way to help the loop being parallelized is to inline the routine with "#pragma forceinline recursive". This method does not guarantee parallelization.

Description

Make sure that the routine specified is indeed a const function or a concurrency-safe function before following the advice to add the annotation.

If the routine is not one of these kinds of functions, then another thing you can try is to inline it with #pragma forceinline recursive. This action may or may not be beneficial.

Example (in C language)

#define N 10000
double A[N], B[N];
int bar(int);
void foo(){
  int i;
  for (i=0;i<N;i++){
    A[i] = B[i] * bar(i);
  }
}

In this case, the compiler does not parallelize the loop because it is not safe to do so without further information about routine bar, which is being called. The compiler generates a message of this form:

id30528.c(6): remark #30528: (PAR) Add "__declspec(const)" to the declaration of routine "bar" in order to parallelize the loop at line 6. Alternatively, adding "__declspec(concurrency_safe(profitable))" achieves a similar effect. [VERIFY] Make sure that the routine satisfies the semantics of this declaration. [ALTERNATIVE] Yet another way to help the loop being parallelized is to inline the routine with "#pragma forceinline recursive". This method does not guarantee parallelization.

If you determine it is safe to do so, you can add the pragma as follows:

#define N 10000
double A[N], B[N];
void foo(){
  int i;
#pragma forceinline recursive
  for (i=0;i<N;i++){
    A[i] = B[i] * bar(i);
  }
}

Verify

Make sure that the routine satisfies the semantics of this declaration. Another way to help the loop being parallelized is to inline the routine with the forceinline recursive pragma, but this method does not guarantee parallelization.

Message

Store the value of the upper-bound expression (foo->len) of the loop at line 123 into a temporary local variable, and use this variable as the new upper-bound expression of the loop. To do this, insert a statement of the form "temp = foo->len" right before the loop, where "temp" is the newly created local variable. Make sure to choose a variable name that is unique. Then replace the loop's original upper-bound expression with "temp". [VERIFY] Make sure that the value of the upper-bound expression does not change throughout the entire execution of the loop.

Description

This message advises you to use a local-variable for the loop upper-bound if the upper-bound does not change during the execution of the loop. This enables the compiler to recognize the loop as a proper counted doloop which in turn enables various loop optimizations including vectorization and parallelization.

This message appears when the compiler can output the exact upper-bound variable to be replaced.

Example (in C/C++ language)

typedef struct
{
    float*      data;
} Vector;

typedef struct
{
    int         len;
} NetEnv;

// This one does not vectorize
void
mul(
    NetEnv*     ne,
    Vector*     rslt,
    Vector*     den,
    Vector*     num)
{
    float*      r;
    float*      d;
    float*      n;
    int i;

    r = rslt->data;
    d = den->data;
    n = num->data;

    for (i = 0; i < ne->len; ++i)
    {
        r[i] = n[i] * d[i];
    }
    return;
}

In this case, the compiler is unable to vectorize the loop at /O2, the default. Adding the /Qguide option produces the following message:

id30532.c(28): remark #30532: (LOOP) Store the value of the upper-bound expression (ne->len) of the loop at line 28 into a temporary local variable, and use this variable as the new upper-bound expression of the loop. To do this, insert a statement of the form "temp = ne->len" right before the loop, where "temp" is the newly created local variable. Make sure to choose a variable name that is unique. Then replace the loop's original upper-bound expression with "temp". [VERIFY] Make sure that the value of the upper-bound expression does not change throughout the entire execution of the loop.

If you determine it is safe to do so, you can modify the program code as follows:

typedef struct
{
    float*      data;
} Vector;

typedef struct
{
    int         len;
} NetEnv;

// This one vectorizes
void
mul(
    NetEnv*     ne,
    Vector*     rslt,
    Vector*     den,
    Vector*     num)
{
    float*      r;
    float*      d;
    float*      n;
    int i, local_len;

    r = rslt->data;
    d = den->data;
    n = num->data;

    local_len = ne->len;
    for (i = 0; i < local_len; ++i)
    {
        r[i] = n[i] * d[i];
    }
    return;
}

Message

Store the value of the upper-bound expression of the loop at line 123 into a temporary local variable, and use this variable as the new upper-bound expression of the loop. To do this, insert a statement of the form "temp = upper-bound of loop" right before the loop, where "temp" is the newly created local variable. Make sure to choose a variable name that is unique. Then, replace the loop's original upper-bound expression with "temp". [VERIFY] Make sure that the value of the upper-bound expression does not change throughout the entire execution of the loop.

Description

This message advises you to use a local-variable for the loop upper-bound if the upper-bound does not change during the execution of the loop. This enables the compiler to recognize the loop as a proper counted doloop which in turn enables various loop optimizations including vectorization and parallelization.

This message appears when the compiler cannot output the exact upper-bound variable to be replaced.

Example (in C/C++ language)

class FooClass  {
public:
    const int getValue() { return m_numTimeSteps;}
        void Foo2(double*  vec);
private:
        int m_numTimeSteps;
};
void FooClass::Foo2(double*  vec)
{
        // this will not vectorize
        for (int k=0; k < m_numTimeSteps; k++)
                vec[k] = 0.0;
 
        // this will not vectorize
        for (int k=0; k < getValue(); k++)
                vec[k] = 0.0;
 
        // this will vectorize
        int ub1 = m_numTimeSteps;
        for (int k=0; k < ub1; k++)
                vec[k] = 0.0;
 
        // this will vectorize
        int ub2 = getValue();
        for (int k=0; k < ub2; k++)
                vec[k] = 0.0;
}

Verify

Make sure that the value of the upper-bound expression does not change throughout the entire execution of the loop.