[cfe-dev] MSVC compiler intrinsic question

[Jean-Daniel Dupas]

Le 4 nov. 2012 à 18:54, Ryan Molden <ryanmolden at gmail.com> a écrit :

> 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- Jean-Daniel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121105/c68e4e94/attachment.html>