'auto' bug in icpc 12.1.6 & 13.0.1

[Christian_Godenschwa]

The following code seems not to work with the compilers mentioned above on Linux OS.

[cpp]

#include <vector>
#include <iostream>

typedef unsigned long T;  // doesn't work
//typedef unsigned int T; // works

int main()
{
   std::vector<T> fibonacci;
   
   fibonacci.push_back( T(0) );
   fibonacci.push_back( T(1) ); // works for just 2 elements
   fibonacci.push_back( T(1) ); // doesn't work with 3 elements (and "unsigned long" and auto)
 //fibonacci.push_back( T(2) ); // works again with 4 elements
   
   auto fib( fibonacci );           // doesn't work
 //std::vector<T> fib( fibonacci ); // works

   for( int i = 0; i < fib.size(); ++i )
      std::cout << fib << ", ";
   std::cout << std::endl;
   
   return 0;
}
[/cpp]

Output:

[bash]

[SHELL]> g++ -std=c++0x main.cpp && ./a.out

0, 1, 1,

[SHELL]> icpc -std=c++0x main.cpp && ./a.out

6303744, 1, 1,

[/bash]

Valgrind output (We suspect the output to be correct due to 0 initialization of memory):

[bash]

[SHELL]> valgrind ./a.out

==1734== Memcheck, a memory error detector

==1734== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.

==1734== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info

==1734== Command: ./a.out

==1734==

==1734== Invalid read of size 8

==1734==    at 0x400FCD: main (in ~/a.out)

==1734==  Address 0x5b0b140 is 0 bytes inside a block of size 24 free'd

==1734==    at 0x4C273B8: operator delete(void*) (vg_replace_malloc.c:480)

==1734==    by 0x400FB8: main (in ~/a.out)

==1734==

0, 1, 1,

==1734==

==1734== HEAP SUMMARY:

==1734==     in use at exit: 0 bytes in 0 blocks

==1734==   total heap usage: 4 allocs, 4 frees, 80 bytes allocated

==1734==

==1734== All heap blocks were freed -- no leaks are possible

==1734==

==1734== For counts of detected and suppressed errors, rerun with: -v

==1734== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 5 from 5)

[/bash]

[Georg_Z_Intel]

Hello, that's high likely a bug. I've filed a defect ticket for engineering (DPD200239961). I'll keep you updated on this. Thank you for reporting! Best regards, Georg Zitzlsberger

[SergeyKostrov]

>>... >> typedef unsigned long T; // doesn't work >>// typedef unsigned int T; // works >>... I'm not a supporter of using T as a type declaration synonym but it is clear that something is wrong. Here are two simplified test-cases: // Test-Case 1 { typedef unsigned long T; T tA = 0U; std::vector< T > tVec; tVec.push_back( T( 0 ) ); tVec.push_back( ( T )1 ); } // Test-Case 2 { typedef unsigned int T; T tA = 0U; std::vector< T > tVec; tVec.push_back( T( 0 ) ); tVec.push_back( ( T )1 ); }

[Christian_Godenschwa]

The problem we experienced originated in a templated function. The 'T' just a remained during simplification.

[SergeyKostrov]

>>... >> typedef unsigned long T; // doesn't work >>// typedef unsigned int T; // works >>... I couldn't reproduce the problem with the typedef declaration using version 12 of Intel C++ Compiler ( 12.1.3.300 / 32-bit ) on a Windows platform.

[Georg_Z_Intel]

Hello, The described problem is fixed with the next update: Intel(R) Composer XE 2013 Update 3 (edit: fixed typo 2011->2013) Best regards, Georg Zitzlsberger