Hi,

The compiler update 2013SP1 requires mac osx 10.8 to be installed, as mentionned in the release notes. The previous version 2013 requires only 10.7.

Could the compiled application be deployed on the previous version mac osX  10.6 or 10.7 ? What is the minimal version of Mac OS for the deployed application.

I don't see this information in the release notes.

Mickaël, 

Hello.

I'm using Composer XE 2013 SP1 (version: 14.0.0 20130728).

I got an error, while compiling this code:

#include <tuple>
#include <memory>

int main()
{
    auto a = std::make_tuple(std::unique_ptr<char>(new char), 0);
    return 0;
}

Command line and comiper output is here:

icpc tmp.cpp -gcc-name=gcc-4.7 -std=gnu++11 -lstdc++ 

/usr/include/c++/4.7/type_traits(1251): error: function "std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp> &) [with _Tp=char, _Dp=std::default_delete<char>]" (declared at line 262 of "/usr/include/c++/4.7/bits/unique_ptr.h") cannot be referenced -- it is a deleted function
          static decltype(__test_aux<_To1>(std::declval<_From1>()), __one())
                                           ^
          detected during:
            instantiation of "std::__is_convertible_helper<_From, _To, false>::__test [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" based on template arguments <const std::unique_ptr<char, std::default_delete<char>> &, std::unique_ptr<char, std::default_delete<char>>> at line 1258
            instantiation of class "std::__is_convertible_helper<_From, _To, false> [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" at line 1265
            instantiation of class "std::is_convertible<_From, _To> [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" at line 117
            instantiation of class "std::__and_<_B1, _B2> [with _B1=std::is_convertible<const std::unique_ptr<char, std::default_delete<char>> &, std::unique_ptr<char, std::default_delete<char>>>, _B2=std::is_convertible<const int &, int>]" at line 848 of "/usr/include/c++/4.7/tuple"
            instantiation of "std::tuple<std::__decay_and_strip<_Elements>::__type...> std::make_tuple(_Elements &&...) [with _Elements=<std::unique_ptr<char, std::default_delete<char>>, int>]" at line 9 of "tmp.cpp"

compilation aborted for tmp.cpp (code 2)

If I compile this code with gcc compiler - there are no problem. What's wrong?

Hello.

My compiler version is: Intel Composer XE 2013 SP1 14.0.0 20130728

I can't compile succesfully this code:

#include <tuple>
#include <memory>
int main()
{
    auto a = std::make_tuple(std::unique_ptr<char>(new char), 0);
    return 0;
}

Command line is:

icpc tmp.cpp -gcc-name=gcc-4.7 -std=gnu++11 -lstdc++

Error message:

/usr/include/c++/4.7/type_traits(1251): error: function "std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp> &) [with _Tp=char, _Dp=std::default_delete<char>]" (declared at line 262 of "/usr/include/c++/4.7/bits/unique_ptr.h") cannot be referenced -- it is a deleted function
          static decltype(__test_aux<_To1>(std::declval<_From1>()), __one())
                                           ^
          detected during:
            instantiation of "std::__is_convertible_helper<_From, _To, false>::__test [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" based on template arguments <const std::unique_ptr<char, std::default_delete<char>> &, std::unique_ptr<char, std::default_delete<char>>> at line 1258
            instantiation of class "std::__is_convertible_helper<_From, _To, false> [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" at line 1265
            instantiation of class "std::is_convertible<_From, _To> [with _From=const std::unique_ptr<char, std::default_delete<char>> &, _To=std::unique_ptr<char, std::default_delete<char>>]" at line 117
            instantiation of class "std::__and_<_B1, _B2> [with _B1=std::is_convertible<const std::unique_ptr<char, std::default_delete<char>> &, std::unique_ptr<char, std::default_delete<char>>>, _B2=std::is_convertible<const int &, int>]" at line 848 of "/usr/include/c++/4.7/tuple"
            instantiation of "std::tuple<std::__decay_and_strip<_Elements>::__type...> std::make_tuple(_Elements &&...) [with _Elements=<std::unique_ptr<char, std::default_delete<char>>, int>]" at line 9 of "tmp.cpp"

