[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