Build failure using REQUIRES_EH=1 after r205915

[Abramo Bagnara]

Il 23/04/2014 20:16, Richard Smith ha scritto:
> On Wed, Apr 23, 2014 at 9:26 AM, Abramo Bagnara
> <abramo.bagnara at bugseng.com <mailto: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?
> 
> 
> 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.

It seems it is not a GCC bug.

I've commited your proposed change together with an explaining comment
in r207027.


-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com