Linear congruential generator produces different values than gcc and msvc

[llvmbot]

Bugzilla Link	34206
Version	5.0
OS	MacOS X
Attachments	linear_congruential_engine test
Reporter	LLVM Bugzilla Contributor
CC	@mclow

Extended Description

To my understanding the C++ standard does not mandate the algorithms for random number distributions but it does mandate the algorithms for random number generators like linear_congruential_engine. So one should be able to generate consistent random values across all platforms/compilers.

However, i stumbled upon inconsistent values between various compilers and verified this observation with online compilers. I am not sure which compiler is right, but at least gcc and msvc agree on their results.

Please find attached a code snippet to reproduce the observed behavior.

I put this code snippet into Rextester:

http://rextester.com/l/cpp_online_compiler_gcc (g++ 5.4.0)
http://rextester.com/l/cpp_online_compiler_clang (clang 3.8.0)
http://rextester.com/l/cpp_online_compiler_visual (Microsoft 19.00.23506 for x86)

Output:

25214903928 206026503483683 245470556921330 (gcc)
25214903928 18444698300399350051 8295313034219953650 (clang)
25214903928 206026503483683 245470556921330 (msvc)

I also put this code snippet into a Compiler Explorer project. It illustrates that Clang 3.8 and Clang trunk produce exactly the same code/values.

https://godbolt.org/g/rBSjaS

A possibly somehow related issue:

#28213

[jwakely]

The gzipped attachment is a small code snippet which might as well be pasted inline here:

#include <random>
#include <iostream>

int main()
{
  std::linear_congruential_engine<std::uint_fast64_t, 0x5DEECE66Dull, 0xBull, 1ull << 48> gen;

  for (int n=0; n<3; ++n)
    std::cout << gen() << ' ';
}

[LRFLEW]

It looks like this specific instance of std::linear_congruential_engine returning the wrong values might have been fixed with LLVM 12. https://godbolt.org/z/vjr8MPWKW I've had issues checking libc++ with Godbolt in the past, so I'm not certain if this is 100% accurate, but I can't replicate the issue locally either.

[LRFLEW]

I found another example where libc++ produces the wrong values:

#include <random>
#include <iostream>

int main()
{
    std::linear_congruential_engine<std::uint64_t, 0x18000001ull, 0x12347ull, 3ull << 56> gen;

    for (int n=0; n<3; ++n)
        std::cout << gen() << ' ';
    std::cout << std::endl;

    return 0;
}

https://godbolt.org/z/8Ma5nE1hf

The third output value onwards differs in libc++ due to integer overflow. This example should be fixed in #81080.

[jwakely]

Edit: I'm just repeating what the comment above already says, so removed.

[jwakely]

Oh, I've just realised who @LRFLEW is 😹

[LRFLEW]

Edit: I'm just repeating what the comment above already says, so removed.

I looked at the original comment, and it was different enough that it's still worth mentioning. For the record the comment brought up that this construction also gives incorrect values in libc++: std::linear_congruential_engine<unsigned long long int, 864691128455135232ULL, 12347ULL, 4052555153018976267ULL>.

This is slightly different from the example I gave above in terms of why libc++ is giving the wrong result. The example in my previous comment was caused by libc++ recognizing it could use Schrage's algorithm, but incorrectly thinking it didn't need to. This example is caused by libc++ recognizing that Schrage's algorithm cannot be used here, but due to a broken static assert, ends up using the standard (ax+c)%m implementation, which produces the wrong results due to integer overflow. Both of these are addressed in #81080, though the latter simply will refuse to compile. Getting that to compile should probably be its own PR, though.

And yes @jwakely, I figured it was you from the GCC bug report because of your username. I ended up here because the mention of #28213 caused me to realize that issue was supposedly fixed, and looking into how it was addressed led me to finding the problems I'm addressing with #81080.