[cfe-dev] MSVC compiler intrinsic question
ripzonetriton at gmail.com
Sun Nov 4 10:11:52 PST 2012
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.
On Sun, Nov 4, 2012 at 5:54 PM, Ryan Molden <ryanmolden at gmail.com> wrote:
> Hello, I noticed there was a proposed patch by João Matos in August (
> http://firstname.lastname@example.org/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:
> 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'.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev