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

Cause for remark #11074: Inlining inhibited by limit max-size

$
0
0

#11074: Inlining inhibited by limit max-size
#11074: Inlining inhibited by limit max-total-size
#11076: To get full report use -qopt-report=4 -qopt-report-phase ipo

 

I recently started getting these remarks when building a set of C++ files with the Intel compiler. I would like to know more about what it's trying to communicate, but haven't found much online. It's even omitted from the diag-dump list.

 

Does anyone have more information on it? I'd like to be able to 'fix' the root cause and remove it from my list of diag-disable warnings.

 

Thanks!

 


__builtin_isinf, __builtin_isnan, __builtin_isfinite not working on Mac OS X 10.10

$
0
0

On Mac OS X 10.10.5 using Intel compiler version 16.0.0 the functions __builtin_isnan, __builtin_isinf, and __bultin_isfinite are not implemented correctly.

Here is a minimal test-case against the Intel compiler:

 

#include <iostream>
#include <cmath>

int main(int argc, char const * argv[])
{
    std::cout
        << std::isnan(0.0/0.0)    << ""<< __builtin_isnan(0.0/0.0)    << "\n"<< std::isinf(1.0/0.0)    << ""<< __builtin_isinf(1.0/0.0)    << "\n"<< std::isfinite(1.0/0.0) << ""<< __builtin_isfinite(1.0/0.0) << "\n";
}

which when compiled with icpc -fp-model strict test.cpp -o test prints

1 0
1 0
0 1

Thanks.

 

Building Android* Applications Using Microsoft* Visual Studio* IDE [vs-android Enabled]

$
0
0

This topic applies to C++, Windows*, and Android* only.

If you have integrated the vs-android plugin with Microsoft* Visual Studio* v2010, 2012 or 2013, you can build Android* applications using the Intel® C/C++ Compiler from within the IDE.

Note

The vs-android plugin is not supported for Microsoft* Visual Studio* 2015.

Selecting Intel® C++ Compiler in Visual Studio* IDE

To select Intel® C++ Compiler instead of other compilers in Visual Studio, follow these steps:

  1. Create a Visual C++* project, or open an existing project.

  2. In Solution Explorer, select the project(s) to build with Intel® C++ Compiler.

  3. Go to Project > Properties. The Property Pages dialog opens.

  4. Select the Configuration Properties> General category. Under General property list, change Platform Toolset to one of the available x86 icc toolchains.

    Note

    The list of available toolsets contains a corresponding toolset for each installed Intel® C++ Compiler.



  5. Under Project Defaults property list, change Target Architecture to x86 Architecture (x86).

  6. Click OK to save and close the Property Pages dialog.

Selecting this toolset ensures that Intel® C++ Compiler is used for building your projects. Check the display of Intel-specific property pages and properties.

You can now proceed to use the Intel® Compiler to build Android* applications via Microsoft Visual Studio*. For details on how to use Visual Studio*, check Visual Studio* documentation on www.microsoft.com.

gnu-prefix

$
0
0

Lets you specify a prefix that will be added to the names of gnu utilities called from the compiler.

Syntax

Linux OS:

-gnu-prefix=prefix

OS X:

None

Windows OS:

None

Arguments

prefix

Is a string that prepends the name of gnu tools called from the compiler. The value depends on the gnu toolchain used for a particular operating system. For example, for Wind River* Linux 6.x, the prefix value will be x86_64-wrs-linux-. You must append a hyphen to prefix only if the toolchain prefix ends with a hyphen.

You can specify a short name or a pathname:

  • short name: -gnu-prefix=prefix

    In this case, the compiler calls prefix<gnu_utility> instead of <gnu_utility>. The utility with this name should be in the PATH environment variable.

  • pathname: -gnu-prefix=/directory_name/prefix

    In this case, the compiler calls /directory_name/prefix<gnu_utility>. The utility with this name will be invoked by its full pathname.

Default

OFF

The compiler calls gnu utilities by their short names, and looks for them in the path specified by the PATH environment variable.

Description

This option lets you specify a prefix that will be added to the names of gnu utilities called from the compiler. This option is available for Linux*-targeted compilers but the host may be either Windows* OS or Linux* OS.

