Reference Number : DPD200136749


Version : 10.1, 11.0, 11.1


Product : Intel® C++ Compilers Professional Edition for Windows* and Linux*.  Intel ® Parallel Composer.


Operating System : Windows* versions prior to Windows Vista* or equivalent, Linux*


Problem Description : When using precompiled headers, you may see the diagnostic:

Warning #677: memory usage conflict with precompiled header file

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.


Resolution Status : We are investigating this issue.  Please contact us via the User Forum or Intel® Premier Support if you are experiencing this issue.



[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.]

Reference Number : DPD200084693


Version : 11.1.038


Operating System : Windows


Problem Description : 

Following case will get unresolved external symbol error at linking stage if use c++ stream to pass numerical variables with option /Qlong_double specified.

Case: test006.cpp

#include <stdio.h>
#include <iostream>
using namespace std;
int main()
{
            int x=0;          //line 6
            cout << x;      //line 7
}

Command:

icl /Od /Ob1 /Qlong_double /MDd test006.cpp 

Fail Output:

 -out:test006.exe
test006.obj
test006.obj : error LNK2001: unresolved external symbol "protected: virtual class std::ostreambuf_iterator<char,struct std::char_traits<char> > __thiscall std::num_put<char,class std::ostreambuf_iterator<char,struct std::char_traits<char> > >::do_put(class std::ostreambuf_iterator<char,struct std::char_traits<char> >,class std::ios_base &,char,UNKNOWN)const " (?do_put@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@MBE?AV?$ostreambuf_iterator@DU?$char_traits@D@std@@@2@V32@AAVios_base@2@D_T@Z)
test006.exe : fatal error LNK1120: 1 unresolved externals

 

While if changing line 6 & 7 to following,  the test will link fine: 

char x='0';          //line 6
cout << x;          //line 7

Currently only using the option combination like "/Ob{1|2} /Qlong_double /MD[d]" and the use of C++ stream to pass numerical variable will trigger this link failure.  

Resolution Status : 
This is a regression from C++ Compiler 11.0 regarding a new feature on 11.1:
"The post-11.0 handling of dllimport and inline, decides not to emit the funciton definition in this case, because it is expected to be supplied from the DLL. You can get the 11.0 and before behavior back by using /mGLOB_cg_lower_dllimport=F."

Other possible work-arounds are:
1. Use /Ob0 while using /Qlong_double.
2. Avoid the use of C++ stream to pass numerical variables. In this case use printf instead.



[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.]

Reference Number : DPD200084262


Version : 11.1.038 for Windows running on Intel(R) 64


Operating System : Windows x64 edition


Problem Description : 
The following program will get stack frame Run-Time Check(RTC) failure due to incompatible RTC stack frame check between Intel C++ Compiler for Windows and Microsoft* Visual C++ 2005 or 2008 for x64 run time library.

--- Program ---

void sub();

int main(int argc, char* argv[])
{
  sub();
  return 0;
}

void sub()
{
  int i;
  __declspec(align(64)) float aiueo[256];

  for (i=0;i<256;i++)
    aiueo[i] = 0;

  return;
}

--- RTC error message ---

Run-Time Check Failure #2 - Stack around the variable 'result.38007' was corrupted.

--- problem definition ---

If array "aiueo" is defined as align(32), align(64) or above, this failure will expose. If array "aiueo" is defined as align(8), align(16), this failure will be avoided.

This is a stack frame Run-Time Check(RTC: /RTCs) incompatible issue between Intel C++ Compiler for Windows and Microsoft Visual C++ Compiler for x64 platform run time library. The program binary is actually gengerated correctly.

Resolution Status : 

This has been fixed in the 11.1.046 C++ Compiler for Windows.

 

[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.]

Reference Number : DPD200135511


Version : 11.1


Operating System : Windows*


Problem Description : The Boost* STL library's bind functionality uses a construct called placeholders to bind function arguments to a function.  Boost implements these placeholders in an anonymous namespace which the Intel® C++ Compiler has problems with when pre-compiled header files are used and debug symbol generation is enabled.  The following code demonstrates the problem (requires Boost* libraries).

pch.h:

#include <boost/bind.hpp>

pch.cpp:

#include "pch.h"

test-bind.cpp:

#include "pch.h" class blh_widge { public: void Init(); private: void OnInputComplete(int, int, int); }; void blh_widge::Init() { boost::bind(&blh_widge::OnInputComplete, this, _1, _2, _3) {} } int main() { return(0); }

Reproduce:

icl -Od -I<boost include> -Ycpch.h -Fptest-bind.pch -c -Zi pch.cpp icl -Od -I<boost include> -Yupch.h -Fptest-bind.pch -Zi test-bind.cpp test-bind.cpp Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. -out:test-bind.exe -debug -pdb:test-bind.pdb test-bind.obj test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<1> __N_13_test_bind_cpp_main::_1" (?_1@__N_13_test_bind_cpp_main@@3U?$arg@$00@boost @@A) referenced in function ___sti__?_1@__N_13_test_bind_cpp_main@@3U?$arg@$00@b oost@@A test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<2> __N_13_test_bind_cpp_main::_2" (?_2@__N_13_test_bind_cpp_main@@3U?$arg@$01@boost @@A) referenced in function ___sti__?_2@__N_13_test_bind_cpp_main@@3U?$arg@$01@b oost@@A test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<3> __N_13_test_bind_cpp_main::_3" (?_3@__N_13_test_bind_cpp_main@@3U?$arg@$02@boost @@A) referenced in function ___sti__?_3@__N_13_test_bind_cpp_main@@3U?$arg@$02@b oost@@A test-bind.exe : fatal error LNK1120: 3 unresolved externals

Resolution Status : This issue is resolved in the Intel® Parallel Composer Update 1 or Intel® C++ Compiler Professional Edition for Windows* 11.1.038.


[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.]

Reference Number : DPD200008448, DPD200137998


Version : All the 10.x, 11.x compilers and the older versions.


Operating System : Linux, Windows


Problem Description : 
    Test case 1: test.c
             int round(float in);
             int foo(float in)
             {
                  int res=round(in);
                  if(res !=0) res = 1;
                   return res;
              }

        Test case 2: test.c
              float memcpy(char*, char*, int);
              float res;
              void foo(char* in, char* out)
              {
                   res = memcpy(in, out, 100);
              }
     Test case 3: test.c
             double pow();
             void bar(double);
             void foo()
             {
                  int a=0;
                  int b[1]={255};
                  bar(pow(b[a],2));
             }
     compile the test case: icl test.c -c
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.
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.
Resolution Status : 
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'.
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.



[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.]

Reference Number : 
U66541 / DPD200137349

Version : 
Intel C++ compiler 11.1.035


Operating System : 
Windows


Problem Description :

When I change the project property in VS2003 to set the /Qfp-speculation to safe, the result in command line is not "/Qfp-speculation:safe", it is appearing as "/Qfp-speculationsafe" and we get error during compilation.

Resolution Status :


One needs to provide an argument to compiler /Qfp-speculation. The valid arguments are fast, safe, strict and off. The compiler option /Qfp-speculation from IDE is not being set properly. You may set this option from command line property page as work around.

We have tried /Qfp-speculation:safe in VS2008 from command line and there is no issue.




[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.]

Reference Number :  DPD200110877


Version : 11.0, 11.1 or Intel® Parallel Composer


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


Problem Description : The OpenMP* 3.0 standard now supports using STL iterators for OpenMP loop bounds.  However, the Intel® C++ Compiler does not parallelize code like the following:

#include <vector>

void iterator_example()
{
  std::vector<double> vec(23);
  std::vector<double>::iterator it;

#pragma omp parallel for default(none) shared(vec) 
  for (it = vec.begin(); it < vec.end(); it++)
  {
    *it = 1.0;// do work with *it //
  }
}

The compiler will not give an indication (as it should) that the loop was parallelized for OpenMP*.  If you examine the code, you will see that the compiler generates a serial version of the loop.  This is because of an issue with the compiler using function calls on loop bounds that are inlined causing the compiler to not recognize the loop as being a validly formed loop for parallelization.


Resolution Status : This will be resolved in an upcoming compiler update.



[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.]