I am not sure I understand your point about the __has_trivial_constructor intrinsic being broken... it seems to work pretty fine to me ?
Darn, you're right, thanks for the correction.
Boost::is_pod and boost::has_trivial_constructor become broken because the first one use the intrinsic and the second one use the first one...
Yup, that was what I was seeing.
As far as I am concerned, I patched boost/type_traits/intrinsics.hpp by commenting out the __is_pod intrinsic, and now everything seems working fine.
Most of the time, code using is_pod can be refined to be more generic and only use the other intrinsics. I thus managed to remove all is_pod uses from my code and thus still always benefit from compiler information.
Perhaps it would be possible to rebuild a non-broken is_pod using compiler information, based only on the other intrinsics ?
Yep, just done it: change intrinsics.hpp to contain: # define BOOST_IS_POD(T) (__is_pod(T) && __has_trivial_constructor(T)) and your test case passes now. I need to do some more testing, but that does look like a good fix. John.