freebsd13+clang+openmp bug in dlpolyselect
This seemingly happens only on freebsd 13.0, and might lead to sporadic failures. The fact that it failed for full_p30_JL is just because full_p30_JL uses
dlpolyselect many times, and it seems that the failure probability is in the whereabouts of 1 in 50, which doesn't make it trivial to reproduce.
Commit 7c646142 is sweeping things under the rug, but I'm still hesitant as to whether this kind of thing could be worth investigating. It might be a bug that we can hardly do anything about, but it could as well be our fault.
To reproduce (assuming you have all sorts of things installed, such as docker, kvm, and such, and that you're in the proper unix group):
git clone firstname.lastname@example.org:cado-nfs/cado-nfs cd cado-nfs git submodule update --init --remote --recursive make -C /tmp/cado-nfs/ci/utilities/tanker/ ci/debug.sh "checks on freebsd13.0 system with clang" # (takes a few minutes!) export CC=clang CXX=clang++ CFLAGS="-O0 -g -W -Wall -std=c11" CXXFLAGS="-O0 -g -W -Wall -std=c++11" export force_build_tree=/tmp/build eval $(gmake show) gmake cmake gmake -j2 dlpolyselect while gdb -ex r -ex q --args $build_tree/polyselect/dlpolyselect -N 701173953068971112417987441927 -easySM 350586976534485556208993720963 -df 3 -dg 2 -area 367001600.0 -Bf 2048.0 -Bg 4096.0 -bound 3 -modm 5 -modr 0 -t 2 ; do : ; done
(getting out of this crazy loop is a bit tricky, but from gdb you can do do
shell mv (path to dlpolyselect) (path to dlpolyselect).moved)
I've tried a few things that could help alleviate the problem, but at the moment none worked. Well, taking out the schedule(dynamic) in the main for loop does, but that isn't a satisfactory answer.