GCC rejects constexpr operations on cpp_int (> double_limb_type) initialized from a double_limb_type integer

[marcoffee]

Currently, gcc is rejecting to compile constexpr operations on fixed cpp_ints wider than double_limb_type. It says that the current initialized field is m_double_first_limb, even after we initialize m_data:

Here

multiprecision/include/boost/multiprecision/cpp_int.hpp

Lines 583 to 588 in df89bfd

	constexpr data_type(double_limb_type i) : m_double_first_limb(i)
	{
	#ifndef BOOST_MP_NO_CONSTEXPR_DETECTION
	if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb))
	{
	data_type t(static_cast<limb_type>(i & max_limb_value), static_cast<limb_type>(i >> limb_bits));

And here

multiprecision/include/boost/multiprecision/cpp_int.hpp

Lines 776 to 781 in df89bfd

	constexpr data_type(double_limb_type i) : m_double_first_limb(i)
	{
	#ifndef BOOST_MP_NO_CONSTEXPR_DETECTION
	if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb))
	{
	data_type t(static_cast<limb_type>(i & max_limb_value), static_cast<limb_type>(i >> limb_bits));

There's also this one, but it will only be an issue with constexpr dynamic allocations, I can fix it here or I can fix it at my PR #654. I also think the BOOST_MP_ENDIAN_LITTLE_BYTE check will not be needed anymore as the split will be explicit as in the other cases

multiprecision/include/boost/multiprecision/cpp_int.hpp

Lines 231 to 235 in df89bfd

	#if BOOST_MP_ENDIAN_LITTLE_BYTE
	constexpr data_type(double_limb_type i) noexcept : double_first(i)
	{}
	constexpr data_type(signed_double_limb_type i) noexcept : double_first(static_cast<double_limb_type>(boost::multiprecision::detail::unsigned_abs(i))) {}
	#endif

Below is a minimal reproducible example

#include <boost/multiprecision/cpp_int.hpp>


template <int Bits>
inline constexpr auto repro = [] constexpr noexcept {
  namespace mp = boost::multiprecision;

  using ubits_t = mp::number<
    mp::cpp_int_backend<Bits, Bits, mp::unsigned_magnitude, mp::unchecked, void>,
    // also happens for mp::et_on
    mp::et_off
  >;

  ubits_t x = static_cast<unsigned __int128>(0);
  // ubits_t x = 0U;  // does not fail

  // x *= x;  // multiplication also fails
  x += x;
  return x;
}();

// DOES NOT FAIL
// static_assert(repro<128> == 0);

// FAIL
static_assert(repro<129> == 0);
// static_assert(repro<192> == 0);
// static_assert(repro<512> == 0);

Here's a link to compiler explorer. You can see that this is GCC only as clang works fine.

The solution is a simple change on how the cpp_ints are constructed on the m_double_first_limb (initialize m_data instead of m_double_first_limb on all cases). I can open a PR (with regression tests) if needed (I have a working version here that I used to locate the issue).

[jzmaddock]

Ugh, the whole point of that union is to support faster runtime initialization in the common cases.

I thought this had come up before somewhere and we had a workaround? @ckormanyos @mborland ?

[mborland]

I'm not sure of how to get around this prior to C++20 which allows the changing of an active member of a union inside a constexpr expression.

[marcoffee]

I made some tests to try to avoid full m_data initialization on runtime and it gets weirder:

Note 1: I know the codes that compile below do not properly initialize the union, I'm just testing the gcc compilation behavior.
Note 2: I omitted the #ifndef BOOST_MP_NO_CONSTEXPR_DETECTION/#endif to reduce the code blocks' heights. The behavior is the same with it.

1. If we completely remove the m_double_first_limb initialization/assignment, it compiles:

constexpr data_type(double_limb_type i)
{
   if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb))
   {
      data_type t(static_cast<limb_type>(i & max_limb_value), static_cast<limb_type>(i >> limb_bits));
      *this = t;
   }
}

2. If we add an else that initializes m_double_first_limb on runtime, it fails with the same previous error:

constexpr data_type(double_limb_type i)
{
   if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb))
   {
      data_type t(static_cast<limb_type>(i & max_limb_value), static_cast<limb_type>(i >> limb_bits));
      *this = t;
   }
   else
   {
      m_double_first_limb = i;
   }
}

3. If we add a throw inside that else block, it compiles again:

constexpr data_type(double_limb_type i)
{
   if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb))
   {
      data_type t(static_cast<limb_type>(i & max_limb_value), static_cast<limb_type>(i >> limb_bits));
      *this = t;
   }
   else
   {
      throw std::runtime_error("err");
      m_double_first_limb = i;
   }
}

The behavior is the same if we replace if (BOOST_MP_IS_CONST_EVALUATED(m_double_first_limb)) with if consteval.

It seems to me this issue is from gcc is trying to parse both contexts (consteval and non-consteval) and discarding the non-consteval case only if it fails (case 3) somehow (like assuming it as UB and optimizing it out, leaving it like case 1).

As a side note, the other constructors build m_data directly (see below), so the added cost of initializing it here would just place this constructor on par with the other ones. Also note that the current implementation (double_limb_type constructor) leaves the remaining limbs uninitialized, so a call for e.g. normalize would constitute UB due to uninitialized access.

multiprecision/include/boost/multiprecision/cpp_int.hpp

Lines 573 to 578 in df89bfd

	constexpr data_type()
	: m_data{0}
	{}
	constexpr data_type(limb_type i)
	: m_data{i}
	{}

Another valid reason to use m_data is that it makes the constructor a valid constexpr constructor on C++11 and above (it avoids relying on the C++20 rule that allows changing the active member of a union in a constant expression).

EDIT: I have submitted a gcc bug related to that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126483

[jzmaddock]

It gets weirder: we did fix this, and if we change the test case to this:

unsigned __int128 i128 = 0;
ubits_t x = i128;

Then everything compiles, it seems to be only unsigned __Int128 literals that are tripping things up. What's more if I construct from a literal and generate runtime code, I'm unable to observe in gdb which code path is being taken :(