[clang-3.2] unique_ptr: compiler errors

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[clang-3.2] unique_ptr: compiler errors

Suman Kar
Hello,

The following:

#include <memory>
int main() {
 using namespace std;
 unique_ptr<int> up( new int( 30 ) );
}

generates:

$ /d/llvm_workspace/build/Debug+Asserts/bin/clang++ -std=c++11 -Wall foo.cpp
 -o foo
In file included from vector.cpp:1:
In file included from c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\memory:75:
c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:228:2: error: no
      matching function for call to '_S_destroy'
        _S_destroy(&_M_mutex);
        ^~~~~~~~~~
c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:273:7: note:
      candidate template ignored: substitution failure [with _Rm =
      __gthread_recursive_mutex_t]: non-type template argument evaluates to 4,
      which cannot be narrowed to type 'bool'
      _S_destroy(_Rm* __mx)
      ^
c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:282:7: note:
      candidate template ignored: substitution failure [with _Rm =
      __gthread_recursive_mutex_t]: no member named 'actual' in
      '__gthread_recursive_mutex_t'
      _S_destroy(_Rm* __mx)
      ^
c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:290:7: note:
      candidate template ignored: substitution failure [with _Rm =
      __gthread_recursive_mutex_t]: no type named '__type' in
      '__gnu_cxx::__enable_if<false, void>'
      _S_destroy(_Rm* __mx)
      ^
1 error generated.

I am using clang 3.2 version:

clang version 3.2 (trunk 157115) (llvm/trunk 157155)
Target: i686-pc-mingw32
Thread model: posix

I'd like to know if this is a problem with my installation/gcc/build
issue. Any help will be much appreciated.

Regards,
Suman
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [clang-3.2] unique_ptr: compiler errors

Richard Smith
Hi,

On Sat, Jun 2, 2012 at 10:45 AM, Suman Kar <[hidden email]> wrote:

> Hello,
>
> The following:
>
> #include <memory>
> int main() {
>  using namespace std;
>  unique_ptr<int> up( new int( 30 ) );
> }
>
> generates:
>
> $ /d/llvm_workspace/build/Debug+Asserts/bin/clang++ -std=c++11 -Wall foo.cpp
>  -o foo
> In file included from vector.cpp:1:
> In file included from c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\memory:75:
> c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:228:2: error: no
>      matching function for call to '_S_destroy'
>        _S_destroy(&_M_mutex);
>        ^~~~~~~~~~
> c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:273:7: note:
>      candidate template ignored: substitution failure [with _Rm =
>      __gthread_recursive_mutex_t]: non-type template argument evaluates to 4,
>      which cannot be narrowed to type 'bool'
>      _S_destroy(_Rm* __mx)
>      ^
> c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:282:7: note:
>      candidate template ignored: substitution failure [with _Rm =
>      __gthread_recursive_mutex_t]: no member named 'actual' in
>      '__gthread_recursive_mutex_t'
>      _S_destroy(_Rm* __mx)
>      ^
> c:/MinGW/lib/gcc/mingw32/4.6.2/include/c++\ext/concurrence.h:290:7: note:
>      candidate template ignored: substitution failure [with _Rm =
>      __gthread_recursive_mutex_t]: no type named '__type' in
>      '__gnu_cxx::__enable_if<false, void>'
>      _S_destroy(_Rm* __mx)
>      ^
> 1 error generated.
>
> I am using clang 3.2 version:
>
> clang version 3.2 (trunk 157115) (llvm/trunk 157155)
> Target: i686-pc-mingw32
> Thread model: posix
>
> I'd like to know if this is a problem with my installation/gcc/build
> issue. Any help will be much appreciated.

This is a libstdc++ bug, in code which seems to be Win32-specific. The
code looks like this (around ext/concurrence.h:273):

    template<typename _Rm>
      static typename __enable_if<sizeof(&_Rm::sema), void>::__type
      _S_destroy(_Rm* __mx)

The intent appears to be to cause a substitution failure if there is
no _Rm::sema member, but the actual effect is that this is always
ill-formed in C++11 mode, since a pointer/pointer-to-member has size >
1, and thus the sizeof expression can't be narrowed to bool. You can
fix this header by casting the result of sizeof to bool:

      static typename __enable_if<(bool)sizeof(&_Rm::sema), void>::__type

I've filed this against libstdc++ as gcc.gnu.org/PR53578.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [clang-3.2] unique_ptr: compiler errors

Suman Kar
On Tue, Jun 5, 2012 at 5:49 AM, Richard Smith <[hidden email]> wrote:
> Hi,
>
> On Sat, Jun 2, 2012 at 10:45 AM, Suman Kar wrote:
[...]

>>
>> I'd like to know if this is a problem with my installation/gcc/build
>> issue. Any help will be much appreciated.
>
> This is a libstdc++ bug, in code which seems to be Win32-specific. The
> code looks like this (around ext/concurrence.h:273):
>
>    template<typename _Rm>
>      static typename __enable_if<sizeof(&_Rm::sema), void>::__type
>      _S_destroy(_Rm* __mx)
>
> The intent appears to be to cause a substitution failure if there is
> no _Rm::sema member, but the actual effect is that this is always
> ill-formed in C++11 mode, since a pointer/pointer-to-member has size >
> 1, and thus the sizeof expression can't be narrowed to bool. You can
> fix this header by casting the result of sizeof to bool:
>
>      static typename __enable_if<(bool)sizeof(&_Rm::sema), void>::__type
>
> I've filed this against libstdc++ as gcc.gnu.org/PR53578.

This is great! Thanks a ton!

I've just patched the header. However, it is rather strange that the
same code compiles as-is (i.e. without patching) with gcc 4.6.2
(-std=c++0x -Wall) but complains with clang  (-std=c++11 -Wall). I
take it to be a limitation on gcc's part, of C++11 support,
specifically the bit about narrowing.

There are some helpful comments (already!) on the gcc bug too.

Regards,
Suman

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev