added CMake option USE_INT128 and support built-in __int128 / some compilation fixes

[firewave]

No description provided.

[firewave]

See also #7833 (comment).

Using __int128 it almost fully builds except for the requirement on ValueFlow::Value::equalTo() (suggestions on how to address it in this PR are welcome). The conversion to string for actual 128-bit values does not exist yet but this already exposes overflow issues in the existing code.

[firewave]

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).

[danmar]

hmm.. how about:

VALUEFLOW_INT128=no
VALUEFLOW_INT128=gcc
VALUEFLOW_INT128=boost

?

[firewave]

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.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

The conversion to string for actual 128-bit values does not exist yet but this already exposes overflow issues in the existing code.

I filed https://trac.cppcheck.net/ticket/14154 about that.

[pfultz2]

#7658 should be merged first before this pr. This adds another flag that needs to be added every where. #7658 already fixes that so this PR should be based on # 7658.

[firewave]

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.)