John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project
On Sat, May 28, 2011 at 6:47 PM, Bryce Lelbach <blelbach@cct.lsu.edu> wrote:
John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this?
If you don't hear from John by Monday, please go ahead and fix it. Please test carefully before you commit - a break in that header would mess up a lot of libraries. Thanks, --Beman
On 28 May 2011 23:47, Bryce Lelbach <blelbach@cct.lsu.edu> wrote:
John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this?
I just noticed this change. To avoid warnings, you should check that a macro is defined before using it. Common macros can be added to detail/workaround.hpp to make that easier. Although in this case I think we should be using clang's feature checking macros. For example (untested): #if defined(__has_extension) # if __has_extension(is_union) # define BOOST_IS_UNION(T) __is_union(T) # endif // .... #endif Maybe it should also check for clang first. That's pretty verbose though, perhaps something to consider for a future release. But it should be more robust than checking version numbers.
On Tue, Jun 7, 2011 at 3:41 PM, Daniel James <dnljms@gmail.com> wrote:
On 28 May 2011 23:47, Bryce Lelbach <blelbach@cct.lsu.edu> wrote:
John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this?
I just noticed this change. To avoid warnings, you should check that a macro is defined before using it. Common macros can be added to detail/workaround.hpp to make that easier.
Although in this case I think we should be using clang's feature checking macros. For example (untested):
#if defined(__has_extension)
# if __has_extension(is_union) # define BOOST_IS_UNION(T) __is_union(T) # endif
// ....
#endif
Maybe it should also check for clang first. That's pretty verbose though, perhaps something to consider for a future release. But it should be more robust than checking version numbers.
For Clang feature tests, please use __has_feature (or the newer __has_extension) rather than peeking at Clang version numbers. __has_feature/__has_extension are language-dialect aware and represent what the compiler actually supports, while Clang version numbers can vary widely from one vendor to another (e.g., Apple's version numbers for its Clang-based compilers are distinct from the LLVM project's version numbers for Clang). - Doug
On 10 June 2011 18:13, Doug Gregor <doug.gregor@gmail.com> wrote:
For Clang feature tests, please use __has_feature (or the newer __has_extension) rather than peeking at Clang version numbers. __has_feature/__has_extension are language-dialect aware and represent what the compiler actually supports, while Clang version numbers can vary widely from one vendor to another (e.g., Apple's version numbers for its Clang-based compilers are distinct from the LLVM project's version numbers for Clang).
Can we distinguish between Apple's versions and LLVM's versions?
On Sun, Jun 12, 2011 at 4:27 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 June 2011 18:13, Doug Gregor <doug.gregor@gmail.com> wrote:
For Clang feature tests, please use __has_feature (or the newer __has_extension) rather than peeking at Clang version numbers. __has_feature/__has_extension are language-dialect aware and represent what the compiler actually supports, while Clang version numbers can vary widely from one vendor to another (e.g., Apple's version numbers for its Clang-based compilers are distinct from the LLVM project's version numbers for Clang).
Can we distinguish between Apple's versions and LLVM's versions?
__APPLE_CC__ will say whether we're running on Darwin, but otherwise, no. - Doug
On 13 June 2011 20:33, Doug Gregor <doug.gregor@gmail.com> wrote:
On Sun, Jun 12, 2011 at 4:27 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 June 2011 18:13, Doug Gregor <doug.gregor@gmail.com> wrote:
For Clang feature tests, please use __has_feature (or the newer __has_extension) rather than peeking at Clang version numbers. __has_feature/__has_extension are language-dialect aware and represent what the compiler actually supports, while Clang version numbers can vary widely from one vendor to another (e.g., Apple's version numbers for its Clang-based compilers are distinct from the LLVM project's version numbers for Clang).
Can we distinguish between Apple's versions and LLVM's versions?
__APPLE_CC__ will say whether we're running on Darwin, but otherwise, no.
That will a problem for working around bugs. Anyway, I think this means the type traits change is incorrect. Since this is for a version of clang that won't be released for some time, it's probably best to revert it in the release branch.
On Mon, Jun 13, 2011 at 12:47 PM, Daniel James <dnljms@gmail.com> wrote:
On 13 June 2011 20:33, Doug Gregor <doug.gregor@gmail.com> wrote:
On Sun, Jun 12, 2011 at 4:27 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 June 2011 18:13, Doug Gregor <doug.gregor@gmail.com> wrote:
For Clang feature tests, please use __has_feature (or the newer __has_extension) rather than peeking at Clang version numbers. __has_feature/__has_extension are language-dialect aware and represent what the compiler actually supports, while Clang version numbers can vary widely from one vendor to another (e.g., Apple's version numbers for its Clang-based compilers are distinct from the LLVM project's version numbers for Clang).
Can we distinguish between Apple's versions and LLVM's versions?
__APPLE_CC__ will say whether we're running on Darwin, but otherwise, no.
That will a problem for working around bugs.
Theoretically, yes. If it becomes a practical problem, we'll deal with it.
Anyway, I think this means the type traits change is incorrect. Since this is for a version of clang that won't be released for some time, it's probably best to revert it in the release branch.
I don't know which type-traits changes you're referring to. If the intent is to pick up Clang's built-ins, then __has_feature is the way to detect which built-ins are available regardless of Clang version. - Doug
participants (4)
-
Beman Dawes -
Bryce Lelbach -
Daniel James -
Doug Gregor