I have been operating an open source chess program tournament for a long time, and I have noticed that some contestants compiled with the Intel compiler crash and result in the engine losing the game as well as spawning an error message in Windows

I have Visual Studio and I have tried new project and loaded one of the problem engines and after cleaning up some defects related to the C++ ISO standard I was able to make a stable x64 build

now the program works fine, so this tells me the Intel compiler needs some work on it to eliminate the crashing

Hello,

I'm not sure if this is the proper forum to post on, so please excuse me if my question should have been posted elsewhere.

We are developing software that depends heavily on numerical computation and we want to use intel compiler to achieve a boost in our performance. So far, the platform we have been developing on is Linux.

We consider purchasing Intel® Parallel Studio XE 2015 Composer Edition for Linux and Windows.

My question is: Will the code that we compile on Linux using ICC with MKL and TBB also compile on Windows using the Win version of the aforementoned tools?

Thank you in advance,

Kyriakos

Hello.

The compiler always crashes while compiling <mutex> header from Visual Studio 2015 RC1. Bug is absolutely reproducible, it is enough to attempt to compile a .cpp file with single line:

#include <mutex>

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.4.221 Build 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

mx.cpp
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\mutex(449): internal error: assertion failed at: "shared/cfe/edgcpfe/templates.c", line 28214

Best regards,

Yakov Markovitch

I noticed from the end-of-beta survey that optionprotect-parens was introduced, presumably to comply with that part of C and C++ standards while permitting optimization of sum reduction when /fp:fast is set (as it is by default in ICL).

protect-parens shows excellent results in my testing of C and Cilk(tm) Plus code, with performance gains up to 40%, even though several cases of pessimization in violation of parens had already been corrected (where previously /fp:source was needed to optimize).

It kills simd optimization of several cases of C++ accumulate() and inner_product().  Was that expected? 

I suppose it's credible that protect-parens makes /fp:fast consistent with Microsoft compiler for STL, but I hate to revive the old argument that STL is incompatible with simd optimization or the mis-used terminology "code modernization."

If you download latest CUDA 7.5 and compile the samples with Pre-Release (Beta) Package ID: w_comp_lib_2016.0.06 most of the Projects failed with error MSB3721.

MS Compiler
147>     Bibliothek "../../bin/win64/Debug/cuSolverRf.lib" und Objekt "../../bin/win64/Debug/cuSolverRf.exp" werden erstellt.
147>  cuSolverRf_vs2012.vcxproj -> C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\7_CUDALibraries\cuSolverRf\../../bin/win64/Debug/cuSolverRf.exe
========== Alles neu erstellen: 147 erfolgreich, 0 fehlerhaft, 0 übersprungen ==========

Intel Compiler
147>     Bibliothek "../../bin/win64/Debug/cuSolverRf.lib" und Objekt "../../bin/win64/Debug/cuSolverRf.exp" werden erstellt.
========== Alles neu erstellen: 31 erfolgreich, 116 fehlerhaft, 0 übersprungen ==========

I assume projectconversion did notwork correct in all cases.

protocoll attached as txt file

I try to compile the ngspice SPICE program with the Intel compiler on
Windows 7 64bit, using Visual Studio 2013 Community. The machine has
32GB RAM. NGSPICE is a program with over 2500 files (2400 .obj in
the final result).

It is not possible to turn on /Qipo as it results in lots of [~44]
object files that can't be found (the compiler seems to be doing some
4 passes before giving up). With /Qip the code is some 20% slower
than with the old Microsoft compiler, which makes using the Intel
compiler somewhat pointless :-)

Id don't see a pattern in the files that can't be found, although
sometimes they come from the same director(y)(ies).

I have seen one occasion where the compiler complained it could not
write a file.

As /Qipo does not work, the advisor and instrumentation tools also fail.
I have not checked carefully, but I think the profiler never works, even
when /Qipo is set to /Qip.

It is certainly possible that I am doing something wrong. Is there a
limit on the number of files that can be processed, or on the number
of files that can be passed to the linker?

-marcel

--------------- error message -------------
...
1>C:\ngspice-ngspice\src\frontend\com_let.c(15) (col. 1): : error : 04010002_1670
1>
1>xilink: : error #10014: problem during multi-file optimization compilation (code 4)
1>xilink: : error #10014: problem during multi-file optimization compilation (code 4)

When compiling with icpc, regardless of which code, I get

icpc: error #10401: error running 'xcrun -find ld'

Any idea on how this can be fixed?

2>xilink: : error #10014: problem during multi-file optimization compilation (code -1073741819)
2>xilink: : error #10014: problem during multi-file optimization compilation (code -1073741819)

I am using the latest stable 15 version of ICC, and MSVC 2013.

What the hell this means? Shouldn't be numbers in error code dated back to 1980's ?!

best

Hello,

I am tryoing to compile and run helloflops2 from "example from "Intel Xeon Phi Coprocessor High-Performance Programming". I could compile the code using this command line:

   > icc -openmp -mmic -qopt-report-phase=vec -qopt-report=3  -O3 helloflops2.c -o helloflops2

Then, I scp "helloflops2" file to mic0:/root and try to run it using: "./helloflops2"  and I got this error:

./helloflops2: error while loading shared libraries: libiomp5.so: cannot open shared object file: No such file or directory

In the host processor, I have set all the environment variables:

   > source /opt/intel/composerxe/bin/compilervars.sh intel64

   > export LD_LIBRARY_PATH=/opt/intel/composer_xe_2015.3.187/compiler/lib/intel64

In mic0, i copied  "libiomp5.so" file into /lin64 folder and issued this:

   > export LD_LIBRARY_PATH=/lib64

Still I am getting the error. Any help is highly appreciated.

Ali

Hi,

I had a for loop which had some branches due to which the loop was not a candidate of vectorization which I confirmed from the optimization report. I removed this branches using masking, and now the same for loop satisfies all the necessary requirement for a loop to be vectorized, like

1. No Branches or Jumps.

2. No Dependencies. e.t.c

Below is a output from the optimization report with option -vec-report5. As can be seen from the vectorization report the loop was splitted and part1 (chunk1) was supposed to give a speed of 2.140 and part2 (chunk2) was supposed to give a speed up of 1.4 but when I execute the code in real time I cannot find any speedup at all, time is almost equal to original. I also checked the assembly for the same loop and it seems that compiler do generates the machine code instructions with xmm registers. 

LOOP BEGIN at ../../../sample.c(2635,5)
<Distributed chunk1>
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2637,9) ]
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2638,9) ]
   remark #15301: PARTIAL LOOP WAS VECTORIZED
   remark #15449: unmasked aligned unit stride stores: 2 
   remark #15460: masked strided loads: 2 
   remark #15475: --- begin vector loop cost summary ---
   remark #15476: scalar loop cost: 12 
   remark #15477: vector loop cost: 5.500 
   remark #15478: estimated potential speedup: 2.140 
   remark #15479: lightweight vector operations: 7 
   remark #15481: heavy-overhead vector operations: 1 
   remark #15487: type converts: 2 
   remark #15488: --- end vector loop cost summary ---
LOOP END

LOOP BEGIN at ../../../sample.c(2635,5)
<Remainder, Distributed chunk1>
LOOP END

LOOP BEGIN at ../../../sample.c(2635,5)
<Distributed chunk2>
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2641,9) ]
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2641,9) ]
   remark #15388: vectorization support: reference mask5 has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference bi has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15388: vectorization support: reference ai has aligned access   [ ../../../sample.c(2661,2) ]
   remark #15399: vectorization support: unroll factor set to 2
   remark #15301: PARTIAL LOOP WAS VECTORIZED
   remark #15448: unmasked aligned unit stride loads: 10 
   remark #15449: unmasked aligned unit stride stores: 1 
   remark #15458: masked indexed (or gather) loads: 10 
   remark #15475: --- begin vector loop cost summary ---
   remark #15476: scalar loop cost: 72 
   remark #15477: vector loop cost: 47.370 
   remark #15478: estimated potential speedup: 1.480 
   remark #15479: lightweight vector operations: 67 
   remark #15480: medium-overhead vector operations: 1 
   remark #15488: --- end vector loop cost summary ---
LOOP END

LOOP BEGIN at ../../../sample.c(2635,5)
<Remainder, Distributed chunk2>
LOOP END

My Question is that is this possible that although the optimization report shows opportunity of speed and machine code do use the 128 bits xmm registers rather than the scalar code, but still in real time it does not shows any speedup? Or is it because of some heavy overhead vectorization operations as shown in the optimization report (But I think compiler do considers it while compilation) ? If I am wrong or missing something, any help for the right direction would be appericiated.

