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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Gerald Pfeifer
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?

Thanks,
Gerald
Reply | Threaded
Open this post in threaded view
|

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

Richard Sandiford-9
Gerald Pfeifer <[hidden email]> writes:

> 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?

Would it work to #define vec_step to vec_step_ or something on affected
hosts, say in system.h?

I'd prefer that to renmaing since "vec_step" does seem the most natural
name for the variable.  The equivalent scalar variable is "step" and
other vector values in the surrounding code also use the "vec_" prefix.

Thanks,
Richard
Reply | Threaded
Open this post in threaded view
|

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

David Edelsohn-2
In reply to this post by Gerald Pfeifer
On Sat, Jul 20, 2019 at 2:39 AM Gerald Pfeifer <[hidden email]> 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?

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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