http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750
--- Comment #14 from Seth Heeren <bugs at sehe dot nl> 2011-04-27 09:48:57 UTC
---
I just built a debian SID chroot and applied the diff to it's libstdc++6
(4.6.0-2), and tested your patch with the minimal.cpp from this bug report
patch -p1 < ~sehe/attachment.cgi?id=24108
patching file parallel/multiway_merge.h
patching file parallel/losertree.h
patching file parallel/par_loop.h
Hunk #1 succeeded at 91 with fuzz 1.
patching file parallel/quicksort.h
patching file parallel/random_shuffle.h
patching file parallel/multiway_mergesort.h
patching file parallel/partial_sum.h
g++-4.6 -g -O0 -fopenmp minimal.cpp -o minimal -save-temps
valgrind --leak-check=full ./minimal
==5960== LEAK SUMMARY:
==5960== definitely lost: 0 bytes in 0 blocks
==5960== indirectly lost: 0 bytes in 0 blocks
==5960== possibly lost: 456 bytes in 3 blocks
==5960== still reachable: 1,748 bytes in 3 blocks
==5960== suppressed: 0 bytes in 0 blocks
The allocation possibly lost are attributed to GOMP_parallel_start from
numeric:99).
Helgrind gives quite the array of possible data races. I don't know whether I
need to worry about them (as I don't know what kind of thread primitives GOMP
uses internally and if helgrind supports them).
If you want I can attach precompiled sources + val/helgrind outputs
