On Sat, Jul 20, 2019 at 12:33:16PM -0400, David Edelsohn wrote: > On Sat, Jul 20, 2019 at 2:39 AM Gerald Pfeifer <ger...@pfeifer.com> wrote: > > > > I have seen an increasing number of reports of GCC failing to > > build with clang on powerpc (on FreeBSD, though that's probably > > immaterial). > > > > Turns out that clang has vec_step as a reserved word on powerpc > > with AltiVec. > > > > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c. > > > > > > The best approach I can see is to rename vec_step. Before I prepare > > a patch: what alternate name/spelling would you prefer? > > vec_step is not defined in any of the PowerPC ABIs nor the Altivec > PEM/PIM. Clang is not using a namespace reserved to the compiler by > defining vec_step. The PowerPC maintainers in the Clang community are > not willing to rectify this?
The PIM defines vec_step, in 2.5.3, "Value for Adjusting Pointers". Why does clang enable the altivec extensions by default? That won't work very well, e.g. vec_step is in the user namespace normally. On GCC, you need to #include <altivec.h> to enable the extensions, as 2.6 in the PIM suggests. Clang has an altivec.h as well, but it seems to define vec_step elsewhere. This is probably a bug? GCC has /* This also accepts a type for its parameter, so it is not enough to #define vec_step to __builtin_vec_step. */ #define vec_step(x) __builtin_vec_step (* (__typeof__ (x) *) 0) so maybe clang should do something similar to handle this "interesting" syntax extension. Segher