compilation aborted for tmp.cpp (code 2)

What's wrong? If I'm compile it by the GCC compiler, there are no errors.

Thanks.

I'm trying to install Intel® C++ Composer XE for Linux (composer_xe_2013_sp1.0.080). It is the academic version (), and was downloaded about 1 hour ago.

I try to accept defaults before the actual install, but the installation program forces me to chose and installation directory. At the prompt, I enter "/opt", or "/opt/", or "/opt/intel", or "/opt/intel/". The installation program simply loops back around as if I did not enter anything.

I've run the program through `sudo`, and even dropped into a root terminal with `su -` to ensure sudo was not dropping too soon.

How do I fix this? Its incredibly annoying behavior.

Thanks in advance.

I'm using icc 14.0.0 on Xubuntu 13.04 and std::chrono::duration_cast returns results which are 1000 times too small. Here is the test code:

#include <iostream>
#include <chrono>
#include <thread>using namespace std;
int main()
{
   auto start = chrono::high_resolution_clock::now();
   this_thread::sleep_for(chrono::milliseconds(10));
   auto end = chrono::high_resolution_clock::now();
   cout << "chrono::duration [ns]: "<< chrono::duration_cast<chrono::nanoseconds>(end - start).count() << "n";
}

When built with icc (icc -std=c++11 clock.cpp) it produces:

chrono::duration [ns]: 10057

The same code built with gcc 4.8.1 (g++-4.8 -std=c++11 clock.cpp) produces a correct result:

chrono::duration [ns]: 10058344

The same problem occures when cast is made to microseconds or milliseconds.

icpc --version
icpc (ICC) 13.0.1 20121010

with attribute packed turn on gets this error:

test.cpp(27): error: invalid type conversion: "char *" to "const char (&)[7]"
   set(ms.data);

without the attribute packed it compiles fine.

is this correct behavior?

#include <iostream>
#include <string.h>

char msg[90];

//struct __attribute__((__packed__)) MyStruct
struct MyStruct                            
{
 char data[7];
};

void set( const char (&str)[7] )
{
memcpy(msg,str,7);
}

int main()
{
 char str[7];
 str[0] = '1';
 str[1] = 0;

 MyStruct ms;

 set(ms.data);
 set(str);
 std::cout << msg << std::endl;
 return 0;
}

Hi,

    I am running some climate models and met an annoying problem. If the climate model was compiled wih debug mode -O0 (using intel/12.1.9.293 and openmpi 1.4.3), then the running result is totally different from that running model compiled with -O3 option.

    Could someone please tell me if this is normal?  Should a model compiled with debug mode be used in production runs?

     Many thanks.

Cheers,

Lyndon.

Hello,

I am trying to build an open source software module with the intel compilers. I installed Visual Studio 2010 and Intel Composer XE 2013 +  Intel Fortran compiler. Now icl and ifort work fine but I can't find the icc C compiler? What did I miss? Do I need an additional package for plain C code?

Apple released Xcode 5.0 for OS* X 10.8 Mountain Lion 18 September 2013.

The Intel Compilers for OS* X currently do no support integration into Xcode 5.0.  We will support Xcode 5.0 in a future update release.  We recommend that customers NOT install Xcode 5.0 on their systems until we have support in the Intel Compilers.  At this time we do not have a date for the release of the Intel Compilers for OS* X.

ron

Greetings,

I am developing an API for the implementation of Mimetic finite Differences as part of my Ph.D. research. I am currently using:

[ejspeiro@node01 ~]$ icpc --version
icpc (ICC) 11.0 20081105
Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.

As I was coding a CCS Matrix implementation for my API, I came across a curious behavior: Given an array of length num_values_, say we need to count the number of zeros and non-zeros: My first raw approach was to insert an if clause testing for each values, as I traverse the array, but I noticed that I could just keep track of the non-zero values, and subtract this number from the total values. I thought I could then divide each value by itself thus creating a one, which could be casted out to int, and then be accumulated:

for (int ii = 0; ii < num_values_; ii++) {
  num_non_zero_ = num_non_zero_ + (int) (array[ii]/array[ii]);
}

But this clearly would yield an error because in the case of array[ii] being equal to zero, this code may crash... although it has not happened yet, while compiling with icpc... so my first question is... why? So I changed it to:

for (int ii = 0; ii < num_values_; ii++) {
  num_zero_ = num_zero_ + !(array[ii]);
}

In here, we keep track of of the number of zero values, under the assumption that denying any double number will result in 0, whereas the only way that such negation results in 1, is for the number to be 0.0. However, in the first approach, icpc will actually vectorize such loop:

icpc -c -O2 -Iinclude -MMD -MP -MF build/Release/Intel-Linux-x86/src/mtk_ccs_matrix.o.d -o build/Release/Intel-Linux-x86/src/mtk_ccs_matrix.o src/mtk_ccs_matrix.cc
src/mtk_ccs_matrix.cc(64): (col. 22) remark: LOOP WAS VECTORIZED.
src/mtk_ccs_matrix.cc(91): (col. 3) remark: LOOP WAS VECTORIZED.

However under my corrected approach, it does not...what do you guys think? How correct is my assumption on denying double values?

PS: If anyone have a comment on how to post better looking code, I would really appreciate it :) Thanks!

where can we download the intel fortran v11.1.059 and intel C++ v11.1.059? Can you give me a web link? Thanks!

www.pallavi-agarwal.com -Quℰen~@ℳuMbai ℰScoℛTs Sℰℛvicℰs!!O9987131609!!,ℳUMBAℐ Female EScℴℛT,ℳuMbaℐ iℕdepeℕdent escoℝts

www.pallavi-agarwal.com -Quℰen~@ℳuMbai ℰScoℛTs Sℰℛvicℰs!!O9987131609!!,ℳUMBAℐ Female EScℴℛT,ℳuMbaℐ iℕdepeℕdent escoℝts

www.pallavi-agarwal.com -Quℰen~@ℳuMbai ℰScoℛTs Sℰℛvicℰs!!O9987131609!!,ℳUMBAℐ Female EScℴℛT,ℳuMbaℐ iℕdepeℕdent escoℝts

Is there a pdf version of documentation for C++ Compiler 14.0 (e.g.  User and Reference Guide for the Intel® C++ Compiler 14.0) available?

where can we download the intel fortran v11.1.059 and intel C++ v11.1.059? Can you give me a web link? Thanks!

I've run into a problem recently with the v13.x series of the Intel C++ compiler. I previously documented the problem in some more detail at the following Stack Overflow post;

http://stackoverflow.com/questions/18927939/segfault-during-static-initi...

In short: if I have a system with a version of the Boost C++ libraries installed that was built using gcc, and I try to build a program using icpc that links to the Boost.Thread library, the resulting program yields a segmentation fault during static/global object initialization. Only this permutation of compilers causes a problem. If I build Boost using icpc, then I can build programs successfully using gcc or icpc. If I build Boost with gcc and build a test program using gcc, it also works just fine. I have duplicated this behavior on Ubuntu 12.04 and Ubuntu 13.04; the former should at least be a supported platform for this release of the compiler.

I haven't had the chance to try a newer version of the compiler, as my support period has expired. For this reason, I've also been unable to submit the issue to Intel's support, but I thought I would try here to see if any more information was available. It appears to be a bug in the Intel toolchain of some kind.

Steps to reproduce:

1. Start with an Ubuntu 12.04 system.

