Renaming vec_step in tree-vect-loop.c (to fix build on powerpc/clang)

[Segher Boessenkool]

On Sat, Jul 20, 2019 at 12:33:16PM -0400, David Edelsohn wrote:
> On Sat, Jul 20, 2019 at 2:39 AM Gerald Pfeifer <gerald@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