[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #7 from Martin Liška --- (In reply to Andrew Pinski from comment #6) > I ran with =31 on aarch64 and ref was working. Maybe it is only test input > is a problem. I can confirm that, ref.pl is fine. It doesn't call fork (breakpoint at fork is never triggered).
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #6 from Andrew Pinski --- I ran with =31 on aarch64 and ref was working. Maybe it is only test input is a problem.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Martin Liška --- It's about a fork being called after a loop, where one threadsleaves gomp_simple_barrier_wait (>threads_dock) and runs the folk. Other threads have't cross the wait barrier. Jakub?
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #4 from rguenther at suse dot de --- On Wed, 1 Feb 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 > > Martin Liška changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #3 from Martin Liška --- > May I close it as invalid? Well, why did we parallelize a loop with a fork() call?
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- May I close it as invalid?
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #2 from Martin Liška --- And running with OMP_NUM_LIMIT=1 works fine.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Well, it's not GCC 7 regression, problem is that we generate a GOMP_parallel. After it's done, the main thread is going to do fork/exec: #0 __libc_fork () at ../sysdeps/nptl/fork.c:49 #1 0x004ef765 in Perl_my_fork () at util.c:2303 #2 0x004915f6 in Perl_pp_fork () at pp_sys.c:4009 #3 0x004acccd in Perl_runops_standard () at run.c:37 #4 0x00445f28 in S_run_body (oldscope=1) at perl.c:2017 #5 perl_run (my_perl=) at perl.c:1934 #6 0x004034a2 in main (argc=4, argv=0x7fffdb88, env=) at perlmain.c:98 (gdb) info threads Id Target Id Frame * 1Thread 0x77fae780 (LWP 3579) "perlbench_base." __libc_fork () at ../sysdeps/nptl/fork.c:49 2Thread 0x770e6700 (LWP 3583) "perlbench_base." do_spin (val=8, addr=0x77e044) at ../../../libgomp/config/linux/wait.h:56 3Thread 0x768e5700 (LWP 3584) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 4Thread 0x760e4700 (LWP 3585) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 and that's why the other threads will not reach the barrier.