Hi friends,

In my windows,I compile the code link with mkl,but it still not work.

>"C:\Program Files (x86)\Intel\Composer XE 2015\bin\compilervars.bat" intel64

>"C:\Program Files (x86)\Intel\Composer XE 2015\mkl\bin\mklvars.bat" intel64

>icl mycode.cpp /Qmkl

.........cannot find fftw3.h.......................

most according to to this page:https://software.intel.com/en-us/articles/intel-mkl-111-getting-started

I used the mkl 11.2

thanks.

Hello,

I am trying to compile an Android Kernel and got an error, which seems to be a fault of Intel ICC compiler semantics.

#define for_each_cpu_worker_pool(pool, cpu)				\
	for ((pool) = &per_cpu(cpu_worker_pools, cpu)[0];		\
	     (pool) < &per_cpu(cpu_worker_pools, cpu)[NR_STD_WORKER_POOLS]; \
	     (pool)++)

Where in a code file we have this piece then:

for_each_cpu_worker_pool(pool, cpu)
	{
		WARN_ON_ONCE(cpu != smp_processor_id());

		mutex_lock(&pool->manager_mutex);
		spin_lock_irq(&pool->lock);

Which normally should be then replaced like this (plain and simple):

for ((pool) = &per_cpu(cpu_worker_pools, cpu)[0]; (pool) < &per_cpu(cpu_worker_pools, cpu)[NR_STD_WORKER_POOLS]; (pool)++)
{
WARN_ON_ONCE(cpu != smp_processor_id());

		mutex_lock(&pool->manager_mutex);
		spin_lock_irq(&pool->lock);
...

But instead command line is throwing out this error:

workqueue.c(4989): error: expected a ")"
  		for_each_cpu_worker_pool(pool, cpu) {
                ^

Can I use some workaround to fix this?

Hello All,

Today I installed Visual Studio 2015 Community edition (RTM) and discovered that a very simple code won't compile with Intel 2016 Compiler (update 2, Version 16.0 Beta Build 20150527).

The code:

#include <string>
#include <iostream>

using namespace std;

int main()
{
    cout << "Hello!!";
    return 0;
}

The error message:

1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(1617): error : a nonstatic member reference must be relative to a specific object
1>            -> decltype(_STD invoke(get(), _STD forward<_Types>(_Args)...))

Hope it will be fixed in the next release, since it is complete show-stopper!

Regards,

       Michael

Hello,

we are trying to speed up a parallel program using the Intel Compiler and the OpenMP library.

We have observed that the program hangs after running ok for 3-4 days, in one of the parallel loops. The binary keeps running but stays in a permanent waiting state. Here is the gdb stack trace:

#0 0x00007fefbc1bf705 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007fefbc98e9ce in __kmp_suspend_template (th_gtid=, flag=) at ../../src/z_Linux_util.c:1819
#2 __kmp_suspend_64 (th_gtid=-1145176444, flag=0x80) at ../../src/z_Linux_util.c:1874
#3 0x00007fefbc92fe08 in suspend (this=, th_gtid=) at ../../src/kmp_wait_release.h:405
#4 __kmp_wait_template (this_thr=, flag=, final_spin=, itt_sync_obj=) at ../../src/kmp_wait_release.h:224
#5 wait (this=, this_thr=, final_spin=, itt_sync_obj=) at ../../src/kmp_wait_release.h:414
#6 __kmp_hyper_barrier_gather (bt=3149790852, this_thr=0x80, gtid=1, tid=-1, reduce=0x7fefbbbdfe00, itt_sync_obj=0x0) at ../../src/kmp_barrier.cpp:510
#7 0x00007fefbc9331c3 in __kmp_join_barrier (gtid=-1145176444) at ../../src/kmp_barrier.cpp:1364
#8 0x00007fefbc959ee2 in __kmp_internal_join (id=0x7fefbbbdfe84, gtid=128, team=0x1) at ../../src/kmp_runtime.c:7142
#9 0x00007fefbc9609a4 in __kmp_join_call (loc=0x7fefbbbdfe84, gtid=128, exit_teams=1) at ../../src/kmp_runtime.c:2322
#10 0x00007fefbc9345bd in __kmpc_fork_call (loc=0x7fefbbbdfe84, argc=128, microtask=0x1) at ../../src/kmp_csupport.c:326
#11 0x000000000045f4fb in CovarianceMatrixCxx::kalman (......) at G2/CovarianceMatrixCxx.cpp:295
 

So far, we have observed this problem using Scientfic Linux 7 (glibc 2.17), but not using Scientific Linux 6 (glibc 2.12), when using "icc -openmp". The behaviour is the same when using "icc -fopenmp".

When we use the GNU C++ Compiler with OpenMP (g++ -fopenmp), the program runs fine in both SL6 and SL7. 

In summary, this looks like a problem when combining the Intel Compiler and SL7, when the OpenMP library is used. This is the ICC version we are using:

> icc --version

icc (ICC) 15.0.1 20141023

Unfortunately, the program is quite complex and we have not been able to generate a simplified version of the problem that can be easily reproduced. Below is an snapshoot of the loop that is hanging.

Are you aware of any kind of problem similar to this one?

Any help is appreciated,

Javier

                        #pragma omp parallel for private(i,j,k)
                        for(i=0; i
                        {
                                v_temp[i] = 0.0;

                                for(k=0; k
                                        j = index_OfNonZero[k];

                                        if(j >= i) {
                                                v_temp[i] += v_Matrix[i][j]*v_KalmanVec[j].d_A;
                                        } else {
                                                v_temp[i] += v_Matrix[j][i]*v_KalmanVec[j].d_A;
                                        }

                                }//for k
                        }//for i

I'm currently trying to port a big application from gcc to the Intel Compiler. I managed to compile it with 13, but I have to do it again for 15, especially since a lot of the code now uses C++11.

Unfortunately, a piece (a Boost::Spirit grammar) that compiled fine with icpc 13 (and gcc and Visual Studio) now fails to compile, and I have absolutely no clue as to what is happening. I managed to limit the code to this grammar:

#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/phoenix_operator.hpp>
#include <boost/spirit/include/phoenix_function.hpp>

namespace qi    = boost::spirit::qi;
namespace ascii = boost::spirit::ascii;

//
// expression and operator datatypes
// used for parsing the tree
//
struct binary_op;

struct expr_node
{
  typedef boost::variant<double, std::string,
    boost::recursive_wrapper<expr_node>,
    boost::recursive_wrapper<binary_op>,
    boost::recursive_wrapper<std::vector<expr_node> > > type;

  expr_node()
    : type_str("none") {}

  template <typename Expr>
  expr_node(Expr const& expr, const std::string type_str = "none")
    : expr(expr), type_str(type_str) {}

  type expr;
  std::string type_str;
};

struct binary_op
{
  binary_op(const std::string& op, expr_node const& left, expr_node const& right)
  : op(op), left(left), right(right) {}

  std::string op;
  expr_node left;
  expr_node right;
};

struct expr_node_phx
{
  template <typename T, typename U>
  struct result { typedef expr_node type; };

  expr_node operator()(expr_node const& expr, const std::string& type_str) const
  {
    expr_node e(expr.expr,type_str);
    return e;
  }
};

boost::phoenix::function<expr_node_phx> exnd;

struct binary_op_phx
{
  template <typename S, typename T, typename U>
  struct result { typedef T type; };

  expr_node operator()(const std::string& name, expr_node const& expr, expr_node const& rhs) const
  {
    return expr_node(binary_op(name,expr,rhs));
  }
};

boost::phoenix::function<binary_op_phx> biop;

//
//  grammar for parsing expressions
//
template <typename Iterator>
struct Grammar : qi::grammar<Iterator,expr_node(),ascii::space_type>
{
  Grammar() : Grammar::base_type(log_expr)
  {
    using qi::_val;
    using qi::_1;

      log_expr =      log_term  [_val = _1]
      >> *(    '|'>> log_term  [_val = biop("|",_val,_1)]);
    }

    // auto and basic parsers
    qi::rule<Iterator,expr_node()  ,ascii::space_type> log_expr,log_term;
};

std::string parse()
{
  typedef std::string::const_iterator iterator_type;
  Grammar<iterator_type> ixgrammar;
}

The full error is the following one:

PATH/boost/boost_1_58_0/include/boost/core/enable_if.hpp(36): error: incomplete type is not allowed
    struct enable_if : public enable_if_c<Cond::value, T> {};
                                          ^
          detected during:
            instantiation of class "boost::enable_if<Cond, T> [with Cond=boost::mpl::and_<boost::fusion::traits::is_sequence<boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type,
                      boost::spirit::unused_type, boost::spirit::unused_type>>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,
                      boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>>,
                      boost::mpl::not_<boost::is_convertible<boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type>>,
                      boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>, boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>>>, boost::mpl::bool_<true>, boost::mpl::bool_<true>, boost::mpl::bool_<true>>, T=void]" at line 92 of
                      "PATH/boost/boost_1_58_0/include/boost/type_traits/is_convertible.hpp"
            instantiation of class "boost::detail::is_convertible_basic_impl<From, To, false> [with From=boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type,
                      boost::spirit::unused_type, boost::spirit::unused_type>>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,
                      boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>, To=boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>]" at line 357 of
                      "PATH/boost/boost_1_58_0/include/boost/type_traits/is_convertible.hpp"
            instantiation of class "boost::detail::is_convertible_impl<From, To> [with From=boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type,
                      boost::spirit::unused_type>>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>, To=boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>]" at line 437 of
                      "PATH/boost/boost_1_58_0/include/boost/type_traits/is_convertible.hpp"
            instantiation of class "boost::detail::is_convertible_impl_dispatch<From, To> [with From=boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type,
                      boost::spirit::unused_type, boost::spirit::unused_type>>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,
                      boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>, To=boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>]" at line 482 of
                      "PATH/boost/boost_1_58_0/include/boost/type_traits/is_convertible.hpp"
            instantiation of class "boost::is_convertible<From, To> [with From=boost::fusion::cons<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>, boost::fusion::cons<boost::spirit::qi::action<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type,
                      boost::spirit::unused_type>>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>>>, boost::fusion::nil_>>, To=boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard, true, false>]" at line 27 of
                      "PATH/boost/boost_1_58_0/include/boost/mpl/aux_/nested_type_wknd.hpp"
            [ 26 instantiation contexts not shown ]
            instantiation of class "boost::proto::transform<PrimitiveTransform, X>::result<Sig> [with PrimitiveTransform=boost::proto::switch_<boost::spirit::meta_compiler<boost::spirit::qi::domain>::cases, boost::proto::tag_of<boost::proto::_> ()>, X=void, Sig=boost::spirit::meta_compiler<boost::spirit::qi::domain>::meta_grammar (boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<const
                      boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign,
                      boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::spirit::_1_type>, 2L>> &>, 2L> &, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::dereference, boost::proto::argsns_::list1<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<const char &>, 0L>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const
                      boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>> &>, 2L> &>, 2L> &>, 1L> &>, 2L>, boost::mpl::void_, boost::spirit::unused_type)]" at line 206 of "PATH/boost/boost_1_58_0/include/boost/spirit/home/support/meta_compiler.hpp"
            instantiation of class "boost::spirit::result_of::compile<Domain, Expr, Modifiers, Enable> [with Domain=boost::spirit::qi::domain, Expr=boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (),
                      boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::spirit::_1_type>, 2L>> &>, 2L> &, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::dereference,
                      boost::proto::argsns_::list1<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char &>, 0L>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>,
                      std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>,
                      boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>> &>, 2L> &>, 2L> &>, 1L> &>, 2L>,
                      Modifiers=boost::spirit::unused_type, Enable=void]" at line 184 of "PATH/boost/boost_1_58_0/include/boost/spirit/home/qi/nonterminal/rule.hpp"
            instantiation of "void boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::define<Auto,Expr>(boost::spirit::qi::rule<Iterator, T1, T2, T3, T4> &, const Expr &, boost::mpl::true_) [with Iterator=__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, T1=expr_node (), T2=boost::spirit::ascii::space_type, T3=boost::spirit::unused_type, T4=boost::spirit::unused_type, Auto=boost::mpl::false_,
                      Expr=boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const
                      boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::spirit::_1_type>, 2L>> &>, 2L> &, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::dereference, boost::proto::argsns_::list1<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right,
                      boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char &>, 0L>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type,
                      boost::spirit::unused_type> &, const boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,
                      boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>> &>, 2L> &>, 2L> &>, 1L> &>, 2L>]" at line 221 of
                      "PATH/boost/boost_1_58_0/include/boost/spirit/home/qi/nonterminal/rule.hpp"
            instantiation of "boost::spirit::qi::rule<Iterator, T1, T2, T3, T4> &boost::spirit::qi::rule<Iterator, T1, T2, T3, T4>::operator=(const Expr &) [with Iterator=__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, T1=expr_node (), T2=boost::spirit::ascii::space_type, T3=boost::spirit::unused_type, T4=boost::spirit::unused_type, Expr=boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right,
                      boost::proto::argsns_::list2<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign,
                      boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::spirit::_1_type>, 2L>> &>, 2L> &, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::dereference, boost::proto::argsns_::list1<const boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_right, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<const char &>, 0L>, const boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript, boost::proto::argsns_::list2<boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, expr_node (), boost::spirit::ascii::space_type, boost::spirit::unused_type, boost::spirit::unused_type> &, const
                      boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::attribute<0>>, 0L>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list4<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<binary_op_phx>, 0L>, boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<const char *>, 0L>, boost::spirit::_val_type, boost::spirit::_1_type>, 4L>>>, 2L>> &>, 2L> &>, 2L> &>, 1L> &>, 2L>]" at line 82 of "test.cpp"
            instantiation of "Grammar<Iterator>::Grammar() [with Iterator=__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>]" at line 92 of "test.cpp"

