A bit off-topic, but std::random_device is not required to use a TRNG. Not all machines even have hardware generators (I know Intel added one a few years ago; I don't know if AMD has one), and of those that do not all OSs support them.
So an implementation that uses a PRNG behind std::random_device doesn't necessarily have anything to fix.
Unless GCC has finally fixed things <random>'s implementation of std::random_device is not truly random. std::random_device::entropy returns zero, indicating GCC is using a pseudo-random number engine.
GCC (or, to be precise, GNU libstdc++) always (at least going back to 2012 in github history) used the good random_device, implemented in terms of RDRAND and /dev/urandom, even though they didn't bother implementing the entropy method until 2017.
The only library I know of with PRNG random_device is MinGW
@Cubbi, Code::Blocks as one of the bundles, the MinGW bundle, includes the GCC/G++ compiler and GDB debugger from TDM-GCC.
@helios, I know it isn't a requirement to have a TRNG, though to me is seems a bit slapdash to be without. My opinion.
Just my opinion, not having one is a minor problem that should be looked at correcting.
Any code that I write that can use std::random_device checks to see if it a TRNG is there by checking the entropy, and run different code depending on the results.
Or just use a PRNG and "warm up" the sequencing by discarding a number of generated random numbers beforehand.
It is because of the variation in what features are implemented I still suggest using more than one IDE/compiler.