https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64177
Bug ID: 64177
Summary: Various cilk+ testsuite failures
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Over the last 2 weeks, I've seen many Cilk+ test hangs (across various
x86_64-linux and i686-linux regtests), grepping the test_summary outputs
reveals:
FAIL: c-c++-common/cilk-plus/CK/fib.c -O1 execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c -O2 -std=c99 execution
test
FAIL: c-c++-common/cilk-plus/CK/fib.c -g execution test
FAIL: g++.dg/cilk-plus/CK/for1.cc -g -O2 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -g -O2 execution test
FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g execution test
FAIL: g++.dg/cilk-plus/CK/fib-opr-overload.cc -O1 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c -O1 execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 -flto -g execution test
FAIL: c-c++-common/cilk-plus/CK/spawning_arg.c -O3 -g execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c -O1 execution test
FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g execution test
FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c -g execution test
FAIL: c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c -O3 execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 execution test
FAIL: c-c++-common/cilk-plus/CK/spawner_inline.c -O3 execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O3 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/CK/fib.c -g execution test
FAIL: c-c++-common/cilk-plus/CK/steal_check.c -O2 -std=c99 execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O2 -ftree-vectorize execution
test
FAIL: c-c++-common/cilk-plus/CK/spawning_arg.c -O1 execution test
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c -O1 execution test
This is on a i7-5960X CPU, i.e. 8 core, 16 threads, but usually happens only
when the system is under high load (make -j16 toplevel check).
I've managed to (after about 30 iterations) reproduce steal_check.c hang, and
in that case it seems the Cilk+ runtime decided to schedule foo in the initial
thread (the one which called main2), so obviously it then busy loops forever
until killed, because the test relies on foo being run in a different thread
from the initial thread. From what I've browsed on the web, seems _Cilk_spawn
doesn't guarantee that the function is executed in a different thread, so it
looks invalid to me (not to mention that it doesn't use any proper barriers in
the busy waiting loop, so at least on non-i?86/x86_64 CPUs I'd say it would
fail miserably very often). The question is if the other tests I saw failing
are also bugy, or if there are races in the library.
I'm using 3.17.4-300.fc21.x86_64 kernel (if that matters).