I tried defining GCC macros to see if something was missing in Boost config, but it didn't change the error. Also I didn't find anything relevant of Internet :(

We are quite eager to thnk about shipping the product compiled with the Intel Compiler because of performance, but having this issue is quite worrying...

Hello,

before installing the new c++ compiler I deinstalled the old MS Visual c++ version 10.

Starting icl I got the message: Microsoft Visual C++ not found in path. 

My question: Which free version is available now? Please give me the recommended link to download it.

Thank you.

Peter

Hi, all,

Now our team try to use the icc replace gcc which we have used years. But find the icc compiled executable file performance is bad than gcc.

We use the script generated some small demos to test this, all in the attached test.tar.gz

Test machine CPU: Intel(R) Xeon(R) CPU E7-4850 v2 @ 2.30GHz
OS: Centos 6.6
GCC: 4.7.2
ICC: parallel_studio_xe_2015_update3

In the test.tar.gz, contains N10, N50, N100, N250, N500 folders, in each folder, contains f10A.c file, which is auto generated by genf2A.pl, then make to generate f10Agcc and f10Aicc, use run.csh to run them and compare the result.

At last, the result is as below:

                GCC      ICC
N10        0.384     0.291
N50        2.107     2.155 
N100      5.429     5.648
N250      15.397     23.575
N500      38.949     58.672 

When N<100, the icc is better than gcc, but when N>100, especially N=500, the icc performance is much worse than gcc.

How can we improve the icc performance? Maybe add some special compiling options?
Anyone know please tell me, thanks very much!

hello,

Just curious thinking it wud be nice integrating  intel XDK in c# to complement the mordern  beginer programmers point of view.

Dear Sir/Madam
I need PRIMME-V1 for building SLEPC so i am trying to build the application using intel 2015 suite on CentOS 6.5.
I am getting following error:-

mpiifort -fPIC -o seq_dprimme driver_seq.o readuc.o shared_utils.o ssrcsr.o  ilut.o amux.o -L/opt/user1-INTEL/finaluser1/ToolsInstaller/Mechanical/OOFEM/PRIMME -I/opt/user1-INTEL/finaluser1/ToolsInstaller/Mechanical/OOFEM/PRIMME/PRIMMESRC/COMMONSRC -I/opt/user1/user1_Installed/Ajavascript:void(0)pplication_Dependencies/include -lprimme -llapack -lblas -lm
driver_seq.o: In function `main':
driver_seq.c:(.text+0x0): multiple definition of `main'
/opt/intel/composer_xe_2015.3.187/compiler/lib/intel64/for_main.o:for_main.c:(.text+0x0): first defined here
/opt/intel/composer_xe_2015.3.187/compiler/lib/intel64/for_main.o: In function `main':
for_main.c:(.text+0x2a): undefined reference to `MAIN__'
make[1]: *** [seq_dprimme] Error 1
make[1]: Leaving directory `/opt/user1-INTEL/finaluser1/ToolsInstaller/Mechanical/OOFEM/PRIMME/DTEST'
make: *** [seq_dprimme] Error 2
/opt/user1/user1_Installed/Application_Dependencies/lib/libprimme.a

The following commands sets the appropriate compilation options.     

tar -xzvf primme_v1.1.tar.gz
        cd PRIMME
        sed -i "/^TOP =/c TOP = $PWD" Make_flags
        sed -i "/^CC/c CC = $MPIC_COMP" Make_flags
        sed -i "/^F77/c F77 = $MPIF_COMP" Make_flags
        sed -i "/^CFLAGS/c CFLAGS = -O2 -fPIC" Make_flags
        sed -i "/^FFLAGS/c FFLAGS = -O2 -fPIC" Make_flags
        sed -i "/^LDR/c LDR = $MPIF_COMP -fPIC"  Link_flags
        sed -i "/^ LDFLAGS/c LDFLAGS =  "  Link_flags
        sed -i "/^ LIBS/c LIBS = -lprimme -llapack -lblas -lm " Link_flags
        sed -i "/^INCLUDE/c INCLUDE = -I\$(COMMONDIR) -I$user_install_path/Application_Dependencies/include"  Link_flags

         make VERBOSE=1 all

Eagerly awaiting your reply.

Hello,

Beta 2016 update 2 has a problem with VS 2015 new run-time libraries. Consider the following code (should be compiled and linked as Win32/64 Dll):

#include <Windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <mathimf.h>

#pragma comment( lib, "libmmds" )

//  Uncomment this to remove some errors
//  #pragma comment( lib, "legacy_stdio_definitions" )

BOOL APIENTRY DllMain( HMODULE hModule,
  DWORD  ul_reason_for_call,
  LPVOID lpReserved
  )
  {
  switch( ul_reason_for_call ) {
	case DLL_PROCESS_ATTACH:
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
	  break;
	}
  return TRUE;
  }


__declspec(dllexport) void CalculateSomeStuff( double x, double& Val )
  {
  Val = pow( x, 2.3 );
}

If the target is 32 bit, then the linkage stage will give the errors:

ipo: : warning #11021: unresolved __snprintf
1>          Referenced in libmmds.lib(libm_error.obj)
1>ipo: : warning #11021: unresolved __vsnprintf
1>          Referenced in MSVCRT.lib(vsnprintf.obj)
1>ipo: : error #11023: Not all components required for linking are present on command line

If legacy_stdio_definitions is included, 32bit target will build successfully.

If the target is 64 bit, then the linkage step will give the errors:

1>  Win32Project1.cpp
1>ipo: : warning #11021: unresolved __imp__snprintf
1>          Referenced in libmmds.lib(libm_error.obj)
1>ipo: : warning #11021: unresolved __imp___iob_func
1>          Referenced in libmmds.lib(libm_error.obj)
1>ipo: : warning #11021: unresolved __imp__vsnprintf
1>          Referenced in MSVCRT.lib(vsnprintf.obj)
1>ipo: : error #11023: Not all components required for linking are present on command line
1>     Creating library c:\vs_test\ConsoleApplication1\x64\Release\Win32Project1.lib and object c:\vs_test\ConsoleApplication1\x64\Release\Win32Project1.exp
1>libmmds.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp__snprintf referenced in function write_message
1>libmmds.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp_vsnprintf referenced in function write_message
1>MSVCRT.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp_vsnprintf
1>libmmds.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp___iob_func referenced in function write_message
1>MSVCRT.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp__vsnprintf
1>c:\vs_test\ConsoleApplication1\x64\Release\Win32Project1.dll : fatal error LNK1120: 4 unresolved externals

Including legacy_stdio_definitions will not fix the problem completely:

1>ipo: : warning #11021: unresolved __imp___iob_func
1>          Referenced in libmmds.lib(libm_error.obj)
1>ipo: : error #11023: Not all components required for linking are present on command line
1>     Creating library c:\vs_test\ConsoleApplication1\x64\Release\Win32Project1.lib and object c:\vs_test\ConsoleApplication1\x64\Release\Win32Project1.exp
1>libmmds.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp___iob_func referenced in function write_message

I believe the version of libmmds.lib should be somehow adjusted to new VS2015 run-time.

Regards,

  Michael