<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 23, 2014 at 9:26 AM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@bugseng.com" target="_blank">abramo.bagnara@bugseng.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In r205915 you've added to ThreadSafetyTIL.h a mechanism to avoid<br>
explicit delete for SExpr, but this break compilation with REQUIRES_EH=1<br>
as shown below:<br>
<br>
$ make VERBOSE=1 REQUIRES_EH=1<br>
llvm[0]: Compiling ThreadSafety.cpp for Debug+Asserts build<br>
if  g++ -Illvm-r206978-build/include<br>
-Illvm-r206978-build/tools/clang/lib/Analysis -Illvm-r206978/include<br>
-Illvm-r206978/tools/clang/lib/Analysis  -D_DEBUG -D_GNU_SOURCE<br>
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS<br>
-Illvm-r206978/tools/clang/lib/Analysis/../../include<br>
-Illvm-r206978-build/tools/clang/lib/Analysis/../../include -g<br>
-std=c++11 -fvisibility-inlines-hidden -fPIC -Woverloaded-virtual<br>
-ffunction-sections -fdata-sections -Wcast-qual -fno-strict-aliasing<br>
-pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings<br>
-I/home/abramo/eclair_cplusplus/deps/traps/include<br>
-Wno-maybe-uninitialized -Wno-missing-field-initializers -c -MMD -MP -MF<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp"<br>
-MT<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.o"<br>
-MT<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d"<br>
llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp -o<br>
llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.o ; \<br>
                then /bin/mv -f<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp"<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d";<br>
else /bin/rm<br>
"llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp";<br>
exit 1; fi<br>
In file included from<br>
llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp:25:0:<br>
llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTIL.h:<br>
In member function ‘clang::threadSafety::til::SExpr*<br>
clang::threadSafety::til::CopyReducer::reduceUndefined(clang::threadSafety::til::Undefined&)’:<br>
llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTIL.h:120:8:<br>
error: ‘static void clang::threadSafety::til::SExpr::operator<br>
delete(void*)’ is private<br>
   void operator delete(void *) LLVM_DELETED_FUNCTION;<br>
        ^<br>
In file included from<br>
llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp:26:0:<br>
llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTraverse.h:127:38:<br>
error: within this context<br>
     return new (Arena) Undefined(Orig);<br>
                                      ^<br>
... and many others.<br>
<br>
I don't think this is expected: what do you think about to remove the<br>
private deleted operator delete? Are there better way to fix that?</blockquote><div><br></div><div>This looks like a GCC bug; it shouldn't be checking accessibility on this 'operator delete' here, as far as I can see. The simplest fix is to make the 'operator delete' public -- it's already marked LLVM_DELETED_FUNCTION, and that's sufficient to stop these objects getting accidentally deleted.</div>
</div></div></div>