<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Tue, 24 Nov 2009 15:53:22 -0800 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/intel-c-compiler-for-linux-kb/type/software-defects/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network articles feed</title>
    <link>http://software.intel.com/en-us/articles/intel-c-compiler-for-linux-kb/software-defects/</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>error 409 when building boost libraries 1.40.0 with Intel compiler</title>
      <description><![CDATA[ <p><strong>Problem : <br /></strong>When building boost libraries version 1.40.0 with Intel compiler 11.1.046, the compiler report error #409 like below:</p>
<blockquote>
<p>./boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp(119): error #409: "boost::wave::cpplexer::re2clex::lexer&lt;IteratorT, PositionT&gt;::lexer(const IteratorT &amp;, const IteratorT &amp;, const PositionT &amp;, boost::wave::language_support)" provides no initializer for:<br />const member "boost::wave::cpplexer::re2clex::lexer&lt;IteratorT, PositionT&gt;::cache"<br />{<br />^<br />detected during:<br />instantiation of "boost::wave::cpplexer::re2clex::lex_functor&lt;IteratorT, PositionT&gt;::lex_functor(const IteratorT &amp;, const IteratorT &amp;, const PositionT &amp;, boost::wave::language_support) [with IteratorT=char *, PositionT=boost::wave::util::file_position_type]" at line 402<br />instantiation of "boost::wave::cpplexer::lex_input_interface *boost::wave::cpplexer::new_lexer_gen&lt;IteratorT, PositionT&gt;::new_lexer(const IteratorT &amp;, const IteratorT &amp;, const PositionT &amp;, boost::wave::language_support) [with IteratorT=char *, PositionT=boost::wave::util::file_position_type]" at line 52 of "libs/wave/src/instantiate_re2c_lexer.cpp"</p>
</blockquote>
<p><strong>Environment :</strong> <br /><br />Boost libraries version 1.40.0 for linux*<br />Intel C++ Compiler for linux, version 11.1.046<br /><br /><strong>Root Cause :</strong> <br />Need initializer for const variable cache defined in file cpp_re2c_lexer.hpp, line 107. Refer this article <a href="http://software.intel.com/en-us/articles/cdiag409">http://software.intel.com/en-us/articles/cdiag409</a> for details.<br /><br /><strong>Resolution : <br /></strong>This error no longer occurs with the Intel® C++ Compiler 11.1.059 for Linux*.  As a workaround as well, you can add an initializer for the const variable cache in file boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp. For example:</p>
<pre name="code" class="cpp">template &lt;typename IteratorT, typename PositionT&gt;
inline
lexer&lt;IteratorT, PositionT&gt;::lexer(IteratorT const &amp;first, 
IteratorT const &amp;last, PositionT const &amp;pos, 
boost::wave::language_support language_) 
: filename(pos.get_file()), at_eof(false), language(language_),cache(token_cache&lt; typename lexer &lt; IteratorT, PositionT &gt;::string_type &gt;())
{
using namespace std; // some systems have memset in std
memset(&amp;scanner, '\0', sizeof(Scanner));
</pre>
<p> </p> ]]></description>
      <link>http://software.intel.com/en-us/articles/error-409-when-building-boost-libraries-1400-with-intel-compiler</link>
      <pubDate>Tue, 17 Nov 2009 19:21:42 -0800</pubDate>
      <comments>http://software.intel.com/en-us/articles/error-409-when-building-boost-libraries-1400-with-intel-compiler#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/error-409-when-building-boost-libraries-1400-with-intel-compiler</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
    </item>
    <item>
      <title>Warning #677: memory usage conflict with precompiled header file seen on Windows* XP and Linux*</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><strong>Reference Number :</strong> DPD200136749<br /><br /><br /><strong>Version : </strong>10.1, 11.0, 11.1<br /><br /><br /><strong>Product : </strong>Intel® C++ Compilers Professional Edition for Windows* and Linux*.  Intel ® Parallel Composer.<br /><br /><br /><strong>Operating System :</strong> Windows* versions prior to Windows Vista* or equivalent, Linux*<br /><br /><br /><strong>Problem Description : </strong>When using precompiled headers, you may see the diagnostic:<br /><br />Warning #677: memory usage conflict with precompiled header file<br /><br />This means that there was an internal problem with the precompiled header processing in the compiler and precompiled headers will not be used for the file in question which may cause an increase in build times.<br /><br /><br /><strong>Resolution Status :</strong> We are investigating this issue.  Please contact us via the User Forum or Intel® Premier Support if you are experiencing this issue.<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/warning-677-memory-usage-conflict-with-precompiled-header-file-seen-on-windows-xp-and-linux</link>
      <pubDate>Thu, 22 Oct 2009 15:35:39 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/warning-677-memory-usage-conflict-with-precompiled-header-file-seen-on-windows-xp-and-linux#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/warning-677-memory-usage-conflict-with-precompiled-header-file-seen-on-windows-xp-and-linux</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Windows* Knowledge Base</category>
      <category>Intel® Parallel Composer Knowledge Base</category>
    </item>
    <item>
      <title>Putting -lm Before User Objects/Libraries on Link Line Can Impact Performance</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><strong>Reference Number : </strong>DPD200121218<br /><br /><br /><strong>Version :</strong> 11.0<br /><br /><br /><strong>Operating System :</strong> Linux*<br /><br /><br /><strong>Problem Description : </strong>Starting with 11.0.081, a fix was made to the compiler driver to link the Intel Math Library libimf statically by default (the intended and documented behavior) instead of dynamically.  If -lm is used with the compiler driver (icc/icpc/ifort), the driver automatically inserts libimf before libm in the link line.  Linking in libimf.a when this is done causes a problem if -lm precedes any user-created objects or libraries.  For example:<br /><br />
<pre name="code" class="plain:nogutter:nocontrols">icc -lm user1.o user2.o -luser3</pre>
Gets converted by the driver to:<br /><br />
<pre name="code" class="plain:nogutter:nocontrols">ld ... -Bstatic -limf -Bdynamic -lm ... user1.o user2.o -luser3 ...</pre>
On Linux, static libraries must come after the object/library files that use them in the link line in order for the symbols to resolve.  Since libimf.a comes before the objects/libraries that use standard math functions, these math functions won't resolve to the static Intel math library.  However, the dynamic libm doesn't have an order dependency because it is a dynamic library, so the math functions will resolve to the GNU math library.  This can have a significant performance impact.<br /><br /><br /><strong>Resolution Status : </strong>Starting with 11.1.056, the compiler now emits a warning if -lm precedes other user objects or libraries on the linker command line.  If you run into a performance regression between compilers prior to 11.0.081 and compilers from 11.0.081 on, please verify that you don't have -lm being used prior to your objects/libraries in your link lines if you use icc/icpc/ifort to link. Using the above example, make the following change:<br /><br />
<pre name="code" class="plain:nogutter:nocontrols">icc user1.o user2.o -luser3 -lm</pre>
<em>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</em></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/putting-lm-before-user-objectslibraries-on-link-line-can-impact-performance</link>
      <pubDate>Wed, 14 Oct 2009 11:45:33 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/putting-lm-before-user-objectslibraries-on-link-line-can-impact-performance#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/putting-lm-before-user-objectslibraries-on-link-line-can-impact-performance</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Linux* Knowledge Base</category>
    </item>
    <item>
      <title>Thread affinity compiler switches have no effect</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><b>Reference Number : DPD200119846 </b><br /><br /><br /><b>Version : <br />Intel® C++ Compiler for Linux*and Windows*, 11.1 initial releases and update 1<br />Intel® Fortran Compiler for Linux*and Windows*, 11.1 initial releases and update 1</b><br /><br /><br /><b>Operating System : Microsoft Windows XP*, Microsoft Windows Vista*, Microsoft Windows Server 2003*; Red Hat Enterprise Linux* 3, 4, 5, SUSE LINUX Enterprise Server* 9, 10, 11, other supported Linux distributions (see Release Notes)</b><br /><br /><br /><b>Problem Description :  Thread affinity compiler switches /Qpar-affinity (Windows*) or -par-affinity (Linux*) are used to specify compiled-in thread affinity of the executable.  However, when the executable is run, no effect is observed.  In other words, the default runtime thread affinity is used, or if KMP_AFFINITY has been set, the runtime thread affinity matches its setting (the switches are supposed to take precedence).</b><br /><br /><br /><b>Resolution Status : The issue has been resolved in the 11.1 update 2 release.  The compiler builds are:<br /></b>Linux* C++: l_cproc_p_11.1.056<br />Linux* Fortran: l_cprof_p_11.1.056<br />Windows* C++: w_cproc_p_11.1.046<br />Windows* Fortran: w_cprof_p_11.1.046<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/thread-affinity-compiler-switches-have-no-effect</link>
      <pubDate>Thu, 24 Sep 2009 10:39:53 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/thread-affinity-compiler-switches-have-no-effect#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/thread-affinity-compiler-switches-have-no-effect</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Windows* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Linux* Knowledge Base</category>
      <category>Intel® Visual Fortran Compiler for Windows* Knowledge Base</category>
    </item>
    <item>
      <title>Numeric casting issue when  during vectorization </title>
      <description><![CDATA[ <br />
<div style="padding-left: 30px;" id="art_pre_template"><b>Reference Number : </b><br /><br />http://software.intel.com/en-us/forums/intel-c-compiler/topic/65372/<br /><br /><b>Version : </b><br />Intel compiler 11.0<br /><br /><b>Operating System : </b><br />Linux<br /><br /><b>Problem Description : </b><br /><br />The unsigned to double casting in the Intel C++ compiler to produces improper result when vectoring.<br /><br />The following test case produces wrong result. If we disable vectorization, there is no issue.<br /><br />$ cat f65372.cpp<br />//f65372.cpp<br /><br />// HW: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz, 2G memory<br />// OS: Fedora 10, kernel 2.6.27.19-170.2.35.fc10.x86_64<br />// Compiler: icpc 11.0 081, all default compiler settings<br /><br />#include &lt;inttypes.h&gt;<br />#include &lt;cstdio&gt;<br /><br />int main()<br />{<br />    const double res=1.0/4294967296.0;<br />    double max=0.0;<br />    int nsiz=16; // smaller nsiz, like 12, would work<br />    uint32_t urand[nsiz];<br /><br />    for (int j=0; j &lt; nsiz; ++j)<br />        urand[j]=0xfffffff0U; // seems to work if MSB is 0<br /><br />    for (int j=0; j &lt; nsiz; ++j) {<br />        double err=urand[j]*res; // doesn't work<br />        //double err=(unsigned int)urand[j]*res; // doesn't work<br />         //double err=(unsigned long)urand[j]*res; // this works<br />        if (err &gt; max)<br />             max=err;<br /><br />    }<br />    printf("Max = %.12g\n",max);<br />}<br /><br />// Incorrect output: Max = 4294967296<br />// Correct output: Max = 0.999999996275<br /><br /><br /><br /><br />$ icc f65372.cpp<br />f65372.cpp(17): (col. 2) remark: LOOP WAS VECTORIZED.<br />f65372.cpp(20): (col. 2) remark: LOOP WAS VECTORIZED.<br />[maya@maya8 f65372]$ ./a.out<br />Max = 4294967296<br /><br /><br /><br />$ icc -no-vec f65372.cpp<br />[maya@maya8 f65372]$ ./a.out<br />Max = 0.999999996275<br /><br /><b>Resolution Status : </b><br /><br />The issue is fixed. The unsigned to double casting in the Intel C++ compiler 11.1 to produces correct result when vectoring. <br /><br />We can use compiler option –no-vec for the older version of the compiler.<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/numeric-casting-issue-when-during-vectorization</link>
      <pubDate>Tue, 25 Aug 2009 00:08:26 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/numeric-casting-issue-when-during-vectorization#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/numeric-casting-issue-when-during-vectorization</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Mac OS X* Knowledge Base</category>
    </item>
    <item>
      <title>Intel® compiler error #10236 issued when using -soname corrupts resulting shared library on Linux</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><span class="sectionHeadingText">Reference Number :</span><strong>  </strong>DPD200137886<br /><br /><br /><span class="sectionHeadingText">Version :</span>  11.1<br /><br /><br /><strong class="sectionHeadingText">Operating System :</strong>  Linux* / IA-32, Intel® 64, IA-64<br /><br /><br /><b><span class="sectionHeading">Problem Description :</span> </b><br /><br />Improvements in the Intel C++ and Fortran 11.1 release compiler drivers cause each (ifort, icpc, icc) to issue error #10236 for any detected missing files; however, each driver fails to exit accordingly after issuing this "fatal" class of diagnostic.<br /><br />Here is an example of the diagnostic issued:<br /><br />            icpc: error #10236: File not found: 'libsubCPP.so'<br /><br /><br />This resulting behavior causes the compiler driver to incorrectly engage the link phase, which causes residual corruption of the Linux shared library (or DSO) when using the Linux linker (ld) <strong>-soname</strong> option with the compiler driver to create a shared library.<br /><br />When using the Intel compiler to create a shared library, linker options must be passed using the <strong>-Wl</strong> or <strong>-Xlinker</strong> option. The latter requires special handling of any linker options that themselves take arguments. <br /><br />In the case of supplying the linker <strong>-soname</strong> option, users must ensure the correct syntax is used with <strong>-Xlinker</strong>.<br /><br />The incorrect syntax is: <strong>-Xlinker -soname <em>&lt;name&gt;</em></strong><br /><br />The correct syntax is one of two forms:<br /><br /><strong>-Xlinker -soname=<em>&lt;name&gt;</em></strong><br /><br />-OR-<br /><br /><strong>-Xlinker -soname -Xlinker <em>&lt;name&gt;</em></strong><br /><br />Where <em><strong>&lt;name&gt;</strong></em> represents the name argument to <strong>-soname</strong> and name assigned to the shared library’s internal <strong>DT_SONAME</strong>field.<br /><br />When the incorrect syntax indicated above is used, the compiler issues the compilation error #10236, removes the "<em>&lt;name&gt;</em>" argument, and then incorrectly engages the link phase to create the shared library, but it provides only the <strong>-soname</strong> option with no <em><strong>&lt;name&gt;</strong></em> argument. It is unknown to the user the resulting shared library contains an invalid embedded <strong>DT_SONAME</strong>. This invalid <strong>DT_SONAME</strong> can cause subsequent confusing linking issues such as unresolved externals when using the shared library, and/or confusing output from the <strong>ldd</strong> utility.<br /><br />The details below show how each compiler driver (icc, icpc, ifort) is susceptible to this defect and the incorrect <strong>DT_SONAME</strong> each can embed into a shared library. What is embedded in the <strong>DT_SONAME</strong> field is influenced by the order options appear on the compiler command line. Additionally, the details show how each compiler creates a valid shared library when the correct form of the <strong>-soname</strong> option is used with <strong>-Xlinker</strong>.<br /><br /> 
<blockquote><strong><span style="text-decoration: underline;">Invalid command line:</span>icpc issues error and embeds invalid SONAME</strong><br /><br />$ icpc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubCPP.a -Xlinker --no-whole-archive -o ./libsubCPP.so -Xlinker -soname libsubCPP.so<br />Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br />icpc: error #10236: File not found: 'libsubCPP.so'<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubCPP.so | grep SONAME<br />SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64<br /><br /><br /><strong><span style="text-decoration: underline;">Valid command line:</span>icpc issues no error and embeds valid SONAME</strong><br /><br />$ icpc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubCPP.a -Xlinker --no-whole-archive -o ./libsubCPP.so -Xlinker -soname=libsubCPP.so<br />Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubCPP.so | grep SONAME<br />SONAME libsubCPP.so<br /><br /><br /><strong><span style="text-decoration: underline;">Invalid command line:</span>icc issues error and embeds invalid SONAME<br /></strong><br />$ icc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubC.a -Xlinker --no-whole-archive -o ./libsubC.so -Xlinker -soname libsubC.so<br />Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br />icc: error #10236: File not found: 'libsubC.so'<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubC.so | grep SONAME<br />SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64<br /><br /><br /><strong><span style="text-decoration: underline;">Valid command line:</span>icc issues no error and embeds valid SONAME<br /></strong><br />$ icc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubC.a -Xlinker --no-whole-archive -o ./libsubC.so -Xlinker -soname=libsubC.so<br />Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubC.so | grep SONAME<br />SONAME libsubC.so<br /><br /><br /><strong><span style="text-decoration: underline;">Invalid command line:</span>ifort issues error and embeds invalid SONAME<br /></strong><br />$ ifort -V -shared -Xlinker -relax -Xlinker --whole-archive libsubF.a -Xlinker --no-whole-archive -o ./libsubF.so -Xlinker -soname libsubF.so<br />Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cprof_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br />ifort: error #10236: File not found: 'libsubF.so'<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubF.so | grep SONAME<br />SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64<br /><br /><br /><strong><span style="text-decoration: underline;">Valid command line:</span>ifort issues no error and embeds valid SONAME<br /></strong><br />$ ifort -V -shared -Xlinker -relax -Xlinker --whole-archive libsubF.a -Xlinker --no-whole-archive -o ./libsubF.so -Xlinker -soname=libsubF.so<br />Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cprof_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br /><br />GNU ld version 2.17.50.0.6-5.el5 20061020<br /><br />$ objdump -x libsubF.so | grep SONAME<br />SONAME libsubF.so<br /></blockquote>
<br /><br /><span class="sectionHeadingText">Resolution Status :</span>  This is a known issue that will be fixed in a future release. To resolve the issue, modify any usage of the <strong>-Xlinker</strong> option with <strong>-soname </strong>to ensure the correct syntax of the <strong>-soname</strong> option is used.<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/intel-compiler-error-10236-with-soname-corrupts-shared-library-on-linux</link>
      <pubDate>Fri, 21 Aug 2009 14:17:04 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/intel-compiler-error-10236-with-soname-corrupts-shared-library-on-linux#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/intel-compiler-error-10236-with-soname-corrupts-shared-library-on-linux</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Linux* Knowledge Base</category>
    </item>
    <item>
      <title>Intel® Fortran and C++ compilers – Invalid option -i turns on incremental linking on Linux</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><span class="sectionHeadingText">Reference Number :</span> DPD200138822<br /><br /><br /><span class="sectionHeadingText">Version :</span> 10.1, 11.0, 11.1<br /><br /><br /><span class="sectionHeadingText">Operating System :</span> Linux*, Mac OS X* / IA-32, Intel® 64, IA-64<br /><br /><br /><span class="sectionHeading"><b>Problem Description : </b><br /></span><br />Both the Intel Fortran and C++ compilers for Mac OS and Linux quietly ignore the invalid option <strong>-i</strong> and pass it to the linker.<br /><br />The effect is harmless on Mac OS because the linker (ld) does not support the <strong>-i</strong> option.<br /><br />For example:<br /><br />
<blockquote>$ ifort -V -i sample.f90<br />Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090511 Package ID: m_cprof_p_11.1.046<br />Copyright (C) 1985-2009 Intel Corporation. All rights reserved.<br /><strong>ld: unknown option: -i</strong></blockquote>
<br />The effect is not harmless on Linux where both compiler driver's (icc, ifort) quietly passing the option to the linker (ld) turns on incremental linking. Incremental linking produces a non-executable <strong>LSB relocatable</strong> file and not a <strong>LSB executable</strong> file. <br /><br />Because the incremental linking is done quietly it leads to user confusion when trying to execute the non-executable <strong>LSB relocatable</strong> file. The attempt to execute the resulting file results in a "Permission denied" error.<br /><br />The demonstration below shows how the invalid -i option leads to this confusing situation and error.<br /><br />
<blockquote>$ <strong>ifort</strong> sample.f90 -o sample<br /><br />$ file sample<br />sample: ELF 64-bit <strong>LSB executable</strong>, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped<br /><br />$ <strong>ifort</strong> -i sample.f90 -o sample<br /><br />$ file sample<br />sample: ELF 64-bit <strong>LSB relocatable</strong>, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped<br /><br />$ ./sample<br />-bash: ./sample: Permission denied<br /><br /><br />$ <strong>icc</strong> sample.c -o sample<br /><br />$ file sample<br />sample: ELF 64-bit <strong>LSB executable</strong>, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped<br /><br />$ <strong>icc</strong> -i sample.c -o sample<br /><br />$ file sample<br />sample: ELF 64-bit <strong>LSB relocatable</strong>, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped<br /><br />$ ./sample<br />-bash: ./sample: Permission denied</blockquote>
<br /><br /><strong class="sectionHeadingText">Resolution Status :</strong> This is a known issue that will be fixed in a future release. Since <strong>-i</strong> is not a valid Intel compiler option, correcting or removing the option will resolve the issue.<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/invalid-option-i-turns-on-incremental-linking-on-linux</link>
      <pubDate>Thu, 13 Aug 2009 08:44:07 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/invalid-option-i-turns-on-incremental-linking-on-linux#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/invalid-option-i-turns-on-incremental-linking-on-linux</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Mac OS X* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Linux* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Mac OS X* Knowledge Base</category>
    </item>
    <item>
      <title>compiler internal error 0_1279</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><b>Reference Number : DPD200008448, DPD200137998</b><br /><br /><br /><b>Version : All the 10.x, 11.x compilers and the older versions.</b><br /><br /><br /><b>Operating System : Linux, Windows</b><br /><br /><br /><b>Problem Description : </b><br />    Test case 1: test.c<br />             int round(float in);<br />             int foo(float in)<br />             {<br />                  int res=round(in);<br />                  if(res !=0) res = 1;<br />                   return res;<br />              }<br /><br />        Test case 2: test.c<br />              float memcpy(char*, char*, int);<br />              float res;<br />              void foo(char* in, char* out)<br />              {<br />                   res = memcpy(in, out, 100);<br />              }<br />     Test case 3: test.c<br />             double pow();<br />             void bar(double);<br />             void foo()<br />             {<br />                  int a=0;<br />                  int b[1]={255};<br />                  bar(pow(b[a],2));<br />             }<br />     compile the test case: icl test.c -c<br />The compiler will report the internal error 0_0, or the internal error 0_1279, or the internal error 0_1208 etc in difference cases.<br />This is the problem in all the cases where the compiler recognize something (defined by user differently than in compiler intrinsics table) being an intrinsic call and expand this call inline.<br /><b>Resolution Status : </b><br />1. Change the function name to your own name different to the compiler intrinsic function. For example, change 'round' in case 1 to 'myround', change 'memcpy' in case 2 to 'mymemcpy', change 'pow' in case 3 to 'mypow'.<br />2. Include the compiler head files to use the intrinsic functions provided by compiler instead of to define your own. Be carefull to the compiler warnings for incompatible declarations during compilation stage.<br /><br /><br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/compiler-internal-error-0_1279</link>
      <pubDate>Mon, 20 Jul 2009 19:50:24 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/compiler-internal-error-0_1279#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/compiler-internal-error-0_1279</guid>
      <category>Intel® Parallel Composer</category>
      <category>Intel® Compilers</category>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Windows* Knowledge Base</category>
      <category>Intel® Parallel Composer Knowledge Base</category>
    </item>
    <item>
      <title>Warning: Unable to locate Debug Information Entry</title>
      <description><![CDATA[ <br />
<div id="art_pre_template"><b>Reference Number : DPD200137826</b><br /><br /><br /><b>Version : Intel(R) C++ Compiler for linux, 11.0.069, 11.0.074, 11.0.081 etc.</b><br /><br /><br /><b>Operating System : Linux</b><br /><br /><br /><b>Problem Description : </b><br />The issue can be reproduced with a simple Helloworld test case by following steps:<br />hello.cpp<br />#include &lt;iostream&gt;<br />Int main(){}<br /><br />Compile: icpc –g hello.cpp<br />Debug: idbc a.out<br />The idb will report:<br />Reading symbols from xxx/a.out…<br />Warning: Unable to locate Debug Information Entry.<br />Further instances ignored.<br />Done<br /><br /><br /><b>Resolution Status : </b><br /><br />Please upgrate the compiler to 11.1 version.<br /><br /><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></div> ]]></description>
      <link>http://software.intel.com/en-us/articles/warning-unable-to-locate-debug-information-entry</link>
      <pubDate>Sun, 12 Jul 2009 21:27:06 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/warning-unable-to-locate-debug-information-entry#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/warning-unable-to-locate-debug-information-entry</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
    </item>
    <item>
      <title>Internal Compiler Error</title>
      <description><![CDATA[ <!--page break--> 
<hr />
<div class="sectionHeading">Problem Description</div>
<p>A compilation fails with a message similar to one of the following:</p>
<blockquote>example.c(22): internal error: <br /><br />Please visit 'http://www.intel.com/software/products/support' for assistance.<br /><br />[ Aborting due to internal error. ]<br /><br />compilation aborted for example.c (code 1) <br /></blockquote>
<p> </p>
<p>or</p>
<blockquote>catastrophic error: **Internal compiler error: internal abort** <br /><br />Please report this error along with the circumstances in which it occurred in a Software Problem Report. <br /><br />Note: File and line given may not be explicit cause of this error.<br /><br />compilation aborted for example.f90 (code 3)<br /></blockquote>
<p> </p>
<!--page break--> 
<hr />
<div class="sectionHeading">Explanation</div>
<p>This message usually indicates a compiler defect.</p>
<p>Please report the problem to Intel through the <a href="http://software.intel.com/en-us/forums/">Intel® Software Network Forums</a> or <a href="https://premier.intel.com/">Intel® Premier Support</a> (support license and registration required). You will need to supply a test case along with a list of the compile options used and the exact compiler version that shows the problem. If you are not using a current compiler version, try the most recent version available to you as the error may have already been corrected.</p>
<p>Please note that this message is generic in nature and does not have a single cause nor solution. Providing a test case that reproduces the error is the only way to get a precise analysis of the problem.</p>
<p>In some, but not all, cases, you can work around the error by reducing the optimization level. You may find it helpful to try compiling with fewer switches to see if you can find one that, when removed, eliminates the error. It is also helpful to remove or comment out portions of the source file to see if you can isolate the line or lines that trigger the problem. The smaller the test case, the easier it will be for Intel to resolve the problem.</p>
<p> </p>
<p> </p>
<p> </p>
<p><i>[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]</i></p>
<p> </p> ]]></description>
      <link>http://software.intel.com/en-us/articles/internal-compiler-error</link>
      <pubDate>Thu, 02 Jul 2009 10:24:50 -0700</pubDate>
      <comments>http://software.intel.com/en-us/articles/internal-compiler-error#comments</comments>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/internal-compiler-error</guid>
      <category>Intel® C++ Compiler for Linux* Knowledge Base</category>
      <category>Intel® C++ Compiler for Mac OS X* Knowledge Base</category>
      <category>Intel® C++ Compiler for Windows* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Linux* Knowledge Base</category>
      <category>Intel® Fortran Compiler for Mac OS X* Knowledge Base</category>
      <category>Intel® Parallel Composer Knowledge Base</category>
      <category>Intel® Visual Fortran Compiler for Windows* Knowledge Base</category>
    </item>
  </channel></rss>