Message ID | 20200925090939.GC2131@tucnak |
---|---|
State | New |
Headers | show |
Series | powerpc, libcpp: Fix gcc build with clang on power8 [PR97163] | expand |
Hi! On Fri, Sep 25, 2020 at 11:09:39AM +0200, Jakub Jelinek wrote: > libcpp has two specialized altivec implementations of search_line_fast, > one for power8+ and the other one otherwise. > Both use __attribute__((altivec(vector))) and the GCC builtins rather than > altivec.h and the APIs from there, which is fine, but should be restricted > to when libcpp is built with GCC, so that it can be relied on. > The second elif is > #elif (GCC_VERSION >= 4005) && defined(__ALTIVEC__) && defined (__BIG_ENDIAN__) > and thus e.g. when built with clang it isn't picked, but the first one was > just guarded with > #elif defined(_ARCH_PWR8) && defined(__ALTIVEC__) > and so according to the bugreporter clang fails miserably on that. Yeah. This could be rewritten to use the more portable, more modern intrinsics, but that would need a lot of testing etc. Since the only thing this does is speed up the compiler a few percent, and nothing changes for a bootstrapped compiler (whatever the build compiler is), it is just fine. > PR bootstrap/97163 > * lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version > for GCC >= 4.5. Okay for trunk (and whatever backports you want of course, if any). Thanks! Segher
--- libcpp/lex.c.jj 2020-07-28 15:39:56.434118065 +0200 +++ libcpp/lex.c 2020-09-24 18:09:06.358207369 +0200 @@ -531,11 +531,11 @@ init_vectorized_lexer (void) search_line_fast = impl; } -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__) +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC__) /* A vection of the fast scanner using AltiVec vectorized byte compares and VSX unaligned loads (when VSX is available). This is otherwise - the same as the pre-GCC 5 version. */ + the same as the AltiVec version. */ ATTRIBUTE_NO_SANITIZE_UNDEFINED static const uchar *