'auto' bug in icpc 12.1.6 & 13.0.1

'auto' bug in icpc 12.1.6 & 13.0.1

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

#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[i] << ", ";
   std::cout << std::endl;
   
   return 0;
}

Output:

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

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

[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)

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Georg Zitzlsberger (Intel)'s picture

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

>>...
>> 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 );
}

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

>>...
>> 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 Zitzlsberger (Intel)'s picture

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

Login to leave a comment.