2. Download the latest version of the Boost C++ libraries: http://sourceforge.net/projects/boost/files/latest/download?source=files (note that I've been able to duplicate the problem using a few different versions of Boost, including 1.41, 1.53, 1.54, and the latest SVN version)

3. Extract the archive: tar xjf boost_1_54_0.tar.bz2

4. Build the library; it should default to the gcc toolset on Linux;
    cd boost_1_54_0
    ./bootstrap.sh
    ./b2 debug-symbols=on

5. After the build is complete, the resulting libraries are located in the ./stage/lib subdirectory. Save the following test program to the file "test.cc":
    #include <boost/version.hpp>
    #include <boost/thread.hpp>
    int main()
    {
        boost::this_thread::sleep(boost::posix_time::seconds(1));
    }

6. Now, build the program using icpc:
    icpc test.cc -o test -Lstage/lib -lboost_thread -lboost_system

7. Run the resulting program:
    ./test
    The program should die with a segmentation fault immediately. If you use a debugger, you can see that the fault occurs during static initialization.

8. Verify that the program should work using g++:
    g++ test.cc -o test -Lstage/lib -lboost_thread -lboost_system
    ./test
    The program should pause for one second and then exit successfully.

If anyone has any recommendations on how I should proceed, I would appreciate it. Thank you.

I've run into a problem recently with the v13.x series of the Intel C++ compiler. I previously documented the problem in some more detail at the following Stack Overflow post;

http://stackoverflow.com/questions/18927939/segfault-during-static-initi...

In short: if I have a system with a version of the Boost C++ libraries installed that was built using gcc, and I try to build a program using icpc that links to the Boost.Thread library, the resulting program yields a segmentation fault during static/global object initialization. Only this permutation of compilers causes a problem. If I build Boost using icpc, then I can build programs successfully using gcc or icpc. If I build Boost with gcc and build a test program using gcc, it also works just fine. I have duplicated this behavior on Ubuntu 12.04 and Ubuntu 13.04; the former should at least be a supported platform for this release of the compiler.

I haven't had the chance to try a newer version of the compiler, as my support period has expired. For this reason, I've also been unable to submit the issue to Intel's support, but I thought I would try here to see if any more information was available. It appears to be a bug in the Intel toolchain of some kind.

Steps to reproduce:

1. Start with an Ubuntu 12.04 system.

2. Download the latest version of the Boost C++ libraries: http://sourceforge.net/projects/boost/files/latest/download?source=files (note that I've been able to duplicate the problem using a few different versions of Boost, including 1.41, 1.53, 1.54, and the latest SVN version)

3. Extract the archive: tar xjf boost_1_54_0.tar.bz2

4. Build the library; it should default to the gcc toolset on Linux;
    cd boost_1_54_0
    ./bootstrap.sh
    ./b2 debug-symbols=on

5. After the build is complete, the resulting libraries are located in the ./stage/lib subdirectory. Save the following test program to the file "test.cc":
    #include <boost/version.hpp>
    #include <boost/thread.hpp>
    int main()
    {
        boost::this_thread::sleep(boost::posix_time::seconds(1));
    }

6. Now, build the program using icpc:
    icpc test.cc -o test -Lstage/lib -lboost_thread -lboost_system

7. Run the resulting program:
    ./test
    The program should die with a segmentation fault immediately. If you use a debugger, you can see that the fault occurs during static initialization.

8. Verify that the program should work using g++:
    g++ test.cc -o test -Lstage/lib -lboost_thread -lboost_system
    ./test
    The program should pause for one second and then exit successfully.

If anyone has any recommendations on how I should proceed, I would appreciate it. Thank you.

See the following example code:

Dear All,

I am running a Mac OS X 10.8.5 and a Mac OS X 10.6.8. Until recently I had no problem to compile complex projets that were using C, C++ and Fortran code using icc and ifort 13.0.0 (20120731). I recently upgraded to gcc48 from Mac Port and now I cannot compile anymore C++ code (C and Fortran are fine). I reinstalled icc but it does not help and I get stuck. The problem is clearly an incompatibility with the STL headers of gcc.

