[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD

[jb at gcc dot gnu.org]

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?