[llvm-bugs] [Bug 24769] New: clang-3.7: OpenMP corrupts C++11 lambda captures?

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24769

            Bug ID: 24769
           Summary: clang-3.7: OpenMP corrupts C++11 lambda captures?
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Clang Compiler Support
          Assignee: unassignedclangbugs at nondot.org
          Reporter: zerolo at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14863
  --> https://llvm.org/bugs/attachment.cgi?id=14863&action=edit
Repo. Compile with "-fopenmp -std=c++11".

When using OpenMP directives around a C++11 lambda, the captures of that lambda
suddenly refer to invalid / corrupt data.

The attached example contains a templated function taking a functor / lambda.
That lambda is executed on a single thread while all other threads are blocked
in the function.
With clang + openmp, the variable / reference captures within that lambda refer
to bogus data, at least that's what it looks like.

After compiling the attached example with
> clang++ -fopenmp -std=c++11 clang_omp_repo.cpp
The output looks like this
> ./a.out 
[before parallel] &shared: 0x7fff9ec106c0
[inside lambda] &shared: 0x7fff9ec10218
^ the shared variable inside the lambda has a different address, this shouldn't
be
[inside lambda] -1631518096: shared: -1631516992 (should be 32767)
^ the captured thread index and numThreads are bogus values as well
[before lambda] 0: shared: 9 (should be <= 8)
^ because the lambda referred to a different place, the "real" shared wasn't
reset
[before lambda] 7: shared: 10 (should be <= 8)
[before lambda] 3: shared: 11 (should be <= 8)
[before lambda] 6: shared: 15 (should be <= 8)
[before lambda] 2: shared: 12 (should be <= 8)
[before lambda] 5: shared: 16 (should be <= 8)
[before lambda] 1: shared: 13 (should be <= 8)
[before lambda] 4: shared: 14 (should be <= 8)
[inside lambda] &shared: 0x7fff9ec10218
[inside lambda] -1631518096: shared: -1631516992 (should be 32767)
[after parallel] shared: 16 (should be 0)


The same code works fine on g++-4.9.2 or Intel Compiler 15.0.2.

Version info:
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation:
/home_as/shared/arbeitsgruppen/digitalx/installs/gcc/4.9.2/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.2
Selected GCC installation:
/home_as/shared/arbeitsgruppen/digitalx/installs/gcc/4.9.2/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.2
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150910/23a00ea3/attachment.html>