Any known solution? Thanks.

icc --version

icc (ICC) 13.0.0 20120731
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

icc -std=c++11 src/tpsa.cpp
/opt/local/include/gcc48/c++/bits/alloc_traits.h(555): error: invalid type for defaulted assignment operator
__allow_copy_cons& operator=(__allow_copy_cons&&) = default;
^

/opt/local/include/gcc48/c++/bits/random.h(117): error: expression must have a constant value
+ std::__lg(__m) + 2>::type _Tp2;
^

/opt/local/include/gcc48/c++/bits/random.h(1642): error: invalid union member -- class "std::mersenne_twister_engine<uint_fast32_t={uint32_t={unsigned int}}, 32UL, 624UL, 397UL, 31UL, 2567483615U, 11UL, 4294967295U, 7UL, 2636928640U, 15UL, 4022730752U, 18UL, 1812433253U>" has a disallowed member function
mt19937 _M_mt;
^

/opt/local/include/gcc48/c++/bits/alloc_traits.h(57): error: expression must have a constant value
static const bool __value = _S_chk<_Alloc, _Tp>(nullptr);

...

Environment: Linux (Ubuntu 12.04), ICC (version XE 13.0), cross-building for Wind River Linux When we use the Wind-River-provided gcc in the Wind-River SDK, header includes start with our headers, move to the headers in the SDK sysroots (there are two) and stay there. When we use ICC, header includes start with our headers, move to the headers in the first SDK sysroot, and then escape to /usr/include. For example, one of our library files is compiled: icc -c -fno-omit-frame-pointer -w3 -Wall -diag-disable 274 -Wno-attributes -xAVX -platform=wrl50 -pthread -shared -fpic -O2 \ -MD DXM_Lib.c -o cpu/DXM_Lib.o And the generated dependency file starts with: cpu/DXM_Lib.o: DXM_Lib.c ../../../../Include/PTL_Lib.h \ ../../../../Include/PTL_Types.h ../../../../../Include/stdints.h \ /home/WindRiver/SDK/sysroots/x86_64-wrlinuxsdk-linux/usr/toolchain/bin/../lib/gcc/i686-wrs-linux-gnu/4.6.3/include/stdint.h \ /usr/include/stdint.h \ /usr/include/features.h \ /usr/include/bits/predefs.h \ /usr/include/sys/cdefs.h \ /usr/include/bits/wordsize.h \ /usr/include/gnu/stubs.h \ /usr/include/bits/wordsize.h \ /usr/include/gnu/stubs-64.h \ /usr/include/bits/wchar.h \ /usr/include/bits/wordsize.h \ It appears the -platform=wrl50 gets us the path to the first sysroot, but not to the second? For comparison, a cross-GCC dependency file starts: cpu/DCP_Lib.o: DCP_Lib.c ../../../Include/DCP_Lib.h \ ../../../Include/PTL_Lib.h ../../../Include/PTL_Types.h \ ../../../../Include/stdints.h \ /home/WindRiver/SDK/sysroots/x86_64-wrlinuxsdk-linux/usr/toolchain/bin/../lib/gcc/i686-wrs-linux-gnu/4.6.3/include/stdint.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/stdint.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/features.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/predefs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/sys/cdefs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/wordsize.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/gnu/stubs.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/gnu/stubs-64.h \ /home/WindRiver/SDK/sysroots/intel_xeon_core-wrs-linux/usr/include/bits/wchar.h \

Compatibility Issue detected: Intel C++ compiler does not support _M_IX86_FP macro. Take a look at 'Predefined Macros' topic on MSDN for more information.

...
_M_IX86_FP - Expands to a value indicating which /arch compiler option was used:

0 if /arch was not used.
1 if /arch:SSE was used.
2 if /arch:SSE2 was used.

See /arch (Minimum CPU Architecture) for more information.
...