MSVC compiler intrinsic question

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

Hi Ryan.

I’d say we should implement these correctly unless something in MS’s standard library relies on the incorrect behavior to function properly. The consensus seems to be that Clang has no goal to be bug-for-bug compatible with MSVC unless it prevents something from working correctly.

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.

IIRC, __has_nothrow_move_assign rely on the noexcept keyword, which is not yet implemented in MSVC 2012, but will be in a future release, so you should not rely on the misbehavior.

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


cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

– Jean-Daniel