[PATCH] D20119: [libunwind] Improve unwinder stack usage

[Asiri Rathnayake via cfe-commits]

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