If you specify option -gnu-prefix with option -gcc-name (or -gxx-name), the following occurs:

  • If a name specified in -gcc-name (or -gxx-name) contains a full path to a binary then option -gnu-prefix has no effect on the specified name; other binutils will have the prefix.

  • Otherwise, option -gnu-prefix is applied to the name specified in -gcc-name (or -gxx-name).

The above approach provides flexibility to specify an alternative gcc name outside of the default toolchain. At the same time, if a short name is provided in option -gcc-name, it is assumed to be a part of the default toolchain and a prefix will be added.

Instead of using option -gnu-prefix, you can create symlinks for the short names of gnu utilities in the toolchain and add them to the PATH. For example, ld--> i686-wrs-linux-gnu-ld.

Note

Even though this option is not supported for a Windows-to-Windows native compiler, it is supported for a Windows-host to Linux-target compiler.

IDE Equivalent

None

Alternate Options

None

Example

Consider that you are setting up the compiler to produce an application for a Wind River* Linux 6.

Assume that your gnu cross toolchain for the target OS is located in the following directory:

/WRL/60/x86_64-linux/usr/bin/x86_64-wrs-linux

and gnu utilities in the toolchain have prefixx86_64-wrs-linux-.

Assume your sysroot for the target OS is located in the following directory:

/WRL/60/qemux86-64

To compile your application for Wind River* Linux 6, you must enter the following commands:

export PATH=/WRL/60/x86_64-linux/usr/bin/x86_64-wrs-linux:PATH
icc --sysroot/WRL/60/qemux86-64 -gnu-prefix=x86_64-wrs-linux- app.c

The following examples show what happens when you specify both -gcc-name and -gnu-prefix.

Example 1:

Command line: -gcc-name=foobar –gnu-prefix=em64t-
Actual gcc name used in the compiler: em64t-foobar
ld name used in the icc: em64t-ld

Example 2:

Command line: -gcc-name=/a/b/foobar –gnu-prefix=em64t-
Actual gcc name used in the compiler: /a/b/foobar
ld name used in the icc: em64t-ld

See Also

Building Android* Applications Using Eclipse* IDE and Android* NDK

$
0
0

By default, the Android* NDK is configured to build an application for debugging within Eclipse* and all optimizations are turned off. When the code is ready for deployment, you must compile it for performance.

  1. Open Application.mk in your application’s jni folder at %NDK_DIR%\samples\hello-jni\jni\.

  2. To switch to the release mode, add the following line:

    APP_OPTIM=release

  3. To target a specific processor, for example, to build application to run on the Intel® Atom™ processor, add the following line:

    APP_CFLAGS:=-xATOM_SSSE3

  4. To enable advanced optimizations of Intel® C++ Compiler, for example, to increase the optimization level, add the following line:

    APP_CFLAGS:=-xATOM_SSSE3 –O3
    

  5. To enable interprocedural optimizations, add:

    APP_CFLAGS:=-xATOM_SSSE3 –O3 –ipo
    

  6. Build the application.

Note

The APP_OPTIM and APP_CFLAGS can be given as arguments in building from the command line. Here is an example:

>>ndk-build V=1 -B APP_ABI=x86 NDK_TOOLCHAIN:=x86-icc APP_OPTIM=release
APP_CFLAGS=”-xATOM_SSSE3 –O3 -ipo”

platform

$
0
0

Specifies the target platform for cross compilation.

Syntax

-platform=default|<target platform>|<embedded target platform>

Arguments

default

Disables previously defined -platform, --sysroot, and -gnu-prefix values and forces compiler to generate code for the default target, which could be, for example, Linux*.

target platform

Can be any one of the following, if supported:

qnx640

Specifies the QNX* Neutrino* RTOS target.

mvl50

Specifies the MontaVista* Linux* OS target.

netbsd51

Specifies the NetBSD* OS target.

wrl30

Specifies the Wind River* Linux* OS target.

embedded target platform

Can be any one of the following, if supported:

android

Specifies the Android* target.

celpr28

Specifies the CE Linux* OS target.

wrl43

Specifies the Wind River* Linux* OS v4.3 target.

wrl50

Specifies the Wind River* Linux* OS v5.0 target.

yl12

Specifies the Yocto* Project OS v1.2 target.

yl13

Specifies the Yocto* Project OS v1.3 target.

Description

