https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85439
Bug ID: 85439
Summary: mt19937_64 producing unexpected result only in certain
configuration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foddex at foddex dot net
Target Milestone: ---
Created attachment 43967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43967&action=edit
Code mentioned in report
My sincere apologies if this doesn't belong here, I'm not a regular.
In my tests to establish STL's mersenne twister's reproducability, I have found
an interesting problem that I think is a bug in the libstdc++ runtime in Linux,
but I may be wrong.
I ran the attached code on the various platforms and compiler combinations:
LINUX:
- g++ version 7.3.1 20180130 (Red Hat 7.3.1-2) on Fedora 26 4.12.14-300
- clang++ version 4.0.1 (tags/RELEASE_401/final) on Fedora 26 4.12.14-300
- clang++ version 6.0.0 (tags/RELEASE_600/final) on Arch Linux 4.15.13-1
OSX:
- clang++ 9.1.0 Apple LLVM on High Sierra
WINDOWS:
- MSVC2017 15.6.6 on Windows 10
For g++ and clang++ the compilations options are identical on all platforms:
main.cpp -std=c++11
On MSVC a default solution was used.
The output on Linux is as follows:
32 bits gen, uint32_t: 3499211612
32 bits gen, uint64_t: 15028999435905310454
64 bits gen, uint32_t: 3379370269
64 bits gen, uint64_t: 14514284786278117030
32 bits gen, float: 0.814724
64 bits gen, float: 0.786821
32 bits gen, double: 0.135477
64 bits gen, double: 0.786821
The output of the clang++ on OS X and MSVC applications is as follows:
32 bits gen, uint32_t: 3499211612
32 bits gen, uint64_t: 15028999435905310454
64 bits gen, uint32_t: 4143361702
64 bits gen, uint64_t: 14514284786278117030
32 bits gen, float: 0.814724
64 bits gen, float: 0.786821
32 bits gen, double: 0.135477
64 bits gen, double: 0.786821
Note that the output only differs on the 3rd line.
Since MSVC and clang agree on all tests, and their implementations are
independent, I came to the conclusion it must be a bug in libstd++ on Linux.
