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
