On 04/11/20 10:15 +, Jonathan Wakely wrote:
On 04/11/20 09:45 +0100, Stephan Bergmann via Libstdc++ wrote:
On 03/11/2020 23:25, Jonathan Wakely wrote:
On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote:
On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:
This extends th
On 04/11/20 09:45 +0100, Stephan Bergmann via Libstdc++ wrote:
On 03/11/2020 23:25, Jonathan Wakely wrote:
On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote:
On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:
This extends the fast path to also work when the URBG's range of
On Wed, 4 Nov 2020 at 10:46, Stephan Bergmann via Libstdc++
wrote:
> To me it looks like it boils down to disagreement between g++ and
> clang++ over
>
> > struct S { static constexpr int f() { return 0; } };
> > void f(S & s) { static_assert(s.f(), ""); }
>
> where I think Clang might be right in
On 03/11/2020 23:25, Jonathan Wakely wrote:
On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote:
On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:
This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Pre
On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote:
On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:
This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Previously,
the slow path would be used for engi
On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:
This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Previously,
the slow path would be used for engines with a uint_fast32_t result type
if that type is actually a
