[cfe-dev] MSVC compiler intrinsic question

Ryan Molden ryanmolden at gmail.com
Sun Nov 4 09:54:01 PST 2012


Hello, I noticed there was a proposed patch by João Matos in August (
http://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg55616.html). I don't
see it in trunk so I suspect it was never committed.

I too need these intrinsics so I was applying the patch locally and writing
some simple tests for it and noticed something strange. I thought I would
ask people's opinons here as to what the right thing to do is.

The patch above calls out at least the following intrinsics as missing:

__has_nothrow_move_assign
__has_trivial_move_assign
__has_trivial_move_constructor

These are used in Microsoft's implementation of the following standard type
traits:

__has_nothrow_move_assign    -> std::is_nothrow_move_assignable
__has_trivial_move_assign        -> std::is_trivially_move_assignable
__has_trivial_move_constructor -> std::is_trivially_move_constructible

The strange thing is that MSVC 2012 appears to return false for all types I
have tested for __has_nothrow_move_assign and __has_trivial_move_assign.
__has_trivial_move_constructor seems to be implemented properly.

If I were to implement these intrinsics in Clang would it be best to
implement them correctly (i.e. as the standard dictates) or as Microsoft
apparently has in the 2012 MSVC release?  It feels like the former, as I
suspect Microsoft will fix these intrinsics. On the other hand if the idea
is to have code yield the same result as if it had been compiled under MSVC
then it seems the two intrinsics should just be 'return false'.

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121104/51c1bf46/attachment.html>


More information about the cfe-dev mailing list