[TypeTraits] A patch for clang's intrinsics (was: [type_traits] is_enum on scoped enums doesn't works as expected)

John Maddock wrote:
Boost.TypeTraits does not use intrinsics for clang yet. (c.f. https://svn.boost.org/trac/boost/changeset/72725)
this explains why it is not working now. Is someone working on this issue?
Not me, we need a Clang expert to look into it - or at least someone with access to Clang to take care of the testing - someone did submit a patch to enable intrinsic support for Clang, but it broke more things than it fixed so it got reverted :-(
Let's proceed step by step. As a first step, I made a patch to use clang's intrinsics except problematic intrinsics (i.e. `is_pod` and `is_empty`). All the tests run successfully on gcc-4.4, 4.5, 4.6, clang (trunk) and Mac OS X Lion's clang (Apple clang version 2.1). Regards, Michel

Let's proceed step by step. As a first step, I made a patch to use clang's intrinsics except problematic intrinsics (i.e. `is_pod` and `is_empty`).
All the tests run successfully on gcc-4.4, 4.5, 4.6, clang (trunk) and Mac OS X Lion's clang (Apple clang version 2.1).
Applied, thanks! John.

Update: `__is_pod` and `__is_empty` can be safely used with libc++. A patch attached (against trunk). All the tests run fine. Regards, Michel

Update: `__is_pod` and `__is_empty` can be safely used with libc++.
A patch attached (against trunk). All the tests run fine.
OK I'm curious - why would a compiler intrinsic work when used with one std lib, not not when used with another? John.

John Maddock wrote:
Update: `__is_pod` and `__is_empty` can be safely used with libc++.
A patch attached (against trunk). All the tests run fine.
OK I'm curious - why would a compiler intrinsic work when used with one std lib, not not when used with another?
Here is the details: libstdc++ (of gcc-4.2) defines `struct __is_pod` in some header file. To deal with this, clang disables __is_pod intrinsics when finding `struct __is_pod`; then, __is_pod is not treated as keyword and it becomes just an identifier. However, even in this case, old clang sets __has_feature(is_pod) to 1. So we cannot rely on `#if __has_feature(is_pod)` to check the availability of __is_pod intrinsics. libc++ does not define `struct __is_pod`, so we can safely check the availability of __is_pod intrinsics by `#if __has_feature(is_pod)`. Ditto for __is_empty. Regards, Michel

OK I'm curious - why would a compiler intrinsic work when used with one std lib, not not when used with another?
Here is the details:
libstdc++ (of gcc-4.2) defines `struct __is_pod` in some header file. To deal with this, clang disables __is_pod intrinsics when finding `struct __is_pod`; then, __is_pod is not treated as keyword and it becomes just an identifier. However, even in this case, old clang sets __has_feature(is_pod) to 1. So we cannot rely on `#if __has_feature(is_pod)` to check the availability of __is_pod intrinsics.
libc++ does not define `struct __is_pod`, so we can safely check the availability of __is_pod intrinsics by `#if __has_feature(is_pod)`.
Ditto for __is_empty.
Got it, that's just plain nasty isn't it? Will apply the patch shortly, John.

Le 01/09/11 19:39, John Maddock a écrit :
OK I'm curious - why would a compiler intrinsic work when used with one std lib, not not when used with another?
Here is the details:
libstdc++ (of gcc-4.2) defines `struct __is_pod` in some header file. To deal with this, clang disables __is_pod intrinsics when finding `struct __is_pod`; then, __is_pod is not treated as keyword and it becomes just an identifier. However, even in this case, old clang sets __has_feature(is_pod) to 1. So we cannot rely on `#if __has_feature(is_pod)` to check the availability of __is_pod intrinsics.
libc++ does not define `struct __is_pod`, so we can safely check the availability of __is_pod intrinsics by `#if __has_feature(is_pod)`.
Ditto for __is_empty.
Got it, that's just plain nasty isn't it? Yes. It seems that C++ compiler and C++ standard library providers shouldn't use the same prefix for the intrinsics and the internals.
Best, Vicente
participants (4)
-
John Maddock
-
Michel Morin
-
Michel MORIN
-
Vicente J. Botet Escriba