Bug 49231 - #pragma omp parallel for never returns
Summary: #pragma omp parallel for never returns
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libgomp (show other bugs)
Version: 4.4.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-30 12:57 UTC by Parviz Fariborz
Modified: 2011-05-30 16:30 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
The attached file re-produces the probem that I have reported above (181 bytes, application/octet-stream)
2011-05-30 12:57 UTC, Parviz Fariborz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Parviz Fariborz 2011-05-30 12:57:57 UTC
Created attachment 24396 [details]
The attached file re-produces the probem that I have reported above

Hi,

The attached program when compiled using gcc 4.4.3 produces the following output and never returns :

...
===> Fpga: 865, Thread: 6
===> Fpga: 866, Thread: 6
===> Fpga: 867, Thread: 6
===> Fpga: 868, Thread: 6
===> Fpga: 869, Thread: 6
===> Fpga: 870, Thread: 6
===> Fpga: 871, Thread: 6
===> Fpga: 872, Thread: 6
===> Fpga: 873, Thread: 6
===> Fpga: 874, Thread: 6

I have to kill the process to make it exit. 

The same program when compiled using gcc 4.3.3 and run on the same machine works fine and produces the correct output.

I compile and run the program on a redhat 4 linux machine with the following specs:

mawhp2:/home/parvizf/tmp=> uname -a
Linux mawhp2 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

mawhp2:/home/parvizf/tmp=> cat /etc/redhat-release 
Red Hat Enterprise Linux WS release 4 (Nahant Update 8)

Thanks in advance for your help.
-Parviz
Comment 1 Jakub Jelinek 2011-05-30 13:15:49 UTC
Can't reproduce, tried gcc 4.4.5, 4.6 and 4.7, both -m32 and -m64, gcc and g++, and various options.
Comment 2 Parviz Fariborz 2011-05-30 15:11:16 UTC

-Parviz(In reply to comment #1)
> Can't reproduce, tried gcc 4.4.5, 4.6 and 4.7, both -m32 and -m64, gcc and g++,
> and various options.

The compile/link option -static seems to be significant in this case. The executable built with the following command :

/tools/linux64/gcc-4.4.3/bin/g++ -o omp -g -static -fopenmp -lgomp -lpthread -I/tools/linux64/gcc-4.4.3/include -L/usr/lib64 -L/tools/linux64/gcc-4.4.3/lib64 omp.cc

Do not work. When I remove the -static option, it does work. Any ideas?
Comment 3 Jakub Jelinek 2011-05-30 16:30:16 UTC
See http://www.akkadia.org/drepper/no_static_linking.html
If you still for whatever weird reason insist to link statically, for NPTL you need to -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
because if only some objects from libpthread are linked in, it can misbehave in various ways.  In RHEL6 libpthread.a contains just one object ld -r linked together the whole normal libpthread.a contents, but in upstream glibc as well as older RHEL versions (no idea about other distros) you need to link as
mentioned above.