https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473
--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> --- (In reply to Rimvydas (RJ) from comment #0) > Created attachment 39550 [details] > changes to tests > > Native configuration is x86_64-unknown-dragonfly4.7 > > r239356 Replace KISS PRNG with xorshift1024* using per-thread state > caused all execution failures for: > FAIL: gfortran.dg/random_7.f90 -O0 execution test > FAIL: gfortran.fortran-torture/execute/random_1.f90 execution, -O0 > > r239611 Always initialize PRNG using random data from the OS > added: > FAIL: gfortran.dg/random_4.f90 -O0 execution test > > Adding prints for seed and check arrays before comparison shows that they > differ: > ./random_4.x > seed 42 42 42 42 42 > 42 42 42 42 42 42 42 > 42 42 42 42 42 42 42 > 42 42 42 42 42 42 42 > 42 42 42 42 42 42 0 > check -2110421118 -1194805269 1415242221 54534463 1225148040 > 821055102 -1530405947 -1820502322 2146652427 -147906310 -1761641582 > -1622508139 2006260459 151764285 -1191598697 -239551325 -1064082961 > 2093503284 1165045647 -1200385605 -867398903 -830236747 846618033 > 706688103 1954790377 859476278 -1696051309 -1413451556 -1779817981 > 1071423788 1556108935 1966576166 0 > > If -pthread is explicitly used for those tests (attachment) only failure > left is gfortran.dg/graphite/pr68279.f90 pr71348 > (execute/random_1.f90 still fails in testsuite - doesn't take -pthread flag) > > Should libgfortran.so always bring in libpthread.so or new PRNG could be > changed to have deterministic behavior with or without -pthread on DragonFly? I don't know about DragonflyBSD, but at least on Linux the idea is that if a thread library is not linked in, the various thread functions are stubbed out, allowing us to support both single-threaded usage without the overhead of mutexes etc. and multi-threaded usage without needing multiple library builds. This relies on weak symbols and such fancy linker tricks. If the Dragonfly linker doesn't have such features, I suspect you need to either always link in libpthread, or have separate builds for single-threaded and multi-threaded usage? But this is not something new introduced with the new random algorithm, it has been used since the beginning (which is one reason we use the __ghthread_* functions instead of the pthreads API directly). What hasn't been used in libgfortran before is the usage of __gthread_active_p() to check whether threads are linked in or not at runtime. But again, this is not something new, it has been used at least in libstdc++ before. So, do all the libstdc++ tests pass on Dragonfly? If not, perhaps there is something wrong with __ghtread_active_p() on DragonflyBSD?