require et random_device for cons token test

[Jonathan Wakely]

On 24/03/21 08:59 +0000, 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 should be used.
>
>>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 not guarded by the same requirement.
>>
>>Other potentially-raising ctors in token.cc expect exceptions and
>>handle them, but the ("default")-constructed one does not, so the
>>program terminates and the test fails without exercising the other
>>constructor variants.
>
>Why does the "default" token cause an exception?
>
>>This patch arranges to disable the test altogether when the
>>random_device feature is not available.  A reasonable alternative
>>would be to install a std::runtime_error handler around the test01
>>body, so that we exercise at least the exception raising, but then
>>test03 would have to be relaxed, since without even "default", it
>>likely wouldn't meet the tested requirement there.
>>
>>Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
>>with other patches, mostly for the testsuite.  Ok to install?
>
>No, that would disable the test for Windows, where it works OK.
>
>The 'random_device' effective-target is poorly named, it checks
>whether the _GLIBCXX_USE_RANDOM_TR1 macro is defined, which is even
>more poorly named. That macro is defined when /dev/random and
>/dev/urandom are available. But we support std::random_device without
>those files (e.g. on Windows).

And that macro is defined according to the same conditions as
_GLIBCXX_USE_DEV_RANDOM which is tested via #ifdef in cons/token.cc.
So the test already guards the parts that should depend on the
_GLIBCXX_USE_RANDOM_TR1 macro. Everything else in the test *should*
work unconditionally. In theory. We should find out why they don't
(and probably fix the library code, not disable the test).

Several of the other tests in that directory should *not* require that
effective-target. They should now work unconditionally too.

Tangentially, it would also be good to improve the definition of the
effective-target so it is true for Windows and other targets that are
guaranteed to have a useful (non-pseudo RNG) std::random_device.