This option specifies the target platform for cross compilation. If you do not specify the -platform option, the compiler will build a Linux* operating system native application. If you do not specify an argument, you will receive an error message. Using the default value for the option disables previously defined values for -platform option as well as for -gnu-prefix, and --sysroot options, and forces the compiler to generate code for the default target platform.

Example 1:

To compile a C language source file (for example, my_source_file.c ) for a QNX target, use a command similar to the following:

icc -platform=qnx640 my_source_file.c

Example 2:

To compile a C language source file (for example, my_source_file.c ) for an Android* target, use a command similar to the following:

icc -platform=android my_source_file.c

See Also

Building Android* Applications from Command Line

$
0
0

This topic applies to C/C++ on Windows* and OS X* host systems.

You can build applications for Intel architecture-based Android* devices in two ways:

  • Using the Intel® C++ Compiler toolchain as a standalone compiler

  • Enabling the Intel toolchain within the Android NDK build system

Note

For Android* version 5.0 and later, you must use the -fpie and -pie options to generate position-independent code while building dynamically linked executables with the Intel® Compiler for ISS.

Install the 64-bit Android* NDK from http://developer.android.com/sdk/ndk/index.html or the Android* Open Source Project (AOSP) from http://source.android.com/. Refer to the Release Notes for supported NDK versions.

When you install the Intel® C++ Compiler, the installation program integrates the compiler into the Android NDK build system automatically. Note that the Intel® C++ Compiler is the default compiler for Intel architecture-based targets for NDK revisions 9, 9b, 9c, 9d, 10d, and later.

Using Intel® C++ Compiler Toolchain as Standalone Compiler

The Intel C++ Compiler requires a GNU compiler toolchain for the Android* OS to work.

Perform the following steps on Linux* host systems:

  1. Open a terminal window.

  2. Set up the environment for the Intel Compiler using the compilervars file. See Using compilervars File for details.

Perform the following steps on a Windows* host system:

  1. Open the setup environment window, from Start Menu > Intel System Studio 2016 for Linux and Android targets > Compiler and Performance Libraries > Command Prompt with Intel Compiler v16.0 > IA-32 Android [or Intel 64 Android].

    A command prompt window opens up with the prompt at Program Files (x86)\IntelSWTools.

  2. Change directory to \compilers_and_libraries_2016.x.yyy\windows\bin where the compilervars.bat is located.

  3. Set up the environment for the Intel Compiler using the compilervars.bat file. See Using compilervars File for details.

If you see errors requesting to set up ANDROID_SYSROOT and ANDROID_GNU_X86_TOOLCHAIN environment variables, the possible reason is that you used an unsupported NDK version during installation. In such a case, you can set up the environment variables manually.

Using the NDK environment:

If you installed the 32-bit version of the Android NDK, set the environment variables as follows:

//On Linux* system
$ export NDK_DIR=[Android NDK-install-directory]
$ export ANDROID_SYSROOT=$NDK_DIR/platforms/android-18/arch-x86
$ export ANDROID_GNU_X86_TOOLCHAIN=$NDK_DIR/toolchains/x86-4.6/prebuilt/linux-x86
//On Windows* system>>set NDK_DIR=[Android NDK-install-directory]>>set ANDROID_SYSROOT=%NDK_DIR%\platforms\android-18\arch-x86>>set ANDROID_GNU_X86_TOOLCHAIN=%NDK_DIR%\toolchains\x86-4.6\prebuilt\windows-x86

If you installed the 64-bit host version of the Android NDK, set the environment variables as follows :

//On Linux* system
$ export NDK_DIR=[Android NDK-install-directory]
$ export ANDROID_SYSROOT=$NDK_DIR/platforms/android-18/arch-x86
$ export ANDROID_GNU_X86_TOOLCHAIN=$NDK_DIR/toolchains/x86-4.6/prebuilt/linux-x86_64
//On Windows* system>>set NDK_DIR=[Android NDK-install-directory]>>set ANDROID_SYSROOT=%NDK_DIR%\platforms\android-18\arch-x86>>set ANDROID_GNU_X86_TOOLCHAIN=%NDK_DIR%\toolchains\x86-4.6\prebuilt\windows-x86_64

Using the AOSP environment:

If you are using the AOSP environment on a Linux* host, set the variables as follows:

