rmaprath added a comment.

Looks like this patch breakes gcc builds of libunwind (none of the bots seem to 
test it though).

The problem is two-fold, in `src/config.h` we have:

  // Define static_assert() unless already defined by compiler.                 
                                                                                
                                                     
  #ifndef __has_feature
    #define __has_feature(__x) 0
  #endif
  #if !(__has_feature(cxx_static_assert)) && !defined(static_assert)
    #define static_assert(__b, __m) \
        extern int compile_time_assert_failed[ ( __b ) ? 1 : -1 ]  \
                                                    __attribute__( ( unused ) );
  #endif

This is not optimal for gcc when targeting `-std=c++11`, 
`!defined(static_assert)` will be false even though the `static_assert` keyword 
is present. We can easily fix this by checking for the `__cplusplus` version 
instead.

But there is still a problem for compilers that does not support the 
`static_assert` keyword, which has to resort to using this macro version of 
`static_assert(x,y)`. The problem here is that statements like:

  static_assert(check_fit<Registers_or1k, unw_context_t>::does_fit,
                  "or1k registers do not fit into unw_context_t");

Do not fit into that macro (it thinks we're passing three arguments to a macro 
that accepts only two - because of the additional comma in the template 
argument list). I don't see an easy way to address this other than reverting 
some of the work done in the previous patch.

Do many people care about building libunwind with a compiler that does not 
support `static_assert` keyword? If not, I'd prefer to let this slip and get 
rid of the `static_assert` macro definition.

Please shout!


http://reviews.llvm.org/D20119



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to