Build failure using REQUIRES_EH=1 after r205915

[Aaron Ballman]

On Wed, Apr 23, 2014 at 12:26 PM, Abramo Bagnara
<abramo.bagnara at bugseng.com> wrote:
> In r205915 you've added to ThreadSafetyTIL.h a mechanism to avoid
> explicit delete for SExpr, but this break compilation with REQUIRES_EH=1
> as shown below:
>
> $ make VERBOSE=1 REQUIRES_EH=1
> llvm[0]: Compiling ThreadSafety.cpp for Debug+Asserts build
> if  g++ -Illvm-r206978-build/include
> -Illvm-r206978-build/tools/clang/lib/Analysis -Illvm-r206978/include
> -Illvm-r206978/tools/clang/lib/Analysis  -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Illvm-r206978/tools/clang/lib/Analysis/../../include
> -Illvm-r206978-build/tools/clang/lib/Analysis/../../include -g
> -std=c++11 -fvisibility-inlines-hidden -fPIC -Woverloaded-virtual
> -ffunction-sections -fdata-sections -Wcast-qual -fno-strict-aliasing
> -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings
> -I/home/abramo/eclair_cplusplus/deps/traps/include
> -Wno-maybe-uninitialized -Wno-missing-field-initializers -c -MMD -MP -MF
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp"
> -MT
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.o"
> -MT
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d"
> llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp -o
> llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.o ; \
>                 then /bin/mv -f
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp"
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d";
> else /bin/rm
> "llvm-r206978-build/tools/clang/lib/Analysis/Debug+Asserts/ThreadSafety.d.tmp";
> exit 1; fi
> In file included from
> llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp:25:0:
> llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTIL.h:
> In member function ‘clang::threadSafety::til::SExpr*
> clang::threadSafety::til::CopyReducer::reduceUndefined(clang::threadSafety::til::Undefined&)’:
> llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTIL.h:120:8:
> error: ‘static void clang::threadSafety::til::SExpr::operator
> delete(void*)’ is private
>    void operator delete(void *) LLVM_DELETED_FUNCTION;
>         ^
> In file included from
> llvm-r206978/tools/clang/lib/Analysis/ThreadSafety.cpp:26:0:
> llvm-r206978/tools/clang/lib/Analysis/../../include/clang/Analysis/Analyses/ThreadSafetyTraverse.h:127:38:
> error: within this context
>      return new (Arena) Undefined(Orig);
>                                       ^
> ... and many others.
>
> I don't think this is expected: what do you think about to remove the
> private deleted operator delete? Are there better way to fix that?

The operator delete was deleted purposefully as it is not meant to be
called (all SExpr objects must be created within an arena using a
placement new operator, and so they should never be deleted
explicitly). The fact that operator delete is attempting to be used is
the true problem; were it to be called successfully, then a
double-free would occur when the arena was destroyed. So adding the
operator delete back simply trades a compile error for a subtle (but
unlikely to be triggered) bug.

~Aaron