Re: [PATCH] Remove poly_int_pod

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/28/23 11:26, Jason Merrill wrote:
> On 9/28/23 05:55, Richard Sandiford wrote:
>> poly_int was written before the switch to C++11 and so couldn't
>> use explicit default constructors.  This led to an awkward split
>> between poly_int_pod and poly_int.  poly_int simply inherited from
>> poly_int_pod and added constructors, with the argumentless constructor
>> having an empty body.  But inheritance meant that poly_int had to
>> repeat the assignment operators from poly_int_pod (again, no C++11,
>> so no "using" to inherit base-class implementations).
>>
>> All that goes away if we switch to using default constructors.
>>
>> The main complication is ensuring that braced initialisation still
>> gives a constexpr, so that static variables can be initialised without
>> runtime code.  The two problems here are:
>>
>> (1) When initialising a poly_int<N, wide_int> with fewer than N
>>      coefficients, the other coefficients need to be a zero of
>>      the same precision as the explicit coefficients.  This was
>>      previously done in a for loop using wi::ints_for<...>::zero,
>>      but C++11 constexpr constructors can't have function bodies.
>>      The patch instead uses a series of delegated initialisers to
>>      fill in the implicit coefficients.
> 
> Perhaps it's time to update the bootstrap requirement to C++14 (i.e. GCC 
> 5, from eight years ago).  Not that this would affect this particular 
> patch.
IIRC the primary reason we settled on gcc-4.8.x was RHEL7/Centos7.  With 
RHEL 7 approaching EOL moving the baseline forward would seem to make sense.

I'd want to know if this affects folks using SuSE's enterprise distro 
before actually making the change, but I'm broadly in favor of moving 
forward it it's not going to have a major impact on users that are using 
enterprise distros.

jeff