export TOPDIR= #set to the AOSP root directory (example: /export/JB_WW36)
export ANDROID_SYSROOT=$TOPDIR/prebuilts/ndk/8/platforms/android-17/arch-x86
export ANDROID_GNU_X86_TOOLCHAIN=$TOPDIR/prebuilts/gcc/linux-x86/x86/i686-linux-android-4.6

Compiling Source Code

You are now ready to use icc/icpc from a command line in the build environment to compile C/C++ source code.

Here is an example on Linux* host:

$ cd $NDK_DIR/samples/hello-jni/jni
$ icc -platform=android -c hello-jni.c
$ icc -platform=android –shared -o libhello-jni.so hello-jni.o

Enabling Intel Toolchain within Android NDK Build System

To understand how to enable the Intel toolchain within the Android* NDK build system, follow the steps to build the hello-jni sample application that ships with the Android NDK. You can locate the sample in $NDK_DIR/samples/hello-jni/jni/.

Build the sample application with the Intel® C++ Compiler either from the command line or using the *.mk file. In either approach, you need to configure APP_ABI if you want to use ICC. If multiple versions of the Intel compiler are installed, a full compiler package version can be specified. For example, with the Intel® C++ Compiler XX.x, use:

NDK_TOOLCHAIN=x86-iccXX.x.y.nnn
where XX is the major version, x is the minor version, y is the update number, and nnn is the package build number.

From the command line

  1. Open the terminal window and navigate to the jni folder of the sample:

    cd $NDK/samples/hello-jni

  2. Enter the following command:

    $ $NDK_DIR/ndk-build V=1 -B APP_ABI=x86_64 NDK_TOOLCHAIN:=x86_64-icc  // 64-bit Linux host
    >>%NDK_DIR%\ndk-build V=1 -B APP_ABI=x86_64 NDK_TOOLCHAIN:=x86_64-icc // 64-bit Windows host

    where:

    V=1 enables verbose output (optional)

    -B means rebuild all (optional)

    APP_ABI indicates target architecture.

Using the Application.mk file

  1. Open or create the Application.mk file in your application’s jni folder at $NDK_DIR/samples/hello-jni/jni/.

  2. Add the following lines in Application.mk:

    • For 32-bit targets:

      APP_ABI:=x86
      NDK_TOOLCHAIN:=x86-icc
    • For 64-bit targets:

      APP_ABI:=x86_64
      NDK_TOOLCHAIN:=x86_64-icc
  3. Run the command to build the application:

    $ $NDK_DIR/ndk-build V=1 –B    // on Linux* host
    
    >>%NDK_DIR%\ndk-build V=1 –B   // on Windows* host
    

warning #69: integer conversion resulted in truncatio

$
0
0

Getting a warning with icpc (icpc (ICC) 15.0.3 20150407)

/n/dv/src/icc/releases/bin/icpc -std=c++14 -m32 -lstdc++ test.cc
test.cc(7): warning #69: integer conversion resulted in truncation
    test = (std::bitset<128> (0x0123456789abcdefULL << 36));

#include<iostream>
#include<bitset>

int main()
{
  std::bitset<128> test;
  test = (std::bitset<128> (0x0123456789abcdefULL << 36));
  std::cout<<test;
  std::bitset<128> value = (std::bitset<128>(0x1234567890123456) << 64) | std::bitset<128>(0x1234567890123456);
  std::cout<<value;
}

but g++ works

/n/sw/gen/gcc/x86-64/gcc-4.9.2/bin/g++ -std=c++14 -m32 test.cc

a.out
0000000000000000000000000000000000000000000000000000000000000000100110101011110011011110111100000000000000000000000000000000000000010010001101000101011001111000100100000001001000110100010101100001001000110100010101100111100010010000000100100011010001010110

 

any help will be apprecitated.

 

 

 

 

 


Android* Platform

$
0
0

Intel® C++ Compiler is compatible with the GCC compiler in the Android* NDK and can be used to develop applications for x86-based devices running on Android target systems. The Android NDK can be downloaded from http://developer.android.com/sdk/ndk/index.html.

With the Intel compiler and Android NDK you can develop Android applications on Windows* or Linux* hosts.

Note

For Android* version 5.0 and later, you must use the -fpie and -pie options to generate position-independent code while building dynamically linked executables with the Intel® Compiler for ISS.

Debugger does not work with ICC 16.0.0

$
0
0

Hi,

I've updated to  ICC 16 and I see the following error in GDB:

