A CUDA 8 RC + GCC 5.x compatibility issue: unordered_map::emplace and std::forward

(I’m posting this (after discussing the matter on StackOverflow) here after having been sort-of convinced this is probably a CUDA issue rather than a bug in my code.)
Consider the following code:

#include <string>
#include <unordered_map>
    
int main()
{
    std::string s("hello");
    std::unordered_map<std::string, int> map;
    map.emplace(s, 123);
    return 0;
}

This builds fine with:

  • GCC 4.9.3 , no CUDA
  • GCC 5.3.1 , no CUDA
  • GCC 4.9.3 via CUDA 7.5 (with file extension .cu)
  • GCC 4.9.3 via CUDA 8 RC (with file extension .cu)

but fails to compile with GCC 5.3.1 via CUDA 8 RC.

The error I get is:

/usr/include/c++/5/bits/hashtable.h(1526): error: no instance of overloaded function "std::forward" matches the argument list
            argument types are: (std::__cxx11::string)
          detected during:
            instantiation of "std::pair<std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::iterator, __nv_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=<std::__cxx11::string &, int>]" 
(726): here
            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=<std::__cxx11::string &, int>]" 
/usr/include/c++/5/bits/unordered_map.h(380): here
            instantiation of "std::pair<std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::iterator, __nv_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=<std::__cxx11::string &, int>]" 
a.cu(8): here

1 error detected in the compilation of "/tmp/tmpxft_000035f7_00000000-9_a.cpp1.ii".

Why is this happening? Is it indeed a CUDA bug? If so, is this forum the place to report it?

I saw your posting on SO.

Based on this:

GCC 4.9.3 via CUDA 8 RC (with file extension .cu)
but fails to compile with GCC 5.3.1 via CUDA 8 RC.

my guess is that this is a (CUDA) bug. I don’t happen to have a gcc 5.3.1 setup atm, but I have gotten Fedora23 and was about to set up a machine with Fedora23 and CUDA 8 RC to test this.

Based on that I would probably file a bug assuming I made no other interesting discoveries in the process.

I would encourage you to file a bug at developer.nvidia.com

Although this forum is patrolled by NVIDIA people to some degree, there is not a stated guarantee that issues reported here will be converted into NVIDIA bugs.

I had never done that before, so this was my first time. Here it is:

https://developer.nvidia.com/nvbugs/cuda/edit/1774129

(I hope you can see it if you’re not me, I only know how to get an edit link so far.)

[b]txbob[b]: How do I know if anyone at nVIDIA has lookd at my bug? There’s no “status: ASSIGNED” or anything like that.

Well, apparently this was fixed:

Wed, 2016-06-29 10:01
Kevin Kang

Hi, This issue has been fixed now in our development builds, and the fix would be available for you in
the next CUDA release(that following of CUDA 8.0 RC). Thanks again for reporting this issue to us.