vsavchenko added a comment. In D86465#2637186 <https://reviews.llvm.org/D86465#2637186>, @steakhal wrote:
> Ah, I wanted to give it a go, but the bots caught an assertion failure for > the parent revision of this. See the details at the Bugzilla ticket > <https://bugs.llvm.org/show_bug.cgi?id=49642>. > > What is more concerning is that this patch resolves that assertion failure. I > guess it implies it can not be NFC? > Regardless, I'm gonna wait to get that issue fixed before I have a deeper > look. Hmm, I tried it on that test without the fix, and the assertion failure is there. In D86465#2640842 <https://reviews.llvm.org/D86465#2640842>, @steakhal wrote: > In D86465#2640765 <https://reviews.llvm.org/D86465#2640765>, @vsavchenko > wrote: > >> I do have a bit of a struggle here. This is a unit-test and thus should be >> compiled for all of the supported architectures by all of the supported >> compilers. >> Is there a `__has_feature` or something for me to check if `_ExtInt` can be >> used? > > Aa, I get it. It is actually a clang specific extension. By checking git > blame > <https://github.com/llvm/llvm-project/commit/5f0903e9bec97e67bf34d887bcbe9d05790de934>, > it seems to be a quite new feature, clang-11+. > What about something like this? > > using IntTypes = ::Types<int8_t, uint8_t, int16_t, uint16_t, int32_t, > uint32_t, int64_t, uint64_t > #if defined(__clang__) && __clang_major__ >= 11 > , __int128_t, __uint128_t > , signed _ExtInt(200) > , unsigned _ExtInt(200) > #endif > >; > > https://godbolt.org/z/GfMfWEz88 Seems to work for a number of compilers. This is not only a compiler feature, it also should be supported by the target architecture: https://godbolt.org/z/ddjYYx9x6 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86465/new/ https://reviews.llvm.org/D86465 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
