16.0.0 glitch with GCC 5.1.1 C++ headers in C++11 mode

[Dmitry_A_1]

The following code compiles fine with just 'icpc test.cc':

#include <vector>

int main (int argc, char *argv[]) {
  std::vector<int> x (100, 1);
}

But with  icpc -std=c++11, it produces:

/usr/include/c++/5.1.1/bits/stl_iterator_base_types.h(154): error: name followed by "::" must be a class or namespace name
        typedef typename _Iterator::iterator_category iterator_category;
                         ^
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=int]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=int]" at line 4 of "t-icpc.cc"

/usr/include/c++/5.1.1/bits/stl_iterator_base_types.h(155): error: name followed by "::" must be a class or namespace name
        typedef typename _Iterator::value_type        value_type;
                         ^
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=int]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=int]" at line 4 of "t-icpc.cc"

/usr/include/c++/5.1.1/bits/stl_iterator_base_types.h(156): error: name followed by "::" must be a class or namespace name
        typedef typename _Iterator::difference_type   difference_type;
                         ^
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=int]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=int]" at line 4 of "t-icpc.cc"

/usr/include/c++/5.1.1/bits/stl_iterator_base_types.h(157): error: name followed by "::" must be a class or namespace name
        typedef typename _Iterator::pointer           pointer;
                         ^
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=int]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=int]" at line 4 of "t-icpc.cc"

/usr/include/c++/5.1.1/bits/stl_iterator_base_types.h(158): error: name followed by "::" must be a class or namespace name
        typedef typename _Iterator::reference         reference;
                         ^
          detected during:
            instantiation of class "std::__iterator_traits<_Iterator, void> [with _Iterator=int]" at line 163
            instantiation of class "std::iterator_traits<_Iterator> [with _Iterator=int]" at line 4 of "t-icpc.cc"

Observed on Fedora 22 system with stock GCC 5.1.1.

[Judith_W_Intel]

Yes we are aware of this problem see:

https://software.intel.com/en-us/forums/topic/565143

This bug is currently our #1 priority and we hope to have it fixed soon. Sorry for the inconvenience.

Judy

[Alexey_S_2]

Any news on this issue? Since release of MPSS 3.6 (which uses gcc 5.1.1 internaly) this issue renders XeonPhi with recent MPSS unusable with recent ICC 2016 (at least 2016.0.109 has this issue)

[Alexey_S_2]

Well. Any update on this old bug? icc 16.0.1 ( 2016.1.150) seems has same issue.

[Nicholas_S_Intel]

+1 on the sighting.

any update?

[dogunter]

"This bug is currently our #1 priority and we hope to have it fixed soon. Sorry for the inconvenience."

I'm still hitting this issue with the latest Intel 16.0.1 compiler on a system with GCC 5.2.0 installed.  If that was the number 1 priority bug, I'd hate to see how backed up you all are right now.

-david

[TimP]

icc -V
Intel(R) C Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.181 Build 20160204

 g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc6.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc6.0/ --enable-languages='c c++ fortran' --disable-multilib
Thread model: posix
gcc version 6.0.0 20160101 (experimental) (GCC)

$ icpc -Wcheck  nw.cpp

$

I no longer have the compilers from last November and earlier installed, but it seems you will need to upgrade to this month's compiler to see the fix.  Intel probably will not issue another 16.0.1 after moving on to 16.0.2.

[Judith_W_Intel]

Yes as Tim points out it's fixed in update 2. Please download.

[Pritchard__Ben]

Judith Ward (Intel) wrote:

Yes as Tim points out it's fixed in update 2. Please download.

Somewhat related (to the thread title anyway): Still seems to be a problem with std::unordered_map for me (Intel 16.0.2, gcc 5.3.1)

#include <unordered_map>
#include <iostream>
#include <string>

int main(void)
{
    std::unordered_map<std::string, int> m;
    m.emplace("Key", 5);

    for(const auto & it : m)
        std::cout << it.first << " : " << it.second << "\n";

};

/usr/include/c++/5.3.1/bits/hashtable.h(1526): error: no instance of overloaded function "std::forward" matches the argument list
            argument types are: (const char [4])
      __node_type* __node = this->_M_allocate_node(std::forward<_Args>(__args)...);
                                                   ^
          detected during:
            instantiation of "std::pair<std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::iterator, bool> std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::_M_emplace(std::true_type, _Args &&) [with _Key=std::__cxx11::string, _Value=std::pair<const std::__cxx11::string, int>, _Alloc=std::allocator<std::pair<const std::__cxx11::string, int>>, _ExtractKey=std::__detail::_Select1st,
                      _Equal=std::equal_to<std::__cxx11::string>, _H1=std::hash<std::__cxx11::string>, _H2=std::__detail::_Mod_range_hashing, _Hash=std::__detail::_Default_ranged_hash, _RehashPolicy=std::__detail::_Prime_rehash_policy, _Traits=std::__umap_traits<true>, _Args=<const char (&)[4], int>]" at line 726
            instantiation of "std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::__ireturn_type std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::emplace(_Args &&...) [with _Key=std::__cxx11::string, _Value=std::pair<const std::__cxx11::string, int>, _Alloc=std::allocator<std::pair<const std::__cxx11::string, int>>, _ExtractKey=std::__detail::_Select1st,
                      _Equal=std::equal_to<std::__cxx11::string>, _H1=std::hash<std::__cxx11::string>, _H2=std::__detail::_Mod_range_hashing, _Hash=std::__detail::_Default_ranged_hash, _RehashPolicy=std::__detail::_Prime_rehash_policy, _Traits=std::__umap_traits<true>, _Args=<const char (&)[4], int>]" at line 380 of "/usr/include/c++/5.3.1/bits/unordered_map.h"
            instantiation of "std::pair<std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::iterator, bool> std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::emplace(_Args &&...) [with _Key=std::__cxx11::string, _Tp=int, _Hash=std::hash<std::__cxx11::string>, _Pred=std::equal_to<std::__cxx11::string>, _Alloc=std::allocator<std::pair<const std::__cxx11::string, int>>, _Args=<const char (&)[4], int>]" at line 8 of "test.cpp"

[Judith_W_Intel]

I have confirmed that this was fixed by the fix for DPD200380567 which was reported and fixed shortly after 16.0 update 2 was frozen.

Expect the fix in the next update. Once again sorry for the inconvenience.

Here's a description of the problem:

1/15/16
Redeclarations of variadic function templates

When a variadic function template is redeclared using a form that is slightly
different from the original declaration, the front end sometimes corrupted the
type of the function template, causing the variadic nature of parameters to
be lost and incorrect deduction behavior later on.  For example:

  template<typename ...  Ts> void f(Ts&&...);
  template<typename ...  Ts> auto f(Ts&&...)->void {}
  void g() {
    f(1, 2);  // Previously triggered a spurious error.  Now okay.
  }

This is now fixed.

[Kittur_G_Intel]

Hi,
Just letting you know that this issue is fixed in the latest 16.0 update 2 release which you can download and test it out. Thanks for bringing this issue to our attention and patience through this issue as well.
Kittur

[Kittur_G_Intel]

The one Judy refers to is of course fixed in the upcoming 16.0 update 3 release and will let you know as soon as it's out, appreciate much.

_Kittur

[Anoop_M_Intel]

16.0 Update 3 compiler is available for download from Intel Registration Center.

Thanks and Regards
Anoop