added CMake option USE_INT128 and support built-in __int128 / some compilation fixes
#7840
Conversation
|
See also #7833 (comment). Using |
cmake/compilerDefinitions.cmake
Outdated
| if(USE_INT128 AND USE_BOOST_INT128) | ||
| add_definitions(-DHAVE_BOOST_INT128) | ||
| endif() |
There was a problem hiding this comment.
I think the logic around USE_BOOST_INT128 is flawed . On is supposed to force the usage of Boost and Auto should provide a fallback to Boost if no built-in type exists but Boost is enabled (i.e. Visual Studio).
There was a problem hiding this comment.
hmm.. how about:
VALUEFLOW_INT128=no
VALUEFLOW_INT128=gcc
VALUEFLOW_INT128=boost
?
There was a problem hiding this comment.
It would make sense to add Builtin and Boost as a configuration options and drop USE_BOOST_INT128 as a whole. That doesn't even require a deprecation since it is experimental and never fully worked.
firewave
force-pushed
the
i128
branch
11 times, most recently
from
9e1502e to
06d5a64
Compare
I filed https://trac.cppcheck.net/ticket/14154 about that. |
| // TODO: requires check fails with GCC using __int128 | ||
| template<class T, REQUIRES("T must be an arithmetic type", std::is_arithmetic<T> )> |
There was a problem hiding this comment.
I wonder if this is fixed in GCC 16.
From https://gcc.gnu.org/gcc-16/changes.html#libstdcxx:
For targets that support [128-bit integers](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html), std::is_integral<__int128> and similar traits are always true. Previously this was only the case when compiling with GNU dialects (-std=gnu++17, -std=gnu++14, etc.) and not with strict dialects (-std=c++17, etc.)
4aaa856 to
0cdb5c4
Compare
|
3 participants
No description provided.