[PATCH] D41813: [builtins] Enable CRT_HAS_128BIT for MSVC
Loo Rong Jie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 19 05:30:10 PST 2018
rongjiecomputer added a comment.
@rnk I decided to continue to work on this patch, can you take a look?
Explanation:
1.) Change the suffix of some hex literals from `LL` to `ULL` to work around the following clang/MSVC's "bug":
http://coliru.stacked-crooked.com/a/e090d6db12ac32aa
On GCC/Mingw and GCC/Linux, the output is:
Hello
0000000000000000FFFFFFFFFFFFF800
0000000000000000FFFFFFFFFFFFF800
But on Clang/MSVC, it is:
World
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF800
0000000000000000FFFFFFFFFFFFF800
2.) Change `__int128`'s `/` operations to explicit `__divti3` function calls, also to work around clang/MSVC's bug.
3.) Disable the following failing tests (all related to `__float128`/`long double` which clang/MSVC does not have):
- fixunsxfti_test.c
- fixxfti_test.c
- floattixf_test.c
- floatuntixf_test.c
All `*xf*` builtin functions won't work as they require `long double` to be 128 bits, but I don't bother to
disable them right now as clang/MSVC won't emit calls to these functions anyway (until `__float128` is exposed).
I plan to start a discussion in `cfe-dev` about exposing `__float128` and `long double` for clang/MSVC.
clang/MSVC already exposes `__int128`, I think exposing `__float128` should be low-risk.
Do we really need to follow all the bugs in pure MSVC?
https://reviews.llvm.org/D41813
More information about the llvm-commits
mailing list