../build/buildd/gdb-7.7.1/gdb/dwarf2read.c:19061: internal-error: follow_die_offset: Assertion `dwarf2_per_objfile->reading_partial_symbols' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

 

My system settings:

OS: ubuntu 14.04

ICC:icpc (ICC) 16.0.0 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved

GDB: GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

Please help!!!!

BTW, Intel's debugger gdb-ia seems to be working fine

 

 

 

 

 

Alignment in x86 is Broken for Inheritance

$
0
0

Here is a simple program demonstrating the problem. Both "static_assert"s should pass, but only the first does.

//__declspec(align(16)) class Vec3 {}; //For testing purposes on Windows
//class Vec3 {} __attribute__((__aligned__(16))); //For testing purposes on *nix

class Base { public:
    Vec3 v;
};
class Child : public Base {};

static_assert(alignof( Base)>=16,"Check 1");
static_assert(alignof(Child)>=16,"Check 2");

Error while building OpenFOAM with intel compilers!

$
0
0

I was able to build openfoam 3.0.0 few day back ,
but today on recompiling  i am facing some issues , though i have requested help from openfoam team , but since intel compilers are involved here , so i am potting this issue here also .
from error log i was able o sense that the following line was causing error:

mpiicpc -std=c++0x -fp-trap=common -fp-model precise -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -diag-disable 2304 -xHost -O2  -DNoRepository -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/finiteVolume/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/dynamicFvMesh/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/dynamicMesh/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/meshTools/lnInclude -IlnInclude -I. -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/OpenFOAM/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/topoChangerFvMesh/topoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/rawTopoChangerFvMesh/rawTopoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/movingConeTopoFvMesh/movingConeTopoFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/topoChangerFvMesh/topoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/rawTopoChangerFvMesh/rawTopoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/movingConeTopoFvMesh/movingConeTopoFvMesh.o -L/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/lib             -lfiniteVolume -ldynamicFvMesh -ldynamicMesh -lmeshTools  -o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/lib/libtopoChangerFvMesh.so

so i manually removed redundant files, & the following worked fine!
 

mpiicpc -std=c++0x -fp-trap=common -fp-model precise -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -diag-disable 2304 -xHost -O2  -DNoRepository -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/finiteVolume/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/dynamicFvMesh/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/dynamicMesh/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/meshTools/lnInclude -IlnInclude -I. -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/OpenFOAM/lnInclude -I/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/topoChangerFvMesh/topoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/rawTopoChangerFvMesh/rawTopoChangerFvMesh.o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/src/topoChangerFvMesh/movingConeTopoFvMesh/movingConeTopoFvMesh.o  -L/home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/lib             -lfiniteVolume -ldynamicFvMesh -ldynamicMesh -lmeshTools  -o /home/cc/vfaculty/puneets.vfaculty/OpenFOAM/OpenFOAM-3.0.0/platforms/linux64IccDPInt32Opt/lib/libtopoChangerFvMesh.so

 

What might be causing this ? is these a intel specific/generic compilation flag(s) which can ignore errors of these kind?
Any help/hint will be very useful!

Performance Tools for Software Developers - Differences between evaluation, non-commercial and release compilers

$
0
0

Evaluation of Intel® Software Development Tools

Before purchasing a license for one of our products you may wish to first evaluate the compilers, libraries and tools. To request a free evaluation license please visit the Intel® Software Development Tools page to locate the product that best suits your needs.

Note: Evaluation versions of Intel® compilers, available from the Intel® Software Development Tools, are identical to release compilers of the same version.

Free Intel® Software Development Tools

Intel offers free software to qualified academic researchers, students, educators and open source contributors. To find out if you quality for a free software license please visit our Free Intel® Software Development Tools.

Similarly, Intel compilers which are part of the Free Software Tools are identical to release compilers of the same version.

Downloading the Compilers

Up-to-date Intel compilers are available from the Intel Registration Center under the product Downloads column and may be used with any non-expired commercial, evaluation, or non-commercial license.

Have questions?

Check out the Licensing FAQ
Or ask* in our Intel® Software Development Products Download, Registration & Licensing forum

* If you have a question be sure to start a new forum thread

  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • C/C++
  • Fortran
  • Intel® C++-Compiler
  • Intel® Fortran Compiler
  • Concurrent install of Intel Parallel Studio XE 2013 and Intel Parallel Studio XE 2016

    $
    0
    0

    I need to keep the older version of the Intel compiler on my system. I am currently using Studio XE 2013 with MSVC 2010. 

    I would like that configuration to stay active when I install Studio XE 2016. However, during installation it just uninstalled any previous integration with MSVC 2010 and installed its own new integration. I would only like to use the new Intel compiler with MSVC 2015 and would like to continue using the old compiler with MSVC2010. 

    Is there a way to turn off this installation step? Is this a configuration that is generally supported?

    error MSB 6006: "icl" exited with code -1073741819 with Visual Studio 2010 in [Debug|x64] configuration

    $
    0
    0
    Reference Number: DPD200378181
    Version:
        Intel C++ Compiler 16.0 from Intel(R) Parallel Studio XE 2016 RTM and Update 1
    Operating System: Windows

    Problem Description:

    When building the "Debug | x64" configuration of an application with Intel C++ Compiler 16.0 in Visual Studio 2010*, you will get an error below:

    c:\program files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\Intel C++ Compiler 16.0\Microsoft.Cpp.x64.Intel C++ Compiler 16.0.targets (344, 5): error MSB 6006: "icl" exited with code -1073741819

    Note: this issue happens only within Visual Studio 2010* IDE and the [Debug|x64] configuration.

    Resolution Status:

    This issue has been fixed and will be in the coming update release. Please use the following work-around:

    1. Open “Project Properties -> Configuration Properties -> C++ -> Code Generation [Intel C++].
    2. Set "Additional Options for MIC Offload Compiler" property to "-v"
  • Microsoft Windows* 10
  • Microsoft Windows* 8.x
  • Intel® C++-Compiler
  • URL

  • Unpredictable results in OpenMP code fixed by inlining function

    $
    0
    0

    I have a rather complex, large code in C parallelized with OpenMP and Intel C compiler 16.0.1.159. The code produced slightly different results in every run until I did a fix shown below (not because of data races, as discussed below). I cannot explain this fix, and it is not satisfactory anyway. In addition, there was an intermediate fix, which also looked strange. On top of that, I ran the code through Intel Inspector, and it did not detect any data races. Unfortunately, I could not come up with a minimal reproducer.

    Could somebody help with a hypothetical explanation of what I am observing?

    Initial code implementation was somewhat like this, and it produced bad results (different results from one run to another). The real code has many more levels of function nesting than shown, but this, I think, is a good prototype:

    void FuncA(DataType* d) {
      *d = ...;
    }
    
    void FuncB(DataType* d){
      FuncA(d);
    }
    
    void FuncC(DataType** data){
    #pragma omp parallel for
      for (int i = 0; i < n; i++) {
         FuncB(data[i]);
      }
    }

     

    Fix #1 shown below - putting the call to the innermost function in a critical region - worked (code produced correct results):

    void FuncA(DataType* d) {
      *d = ...;
    }
    
    void FuncB(DataType* d){
    #pragma omp critical
      {
        FuncA(d);
      }
    }
    
    void FuncC(DataType** data){
    #pragma omp parallel for
      for (int i = 0; i < n; i++) {
         FuncB(data[i]);
      }
    }

     

    Fix #2 shown below - putting the entire body of the innermost function in a critical region - did not work, code produced different results every run. Question 1: why does this not work when Fix #1 works?

    void FuncA(DataType* d) {
    #pragma omp critical
      {
        *d = ...;
      }
    }
    
    void FuncB(DataType* d){
      FuncA(d);
    }
    
    void FuncC(DataType** data){
    #pragma omp parallel for
      for (int i = 0; i < n; i++) {
         FuncB(data[i]);
      }
    }

     

    Finally, Fix #3 shown below - declaring the innermost function as inline - kind of worked. The code produced correct results every time at the point where the original code failed, however, results crumbled later in the execution:

    inline void FuncA(DataType* d) {
      *d = ...;
    }
    
    void FuncB(DataType* d){
      FuncA(d);
    }
    
    void FuncC(DataType** data){
    #pragma omp parallel for
      for (int i = 0; i < n; i++) {
         FuncB(data[i]);
      }
    }

     

     

    Question 2: the last case makes me think that OpenMP perhaps has a limit on the call stack depth. Is that correct?

     

    Once again, I am as sure as I can be that there are no memory leaks or data races in FuncA or FuncB. This was verified by eye as well as by Intel Inspector.

    Parallel Studio XE 2015 wne FORTAN udated broke CPP VS2015 Inegration

    $
    0
    0

    Hello,

    I had VS2015 integrated with XE2015 CPP, and on the last update, CPP updated followed by FORTRAN, and now I only see FORTRAN integrated with VS2105. How do I get CPP back?

     

    -Steve

     

    Diagnostic 15333: simd loop was not vectorized: exception handling for a call prevents vectorization

    $
    0
    0

    Diagnostic message:"Simd loop was not vectorized: exception handling for a call prevents vectorization"

    This diagnostic message is emitted starting from Intel®  C++ Compiler 16.0 Update 1 version

    Cause:

    This diagnostic message is emitted because the compiler automatically generates a try block for the program block (i.e. code inside {})  when it sees any local object or array created in that block, as those objects/arrays need to be de-allocated in case an exception is thrown.

    Example: In the example below, the function main contains an array allocation so the try block is created.

    %cat main.cpp
    __attribute__((vector)) void f1(double);int main() {
      int n = 10000;
      double a[n];
    #pragma simd
      for(int i = 0 ; i < n ; i++)
          f1(a[i]);}

    % icpc -V
    Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 15.0.5.232 Build 20150805

    % icpc -O3 -qopenmp -qopt-report-file=stdout -c main.cpp

    Intel(R) Advisor can now assist with vectorization and show optimization

      report messages with your source code.

    See "https://software.intel.com/en-us/intel-advisor-xe" for details.
    ....
    ….
     Report from: Interprocedural optimizations [ipo]

    INLINE REPORT: (main()) [1] main.cpp(3,12)

    main.cpp(7): (col. 3) warning #13379: loop was not vectorized with "simd"
      
    Report from: Loop nest, Vector & Auto-parallelization optimizations [loop, vec, par]
    …..
    .....
    LOOP BEGIN at main.cpp(7,3)
      remark #15333: simd loop was not vectorized: exception handling for a call prevents vectorization   [ main.cpp(8,7) ]
      remark #13379: loop was not vectorized with "simd"
    LOOP END

    Workaround:  If the called routine is marked as nothrow() the loop will be vectorized:

      __attribute__((vector, nothrow)) void SimdEnabledFunction(double);   

    % icpc -O3 -qopenmp -qopt-report-file=stdout -c main.cpp
    .......
    ........

    LOOP BEGIN at main.cpp(7,3)
       remark #15301: SIMD LOOP WAS VECTORIZED
    LOOP END
    ======================================

    NOTE: 

    With 15.X.X version of the compiler the diagnostic issued was different:

    LOOP BEGIN at main.cpp(7,3)
       remark #15520: simd loop was not vectorized: loop with early exits cannot be vectorized unless it meets search loop idiom criteria
     ....
    ==========================================

     

     

  • warning
  • error
  • remark
  • Entwickler
  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • C/C++
  • Intel® C++-Compiler
  • URL
  • Visual Studio 2015 Update 1

    $
    0
    0

    Just installed Visual Studio 2015 Update 1 and unfortunately Intel compiler 15 and 16 can not compile new updated headers (STL and co).

    Any info when this will be fixed ?

    thanks.

    Using global pointers to allocate memory on the MIC and reusing it

    $
    0
    0

    Hi all,

    I am using the offload programming model for my project. What I have is a global pointer that I use to allocate memory on the MIC. After doing some more computation on the host I then try to copy the results from host memory to the memory in the MIC using in() for host structure and nocopy() for the global pointer. The documentation and a few of the forum posts say that it should work however in my case it results in a segfault.

    What I read:

    https://software.intel.com/en-us/articles/effective-use-of-the-intel-com...

    The code is something like this:

    //This is global

    __attribute__((target(mic:0))) wildstruct* foo;

    #pragma offload target(mic:0) nocopy(foo) {

    foo = malloc(sizeof(foo));   //foo is then initialized later on in this offload region.

    }

    In another file:

    #pragma offload target(mic:0) in(anotherFoo[0:LENGTH]) nocopy(foo) {

    memset(foo,anotherFoo,sizeof(foo));    //segfaults here. foo is NULL which I believe should not be the case according to the documentation.

    }

    Thanks!

    Viewing all 1665 articles
    Browse latest View live


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