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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
