[PATCH 2/3] libstdc++: Fix up std::generate_canonical for 32-bit arches

[Tomasz Kaminski]

On Wed, Dec 17, 2025 at 9:32 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Wed, 17 Dec 2025 at 20:26, Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > On Wed, Dec 17, 2025 at 07:50:16PM +0000, Jonathan Wakely wrote:
> > > --- a/libstdc++-v3/include/bits/random.tcc
> > > +++ b/libstdc++-v3/include/bits/random.tcc
> > > @@ -3522,10 +3522,9 @@ namespace __detail
> > >        // r = 2;  // Redundant, we only support radix 2.
> > >        using _Rng = decltype(_Urbg::max());
> > >        const _Rng __rng_range_less_1 = _Urbg::max() - _Urbg::min();
> > > -      const _UInt __uint_range_less_1 = ~_UInt(0);
> > >        // R = _UInt(__rng_range_less_1) + 1;  // May wrap to 0.
> > >        const auto __log2_R = __builtin_popcountg(__rng_range_less_1);
> > > -      const auto __log2_uint_max =
> __builtin_popcountg(__uint_range_less_1);
> > > +      const auto __log2_uint_max = __builtin_popcountg(~_UInt(0));
> >
> > I don't see how this can work.  __builtin_popcountg requires some
> integral
> > unsigned type, unsigned __int128 is fine, but __rand_uint128 struct is
> not.
>
> Hmm, good point. I wonder how it's compiling.
>
> > So, if you want to use something like popcount, then you need some
> > function template which for normal unsigned integrals will return
> > __builtin_popcountg on the argument and for struct __rand_uint128 will
> > return __builtin_popcountg(_M_hi) + __builtin_popcountg(_M_lo);
>
> Do we need popcount at all? Isn't it just sizeof(_UInt) * CHAR_BIT?
>
We already have __bit_widht in bit header,  and overload it for
__max_size_type,
so I think we should follow the suit for __rng_uint128 type.

>
>
> >
> > > @@ -3586,25 +3585,25 @@ namespace __detail
> > >      _RealT
> > >      __generate_canonical_any(_Urbg& __urng)
> > >      {
> > > -      static_assert(__d < __builtin_popcountg(~_UInt(0)));
> >
> > And if the above is changed, then this static_assert could stay.
> >
> >         Jakub
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20251217/2fcfba5b/attachment.htm>