aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/CloneFunction.cpp
diff options
context:
space:
mode:
authorNico Weber <nicolasweber@gmx.de>2015-08-06 19:21:25 +0000
committerNico Weber <nicolasweber@gmx.de>2015-08-06 19:21:25 +0000
commit28dc4171e90f516cf06e5c517d89e2e03c5386e8 (patch)
tree91d205e89669764bc1fa3de2b45d65082162fb9d /llvm/lib/Transforms/Utils/CloneFunction.cpp
parent242ca930e8f1ac6f4300b068d1a5c590a74714da (diff)
downloadllvm-28dc4171e90f516cf06e5c517d89e2e03c5386e8.zip
llvm-28dc4171e90f516cf06e5c517d89e2e03c5386e8.tar.gz
llvm-28dc4171e90f516cf06e5c517d89e2e03c5386e8.tar.bz2
Fix nested CrashRecoveryContexts with LLVM_ENABLE_THREADS=OFF, allow them.
libclang uses a CrashRecoveryContext, and building a module does too. If a module gets built through libclang, nested CrashRecoveryContexts are used. They work fine with threads as things are stored in ThreadLocal variables, but in LLVM_ENABLE_THREADS=OFF builds the two recovery contexts would write to the same globals. To fix, keep active CrashRecoveryContextImpls in a list and have the global point to the innermost one, and do something similar for tlIsRecoveringFromCrash. Necessary (but not sufficient) for PR11974 and PR20325 http://reviews.llvm.org/D11770 llvm-svn: 244251
Diffstat (limited to 'llvm/lib/Transforms/Utils/CloneFunction.cpp')
0 files changed, 0 insertions, 0 deletions