On Thu, 25 Mar 2021 at 11:38, Jonathan Wakely wrote:
> On 25/03/21 08:00 -0300, Alexandre Oliva wrote:
> >On Mar 24, 2021, Jonathan Wakely wrote:
> >
> >> Does vxworks provide any platform-specific source of randomness, like
> >> Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes,
On 25/03/21 11:57 +, Jonathan Wakely wrote:
On 25/03/21 07:17 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
This works for me on x86_64-linux and powerpc64le-linux, and also on
x86_64-linux when I kluge the config macros so that the new code path
gets used. Does th
On 25/03/21 07:17 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
This works for me on x86_64-linux and powerpc64le-linux, and also on
x86_64-linux when I kluge the config macros so that the new code path
gets used. Does this work for VxWorks?
Thanks. I (trivially) bac
On 25/03/21 08:03 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
diff --git a/libstdc++-v3/testsuite/util/testsuite_random.h
b/libstdc++-v3/testsuite/util/testsuite_random.h
index 0b670bfb771..c8323078492 100644
--- a/libstdc++-v3/testsuite/util/testsuite_random.h
+++ b
On 25/03/21 08:00 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
Does vxworks provide any platform-specific source of randomness, like
Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes, we
should add support for that (in the next stage 1).
There appears
On Mar 24, 2021, Jonathan Wakely wrote:
> diff --git a/libstdc++-v3/testsuite/util/testsuite_random.h
> b/libstdc++-v3/testsuite/util/testsuite_random.h
> index 0b670bfb771..c8323078492 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_random.h
> +++ b/libstdc++-v3/testsuite/util/testsuite_ra
On Mar 24, 2021, Jonathan Wakely wrote:
> Does vxworks provide any platform-specific source of randomness, like
> Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes, we
> should add support for that (in the next stage 1).
There appears to be a randNumGenCtl syscall that appears to
On Mar 24, 2021, Jonathan Wakely wrote:
> This works for me on x86_64-linux and powerpc64le-linux, and also on
> x86_64-linux when I kluge the config macros so that the new code path
> gets used. Does this work for VxWorks?
Thanks. I (trivially) backported it to apply on our gcc-10 tree, and
te
On 24/03/21 11:27 +, Jonathan Wakely wrote:
On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
If the default constructor throws then th
On 24/03/21 13:22 +, Koning, Paul via Libstdc++ wrote:
On Mar 24, 2021, at 4:59 AM, Jonathan Wakely via Gcc-patches
wrote:
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to hav
> On Mar 24, 2021, at 4:59 AM, Jonathan Wakely via Gcc-patches
> wrote:
>
> On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
>>
>> On target systems that don't support any random_device, not even the
>> default one,
>
> It should be impossible to have no random_device.
Not true; deeply embe
On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
If the default constructor throws then that suggests your target is
misconfigured. Why isn
On 24/03/21 08:59 +, Jonathan Wakely via Libstdc++ wrote:
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to have no random_device. As a fallback a
pseudo random number generator shou
On Mar 24, 2021, Jonathan Wakely wrote:
> It should be impossible to have no random_device. As a fallback a
> pseudo random number generator should be used.
> If the default constructor throws then that suggests your target is
> misconfigured. Why isn't the mt19937 PRNG being used?
This is an x
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
other random_device constructor tests are disable
On target systems that don't support any random_device, not even the
default one, other random_device constructor tests are disabled by
dg-require-effective-target random_device. The token.cc also
exercises the default constructor, in a way that doesn't expect an
exception to be raised, but it's
16 matches
Mail list logo
