require et random_device for cons token test

[Jonathan Wakely]

On 24/03/21 11:27 +0000, Jonathan Wakely wrote:
>On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
>>On Mar 24, 2021, Jonathan Wakely <jwakely@redhat.com> 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 x86_64-vx7r2 target, it has USE_RDRAND and USE_RDSEED both
>>enabled as the only RAND backends.  AFAICT both of them fail their cpuid
>>tests, so _M_init falls through to the default, and throws.
>>
>>I suppose we need to cover the case in which all of the compile-time
>>presumed-available random backends turn out to not be available at
>>run-time, and introduce an MT19937 dynamic fallback in the following
>>default: block, no?
>
>Hmm, that would be tricky because it's currently a static decision
>made during preprocessing. We have no disciminator to tell us at
>runtime that the _M_mt member of the union is active:
>
>    union
>    {
>      struct
>      {
>	void*      _M_file;
>	result_type (*_M_func)(void*);
>	int _M_fd;
>      };
>      mt19937    _M_mt;
>    };
>
>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).
>
>But even if it does, we should still have a dynamic fallback at
>runtime. I have a patch coming to do that ...

Attached (the patch is generated with -b to ignore changes in
whitespace, for ease of reading the diff).

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?

The problem this fixes is a regression. Before GCC 10 VxWorks would
have always used the mt19937 code. Now it tries to use rdrand/rdseed
instructions and fails if the hardware doesn't have them. This patch
should make it work again (using a different PRNG, and a crappy seed
but that's still better than mt19937 with the same seed every time).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 13122 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20210324/cd3d961c/attachment-0001.bin>