[PATCH] libstdc++: Fix up all_pedantic_errors.cc [PR119739]

[Nathan Myers]

On 12/17/25 3:10 AM, Jakub Jelinek wrote:
> On Wed, Dec 17, 2025 at 07:55:01AM +0100, Jakub Jelinek wrote:
>> Because we don't have unsigned _BitInt(128) in C++ right now, I'm afraid you
>> want some unsigned __int128 like class for #ifndef __SIZEOF_INT128__ which
>> will handle all the operations you need on a pair of unsigned long long.

I had thought "#if defined (SIZEOF_INT128__)" would gate any
mention of __int128. Is it that this symbol is defined where
C code may use that type, even though C++ code cannot?

> Though, I wonder if you really need unsigned __int128 type for 32-bit
> hosts (if __generate_canonical_pow2/any are copied/edited for the
> 128-bit cases.
> 
> Without 128-bit integral type, I think you don't need to worry about
> __log2_R > 64, because simply there is no such unsigned integral type to
> hold it.

Correct... But we still want it to work for the > 64 case, in
cases where we do finally get a 128-bit integer type.

> So
>    constexpr _RealT __Rk = _RealT(_UInt(1) << (__log2_Rk - 1)) * 2.0;
> can be done in that case even using unsigned long long type.

Shifting uint64_t(1) left 64 places, as would occur for
__d == 64 and _RealT=long double (with its 64-bit mantissa)
is UB and ill-formed in constexpr context...

> (Though I wonder if it shouldn't be _RealT(2.0) instead of 2.0).

Maybe?

> I'd hope that
>        const _UInt __x = _UInt(1) << __log2_x;
> and
>            _UInt __sum = _UInt(__urng() - _Urbg::min());
> can be still done in unsigned long long type as well for similar reasons.

> Only the
>            for (unsigned __i = __k - 1, __shift = 0; __i > 0; --__i)
>              {
>                __shift += __log2_R;
>                __sum |= _UInt(__urng() - _Urbg::min()) << __shift;
>              }
>            const _RealT __ret = _RealT(__sum >> __log2_x) / __rd;
> part is problematic, but can't that be handled by hand with a pair of
> unsigned long long __sums?  Of course one can't convert to _RealT in
> that case from the pair but needs to be done from the MS half, multiply
> by some precomputed constant and add the LS half.

Emulating 128-bit integer operations seems like heroics unless C++
is not expected ever to get __int128. The intention was to support
128-bit floating-point formats, with mantissa >= 106 bits, in places
where users have them. Does it seem likely a quad-precision floating
point type would be implemented, but not __int128?